[00:13] <oky> mwhudson: set it in the wrapper, right?
[00:14] <oky> or are you saying the it is set in the wrapper and its being unset
[00:14] <mwhudson> it's set in the environment that invokes snap but is unset inside the snap
[00:15] <mwhudson> http://paste.ubuntu.com/24371015/
[00:16] <mwhudson> i guess i should just file a bug
[01:38] <qengho> Hah ha ha. https://medium.com/@nusenu/is-this-a-ubuntu-based-botnet-deploying-tor-relays-and-bridges-b4ce1a612039
[07:05] <pstolowski> morning
[07:52] <mup> PR snapd#3173 closed: tests: add extra test after the core transition for snap get/set core <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3173>
[07:53] <zyga> pstolowski: hello
[07:54] <mup> PR snapd#3187 opened: interfaces/mount: improve go identifier names of mountinfo, parse optional fields <Created by zyga> <https://github.com/snapcore/snapd/pull/3187>
[07:54] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/3187
[07:54] <mup> PR snapd#3187: interfaces/mount: improve go identifier names of mountinfo, parse optional fields <Created by zyga> <https://github.com/snapcore/snapd/pull/3187>
[07:54] <zyga> pstolowski: follow-up from yesterday
[07:55] <pstolowski> zyga, ok
[07:56] <zyga> pstolowski: if you look at individual commits then the changes are easier to parse
[07:58] <zyga> morphis: hey, are you working today?
[08:10] <mup> PR snapd#3170 closed: interfaces/builting: allow read-only access to /sys/module <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3170>
[08:12] <mwhudson> zyga: two things
[08:12] <mwhudson> zyga: (1) https://forum.snapcraft.io/t/something-filters-out-tmpdir-even-for-classic-snaps/277
[08:12] <mwhudson> zyga: (2) for env var stuff, did you consider looking at main's 3rd argument and using execve rather than getenv/setenv etc?
[08:13] <zyga> hey
[08:13] <zyga> mwhudson: haha, I was just reading that :)
[08:13] <mwhudson> heh
[08:13] <zyga> mwhudson: yes, I want to use execve everywhere, I don't think we can use os.setenv safely
[08:13] <mwhudson> i don't know why i even posted anything about that to a list or bug, i should have just poked you :-)
[08:13] <zyga> mwhudson: as for the TMP thing, I was just about to grep
[08:14] <zyga> :D
[08:14] <mwhudson> zyga: i didn't realize until fairly recently how much of a hack glibc's environment functions are
[08:14] <zyga> mwhudson: I think you just reminded me of a very old bug
[08:14] <zyga> mwhudson: pre-shared namespaces
[08:15] <zyga> mwhudson: hehe, yes, it's all just ... er... creative
[08:15] <zyga> mwhudson: so, look at (sic) mount-support.c and grep for TMPDIR
[08:15] <zyga> mwhudson: we set TMPDIR *when setting the namespace initially*
[08:15] <zyga> not each time
[08:15] <zyga> I'll fix that ASAP
[08:15] <zyga> so it's all bonkers
[08:17] <mwhudson> zyga: that doesn't get called for classic snaps though does it?
[08:18] <mwhudson> unless this classic_confinement bool is very obscurely named :-)
[08:18] <zyga> mwhudson: another good remark, I'll disambiguate that
[08:18] <zyga> mwhudson: correct, it doesn't get called for classic confinement
[08:18] <zyga> hmm hmm
[08:19] <zyga> so we have also snap-exec
[08:19] <zyga> but I grepped and found nothing TMP*
[08:19] <zyga> one more ideas is that the new environment handling code is messing up stuff
[08:19] <zyga> (where snapcraft.yaml can define environment)
[08:19] <zyga> let me fix the first bug and iterate
[08:20] <mwhudson> i did have something of a poke and found nothing
[08:20] <mwhudson> if it turns out to be something glibc does when you execute a setuid binary i might be very angry
[08:21] <mwhudson> oh god
[08:21] <zyga> oh
[08:21] <zyga> that's a good hunch
[08:21] <zyga> probably another AT_SECURE magic
[08:21] <zyga> does the kernel meddle with environment?
[08:21] <mwhudson> http://lists.gnu.org/archive/html/bug-glibc/2003-08/msg00076.html
[08:22] <mwhudson> it seems less likely
[08:22] <mwhudson> syscall(SYS_execve, ...)?
[08:22] <zyga> aha :)
[08:22] <zyga> let's confirm this is really in the code still (but I bet it is)
[08:23] <mwhudson> although i can't find it in my glibc checkout
[08:25] <mwhudson> reading glibc code makes me appreciate go in a few ways
[08:25] <zyga> about to look, just pushed a PR
[08:25] <zyga> yes, glibc has this special kind of mix of being C, having insane indents and having ugly identifiers in one place
[08:25] <zyga> I love C, I really do, but ... not glibc
[08:26] <zyga> https://github.com/snapcore/snapd/pull/3188
[08:26] <mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
[08:26] <zyga> without spread yet, I'll do spread next when we confirm what's going on in glibc
[08:26] <mwhudson> zyga: also preprocessor abuse
[08:26] <mup> PR snapd#3188 opened: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
[08:27] <mwhudson> i think i have found the glibc evil
[08:27] <zyga> mwhudson: look at sysdeps/generic/unsecvars.h
[08:27] <zyga> mwhudson: :)
[08:27] <zyga> it's still there
[08:27] <mwhudson> ah right, i'd found the other end, where that is used
[08:27] <mwhudson> it's AT_SECURE, as you said
[08:27] <zyga> why in the world is this unsetting TMPDIR though
[08:27] <zyga> or TZDIR for that matter
[08:28] <mwhudson> so my syscall idea was not going to help
[08:28] <mwhudson> zyga: i guess so you can't do TMPDIR=/etc <some setuid program> and have it scribble randomly
[08:28] <zyga> aha, yes :/
[08:28] <zyga> indeed
[08:29] <mwhudson> snap run translates TMPDIR to TMPDIR_, snap-confine copies TMDIR_ back to TMPDIR? >:)
[08:30] <zyga> hahaha
[08:30] <zyga> well
[08:30] <zyga> not sure if it is worth all the effort
[08:30] <mwhudson> it's my day for working late in the evening, you're not going to get sense
[08:31] <pedronis> zyga: what does snap-confine do for a classic snap?
[08:32] <mwhudson> one day it will mount /var/lib/snap at /snap on some distros...
[08:32] <mwhudson> (did i guess that right?)
[08:33] <zyga> pedronis: pretty much nothing AFAIR
[08:33] <pedronis> ok
[08:33] <zyga> mwhudson: no, we cannot do that sadly, classic confinement doesn't use any namespaces
[08:33] <zyga> well, let me check
[08:33] <zyga> maybe we do something
[08:34] <zyga> yeah, we mkdir user data directories
[08:34] <zyga> but that's all
[08:37] <zyga> mwhudson: I commented on the forum
[08:38] <zyga> mwhudson: https://github.com/snapcore/snapd/pull/3189
[08:38] <mup> PR snapd#3189: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <https://github.com/snapcore/snapd/pull/3189>
[08:39] <mup> PR snapd#3189 opened: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <https://github.com/snapcore/snapd/pull/3189>
[08:43]  * zyga -> coffee
[08:53] <zyga> re
[09:19] <mup> PR snapd#3082 closed: many: break the /aliases mutation API with a clean 400 (aliases v2) <Blocked> <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3082>
[09:22] <pedronis> Chipaca: hi, I would appreciate a 2nd review for snapd#3087
[09:22] <mup> PR snapd#3087: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087>
[09:23] <Chipaca> hadn't i done this one already?
[09:24] <pedronis> Chipaca: no, you did the helpers one, this one builds tasks on top of them
[09:25] <mup> PR snapd#3160 closed: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3160>
[09:25] <pedronis> Chipaca: yea, that was #3044
[09:27] <pedronis> Chipaca: it's a long adventure
[09:27] <Chipaca> :-)
[09:28] <Chipaca> pedronis— your super-wide screen is leaking again
[09:30] <pedronis> Chipaca: I don't think it's my screen, it's how emacs wraps things for me
[09:30] <Chipaca> pedronis— i meant the comments
[09:31] <pedronis> I know
[09:31] <Chipaca> ah
[09:31] <pedronis> just saying is not the screen
[09:31] <Chipaca> strange, mine leaves those mostly alone
[09:31] <Chipaca> anyway, no biggie
[09:31] <pedronis> Chipaca: anyway just comment and will rewrap
[09:32] <Chipaca> will do
[09:32] <Chipaca> but i'm reviewing based on the diff to master, which doesn't let me comment directly
[09:33] <pedronis> Chipaca: sorry, I need to remove the comment, now all deps are merged
[09:33] <pedronis> it can be reviewed normally
[09:34] <pedronis> Chipaca: it's just biggish, mostly tests
[09:36] <ogra_> zyga, looking at https://github.com/snapcore/snapd/pull/3188, i i'm wondering, is there really any practical case where a setenv would not work ? (why the check?)
[09:36] <mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
[09:38] <Chipaca> ogra_— ENOMEM
[09:38] <Chipaca> setenv can fail with ENOMEM
[09:38] <ogra_> ah, well ... but then you will die anyway
[09:39] <Chipaca> ogra_— yes but ignoring an ENOMEM because it will die anyway is how you get Bad Things done to you
[09:39] <ogra_> heh, k
[09:39] <Chipaca> there's practical, and then there's under attack
[09:40] <ogra_> yup, understood
[09:40] <zyga> ogra_: snap-confine is written in paranoia mode, we try to check all errors
[09:40] <ogra_> i noticed ;)
[09:42] <Chipaca> man, i wish we were in 1.8 already
[09:42] <Chipaca> sort.Slice is where it's at
[09:44] <zyga> Chipaca: when designing a language, make sure that sorting doesn't suck in 1.0 release
[09:45] <zyga> ;-)
[09:46] <Chipaca> well, it is slightly nasty, in that it uses reflect
[09:47] <Chipaca> so the old way is probably faster and cleaner
[09:47] <Chipaca> but ... convenience
[09:48] <morphis> Son_Goku: did you try to enable test execution for snapd recently?
[09:48] <Son_Goku> I don't know what to do for test execution
[09:48] <zyga> Son_Goku: go test ./...
[09:48] <zyga> (probably)
[09:48] <Son_Goku> right now, I don't think it does anything for golang testing...
[09:48] <morphis> ./run-checks would be nice
[09:48] <zyga> wrapped with $distro.magic.incantation --mandatory-swtich=magic-value
[09:49] <zyga> ^^ typo is part of the API
[09:49] <zyga> :D
[09:49] <Chipaca> zyga— you forgot --moar-magic
[09:49] <morphis> Son_Goku: enabling that for use right now
[09:49]  * zyga fetches the coffee from downstairs :)
[09:49] <Son_Goku> I did flip the check switch during 2.23.6 builds, but I didn't see anything happening...
[09:50] <Son_Goku> so I just switched it back off
[09:50] <morphis> ah
[09:50] <morphis> I can look into that later today
[09:50] <zyga> Son_Goku: the "more magic" position
[09:51] <Son_Goku> haha
[09:51] <mcphail> Does anyone have an example of a snapped Rails application?
[09:52] <zyga> mcphail: I think we do but it's a biggie
[09:52] <zyga> mcphail: forum.snapcraft.io runs as a snap
[09:52] <zyga> mcphail: and that's a big discourse thing
[09:52] <mcphail> zyga: cool. Is there a snapcarft.yaml I can look at?
[09:53] <mcphail> (or snapcraft.yaml would be better!)
[09:53] <zyga> I suspect so but the person snapping it is off this week, back next tue
[09:53] <mcphail> zyga: ta. I'll poke again next week
[09:54] <morphis> zyga: isn't the forum just a docker container?
[09:55] <Chipaca> nope, snap
[09:55] <Son_Goku> sadness and despair, according to niemeyer
[09:55] <Son_Goku> :)
[09:56] <ogra_> i think he was quite happy in the end
[09:56] <Son_Goku> well, he was unhappy with the complexity of discourse setup
[09:56] <ogra_> yeah
[09:56] <Chipaca> but we also got services control back from that little experiment, so \o/
[09:56] <Chipaca> :-)
[09:56] <Son_Goku> haha
[09:56] <ogra_> :D
[09:56] <Son_Goku> that's always nice
[09:57] <Chipaca> dogfooding ftw
[09:57] <ogra_> woof
[09:57] <morphis> Chipaca: nice
[09:57] <Son_Goku> most of this is sadness and despair for me, for now
[09:58] <Son_Goku> as all dogfooding just crushes my soul as I use Ubuntu-y things on my nice Fedora system :P
[09:58] <ogra_> Chipaca, .... hmmm ... i wonder ...
[09:58] <Chipaca> Son_Goku— eww
[09:58] <ogra_> Chipaca, how about we'd hook all services inside the core snap on an Ubuntu Core install up to that interface
[09:58] <Chipaca> Son_Goku— i feel your pain
[09:59] <Son_Goku> Chipaca: things get... weird
[09:59] <Chipaca> ogra_— you're preaching to the choir
[09:59] <ogra_> snap stop core.timesyncd && snap install ntpd
[09:59] <Son_Goku> and because some of the redirection stuff doesn't actually work, I get to see really strange stuff from time to time
[09:59] <ogra_> ;)
[09:59] <Chipaca> ogra_— i want the core snap to be fully described in the snap.yaml :-)
[09:59] <Son_Goku> like random GUI application crashes when it launches
[09:59] <morphis> zyga: do you introduced the check-syntax-c rules for snap-confine with 2.24?
[10:00] <mcphail> Son_Goku: you get that on Ubuntu too ;)
[10:00] <zyga> no, that was there for eons
[10:00] <Son_Goku> and my resolution of my computer resetting when I launch a program that uses OpenGL
[10:00] <morphis> zyga: hm, https://paste.ubuntu.com/24373248/
[10:00] <Son_Goku> going from 1080p to 800x600 is unpleasant
[10:00] <zyga> morphis: oh, interesting, maybe difference in indent?
[10:00] <zyga> morphis: but that's fine
[10:00] <morphis> zyga: either there is a difference in how intent works on suse in constrast to Ubuntu
[10:00] <zyga> morphis: I plan to kill indent
[10:00] <zyga> maybe today
[10:01] <morphis> zyga: however, requires me to patch 2.24 now :_)
[10:01] <ogra_> Son_Goku, where are all the bugs for that ? :)
[10:01] <Son_Goku> ogra_: I'd love to file bugs, but I have this thing about not filing bugs when I don't have any idea what is happening :)
[10:01] <Son_Goku> it's not useful or helpful, imo
[10:02] <Chipaca> right, but
[10:02] <ogra_> but then nobody else will know it happened to you when he looks for info if it happens to him
[10:02] <Son_Goku> and in my experience, those kinds of bugs just get ignored anyway
[10:02] <Chipaca> Son_Goku— is this really random? no STR?
[10:02] <Son_Goku> the most repeatable case is in my VMware Fusion VMs
[10:02] <Son_Goku> but it's really random on KVM VMs or on real systems
[10:02] <Chipaca> rats
[10:02] <Son_Goku> applications *do* reliably crash on Fedora GNOME though
[10:02] <Chipaca> Son_Goku— and do you get to see the window before it crashes? or does it straight up never start?
[10:03] <Son_Goku> never starts
[10:03] <Son_Goku> it just dies
[10:03] <Chipaca> Son_Goku— does the error message say something about permission denied, when it dies?
[10:03] <Son_Goku> nope
[10:03] <Chipaca> aw
[10:04] <Son_Goku> if it did, I'd have something to file :D
[10:04] <Chipaca> thought maybe it was merely a bad case of bug #1672819
[10:04] <mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-key> <xenial> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):In Progress by colin-king> <https://launchpad.net/bugs/1672819>
[10:04] <Son_Goku> actually, it might be
[10:04] <Chipaca> that's going to take a while to get better on fedora, i reckon, unless you pick up the patch when cking has it
[10:04] <Son_Goku> Chipaca: I'll have to try to repro again
[10:04] <Son_Goku> on a clean system
[10:05] <Son_Goku> my current VMs are dirty, dirty beasts
[10:05] <Chipaca> Son_Goku— even if you don't know what's going on, steps-to-reproduce are super useful
[10:05] <Chipaca> Son_Goku— also, see if adding/removing virtual cpus changes whether things crash or not (per that bug)
[10:05] <Son_Goku> I know for a fact that everyone with nvidia cards can't use snappy at all for graphical things
[10:06] <Son_Goku> it straight up crashes
[10:06] <Chipaca> that should not happen
[10:06] <Chipaca> does zyga know?
[10:06] <Chipaca> we've got work in there specifically for nvidia
[10:06] <Son_Goku> I think zyga knows
[10:06] <Son_Goku> well, if he didn't before, he does now
[10:06] <zyga> so easy to learn here
[10:06] <Son_Goku> but I think I mentioned it during the 2.23.6 testing
[10:07] <zyga> nvidia support is not perfect, we need a different approach really
[10:07] <Chipaca> zyga is supposed to be off today i think
[10:07] <zyga> me?
[10:07] <Chipaca> which is why i'm pretending he's not here
[10:07] <zyga> really?
[10:07] <zyga> actually
[10:07] <Chipaca> zyga— aren't you?
[10:07] <zyga> my wife is out
[10:07] <Chipaca> zyga— isn't it jueves santo in spain?
[10:07] <zyga> my kids are out
[10:07] <Son_Goku> I thought that ws mvo?
[10:07] <zyga> hmmmhmm
[10:07] <zyga> and I'm here because work
[10:07] <Chipaca> i thought spain did thu+fri, as opposed to other places doing thu+mon
[10:07] <zyga> (my family has a fantastic hike to a castle on a hill next by)
[10:08] <zyga> Chipaca: one thing I miss is people reminding me about holidays in spain
[10:08] <Chipaca> zyga— the one with the wineyards?
[10:08]  * zyga checks wikipedia
[10:08] <Son_Goku> wouldn't that be sergiusens, not zyga?
[10:08] <Chipaca> wineyard?
[10:08] <zyga> Chipaca: no, not that one
[10:08] <ogra_> friday and monday should be off in spain
[10:08] <Chipaca> vineyard!
[10:08] <Chipaca> heh
[10:08] <Son_Goku> oh, you're talking about Spanish vineyards
[10:08]  * Chipaca 's bain is lossy
[10:09] <Son_Goku> anyway, decathorpe privately mentioned to me that he can't run anything on his host system as he uses an nvidia card
[10:09] <Son_Goku> all applications just crash
[10:09] <ogra_> all
[10:09] <Chipaca> sergiusens does not have vineyards close by
[10:09] <ogra_> ?
[10:09] <Son_Goku> ogra_: all GUI ones, anyway
[10:09] <Son_Goku> CLI ones are fine
[10:09] <zyga> https://www.google.es/maps/@42.051898,3.1313432,339m/data=!3m1!1e3!5m1!1e4?hl=pl
[10:09] <zyga> here
[10:09] <ogra_> well, i run gui apps just fine on my desktop that has an nvidia
[10:09] <Chipaca> there are some two mountains chain to the west, which is about 200km as the crow flies (if you ignore it flying up and down again)
[10:10] <Chipaca> but those are not too good :-)
[10:10] <Son_Goku> ogra_: you also use Ubuntu, and not Fedora :)
[10:10] <Son_Goku> currently, I think snappy requires custom implementations for nvidia handling for each distro
[10:10] <ogra_> Son_Goku, right, but thats definitely something we need to fix urgently
[10:10] <zyga> yes
[10:11] <ogra_> and first of all we need a bug for itf from someone who has it happening ;)
[10:11] <Son_Goku> I'm going to poke decathorpe to file a bug
[10:11] <Son_Goku> he doesn't want to... saying it's an edge case
[10:11] <Son_Goku> but it's not... :/
[10:11] <pedronis> Chipaca: thx
[10:11] <Son_Goku> also, Fedora's nvidia implementation is the first to use libglvnd natively
[10:11] <Son_Goku> so I don't know how that affects what we do here in snapd and snap-confine
[10:12] <ogra_> it needs to be supported
[10:13] <zyga> well
[10:13] <zyga> I know what to do
[10:13] <zyga> it's just 1) hardware 2) coordination 3) time
[10:14] <ogra_> well, 1) ... expense it ...
[10:14] <ogra_> :)
[10:14] <Son_Goku> ehh
[10:14] <Son_Goku> this new Canonical may not want to accept it :/
[10:15] <ogra_> if i need to enable a new board for Core i can expense it too ... cross-distro support is still equally important even in the new canonisl i think
[10:15] <Chipaca> you can get an nvidia card for less than the price of an rpi3
[10:15] <ogra_> right
[10:15] <Chipaca> so i doubt it'll be a problem
[10:15] <Son_Goku> ogra_: I hope so
[10:15] <Son_Goku> I'm really worried about it
[10:15] <ogra_> dont be
[10:18] <zyga> Chipaca: interesting, today is a public holiday in almost all of Spain but not in Catalonia
[10:19] <zyga> ogra_: once we start working on nvidia support I'll definitely buy and expense a card
[10:19] <Son_Goku> wow, you got screwed :/
[10:19] <ogra_> because catalonia isnt spain ;)
[10:19] <Chipaca> zyga— Catalunya lliure or something
[10:19] <zyga> Chipaca: exactly ;)
[10:19] <sergiusens> I am here today
[10:19] <sergiusens> not a holiday
[10:19] <zyga> it's interesting to observe how people react when my wife speaks catalan
[10:20] <sergiusens> just Friday
[10:20] <zyga> if she starts they are surprised and use catalan
[10:20] <sergiusens> and yes, it is 7:20 AM and I've been up since 4AM
[10:20] <ogra_> crazy
[10:20] <Chipaca> sergiusens— how's the kid?
[10:20] <zyga> if they start and overhear us they use broken english or spanish
[10:20] <Son_Goku> sergiusens: it's 6:20AM here and I've been up since 3:30AM
[10:20] <sergiusens> Chipaca: read my toot? :-P
[10:21] <Chipaca> on twitter? didn't see it
[10:21] <zyga> but if she switches to catalan again (just to practice) they often ask "wow you speak catalan, how is that possible" :)
[10:21] <sergiusens> my kid is sleeping, I am not anymore
[10:21] <Chipaca> on mastodon i don't have you
[10:21] <Chipaca> (mastodon calls them toots)
[10:21] <zyga> Chipaca: ah, more mastodon?
[10:21] <zyga> is there a snap for it
[10:21] <zyga> last time I looked it was ugly to deploy
[10:21] <Chipaca> zyga— oooh
[10:22] <mcphail> Ha! it was mastodon I was wanting to snappify (hence the question about Rails)
[10:22] <sergiusens> Chipaca<EMAIL_ADDRESS>but I managed to get an account on<EMAIL_ADDRESS>so I might be switching there soon
[10:23]  * zyga doesn't get the new fashion
[10:24] <Chipaca> sergiusens— in mastodon, what's the difference between @sergiusens and<EMAIL_ADDRESS>[10:24] <Chipaca> and why can't you just move?
[10:24] <Chipaca> anyway
[10:24] <Chipaca> this is not helping me get work done
[10:24] <sergiusens> Chipaca: different accounts
[10:24]  * Chipaca cracks his whip at himself
[10:24] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/3189 trivial
[10:24] <mup> PR snapd#3189: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <https://github.com/snapcore/snapd/pull/3189>
[10:25]  * zyga waits unil we get back to uucp for social news
[10:25] <zyga> that will be something ;-)
[10:25] <zyga> I'm ahead of the wave ;-)
[10:25] <ogra_> well, uucp still exists
[10:25] <ogra_> just use it ;)
[10:25] <zyga> Thanks for the review Pharaoh_Atem :)
[10:25] <sergiusens> apparently if you still have identica you could just get federated into mastodon
[10:25] <zyga> ogra_: ha, but if just I use it, nobody will know
[10:26]  * sergiusens goes back to ignoring irc
[10:26] <zyga> Chipaca: and https://github.com/snapcore/snapd/pull/3188 (more important) while you're at it ;)
[10:26] <mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
[10:27] <Chipaca> uhh
[10:27] <Chipaca> zyga— there's a bug about us overriding TEMPDIR on classic
[10:27] <Son_Goku> oh dear
[10:27] <Son_Goku> please don't break me more :(
[10:28] <zyga> Chipaca: it's not that, it's a ld.so thing
[10:28] <zyga> Chipaca: we looked at it in the morning with mwhudson
[10:28] <zyga> Chipaca: AT_SECURE == unset TMPDIR (but not TEMPDIR)
[10:29] <Chipaca> Son_Goku— the bug is about us doing it when we shouldn't, not viceversa
[10:29] <Chipaca> zyga— so to get TMPDIR past snap-confine we'd need to sneak it in?
[10:29] <Chipaca> heh
[10:29] <zyga> Chipaca: hmm, is this still about TMPDIR?
[10:29] <zyga> Chipaca: well
[10:29] <zyga> Chipaca: look at this thread on the forum:
[10:29] <zyga> https://github.com/snapcore/snapd/pull/3188
[10:29] <mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
[10:30] <zyga> https://forum.snapcraft.io/t/something-filters-out-tmpdir-even-for-classic-snaps/277/2
[10:30] <zyga> (sorry, ^C sometimes fails)
[10:30] <Chipaca> 'snap run' -> sets _TMPDIR from TMPDIR; snap-exec -> sets TMPDIR from _TMPDIR, or something like that
[10:30]  * Chipaca reads
[10:30] <zyga> Chipaca: yeah, I proposed something like that
[10:30] <zyga> Chipaca: not sure if we should do it though, feels very very edge case
[10:30] <zyga> it can be done for sure
[10:30] <Chipaca> ah there we go
[10:31] <Chipaca> we probably need to do that to make it work, probably for all other env vars that are cleared for AT_SECURE
[10:31] <zyga> Chipaca: those are listed in...
[10:31] <zyga> UNSECURE_ENVVARS in glibc tree
[10:32] <zyga> http://paste.ubuntu.com/24373481/
[10:32] <Chipaca> NIS_PATH
[10:32] <Chipaca> hue hue hue
[10:32] <zyga> yes, some arcane stuff in there
[10:33] <Chipaca> ANYWAY!
[10:33] <Chipaca> i've got code to code
[10:33] <zyga> me too :)
[10:33] <Chipaca> otherwise #3150 will never see the light of day
[10:36] <mup> PR snapd#3027 closed: snap: run snap-confine from core if snap is also running from core <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3027>
[10:39] <mwhudson> Chipaca: you can just do the env resetting in snap-confine, i think
[10:40] <mwhudson> although hm, maybe snap-exec would be easier, would be easier to re-use the same code that way i guess
[10:43] <Chipaca> mwhudson— I'll let zyga have his fun with that
[10:46] <mwhudson> heh heh
[10:48] <zyga> mwhudson: note that we don't run snap-exec if we use `snap run --shell`
[10:48] <zyga> so I think it has to be snap-confine + snap-run that play
[10:56] <zyga> Chipaca: I'm going through PRs and I got to https://github.com/snapcore/snapd/pull/3150
[10:56] <mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
[10:57] <zyga> Chipaca: is there any way to split this, can anything land before?
[10:57] <Chipaca> zyga— on the one hand, no
[10:57] <zyga> (thanks for de-conflicting)
[10:57] <Chipaca> zyga— on the other hand, no
[10:57] <Chipaca> :-D
[10:57] <Chipaca> zyga— that's what i'm working on right now
[10:57] <zyga> fine :)
[10:57] <zyga> hmm?
[10:57] <zyga> so yes or no? :)
[10:57] <zyga> if you want I will review it as-is
[10:58] <Chipaca> zyga— it can't be split. But it's not really that big?
[10:58] <Chipaca> i mean, etelpmoc.sh is long, but narrow :-)
[10:58] <zyga> Chipaca: like a good bridge should be :)
[10:58] <Chipaca> mostly the silly 'case' thing
[10:59] <Chipaca> the spread test that failed in travis passes when running spread locally. I've rebased to master and repushed, to see if it works in travis or not
[11:00] <Chipaca> but it might be travis messing up the encoding somehow?
[11:00] <mup> PR snapd#3105 closed: tests: download previous snapd package from published versions instead of specific PPA <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3105>
[11:00] <Chipaca> dunno
[11:00] <zyga> Chipaca: maybe some locale stuff is odd there
[11:00] <zyga> btw we seem to run out of machines frequently now
[11:00] <Chipaca> pr'aps
[11:00] <zyga> Chipaca: ping me when you want me to review it
[11:01] <Chipaca> zyga— one thing that could be done to make this shorter is to take lib.exp0 and merge it with the other lib.exp0 and DRY it
[11:01] <Chipaca> but not sure it's worth it
[11:02] <zyga> nah, that's fine
[11:02] <zyga> I was mostly scared about 58 files changed :)
[11:02] <zyga> that's only fun to read when we change to GPL-4
[11:02] <zyga> pedronis: can you have a 2nd look at https://github.com/snapcore/snapd/pull/3010/files
[11:02] <mup> PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <https://github.com/snapcore/snapd/pull/3010>
[11:03] <Chipaca> zyga— ah! 58 files is mostly test data
[11:03] <Chipaca> test config? test ... stuff
[11:04] <Chipaca> zyga— for each completion test there's a .vars, a .sh and a .complete
[11:04] <zyga> right, that's fine
[11:04] <zyga> I'll review it when you ping me
[11:06] <Chipaca> $ find tests/completion/ -type f \! -name \*~ | wc -l
[11:06] <Chipaca> 44
[11:06] <Chipaca> ^ i was curious :-)
[11:07] <mup> PR snapd#3010 closed: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3010>
[11:07] <mup> PR snapd#3016 closed: interfaces: add kubernetes-support interface and adjust related interfaces (LP: #1664638) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3016>
[11:09] <zyga> I could use a review for https://github.com/snapcore/snapd/pull/3149
[11:09] <mup> PR snapd#3149: cmd: make locking around namespaces explicit <Created by zyga> <https://github.com/snapcore/snapd/pull/3149>
[11:09] <zyga> we will then use it for fixing snap-confine and /snap sharing in containers
[11:12]  * ogra_ hugs a bunch of people for https://github.com/snapcore/snapd/pull/3010
[11:12] <mup> PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3010>
[11:13] <ogra_> that will quieten the image boots a lot
[11:14] <zyga> ogra_: yes, totally
[11:21] <zyga> tvoss, ogra_: just merged the rsa changes
[11:21] <tvoss> zyga: great, thank you :)
[11:22] <mup> PR snapd#3130 closed: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3130>
[11:22] <zyga> Pharaoh_Atem, morphis: we need to depend on whatever provides ssh-keygen for snapd >= 2.25
[11:22] <zyga> ditto fir suse
[11:22] <morphis> zyga: I know :-)
[11:23] <morphis> watching the forth and back on this discussion for some
[11:23] <zyga> I'd like to land https://github.com/snapcore/snapd/pull/3138
[11:23] <mup> PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
[11:37] <morphis> zyga: looks like you need to dicuss that with jdstrand further
[11:38] <zyga> morphis: I think this is a misunderstanding there but I will discuss
[11:38] <zyga> jdstrand: if you are around :)
[11:42]  * zyga is getting hungry, brb
[11:46] <Son_Goku> zyga: easy enough to add for me "Requires: /usr/bin/ssh-keygen" :)
[11:52] <NicolinoCuralli> hi guy : is it a awaited behavoiur the manual review for a snap with classic confinement?
[11:53] <Chipaca> NicolinoCuralli— say again please?
[11:53] <zyga> Son_Goku: yes, that's pretty nice :-)
[11:53] <zyga> NicolinoCuralli: yes
[11:53] <zyga> NicolinoCuralli: all snaps that use classic confinement run ... unconfined, so we need to do the classic debian-like review of the software
[11:54] <Chipaca> ah, zyga if you parsed that you're better at it than I am
[11:55] <NicolinoCuralli> chipaca: i upload a snap with classic confinement on the pubblic store and  I hit a manual review ? is it ok?
[11:55] <Chipaca> NicolinoCuralli— yep! as zyga explained.
[11:55] <ogra_> NicolinoCuralli, yes, that is expected ...
[11:55] <zyga> NicolinoCuralli: I think the rules are that the snapcraft yaml is merged in the upstream repository
[11:56] <ogra_> NicolinoCuralli, classic means "unsafe" so it needs review
[11:56] <zyga> NicolinoCuralli: there's a reason to disable confined
[11:56] <zyga> NicolinoCuralli: and the developers are recognized in the community
[11:57] <zyga> NicolinoCuralli: I think that's the rough list but I could be wrong, it's a case-by-case review really
[11:57] <NicolinoCuralli> ok: i need to understand about use of strict mode or classic mode then i need to test the same package in classic or strict confinement
[11:58] <zyga> NicolinoCuralli: if you can do strict - go strict
[11:58] <zyga> NicolinoCuralli: that's better in many ways
[11:58] <icey> zyga: so I should get my PR accepted upstream before getting my classic snap accepted?
[11:58] <zyga> NicolinoCuralli: and is compatible with more distribution
[11:58] <zyga> icey: most likely yes
[11:58] <zyga> icey: what is the software you're thinking about?
[11:58] <icey> zyga: alacritty, a shell written in Rust with GPU acceleration
[11:58] <NicolinoCuralli> how can i help us to make the review more fast for the my snap?
[11:58] <zyga> *shell* ???
[11:59] <zyga> as in /bin/sh
[11:59] <zyga> with GPU accel?
[11:59] <NicolinoCuralli> us -> you
[11:59] <zyga> NicolinoCuralli: I don't know honestly, it's not a well exercised process
[11:59] <icey> zyga: https://github.com/jwilm/alacritty
[11:59] <zyga> NicolinoCuralli: maybe file a bug on the snapstore to track it?
[11:59] <zyga> http://launchpad.net/snapstore
[11:59] <zyga> aha
[12:00] <zyga> interesting :)
[12:00] <zyga> we use GPUs to make teletype emulators nicer
[12:01] <Chipaca> NicolinoCuralli— why do you need it to be classic?
[12:01] <Chipaca> that's where the review starts :-)
[12:02] <NicolinoCuralli> the snap must achieved in a more straight manner the network layer
[12:03]  * zyga fails to parse that
[12:03] <Chipaca> NicolinoCuralli— to do what with it?
[12:03] <Chipaca> NicolinoCuralli— we have interfaces for most things you'd want to do with the network
[12:03] <NicolinoCuralli> Chipaca: advanced network monitoring
[12:03] <Chipaca> NicolinoCuralli— so make it a strict snap, using the network-monitor interface
[12:04] <Chipaca> was it network-monitor?
[12:04]  * Chipaca looks
[12:04] <ogra_> observe :)
[12:04] <NicolinoCuralli> Chipaca; this a one of two project that i want to deploy with snap : https://www.indiegogo.com/projects/fingbox-network-security-wi-fi-troubleshooting#/
[12:04] <Chipaca> network-observe perhaps
[12:05] <Chipaca> NicolinoCuralli— that does sound like something you should be able to do with the network-observe interaface
[12:07] <Bizon> icey: are the current terminal emulators so slow we need a new one written with performance in mind?
[12:07] <NicolinoCuralli> Chicapa : network-control ( it achieve the raw network interface ) , network-* interface, gpio
[12:07] <icey> Bizon: that's not my question to answer :-P I'm just snapping something that somebody else made ;-)
[12:07] <zyga> NicolinoCuralli: what does "achive the raw network interface" mean?
[12:09] <NicolinoCuralli> Zyga: we use libpcap
[12:10] <zyga> NicolinoCuralli: so a raw socket in promiscuous mode?
[12:10] <Son_Goku> zyga, morphis: https://bugzilla.redhat.com/show_bug.cgi?id=1442051
[12:11] <Chipaca> wait, gpio?
[12:11] <NicolinoCuralli> zyga: for ethernet interface  and monitor mode for the wireless interface
[12:11] <morphis> Son_Goku: yeah, nvidia is broken
[12:12] <Chipaca> NicolinoCuralli— is this a core system?
[12:12] <zyga> Son_Goku: thanks, I'm replying in the bug
[12:12] <NicolinoCuralli> Gpio for viualization of state od the network of the sysytem by leds
[12:12] <zyga> ha, nice
[12:13] <Chipaca> NicolinoCuralli— I mean: is the device this is running on an all-snaps system? i.e. 'ubuntu core'?
[12:13] <NicolinoCuralli> Chicapa: could you explain better your question?
[12:13]  * zyga -> food (for real this time)
[12:14] <ogra_> Chipaca, then classic wouldnt work at all
[12:14] <Chipaca> NicolinoCuralli— the snap you are writing, it's for running on a device?
[12:14] <NicolinoCuralli> Chicapa: we want to use snap system for distribution of updates
[12:14] <NicolinoCuralli> Chicapa: the snap is for running a dedicated hardware
[12:15] <zyga> NicolinoCuralli: what Chipaca is asking about is what distribution is running on that device
[12:15] <zyga> NicolinoCuralli: if it's say, debian or ubuntu + snapd + your snap
[12:15] <zyga> NicolinoCuralli: then you can use classic confinement
[12:15] <NicolinoCuralli> ubuntu 16.04 for classic confinement
[12:15] <zyga> NicolinoCuralli: if it is the ubuntu-core distribution
[12:15] <zyga> NicolinoCuralli: then you cannot use classic confinement at all
[12:16] <NicolinoCuralli> zyga, Chiacapa: ubuntu-core for the strict confinement
[12:16] <Chipaca> right
[12:16] <Chipaca> so a classic snap is out of the picture
[12:17] <Chipaca> NicolinoCuralli— but, you should be fine using a strict snap with the appropriate interfaces
[12:17] <Chipaca> NicolinoCuralli— some of them don't auto-connect, but if it's dedicated hardware you can make them autoconnect from the gadget snap
[12:17] <NicolinoCuralli> Classic snap is in the picture : i need to evaluate a feasibility for the classic mode on a standard ubuntu 16.04
[12:18] <NicolinoCuralli> autoconnect from gadget don't work : i try it days ago and report on mailing the problem
[12:18] <morphis> zyga: https://build.opensuse.org/request/show/487821
[12:18] <Chipaca> NicolinoCuralli— OK. That takes us back to the same question: why do you need classic? (it sounds like you don't)
[12:18] <morphis> zyga: but please don't merge yet
[12:18] <Chipaca> NicolinoCuralli— what was the email subject?
[12:19] <NicolinoCuralli> Chicapa: workaround for connect no autoconnect interfaces without login on system
[12:21] <Chipaca> NicolinoCuralli— ah!
[12:22] <Chipaca> I don't know who *knows* this. zyga, or ogra_, either of you know how the autoconnect-from-gadget works?
[12:22] <NicolinoCuralli> Chicapa: I think that some chance that a snap core update can broke some functionality  with my custom kernel the i want to try classic confinement
[12:22] <ogra_> Chipaca, nope
[12:22] <mup> PR snapcraft#1253 opened: Cross-compilation support for the Go plugin <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1253>
[12:22] <ogra_> Chipaca, sounds more like a pedronis question ... i guess it happens during firstboot setup
[12:22] <ogra_> (well, pedronis or mvo)
[12:22] <Chipaca> pr'aps
[12:23] <Chipaca> pedronis— poke poke
[12:23] <NicolinoCuralli> Chicapa: I think that some chance that a snap core update can broke some functionality  with my custom kernel then I want to try classic confinement
[12:23] <pedronis> Chipaca: autoconnect from snap is something we haven't implemented yet
[12:23] <pedronis> afaik
[12:23] <Chipaca> pedronis— oh drat
[12:23] <pedronis> sorry, I mean from gadget
[12:23] <Chipaca> yeah i read you
[12:25] <NicolinoCuralli> Chicapa: my answer is clear for you? sorry for the bad english :D
[12:25] <Chipaca> NicolinoCuralli— so, we have some work to do to autoconnect from the gadget; it's not there yet
[12:26] <Chipaca> NicolinoCuralli— your answer is clear :-) your reasoning isn't :-/
[12:26] <NicolinoCuralli> Chicapa: yes, i know this
[12:26] <NicolinoCuralli> Chicapa: i try to explain better
[12:26] <Chipaca> NicolinoCuralli— I mean, if core breaks your kernel, it'll break whether classic or not
[12:27] <NicolinoCuralli> Chicapa : this because ubuntu-core snap and core snap are the same things
[12:27] <NicolinoCuralli> Chicapa : this because ubuntu-core snap and core snap are the same things?
[12:28] <Chipaca> NicolinoCuralli— yep
[12:28] <Chipaca> (there is no ubuntu-core snap, now)
[12:28] <NicolinoCuralli> what is the best practice for remain aligned with your work on core?
[12:29] <Chipaca> I'm not the right person to answer that
[12:29] <Chipaca> I'm too deep in the trenches
[12:29] <Chipaca> even my two-levels-up view does not cover the whole thing
[12:30] <Chipaca> NicolinoCuralli— maybe JamieBennett
[12:31] <NicolinoCuralli> Chicapa: i mean thins as monitoring the core code use on the edge channel or thing as it
[12:31]  * JamieBennett reads the back scroll
[12:32] <Chipaca> zyga, niemeyer, have you guys ever seen travis insert spurious \u0008's into tests?
[12:32] <JamieBennett> NicolinoCuralli: can you summarise your question again?
[12:34] <NicolinoCuralli> Hi Jamie: we want to try classic confinement on ubuntu 16.04 ( not ubuntu core ) for preserve us from possible problem from misalignement between kernel functionality ( apparmor etc ) and snapd
[12:35] <NicolinoCuralli> but with Chicapa and Zyga answert i understood that it don't preseve us from a possibile problem of misaligment
[12:36] <NicolinoCuralli> JamieBennet: is it correct?
[12:36] <mup> PR snapd#3087 closed: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3087>
[12:36] <JamieBennett> NicolinoCuralli: are you using a custom kernel on ubuntu classic?
[12:37] <NicolinoCuralli> yes
[12:37] <NicolinoCuralli> the board is custom
[12:37] <JamieBennett> NicolinoCuralli: So your custom kernel will have to closely match anything we do with our kernel as we only guarantee our kernel/snapd combo for reference devices
[12:38] <JamieBennett> You would have to look at our kernel development tree and keep up to date
[12:39] <NicolinoCuralli> the same for uboot used and snapd?
[12:39] <NicolinoCuralli> JamieBennet : the same for uboot used and snapd?
[12:40] <JamieBennett> well, snapd would (zyga correct me if I am wrong) be refreshed as normal, just like if one of our kernels were used but if there is something missing from your kernel then potentially snapd would behave badly / not work
[12:40] <JamieBennett> we don't tend to mess too much with uboot once it is working
[12:41] <morphis> Son_Goku: looks like the vendorized build of snapd is broken on fedora with the name change of the upstream tarball
[12:41] <morphis> Son_Goku: seeing: error: File /builddir/build/SOURCES/snapd-2.24.tar.gz: No such file or directory
[12:41] <Son_Goku> yeah, I fixed it in my spec
[12:41] <morphis> when building with $ rpmbuild --with vendorized -bs snapd.spec
[12:42] <Son_Goku> http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n49
[12:42] <morphis> tought I've fetch your latest already
[12:43] <morphis> Son_Goku: yeah I have that change
[12:43] <NicolinoCuralli> JamieBennett: how can we integrate our board with yours for make it a reference device ?
[12:44] <morphis> Son_Goku: with http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/commit/?id=868fcee99a09259d0707fbc7544725a03204656f as latest change and not local changes I get that build error
[12:45] <JamieBennett> NicolinoCuralli: for it to be a Canonical reference device it needs a kernel and gadget from Canonical, this means that we commit to ensuring it works throughout the dev cycle. It is heavily tested and if problems arise we fix them. For your board there isn't the same level of commitment as you are doing the work, not Canonical.
[12:46] <JamieBennett> NicolinoCuralli: So it is down to you to ensure your image works, so tracking our kernels, applying any needed patches, and testing
[12:46] <JamieBennett> NicolinoCuralli: If you wanted Canonical to do that work then we would need to have a conversation around that
[12:46] <mup> PR snapcraft#1254 opened: ci: fix travis ordering for locales generation <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1254>
[12:47] <Son_Goku> morphis:
[12:47] <Son_Goku> [makerpm@yu-ohki SPECS]$ rpmbuild -bs --with vendorized snapd.spec
[12:47] <Son_Goku> error: File /home/makerpm/rpmbuild-snp2/SOURCES/snapd_2.24.vendor.orig.tar.xz: No such file or directory
[12:47] <Son_Goku> [makerpm@yu-ohki SPECS]$ rpmbuild --with vendorized -bs snapd.spec
[12:47] <Son_Goku> error: File /home/makerpm/rpmbuild-snp2/SOURCES/snapd_2.24.vendor.orig.tar.xz: No such file or directory
[12:47] <Son_Goku> works for me?
[12:47] <Son_Goku> are you sure you're using your correct spec
[12:48] <morphis> Son_Goku: the srpm build isn't what fails
[12:48] <Son_Goku> oh, mock!
[12:48] <morphis> https://paste.fedoraproject.org/paste/wb27V7lHa~SXRAObmJlgo15M1UNdIGYhyRLivL9gydE=
[12:48] <Son_Goku> you need to pass --with vendorized to mock too
[12:48] <morphis> Son_Goku: yes
[12:48] <morphis> ah!
[12:50] <morphis> Son_Goku: that works, thanks!
[12:52] <NicolinoCuralli> JamieBennet: thanks for clarifications about the problem
[12:54] <JamieBennett> NicolinoCuralli: np
[12:55] <NicolinoCuralli> Thanks so much zyga and Chicapa
[12:59] <Chipaca> are we doing the standup today?
[12:59] <Chipaca> it's going to be sparse :-)
[13:00] <pedronis> Chipaca: we are there
[13:00] <ogra_> well, some of us are in there
[13:00] <ogra_> but we could skip
[13:01] <zyga> Chipaca: nope
[13:01] <zyga> what is that character?
[13:04] <morphis> zyga, Son_Goku: this is interesting: https://paste.fedoraproject.org/paste/gs6MGVrtlqxoaQIPFM5YOl5M1UNdIGYhyRLivL9gydE=
[13:05] <Chipaca> zyga— backspace
[13:05] <morphis> I think the "missing function body" errors come from the build tag !gccgo in those .go files
[13:08] <morphis> Son_Goku, zyga: wondering why the %gotest macro has -compiler gc hardcoded
[13:11] <zyga> morphis: huh
[13:11] <zyga> morphis: maybe go packaging magic and .[ch] files doesn't play ball?
[13:11] <morphis> zyga: it's gccgo
[13:12] <morphis> at least looks like that is the problem from a first quick look
[13:21] <pstolowski> zyga, let me know if there is any low hanging fruit that you want landed.. would be good to clean the queue a bit
[13:22] <zyga> pstolowski: I'm just checking
[13:22] <zyga> https://github.com/snapcore/snapd/pull/3189
[13:22] <mup> PR snapd#3189: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <https://github.com/snapcore/snapd/pull/3189>
[13:22] <zyga> https://github.com/snapcore/snapd/pull/3188
[13:22] <mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
[13:22] <zyga> those need to wait for tests
[13:22] <zyga> same here https://github.com/snapcore/snapd/pull/3187
[13:22] <mup> PR snapd#3187: interfaces/mount: improve go identifier names of mountinfo, parse optional fields <Created by zyga> <https://github.com/snapcore/snapd/pull/3187>
[13:25] <mup> PR snapd#2981 closed: tests: add kernel-module-control interface test <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2981>
[13:37] <morphis> zyga, Son_Goku: that is interesting, our vendor .tar.gz doesn't include salsa2020_amd64.s
[13:38] <morphis> which salsa20_amd64.go refers to for the real implementation
[13:38] <zyga> morphis: oh
[13:39] <zyga> morphis: maybe the export code doesn't expect assembly?
[13:39] <morphis> https://github.com/golang/crypto/tree/master/salsa20/salsa
[13:39] <morphis> that is the thing I am not sure
[13:41] <morphis> zyga: copying https://raw.githubusercontent.com/golang/crypto/master/salsa20/salsa/salsa2020_amd64.s manually in place works
[13:42] <zyga> morphis: look at the vendor code
[13:42] <zyga> morphis: govendor bug?
[13:42] <morphis> maybe
[13:42] <morphis> but wondering why the tests build and run with the same tarball on suse
[13:44] <morphis> zyga: https://build.opensuse.org/build/home:mrmorph:branches:system:snappy/openSUSE_Leap_42.2/x86_64/snapd/_log shows it could compile those bits
[14:02] <taaem> So I installed Ubuntu Core 16 on a Raspberry Pi but I noticed that there are only very minimal packages preinstalled, its missing for example lvm2 for lvm hard drives and since apt is not supported and snap doesn't find anything and afaiu it isn't supposed to find stuff like that. So now I have the problem that I can't use my old harddrives with Ubuntu Core because of this missing lvm2
[14:03] <ogra_> taaem, well, ubuntu core forcuses on embedded ...
[14:03] <ogra_> lvm is a rather rare use case
[14:04] <ogra_> (which doesnt mean there wont be a lvm2 snap eventually for external disks or some such, but it is surely not a high prio)
[14:04] <mup> PR snapcraft#1254 closed: ci: fix travis ordering for locales generation <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1254>
[14:06] <taaem> ogra_: okay so I'll have to use another distro then but thanks
[14:07] <ogra_> taaem, what do you try to do ?
[14:08] <taaem> ogra_: I want to use Nextcloud on my rpi3 and I used rasbian and OpenSUSE before and they both failed on me so I thought I'd try Ubuntu Core
[14:09] <ogra_> well, that works fine without lvm at least ...
[14:09] <taaem> and the hdd was lvm from the begginning mostly so i could easily expand the space available without having to mess with nextcloud but only with the underlying fs
[14:09] <ogra_> just with "snap install nextcloud" (and the rest ios done in your browser then)
[14:10] <taaem> yeah but I have already 100GB of data on the lvm partition of my external hdd
[14:10] <taaem> and I certainly don't want to migrate that
[14:11] <ogra_> right, that might not be very pracical then
[14:11] <ogra_> you could file a whishlist bug for getting an lvm snap though :)
[14:11] <ogra_> https://bugs.launchpad.net/snappy/+filebug
[14:12] <zyga> taaem: 100GB will copy in what? 5 minutes?
[14:12] <ogra_> zyga, not on a USB disk i suspect
[14:13] <ogra_> (given that it is attached to a pi i assume it is USB)
[14:13] <taaem> a good ol' hdd
[14:13] <taaem> attached over usb
[14:13] <ogra_> yeah, that gets you 400MB/s max
[14:13] <ogra_> err
[14:14] <ogra_> 400Mbit/s
[14:14] <zyga> ogra_: I just put a very old 160GB disk into a usb 3.0 case
[14:14] <zyga> ogra_: copying at 80MB/s
[14:14] <ogra_> 3.0
[14:14] <ogra_> ...
[14:14] <zyga> so?
[14:14] <zyga> anyway moot point
[14:14] <ogra_> the max for 2.0 is 24MB/s
[14:14] <ogra_> that takes quite a while
[14:14] <zyga> (not really true)
[14:14] <zyga> anyway
[14:14] <zyga> what's wrong with adt
[14:15] <taaem> its usb 2
[14:15] <zyga> tests are very sow today
[14:15] <taaem> btw
[14:15] <zyga> (usb 2.0 has different modes, some are much more efficient)
[14:15] <ogra_> zyga, release day ?
[14:15] <zyga> depends on usb/sata controller
[14:15] <zyga> ogra_: do we rebuild the world on release day
[14:15] <taaem> and I would need 100GB free on another disk to make that migration
[14:16] <ogra_> zyga, plain USB 2.0 controllers cant shovel more than 24MB/s over the bus, no matter how well the scsi->USB part is
[14:16] <ogra_> that only gets you fast  disk IO between the bus and the disk
[14:16] <ogra_> zyga, no, but the main cvonnection to the datacenter gets hammered
[14:17] <zyga> ogra_: https://en.wikipedia.org/wiki/USB_Attached_SCSI
[14:17] <taaem> ogra_: https://bugs.launchpad.net/ubuntu/+bug/1682446
[14:17] <mup> Bug #1682446: lvm is not available on Ubuntu Core <wishlist> <Snappy:New> <Ubuntu:New> <https://launchpad.net/bugs/1682446>
[14:18] <mup> Bug #1682446 opened: lvm is not available on Ubuntu Core <wishlist> <Snappy:New> <Ubuntu:New> <https://launchpad.net/bugs/1682446>
[14:18] <ogra_> The USB 2.0 specification was released in April 2000 and was ratified by the USB Implementers Forum (USB-IF) at the end of 2001. Hewlett-Packard, Intel, Lucent Technologies (now Alcatel-Lucent), NEC, and Philips jointly led the initiative to develop a higher data transfer rate, with the resulting specification achieving 480 Mbit/s, a 40-times increase over the original USB 1.1 specification.
[14:18] <ogra_> zyga, ^^^
[14:19] <ogra_> from https://en.wikipedia.org/wiki/USB
[14:19] <ogra_> The USB 3.0 specification was published on 12 November 2008. Its main goals were to increase the data transfer rate (up to 5 Gbit/s)
[14:19] <zyga> ogra_: not sure what your point is
[14:20] <ogra_> in reality you only get 400Mbit/s on 2.0 ... thanks to protocol overhead ... so it ends at 20-24MB/s
[14:20] <ogra_> and there is no way to get any faster rates over 2.0
[14:20] <zyga> ogra_: there are different protocols
[14:20] <ogra_> but there is a physical limit
[14:21] <zyga> yes but 24MB is not that limit
[14:21] <taaem> so anyway thanks for the help i'll probably install ubuntu mate and that has snap support anyway
[14:21] <ogra_> (and on a sidenote, on the pi you have the NIC on the same USB bus, so the rate is also shared)
[14:21] <zyga> taaem: good luck
[14:21] <zyga> taaem: mate on pi probably uses different kernel
[14:21] <zyga> taaem: and snaps probably won't work (last time I checked)
[14:21] <Threygoo> When is snappy going to be the default package manager for Ubuntu?
[14:22] <ogra_> i think flexiondotorg worksed on getting snap support going in u-mate in 17.04
[14:22] <ogra_> *worked
[14:22] <ogra_> Threygoo, it is already the default for Ubuntu Core
[14:22] <taaem> zyga: oh so then i'll proably wait for that to drop
[14:22] <ogra_> Threygoo, and it will unlikely replace dpkg on classic installations
[14:23] <Threygoo> Dismay at having 2 different package managers depending on Ubuntu variant.
[14:23] <Threygoo> (Desktop or Touch)
[14:23] <zyga> Threygoo: snapd and apt are different tools
[14:24] <zyga> Threygoo: there will always be a deb based version of ubuntu
[14:24] <zyga> Threygoo: but they serve diffeent goals
[14:24] <zyga> Threygoo: expect to see more software devlivered as snaps
[14:24] <zyga> Threygoo: but expect that the system software will be still managed as debs, perhaps as a step on their way to the core snap
[14:24] <zyga> Threygoo: debs and snaps are not aiming to solve the same problem
[14:26] <mcphail> Threygoo: hopefully snaps will replace PPAs
[14:26] <ogra_> yeah
[14:27] <nacc> *some* PPAs :)
[14:27] <nacc> application ones, to be clear :)
[14:27] <ogra_> nacc, are there any others ?
[14:28] <nacc> well, i use ppas for snapshot development of packages
[14:28] <ogra_> like ... the snap edge channel you mean ? :)
[14:28] <nacc> i'm not going to develop the php package in a snap
[14:28] <nacc> as it's a part
[14:28] <nacc> (in snap parlance)
[14:28] <mup> PR snapd#3180 closed: many: fixes for `go vet` in go 1.7 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3180>
[14:28] <Threygoo> Perhaps I had a misunderstanding after reading this. http://www.omgubuntu.co.uk/2017/01/ubuntu-phone-ota-15-ditched
[14:29] <nacc> ogra_: but yeah, that's an option, i suppose -- maybe even with classic confinement, i could do that
[14:29] <zyga> Chipaca: can you have a look at https://github.com/snapcore/snapd/pull/3185
[14:29] <mup> PR snapd#3185: snap: added tasks subcommand <Created by stolowski> <https://github.com/snapcore/snapd/pull/3185>
[14:29] <mup> PR snapd#3188 closed: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3188>
[14:29] <mup> PR snapd#3189 closed: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3189>
[14:49] <mup> PR snapcraft#1255 opened: Update rust plugin to set RUSTFLAGS <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/1255>
[15:05] <pstolowski> Chipaca, thanks for catching .hidden thingy!
[15:05] <Chipaca> pstolowski— :-)
[15:15] <mup> PR snapd#3175 closed: daemon: do not set RemoveSnapPath flag when doing a try <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3175>
[15:15] <mup> PR snapd#3181 closed: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3181>
[15:16]  * zyga goes through PRs and merging stuff that's ready
[15:17] <zyga> https://github.com/snapcore/snapd/pull/3179 needs a 2nd review
[15:17] <mup> PR snapd#3179: packaging: add `built-using` header for 16.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3179>
[15:19] <Chipaca> zyga— snapd#3150 is ready for review fwiw
[15:19] <mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
[15:20] <Chipaca> anyway, time for a break
[15:20] <mcphail> Nice!
[15:24] <zyga> Chipaca: thanks! Ill have a look now
[15:25] <zyga> Chipaca: question
[15:25] <zyga> Chipaca: why not include the completer helper in /etc/bash_completion.d
[15:26] <zyga> specifically asking about this part "Furthermore, at this stage to enable snap completions you need to source /usr/lib/snapd/complete.sh after sourcing /etc/bash_completion (or /usr/share/bash-completion/bash_completion). It adds a default completion handler that overrides and falls back to the usual one."
[15:35] <zyga> Chipaca: added a comment
[15:35] <zyga> Chipaca: it'd be amazing if you could try this on Fedora
[15:37] <Chipaca> zyga— can you explain what you mean with your comment?
[15:37] <Chipaca> zyga— snap-exec is always "inside", isn't it?
[15:38] <zyga> Chipaca: curious, yes
[15:38] <zyga> Chipaca: but what does snap-exec see
[15:38] <zyga> today it would see /etc/os-release is fedora
[15:38] <zyga> so it would set SnapMountDir to /var/lib/snapd/snap
[15:38] <zyga> and I suspect this would no longer work
[15:38] <zyga> because snap-confine mounts /var/lib/snapd/snap in /snap
[15:39] <zyga> Chipaca: do you have a fedora machine around?
[15:39] <Chipaca> zyga— your other comment, on data/info, it's on a change that was then reverted in a later commit or something, right?
[15:39] <zyga> Chipaca: this was just a comment, the modification is indeed reverted
[15:39] <Chipaca> zyga— I do not have a fedora machine around
[15:39] <zyga> Chipaca: fancy getting one :-D
[15:40] <Chipaca> I've done worse things for king and country
[15:40] <ogra_> did it pay off ?
[15:40] <Chipaca> zyga— any pre-built minimal image i can use?
[15:40] <Chipaca> ogra_— i changed country
[15:40] <ogra_> lol
[15:40] <zyga> Chipaca: the server image is nice
[15:41] <zyga> Chipaca: but I recommend workstation
[15:41] <zyga> Chipaca: it's really nice to see
[15:41] <zyga> Chipaca: if you have a 2nd machine or 2GB of extra RAM you can just spin up a VM
[15:41] <Chipaca> zyga— testing this on ubuntu was a bit of a pain, i must say
[15:42] <Chipaca> I was going for a VM, yes
[15:42] <Chipaca> I mean, testing completion
[15:42] <Chipaca> involved bind-mounting snap-exec
[15:42] <zyga> Chipaca: you can install snapd from the repo
[15:43] <zyga> Chipaca: and copy snap-exec and what else might be needed
[15:43] <zyga> Chipaca: there are fewer patches needed now (AFAIR just two)
[15:43] <zyga> anyway, just an idea, it's nice to try IMO
[15:44] <zyga> Chipaca: if you choose to do it I can help you out with any fedora questions
[15:45] <Chipaca> zyga— the workstation live iso is downloading
[15:45] <Chipaca> 1 minute left
[15:45] <zyga> Chipaca: excellent, thank you!
[15:46] <mcphail> Chipaca: does this work like modern bash-completion (where the completions are available as soon as the package is installed) or old bash-completion (where you have to restart the shell or source /etc/bashcompletion)?
[15:47] <Chipaca> mcphail— for now, if you have bash completion working, you need to also source one file from your .bashrc
[15:47] <mcphail> Chipaca: ok. Thanks
[15:47] <Chipaca> mcphail— once this has been kicked about some more we'll probably work with bash-completion upstream to get it working directly
[15:48] <Chipaca> i.e. your .bashrc currently has (say) “. /etc/bash_completion”
[15:48] <mcphail> yep...
[15:48] <Chipaca> after that you'd have to add a line e.g. “. /usr/lib/snapd/complete.sh”
[15:49] <Chipaca> mcphail— (just to be clear, this isn't even on master yet, so it's at least a month away from being “live”)
[15:50] <mcphail> Chipaca: no, that's OK. I've been wrangling with bash-completions for a couple of packages, one of which I've snapped. Just curious to how I'm going to implement this, as it is much needed
[15:50] <Chipaca> also i'm meaning to write a blog post (and a bit of code) around this, because it enables testing bash completers, which is apparently unheard of
[15:50] <Chipaca> mcphail— what this branch does is add a "completer" entry to snap.yaml
[15:50] <Chipaca> mcphail— and that needs to point to a file you ship that's like the snippets you shipped in /usr/share/bash-completion/completers
[15:50] <Chipaca> or was it /completions
[15:51] <Chipaca> and then stuff should just work
[15:51] <Chipaca> (modulo aliases)
[15:51] <mcphail> yep - I let pkg-config work that out for me ;)
[15:51] <Chipaca> with the completer itself running confined
[15:52] <mcphail> Look forward to testing this when it reaches us
[15:52] <Chipaca> i half expect it to fall over on its face at the lightest prodding
[15:52] <Chipaca> but so far it's holding up
[15:52] <Chipaca> (by "it" there I actually mean the whole of bash programmable completion)
[15:56] <Chipaca> eep
[15:56] <Chipaca> i get no cursor in the fedora live thing
[15:56] <zyga> Chipaca: what are you using for virtualization?
[15:57] <Chipaca> kvm
[15:57] <Chipaca> trying -vga qxl now
[15:57] <zyga> Chipaca: you may need some extra options,
[15:57] <zyga> Chipaca: one sec
[15:57] <zyga> Chipaca: it should do fine in kvm but you need to enable ..
[15:58] <Chipaca> one thing i miss from telegram is being able to annoy people by playing random muppets gifs when they're being muppetish
[15:59] <Chipaca> i'm sure that's part of the reason for the change back to irc :-p
[15:59] <mup> PR snapd#3190 opened: Change default options for Arch Linux <Created by Aimilius> <https://github.com/snapcore/snapd/pull/3190>
[15:59] <Chipaca> zyga— -vga qxl got me a cursor
[15:59] <zyga> Chipaca: try https://fedoraproject.org/wiki/Features/Spice
[15:59] <Chipaca> i can now see what i'm pointing at
[15:59] <zyga> Chipaca: this should be better (didn't try it)
[15:59] <Chipaca> yeah, no thank you
[15:59] <zyga>  qemu <disk-image> -usbdevice tablet -soundhw ac97 -vga qxl -spice port=5930,disable-ticketing -enable-kvm
[16:05] <Chipaca> ewwww
[16:05] <Chipaca> the progress bar is wrong on fedora
[16:05] <Chipaca> eww
[16:05] <Chipaca> ick
[16:05] <Chipaca> and ew
[16:05] <zyga> yes
[16:05] <Chipaca> guess what i'll be working on soonish
[16:06] <zyga> morphis knows :)
[16:06] <zyga> I suspect outdated deps
[16:06] <Chipaca> i've had a nicer progress bar in the works for ages, but never got around to polish it enough for release
[16:06] <Chipaca> mostly because i'm not happy with the terminfo thing it uses
[16:06] <Chipaca> so i shall fix terminfo over this weekend
[16:07] <Chipaca> \o/
[16:11] <zyga> Chipaca: any luck getting it to tab-complete?
[16:17] <Chipaca> zyga— it's working on core still? dunno
[16:17] <Chipaca> it seems to think it's a tablet, also
[16:17] <Chipaca> giant swipey things to unlock the screen
[16:18] <Chipaca> hah!
[16:19] <Chipaca> pedronis— you'll love this one
[16:19] <Chipaca> pedronis— panic: cannot checkpoint even after 5m0s of retries every 3s: open /var/lib/snapd/state.json.weprkog: read-only file system
[16:23] <zyga> Chipaca: wat?
[16:23] <zyga> why
[16:23] <Chipaca> zyga— i'm guessing the live iso has a readonly /var or something
[16:23] <zyga> oh
[16:23] <zyga> you are in the iso
[16:23] <zyga> install it already :)
[16:24] <Chipaca> it should work from the iso :-)
[16:24] <zyga> Chipaca: snapd doesn't work from our installers
[16:24] <zyga> aufs and stuff
[16:24] <zyga> (e.g. maas)
[16:24] <zyga> you do really need to install it
[16:25] <Chipaca> hmm
[16:25] <Chipaca> zyga— i mean
[16:25] <Chipaca> dnf install snapd worked
[16:25] <Chipaca> how is it now readonly?
[16:25] <Chipaca> the state.json even has stuff in it
[16:25] <zyga> Chipaca: mmmmm
[16:25] <zyga> no idea then
[16:25] <zyga> what is in /proc/self/mountinfo
[16:25] <zyga> I'm curious myself
[16:26] <zyga> but my fedora's are all installed
[16:26] <Chipaca> oh, looks like the kernel remounted everything readonly
[16:26] <zyga> io issues?
[16:26] <zyga> remount=ro?
[16:26] <Chipaca> looks like it
[16:26] <zyga> curiou
[16:26] <zyga> curious
[16:26] <Chipaca> maybe 2G was not enough
[16:27] <pedronis> Chipaca: love might not be the right word
[16:27] <Chipaca> pedronis— :-D
[16:29] <zyga> Chipaca: 2GB of ram and no disk?
[16:29] <zyga> pedronis: infatuation ;-)
[16:35] <Chipaca> there is a sausage on my screen telling me to join the fedora project
[16:35] <Chipaca> zyga— i blame you
[16:36] <zyga> Chipaca: it's fun :)
[16:37] <zyga> Chipaca: btw, sausage?!?
[16:37] <Chipaca> zyga— in a bun. With a squirt of mustard.
[16:37] <ogra_> is that their equivalent of clippy ?
[16:37] <ogra_> the talking sausage ...
[16:38] <zyga> Chipaca: did you install the german sausage spin? ;-)
[16:38] <zyga> Chipaca: I honestly don't know what is the sausage thing you're talking about
[16:38] <zyga> :D
[16:38] <Chipaca> zyga— it's cycled away, but if it comes back up i'll screenshot it
[16:39]  * qengho worries about Chipaca.
[16:39] <Chipaca> qengho— that makes two of us
[16:41] <Chipaca> zyga— http://imgur.com/egQDBx9
[16:41] <ogra_> clippy in a sausage dress ! i knew it
[16:41] <zyga> woah
[16:41] <zyga> I didn't see that
[16:41] <zyga> I remember the "beefy miracle" release (was it?)
[16:42] <zyga> but ... no :D
[16:42] <zyga> Pharaoh_Atem: ^^ WTF is the sausage about?
[16:42] <ogra_> yeah, the one wheer jono showed up in a sausage dress at the canonical haloween party
[16:42] <Pharaoh_Atem> ooh the Beefy Miracle
[16:42] <Chipaca> maybe it's a portrait of jono!
[16:42] <Chipaca> telling us to join fedora!
[16:42] <Chipaca> that makes sense
[16:43] <Pharaoh_Atem> it's a hot dog
[16:43] <Chipaca> s/portrait/caricature/
[16:43] <Chipaca> s/caricature/uncannily accurate depiction/
[16:43] <ogra_> http://www.phoronix.net/image.php?id=0x2011&image=ubuntu_beefy_jono1_med
[16:43] <Pharaoh_Atem> dafuq
[16:43] <Pharaoh_Atem> wow
[16:43] <Pharaoh_Atem> wut
[16:43] <zyga> hehehe
[16:43] <zyga> see
[16:43] <zyga> maybe new fedora branding
[16:43] <zyga> gone with the blue
[16:44] <Pharaoh_Atem> why is Jono the Beefy Miracle
[16:44] <zyga> add the ketchu-red
[16:44] <zyga> ketchup-red
[16:44]  * zyga shakes fist at BT keyboard
[16:44] <ogra_> Pharaoh_Atem, to praise fedora during a ubuntu helloween party
[16:44]  * Pharaoh_Atem blinks
[16:44] <ogra_> you guys released a few days before or so ...
[16:44] <Pharaoh_Atem> ah yes
[16:44] <ogra_> or a few later ...
[16:44] <Pharaoh_Atem> Fedora 17 was a Halloween release
[16:45] <Chipaca> also because jono
[16:45] <ogra_> yeah
[16:45] <Chipaca> :-)
[16:45] <Pharaoh_Atem> hmm no it wasn't
[16:45] <Pharaoh_Atem> it was a summer release
[16:45] <zyga> Chipaca: do you have that mountinfo
[16:45] <Pharaoh_Atem> anyway
[16:45] <Chipaca> zyga— which mountinfo?
[16:45] <Pharaoh_Atem> Beefy Miracle is amazing
[16:45] <zyga> Chipaca: /proc/self/mountinfo when you got read-only file system
[16:45] <Pharaoh_Atem> zyga: the Beefy Miracle comes from the days of Red Hat Linux
[16:46] <Chipaca> Pharaoh_Atem— to me, hot dog sausages do *not* go with “amazing” :-)
[16:46] <Pharaoh_Atem> back in the old Red Hat Linux edition of Anaconda, it would show an image of a hot dag and a cup of soda at a fridge
[16:46] <Pharaoh_Atem> with the shadowman badge on the fridge door
[16:46] <Pharaoh_Atem> it advised to go take a break while it installs, and said go get a snack or something :)
[16:47] <Chipaca> hah
[16:47] <Pharaoh_Atem> anyway, since then, it hid in the recesses of the Red Hat/Fedora lore, because it disappeared mostly when the RHEL/FC split occurred
[16:47] <Pharaoh_Atem> it was revived I think some time around Fedora 16 or so
[16:47] <Pharaoh_Atem> 15 or 16
[16:48] <Pharaoh_Atem> anyway, it was revived during the effort to centralize Fedora's branding and provide generic templates
[16:48] <Pharaoh_Atem> the creation of the fedora-release and centralized fedora-logos packages also needed debranded counterparts
[16:48] <Pharaoh_Atem> so William Woods, who was on the Anaconda team at the time, brought it back and created a generic Plymouth theme for it
[16:49] <Pharaoh_Atem> and Bill Nottingham created a generic-logos package along with generic-release
[16:50] <Pharaoh_Atem> ah, the generic-logos stuff existed since Fedora 8, but anyway the hot dog was used for the generic branding
[16:51] <Pharaoh_Atem> today, generic-logos is maintained by me, while generic-release is regenerated during each Fedora release development
[16:51] <zyga> Pharaoh_Atem: interesting :)
[16:51] <Chipaca> Pharaoh_Atem— to me, not knowing anything about that, suddenly to have a sausage telling me to do stuff is somewhat surprising
[16:51] <Chipaca> ¯\_(ツ)_/¯
[16:51] <Pharaoh_Atem> he was immensely popular for a time
[16:51] <Erix> does snap packages get updated with a sudo apt-get upgrade command?
[16:51] <zyga> Chipaca: let me explain the ubuntu logo for you ...
[16:51] <zyga> ;-)
[16:51] <ogra_> Erix, they upgrade themselves
[16:51] <Chipaca> zyga— I was there for that one, see :-)
[16:51] <Pharaoh_Atem> most well-known release name for Fedora is the Beefy Miracle
[16:52] <Pharaoh_Atem> it even has its own social media :)
[16:52] <Pharaoh_Atem> and website
[16:52] <Pharaoh_Atem> https://twitter.com/beefymiracle
[16:52] <Pharaoh_Atem> https://beefymiracle.org/
[16:52] <ogra_> Erix, if you want to force an update you can always run "snap refresh" though
[16:52] <zyga> Chipaca: as was I but the point is that it's equally non-obviou
[16:52] <Erix> ogra_, thanks. to be clear; with apt command or bot needed
[16:52] <Pharaoh_Atem> damn, I need to poke wwoods to fix the website
[16:52] <Pharaoh_Atem> the pictures aren't working
[16:53] <nacc> Erix: apt doesn't control snaps
[16:53] <Chipaca> Pharaoh_Atem— so does El Pollod Magnífico! https://twitter.com/accountpolld
[16:53] <Erix> ok. thanks
[16:53] <Erix> nacc
[16:53] <ogra_> Erix, snap has a systemd timer that checks for updates and applies them automatically, so you dont need to do anything
[16:54] <nacc> Erix: iirc, snaps automatically refresh periodically, and you can force an immediate with `snap refresh` -- with appropriate confinement and channels if needed
[16:54] <Chipaca> nacc— yup :-)
[16:55] <Erix> ogra_, nacc thanks
[16:55] <nacc> Chipaca: thanks :)
[16:56] <Erix> Snaps makes things so easy that I'm looking for a downside
[16:56] <Erix> :)
[16:57] <ogra_> if you find it, file a bug and we might fix it ;)
[16:57] <Erix> couldn't find any yet
[16:57] <nacc> heh
[16:58] <zyga> ogra_, Erix: snapd also has an internal timer
[16:58] <zyga> the systemd timer is used as a safety net
[16:58] <zyga> in case we get something very very wrong
[16:58] <zyga> AFAIR the timer is pretty infrequent now
[16:58] <Chipaca> 4 times a day
[16:59] <zyga> systemctl cat snapd.refresh.timer
[16:59] <zyga> 4 times a day?
[17:00]  * zyga reads what OnCalendar does
[17:00] <zyga> aha
[17:00] <zyga> I thought we made it less frequent (like 2 weeks)
[17:00] <Chipaca> zyga— systemctl list-timers snapd.refresh.timer
[17:01] <zyga> nice
[17:01] <zyga> I didn't know about this sub-command
[17:04] <Erix> it looks 3 times a day
[17:04] <Erix> passed 2h 27 min
[17:04] <ogra_> iirc the long term plan is to have the server actually send push notifications to snapd
[17:04] <Erix> left 5 h 26 min
[17:05] <ogra_> if there are snap upgrades available
[17:05] <Erix> every 8 hours
[17:05] <Chipaca> ogra_— the push story is complicated
[17:05] <ogra_> i didnt say it is easy ;)
[17:06] <Chipaca> ok, this is ot from me for today
[17:34] <mup> PR snapcraft#1256 opened: ant plugin: honour proxy configuration <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1256>
[17:39] <Guest5550> Hi guys I've installed some apps from snaps it's throwing me the following error :
[17:39] <Guest5550> Comp failed:  "file:///snap/dekko/124/usr/bin/plugins/ui/MainUI.qml:3 plugin cannot be loaded for module \"Ubuntu.Components\": Cannot load library /snap/dekko/124/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/libUbuntuComponents.so: (libmirclient.so.9: cannot open shared object file: No such file or directory)\n"
[17:39] <Guest5550> any idea what's the reason for this ?
[17:40] <nacc> Guest5550: might be a bug in the snap?
[17:40] <Guest5550> It's works fine about a month but now it's started to breaking
[17:40] <Guest5550> If i installed any app using snap it's giving me the same error
[17:45] <great_man> Hello
[17:45] <great_man> I'm facing a issue on snap apps Cannot load library /snap/dekko/124/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/libUbuntuComponents.so: (libmirclient.so.9: cannot open shared object file: No such file or directory)\n"
[17:46] <great_man> Any idea what's wrong here ?
[17:52] <mup> Bug #1682550 opened: Snap & ubuntu app platform not working <Snappy:New> <https://launchpad.net/bugs/1682550>
[18:52] <mup> PR snapd#3191 opened: many: implement snap alias <snap.app> <alias> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3191>
[18:55] <mup> PR snapd#3192 opened: many: implement snap unalias <alias-or-snap> (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3192>
[19:07] <pedronis> Chipaca: I now have a couple more aliases v2 PRs that can be reviewed, at least a first pass, they likely all need a look from Gustavo
[19:09] <lazyPower> I seem to recall having seen a go plugin that gives the snap builder an option to choose the go version, is that the case or are we relying on scriptlets pending bug 161985 being resolved?
[19:09] <mup> Bug #161985: support i18n plural forms <zope.i18n:Won't Fix> <Zope 3:Won't Fix> <https://launchpad.net/bugs/161985>
[19:09] <lutostag> anybody else hitting, https://bugs.launchpad.net/snappy/+bug/1611078/comments/29 I am too, can't seem to get snaps working in my lxcs, even though they did before...
[19:09] <mup> Bug #1611078: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <verification-failed-xenial> <Snappy:Fix Released by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <apparmor (Ubuntu
[19:09] <mup> Xenial):Fix Released by tyhicks> <linux (Ubuntu Xenial):Fix Released by jjohansen> <lxd (Ubuntu Xenial):Fix Committed> <apparmor (Ubuntu Yakkety):Fix Released
[19:09] <mup> by tyhicks> <linux (Ubuntu Yakkety):Fix Released by jjohansen> <lxd (Ubuntu Yakkety):Fix Released by stgraber> <https://launchpad.net/bugs/1611078>
[19:09] <lazyPower> whoops i mean  bug 1616985
[19:09] <mup> Bug #1616985: the go plugin doesn't support go 1.7 <isv> <plugin> <Snapcraft:Confirmed for sergiusens> <https://launchpad.net/bugs/1616985>
[19:17] <tyhicks> lutostag: are you hitting the issue in an unprivileged container or in a privileged container?
[19:17] <tyhicks> snaps aren't currently supported inside of privileged containers
[19:18] <lutostag> tyhicks: well that would be a good reason, wouldnt it... ;) I'll retry
[19:18] <tyhicks> lutostag: the good news is that it'll likely be supported soon thanks to https://github.com/lxc/lxd/pull/3155
[19:18] <mup> PR lxc/lxd#3155: Enable stacking for privileged containers <Created by stgraber> <Merged by brauner> <https://github.com/lxc/lxd/pull/3155>
[19:19] <lutostag> tyhicks: nope, doesnt work with a priviledged container...
[19:19] <tyhicks> lutostag: that's expected
[19:19] <lutostag> tyhicks: might it also be that I'm using snapped lxd rather than an apt install?
[19:20] <tyhicks> lutostag: it will only work in an unprivileged container today
[19:20] <lutostag> oh, I just did unpriviledged before that too
[19:20] <lutostag> still did not work
[19:20] <stgraber> lutostag: what kernel are you running exactly?
[19:20] <lutostag> I'm on zesty too, which may be the thing
[19:20] <lutostag> Linux doe 4.10.0-19-generic #21-Ubuntu SMP Thu Apr 6 17:04:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[19:21] <stgraber> lutostag: what version of Ubuntu are you using for the container?
[19:21] <lutostag> (and yes I installed squashfuse of course...)
[19:22] <lutostag> I tried both xenial and zesty
[19:22] <lutostag> I'll spin up a yakkety for good measure to
[19:24] <stgraber> lutostag: zesty with a 4.10.0-19-generic kernel and a xenial container works fine here
[19:24] <stgraber> lutostag: does /sys/module/fuse exist on your system?
[19:24] <lutostag> stgraber: host or container?
[19:24] <stgraber> same thing for that particular path
[19:25] <lutostag> stgraber: it does
[19:30] <lutostag> wrong fs type, bad option, bad superblock on /var/lib/snapd/snaps/core_1577.snap (but that would be the somewhat-not-informative line from systemctl status snap-core-1577.mount)
[19:45] <stgraber> lutostag: what do you get if you manually run: /bin/mount /var/lib/snapd/snaps/core_1577.snap /snap/core/1577 -t fuse.squashfuse -o ro,allow_other
[19:46] <lutostag> stgraber: mount: wrong fs type, bad option, bad superblock on /var/lib/snapd/snaps/core_1577.snap
[19:47] <lutostag> which seems like squashfuse isnt installed in the container, but dpkg -l says it is
[19:47] <lutostag> (and reran for good measure)
[19:47] <stgraber> lutostag: hmm, what container image did you use exactly?
[19:47] <lutostag> lxc launch images:ubuntu/yakkety
[19:47] <lutostag> and xenial and zesty
[19:47] <stgraber> ok, then that's the problem
[19:48] <stgraber> looks like squashfuse is missing a dependency on "fuse"
[19:48] <stgraber> which is part of the official Ubuntu images but not in the community images
[19:48] <stgraber> so if you use "lxc launch ubuntu:16.04" it'll work (after you install squashfuse)
[19:48] <stgraber> but if you use "images:ubuntu/xenial" you'll need to install "fuse" and "squashfuse"
[19:48] <lutostag> stgraber: yep, thats it indeed
[19:49] <lutostag> apt install fuse worked like a charm
[19:49] <lutostag> stgraber: sorry for the rigamarole, thanks ;)
[19:49] <stgraber> I'll fix the squashfuse packaging whenever the next Ubuntu release is open for development
[19:50] <lutostag> stgraber: appreciated... and if you're in for another separate riddle...
[19:51] <lutostag> which I think falls more on the snap side than lxd...
[19:52] <lutostag> on ubuntu core 16, if I run the default lxd daemon snap via /bin/snap run lxd falls over in certain situations, and I need to run it as root rather than via the included service file... https://gist.github.com/lutostag/a997f9189c1ae299a313853ecf4b14a7#file-rpi-setup-sh-L86 is what I cobbled together to prevent lxd daemon from spinning up and dieing repeatedly
[19:54] <lutostag> only happens after giving it a /dev/net/tun forwarded to the container
[19:55] <lutostag> anywho I'll have to file a full bug with a smaller repro for reals
[19:55] <lutostag> thanks again
[20:10] <mup> PR snapcraft#1230 closed: lxd: refactor Cleanbuilder into Containerbuild and add Project <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1230>
[20:16] <mup> PR snapd#3187 closed: interfaces/mount: improve go identifier names of mountinfo, parse optional fields <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3187>
[20:24] <mup> PR snapd#3193 opened: interfaces/mount: parse mount options to map[string]string <Created by zyga> <https://github.com/snapcore/snapd/pull/3193>
[20:55] <mup> PR snapcraft#1257 opened: core: support running from other operating systems <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1257>
[21:37] <Croepha> just curious, but when would we be likely to see patches that are going into the ubuntu proper kernel, (Specifically the Intel HDMI auto patches that are in the 4.11 testing kernel) into the ubuntu core pc-linux kernel?
[21:37] <Croepha> intel HDMI audio
[22:26] <mup> PR snapd#3194 opened: tests: copy snap-confine apparmor profile into testbed <Created by zyga> <https://github.com/snapcore/snapd/pull/3194>
[22:27]  * zyga wonders if anyone from the core team is around
[22:27] <zyga> if so, please review the ^^ one liner
[22:53] <zyga> jdstrand: thanks :)
[22:54] <jdstrand> np
[22:56] <zyga> jdstrand: btw, did you see http://klee.github.io/
[22:57] <jdstrand> no, that's cool
[22:58] <zyga> jdstrand: http://www.doc.ic.ac.uk/~cristic/papers/klee-osdi-08.pdf
[22:58] <zyga> this is why I think this is interesting
[23:00] <jdstrand> yeah, I skimmed it. it does seem interesting
[23:03] <ogra_> zyga, approved
[23:03] <zyga> ogra_: thanks
[23:03] <zyga> I'm fixing 14.04 case
[23:03] <zyga> where we dind't rename the aa profile to .real
[23:03] <zyga> eh :)
[23:03] <zyga> life
[23:54] <mup> PR snapd#3194 closed: tests: copy snap-confine apparmor profile into testbed <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3194>


[09:04] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/4304 Needs rebuild due to higher version at destination (groovy/golang-github-lucas-clemente-quic-go). Ready to build (groovy/qtdeclarative-opensource-src)
[09:25] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/4304 Ready to build
[12:31] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4291 Needs rebuild due to higher version at destination
[13:55] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4274 Pending binary packages
[14:05] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/4304 Currently building (groovy/qtbase-opensource-src). Failed to build (groovy/qtdeclarative-opensource-src). Ready to build (groovy/badger, groovy/golang-github-lucas-clemente-quic-go, groovy/syncthing)
[14:14] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4274 Successfully built
[15:18] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4305 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[16:06] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4305 Currently building (groovy/cantor, groovy/dolphin, groovy/elisa-player, groovy/gwenview, groovy/kamoso, groovy/kate, groovy/kde-spectacle, groovy/kdialog, groovy/kget, groovy/kiten, groovy/kmix, groovy/konsole, groovy/kpat, groovy/krfb, groovy/libkf5kmahjongg, groovy/libkgapi, groovy/lokalize, groovy/okular). Failed to build (groovy/k3b). Pending binary packages (groovy/kajongg)
[16:26] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4305 Currently building (groovy/cantor, groovy/dolphin, groovy/gwenview, groovy/kate, groovy/kde-spectacle, groovy/kdialog, groovy/kget, groovy/kiten, groovy/kmix, groovy/konsole, groovy/kpat, groovy/krfb, groovy/lokalize, groovy/okular). Failed to build (groovy/elisa-player). Needs building (groovy/libkf5kmahjongg, groovy/libkgapi). Pending binary packages (groovy/kajongg). Uploading build (groovy/
[16:46] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4305 Currently building (groovy/cantor, groovy/dolphin, groovy/gwenview, groovy/kate, groovy/kget, groovy/kiten, groovy/kmix, groovy/konsole, groovy/kpat, groovy/lokalize, groovy/okular). Diff missing (groovy/kajongg, groovy/kde-spectacle). Failed to build (groovy/elisa-player). Needs building (groovy/krfb, groovy/libkf5kmahjongg, groovy/libkgapi). Pending binary packages (groovy/kamoso, groovy/kdia
[18:05] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/4304 Currently building (groovy/qtbase-opensource-src). Dependency wait (groovy/qttools-opensource-src). Failed to build (groovy/qtdeclarative-opensource-src). Ready to build (groovy/badger, groovy/golang-github-lucas-clemente-quic-go, groovy/syncthing)
[19:46] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4305 Diff missing (groovy/cantor, groovy/dolphin, groovy/elisa-player, groovy/gwenview, groovy/kajongg, groovy/kamoso, groovy/kate, groovy/kde-spectacle, groovy/kdialog, groovy/kiten, groovy/kmix, groovy/konsole, groovy/kpat, groovy/krfb, groovy/libkf5kmahjongg, groovy/libkgapi, groovy/lokalize). Pending binary packages (groovy/kget, groovy/okular)
[19:59] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4305 Generating diffs
[20:01] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4305 Successfully built
[20:06] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4305 Publishing packages
[20:26] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4305 UNAPPROVED queue