[02:55] <mup> Issue snapcraft#1667 closed: Walk the prime directory for elf files and flag the glibc required version <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1667>
[02:55] <mup> PR snapcraft#1843 closed: elf: warn if primed files will not work with the base's linker <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1843>
[04:44] <lohroc> I installed the Brave browser using snapcraft but it changes my mouse cursor while its over it.
[04:45] <lohroc> How do I keep the system cursor over it?
[04:47] <Chipaca> lohroc: we're working on that still
[05:59] <mborzecki> morning
[06:30] <zyga> mborzecki: bad morning
[06:30] <zyga> mborzecki: look at lwn and everywhere
[06:30] <mborzecki> zyga: hey
[06:31] <mborzecki> yeah, and we're not even past the blue monday
[06:32] <mborzecki> btw. must be especially hard if you're a verification engineer at intel
[06:37] <zyga> mborzecki: I think they can use speculative execution to live as if nothing had happened ;-)
[06:42] <mborzecki> zyga: meanwhile, did you manage to go through #4313 by any chance? :)
[06:42] <mup> PR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>
[06:43] <zyga> mborzecki: not all of it, as I said yesterday I didn't sleep well and coundn't focus on reviews with meaningful results
[06:43] <zyga> mborzecki: I'll sort out children & school and get back to it
[06:43] <mborzecki> sure, no rush :) thanks for looking at it
[07:00] <zyga> allright
[07:00] <zyga> coffee and small school run, to pay for food, and I'll be back
[07:02] <zyga> today I will sleep (slightly) better knowing that my destkop is an AMD machine
[07:23] <mborzecki> zyga: nice technical writeup if you haven't read it yet: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
[07:27] <zyga> mborzecki: thanks, very interesting and very scary
[07:44] <jamesh> zyga: not all the vulnerabilities are Intel-only
[07:51] <kalikiana> snappy good morning
[07:51]  * kalikiana coffee
[07:52] <zyga> jamesh: yes, I know that
[07:52] <zyga> jamesh: but the low hanging fruit will go after intel first
[07:52] <zyga> jamesh: spectre is fully generic
[08:11] <jamesh> zyga: picking up from last year, what's the best way forward with the user mounts feature?
[08:33] <zyga> jamesh: I need to review that, I don't rememer; I think it was green on tests and you addressed prior feedback
[08:33] <zyga> jamesh: I'll collect my thoughts and respond today on the PR
[08:35] <jamesh> zyga: it passed CI, yeah.  There was some discussion on the forum, but it died out as we hit the holidays.  It wasn't clear which things were "must be implemented before merge" and what was "should be implemented eventually"
[08:36] <jamesh> zyga: I think this thread came up after you finished up last year too: https://forum.snapcraft.io/t/interacting-with-dbus-daemons-app-container-feature/3245 -- it will probably have some impact on mount namespace construction should we adopt it
[08:44] <mup> PR snapd#4439 closed: Add documentation for supported Go versions <Created by sparkiegeek> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4439>
[08:47] <mborzecki> mvo: morning
[08:47] <mvo> hey mborzecki - good monring
[08:47] <mvo> mborzecki: feel free to releease test-snapd-classic anywhere you neeed it (re your question in the PR)
[08:48] <mborzecki> mvo: great :) can you also approve the i386 snap?
[08:48] <mvo> sure
[08:49] <mvo> mborzecki: its there for you
[08:49] <mborzecki> thanks
[08:51] <mborzecki> hmm funny output from snapcraft, snap version seems to be printed as string or a number? https://paste.ubuntu.com/26318133/
[08:53] <mvo> mborzecki: yeah, there is a bug about this in LP, let me check
[08:53] <mvo> mborzecki: 1669291 where it behaves similarly
[08:54] <mvo> mborzecki: you can workaround via `version: "1.0"`
[08:56] <mborzecki> mvo: right, that's your PR with the test as well #4437
[08:56] <mup> PR #4437: tests: add test that ensures we never parse versions as numbers <Created by mvo5> <https://github.com/snapcore/snapd/pull/4437>
[09:08] <mup> PR snapcraft#1846 opened: Add files via upload <Created by Nissaar> <https://github.com/snapcore/snapcraft/pull/1846>
[10:27]  * kalikiana coffee break
[10:41] <jamesh> zyga: one other question: a while back you said you might be looking at implementing the content interface improvements (allowing multiple snaps to share content to one snap).  Was any progress made on that?
[10:42] <zyga> jamesh: that is mostly ready and waiting for prerequsite to land, https://github.com/snapcore/snapd/pull/4068
[10:42] <mup> PR #4068: interfaces/builtin: add support for content "source" section <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4068>
[10:42]  * jamesh looks
[10:42] <zyga> jamesh: yesterday I merged the code for writable mimic and it should unblock this PR later today, I have one more integration PR to land
[10:43] <jamesh> zyga: awesome.  People were asking about theme support, so it'll be good to have something to build on top of
[10:43] <zyga> I see there are two minor conflicts there but that's really not a problem
[10:45]  * zyga needs more coffee, not sure if weather or something else but I feel like sleeping today :/
[10:50] <kalikiana> zyga: yeah, felt oddly sleepy this morning as well, and it's raining lions and wolves to no end
[10:51] <zyga> kalikiana: I actually woke up at 6:30 but then took a nap :/
[10:51] <zyga> I'm terrible today
[10:52] <kalikiana> naps are awesome. big benefit of working from your house that you can do that easily
[10:58] <Chipaca> zyga: you misspelled "awesome"
[10:58] <zyga> that's one awesome typo ;-)
[10:59] <zyga> but while I'm terrible the world is more terrible so that's ok
[11:06] <Chipaca> mvo: one problem i'm bumping into to easily use your approach at making things testable is that the database needs opening, and closing, around the searches
[11:07] <Chipaca> mvo: i.e. we probably shouldn't hold it open for the duration (but we could, with the argument that 'snap advise' is short lived)
[11:07] <mvo> Chipaca: I see, we can add open/close to the interface
[11:08] <Chipaca> mvo: well... open is weird because it's usually a constructor, not part of the interface
[11:08] <Chipaca> but if it makes things easier i could do that
[11:10] <Chipaca> mvo: seems more natural to make ReplaceCommandsFinder(constructor) instead
[11:10] <mvo> Chipaca: yeah, fine with me
[11:10]  * Chipaca runs with it
[11:10] <Chipaca> and, yes, adding Close() to Finder
[11:20] <mvo> Chipaca: fwiw, there is a deb package for github-boltdb-bolt already so maybe we use that as the starting point (not the fork from coreos)
[11:20] <Chipaca> mvo: can we rename the command to 'advise' instead of 'advice'?
[11:20] <Chipaca> mvo: the former is a verb, the latter is a noun
[11:20] <mvo> Chipaca: sure
[11:21] <Chipaca> mvo: i'm not using the fork, fwiw
[11:22] <mvo> Chipaca: cool
[11:23] <Chipaca> mvo: on the grounds that it's unclear which one we want, but it's easier to move downfork than upfork in this case
[11:25]  * mvo nod
[11:28] <mup> PR snapd#4440 opened: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
[11:53]  * sergiusens waves
[11:53]  * sparkiegeek particles
[11:53] <sergiusens> going to be starting a little later today though as I am home alone with my son who is just waking up
[11:54] <sergiusens> sparkiegeek it was to early to make sense of that on the first read :-P
[11:54] <sergiusens> duality ftw :-)
[11:56] <sparkiegeek> sergiusens: just having to let off steam after seeing Meltdown/Spectre and the ensuing world burning
[12:02] <kalikiana> sergiusens: o/
[12:06] <pedronis> mvo:  I updated  #4392 , in some cases with test comments instead of code changes
[12:06] <mup> PR #4392: many: refresh with appropriate creds <Created by pedronis> <https://github.com/snapcore/snapd/pull/4392>
[12:07] <mvo> pedronis: thank you, I have a look. comments are fine of course
[12:27] <mvo> pstolowski: do we have plans for making daemon starts options via some hook? context is lp 1664163
[12:31] <ogra_> sergiusens, could we land the patch from Bug #1740882 soon into the edge snap ?
[12:31] <mup> Bug #1740882: Missing initrd.img-core in os.snap <Snapcraft:New> <https://launchpad.net/bugs/1740882>
[12:31] <pstolowski> mvo, it's already possible to stop/start services from hooks via snapctl start/stop, but of course the fact that they start automatically on install is an issue
[12:33] <pstolowski> mvo, and yes, maybe we need a dedicated hook for start-services as now it's either install hook or refresh hook, not convienient
[12:34] <mvo> pstolowski: sounds like we need to turn it into a feature request
[12:37] <zyga> mborzecki: man you have a lot of types in that PR
[12:38] <mborzecki> zyga: which one?
[12:38] <zyga> mborzecki: the 1K one
[12:38] <zyga> 4313
[12:40] <mborzecki> right, it grew a 'bit'
[12:55] <mup> PR snapd#4441 opened: snap: add usage hints in `snap download` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4441>
[13:23] <zyga> mborzecki: added one more comment, as my understanding of what the schedule is
[13:23] <zyga> mborzecki: if it's inaccurate please comment
[13:23] <zyga> (on it ;)
[13:25] <Chipaca> to add a package to govendor, am i supposed to edit vendor.json directly?
[13:25] <zyga> Chipaca: no
[13:25] <zyga> Chipaca: I think you want to use the CLI to vendor one more entry
[13:25] <zyga> Chipaca: otherwise vendor will likely rewrite your change and introduce an ever-conflicting change
[13:25] <Chipaca> zyga: how do you do that?
[13:26] <zyga> Chipaca: go get something and then govendor add
[13:26] <Chipaca> zyga: 'govendor get thing...?'
[13:26] <zyga> Chipaca: govendor --help has (to long) help
[13:26] <pedronis> Chipaca: govendor fetch
[13:27] <pedronis> see govendor fetch --help
[13:27] <zyga> mborzecki: for readability I would perhaps reorder the stuff in schedule.go to have all the types first, followed by all the function
[13:27] <zyga> *functions
[13:27] <Chipaca> pedronis: thanks, that worked
[13:27] <Chipaca> govendor fetch +missing
[13:28] <Chipaca> this works despite 'govendor list +missing' getting confused with a 'context' package
[13:33] <mborzecki> zyga: tried to keep the <type, type-methods, type .., parser-functions> order throught the file, it does take a bit of back and forth when reviewing though, that i agree with
[13:34] <mborzecki> zyga: while you're doing review, can you a quick 2nd pass on #4434 ?
[13:34] <mup> PR #4434: tests/main/confinement-classic: enable the test on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4434>
[13:34] <zyga> mborzecki: yep
[13:34] <mborzecki> thanks
[13:37] <zyga> mborzecki: approved
[13:37] <mborzecki> zyga: great, thanks
[13:39]  * kalikiana looking forward to lunch in a few minutes
[13:43] <Chipaca> mvo: https://github.com/mvo5/snappy/compare/snap-advice-command...chipaca:commands-catalog
[13:46] <Chipaca> mvo: piggyback material, or its own PR?
[13:46] <mvo> Chipaca: looking
[13:50] <mvo> Chipaca: own PR is my gut feeling, happy to review
[13:50] <mvo> Chipaca: misspelling mispelling is ironic
[13:50] <Chipaca> mvo: remember mod_speling?
[13:50] <mvo> heh
[13:51] <mup> PR snapcraft#1847 opened: lxd: Use user in container when mounting remote via sshfs <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1847>
[13:52] <Chipaca> mvo: #4442
[13:52] <mup> PR #4442: many: implement the advisor backend, populate it from the store <Created by chipaca> <https://github.com/snapcore/snapd/pull/4442>
[13:52] <Chipaca> maybe i should close it and open it again when it's #4444 :-D
[13:52] <mup> PR snapd#4442 opened: many: implement the advisor backend, populate it from the store <Created by chipaca> <https://github.com/snapcore/snapd/pull/4442>
[13:53] <ogra_> cyphermox, mind taking a look at https://forum.snapcraft.io/t/standard-for-bootstrapping-network-on-raspberry-pi-and-similar-devices/3137 ? (we're wonderign how complex of a wpa-supplicant-only config you can have with plain netplan without NM installed on core)
[13:54] <sergiusens> ogra_ there's a PR with failing tests from ppisati
[13:54] <ogra_> sergiusens, damn
[13:55] <ogra_> i'm really not eager to fiddle with a local build to be able to roll a kernel snap :/
[13:55] <ogra_> but i guess that is what it boils down to then
[13:56] <sergiusens> ogra_ or revert the breakage in the core snap ;-)
[13:56] <ogra_> sergiusens, and get mvo grumpy at me at the 4th day of the year already ? naaaah
[13:57] <ogra_> sergiusens, happy new year btw :)
[14:03] <mvo> sergiusens, ogra_ reverting is not a bad idea actually, maybe not reverting but doing the symlink the other way around?
[14:05] <ogra_> mvo, sounds fine too
[14:06] <ogra_> eventually we want the one in /boot completely gone anyway and just use the other one
[14:06] <mup> PR snapcraft#1848 opened: Fixes for Errors <Created by Tanesh1701> <https://github.com/snapcore/snapcraft/pull/1848>
[14:06] <ogra_> (with split initrd)
[14:43] <mborzecki> off to pick up the kids
[14:51] <sergiusens> zyga are snap relocations a thing already?
[14:52] <sergiusens> zyga I could really use it so I don't depend on the snap name for the path :-)
[14:52] <sergiusens> ogra_ I cannot wait for split initrd, it has been 3 years since we said it should be done ;-)
[14:53] <ogra_> sergiusens, i was nearly done and then changed teams ... now i'm busy with customers :/
[14:53] <ogra_> it *will* happen though :)
[14:53] <ogra_> (needs snapd changes )
[14:56] <ogra_> jdstrand, bah, you are to fast ... i wanted to talk to you about usbmon after my meeting in 1h :P
[14:56] <ogra_> err ... usbtop
[14:56] <zyga> sergiusens: what are snap relocations?
[14:56] <ogra_> zyga, snaps that move from barcelona to warsaw :)
[14:56] <zyga> ogra_: hahaha
[14:57] <zyga> ogra_: with children proceses
[14:57] <ogra_> (happy new year)
[14:57] <ogra_> indeed !
[14:57] <zyga> ogra_: thank you, happy new year :)
[14:57]  * zyga wrote a new thing http://fyke.local:1313/post/core-snap-refresh-and-your-app/
[14:57] <ogra_> thx
[14:57] <zyga> and should write code but writing text is easier today
[14:58] <zyga> and I'm not feeling like tryin 5th coffee to feel awake
[14:58] <ogra_> zyga, my desktop has a really hard time to resolve fyke.local ;)
[14:58] <zyga> oh
[14:58] <zyga> shit
[14:58] <zyga> https://new.zygoon.pl/post/core-snap-refresh-and-your-app/
[14:58] <zyga> I'm obviously not in my good working order today
[14:59] <ogra_> well... it is early in the year :)
[15:00] <kalikiana> re
[15:00] <zyga> ogra_: with the trend I will die before the month is over ;-)
[15:00] <ogra_> lol
[15:00] <sergiusens> zyga if that is true, does that blog post require any proof reading?
[15:01] <zyga> sergiusens: please, I'm always happy to accept correction
[15:01] <zyga> s
[15:01] <zyga> (see)
[15:01] <zyga> sergiusens: there are more posts from the last two days if you want to see those too
[15:04] <mup> PR snapd#4437 closed: tests: add test that ensures we never parse versions as numbers <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4437>
[15:17] <Chipaca> zyga: “it is still fundamental you pretty much every snap application out there.”
[15:26] <zyga> Chipaca: ah, thanks, bad edit
[16:13] <mup> PR core#67 opened: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin <Created by mvo5> <https://github.com/snapcore/core/pull/67>
[16:19] <mvo> sergiusens: do you happen to know from what channel the snapcraft kernel plugin pulls?
[16:21] <sergiusens> mvo I can check
[16:21] <sergiusens> mvo stable... it used to be edge
[16:22] <ogra_> yeah, sadly that means it wont speed up anything to fix it in core
[16:23] <mvo> sergiusens, ogra_ hm, so we need a new stable core with the fix or an update to snapcraft to unbreak people?
[16:23] <ogra_> right
[16:23] <ogra_> https://launchpadlibrarian.net/352266605/0001-kernel-plugin-update-initrd.img-core-path-to-root-bo.patch
[16:23] <ogra_> its  a one liner for snapcraft
[16:24] <ogra_> but apparently some tests fail for the actual PR
[16:24] <sergiusens> ogra_ just fix the tests in the PR ;-)
[16:25] <ogra_> well, i need a kernel snap from some customer tree, atm i'm just reverting to the snapcraft deb and hack the one liner into it :P
[16:25] <sergiusens> ogra_ I can look at it later today, but that's what I have been telling everyone lately and not getting to it ;-)
[16:26] <sergiusens> ogra_ you can also just copy the kernel plugin to your snap and make the change there
[16:26] <ogra_> sure ... but i'm lazy :P
[16:26] <sergiusens> ogra_ then it keeps working for buildd
[16:26] <mvo> sergiusens: it looks like ppisati already updated the unit tests, tests are running
[16:27] <zyga> mborzecki: still here?
[16:30] <mborzecki> zyga: yeah, what's up?
[16:31] <zyga> mborzecki: I added some more comments
[16:31] <zyga> mborzecki: the code is +1, I was just trying to help others that look at it without rich context
[16:31] <zyga> mborzecki: not sure if you want me to +1 and let you consider any of the comments or rather wait
[16:33] <mborzecki> zyga: you can go ahead and +1 :)
[16:33] <mborzecki> my plan is to fix the format in the clockspan line and add the contst for LastWeek/EveryWeek
[16:34] <zyga> mborzecki: thanks! I just found that cleaner
[16:35] <mborzecki> zyga: btw. are you taking a day off tomorrow?
[16:35] <Chipaca> zyga: https://forum.snapcraft.io/t/hello-world-snap-gives-cannot-bind-mount-the-mount-namespace-file-on-debian-testing/3410 says hi
[16:35] <zyga> mborzecki: no,
[16:35] <zyga> Chipaca: looking
[16:35] <Chipaca> zyga: :-)
[16:36]  * Chipaca feels he should be typing in all-caps because the wind is very loud atm
[16:37] <mborzecki> zyga: me neither, i'll probably take it on some other date
[16:37] <mborzecki> tomorrow's a bit unexpected
[16:37] <zyga> hmm, what's tomorrow?
[16:39] <pstolowski> zyga, it's for the holiday on jan 6th
[16:39] <zyga> aah
[16:39] <pstolowski> just learned this too ;)
[16:39] <zyga> well
[16:39] <zyga> no, I'll work, i need to finish stuff and I'm very slow :/
[16:39] <mup> PR snapcraft#1848 closed: Fixes for Errors <Created by Tanesh1701> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1848>
[16:42] <Chipaca> mvo: who should we hug harder to update snapd in debian?
[16:44] <pedronis> Chipaca: maybe, though is probably worth waiting for 2.31
[16:44] <pedronis> for that
[16:44] <mvo> Chipaca: probably mwhudson
[16:44] <mvo> Chipaca: but yeah, maybe 2.31 - maybe
[16:44] <zyga> pedronis: in sid we can just keep on updating, no need to wait
[16:44] <mvo> there will be good stuff in it
[16:44] <zyga> and incrementals are easier (less dep churn)
[16:44] <pedronis> zyga: from a less work pov
[16:45] <pedronis> I mean we definitely want some fixes coming with 2.31
[16:45] <zyga> pedronis: not clear if less if there are deps it's the same amount, it's just a version bump
[16:45] <mborzecki> pstolowski: would you mind taking a look at #4373 once more?
[16:45] <mup> PR #4373: snap: app startup after/before validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4373>
[16:45] <pstolowski> mborzecki, sure
[16:45] <mborzecki> pstolowski: thanks
[16:52] <oSoMoN> jdstrand, hey, I have renamed the “play0ad” snap to “0ad”, and the process-control interface was automatically being connected for play0ad (required to make the game run with strict confinement), I'm wondering if that privilege can be transferred to 0ad?
[16:52] <oSoMoN> or do I need to start a new thread on the forum to do the request again?
[16:53] <mup> PR snapd#4438 closed:  snap: add new `snap advice-command` skeleton <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4438>
[16:55] <kenvandine> mvo, any chance of getting your xdg-settings PR merged soon?  PR #4073
[16:55] <mup> PR #4073: snap: add io.snapcraft.Settings to `snap userd` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4073>
[16:58]  * kalikiana wrapping up for today
[17:03] <jdstrand> oSoMoN: nah. I'll just do it
[17:04] <behalebabo> Making my first snap for a SDL2/OpenGL based game, atm all is working except audio. When in strict confinement, audio does not work and I receive the relevant errors: https://paste.ubuntu.com/26320346/ Adding browser-support to plugs or connecting process-control does work, but are these really necessary for a game?
[17:05] <behalebabo> that's snapd <IP_ADDRESS> on ubuntu 16.04
[17:05] <zyga> behalebabo: hey
[17:05] <zyga> that will go away (as a necessity) with some upcoming work on EPERM from seccomp filters, this is not finished though
[17:07] <oSoMoN> jdstrand, thanks
[17:07] <behalebabo> zyga: alright, what do you recommend I use in the meanwhile?
[17:07] <jdstrand> oSoMoN: done
[17:08] <zyga> behalebabo: I don't know honestly, ideally we could get rid of setpriority call but that may not be trivially easy
[17:08] <zyga> maybe we can use a preload trick to make that a no-op
[17:09] <oSoMoN> thanks jdstrand
[17:09] <oSoMoN> just in time for me to call it a day :)
[17:10] <jdstrand> behalebabo: for now, use process-control and follow this https://github.com/snapcore/snapd/pull/3998
[17:10] <mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
[17:10] <jdstrand> behalebabo: or adjust your snap to comment out setpriority
[17:11] <sborovkov> Hi, why does snapcraft return non zero exit code when uploaded snap requires manual review?
[17:11] <sborovkov> can I make it ignore this?
[17:12] <mvo> Chipaca: quick brainstorm about bug #1665787 - this is about "snap install snap-with-no-revision-in-stable" shows a generic "not-found" instead of providing something more useful. right now the store does not give us any context, so to fix this after each 404 we would have to do another round-trip to the store and query with `channel=""` (any) or we need store support. how do you feel about this? do you think the extra roundtrip is worth it?
[17:12] <mup> Bug #1665787: snap install with correct name and wrong channel gives misleading error <snapd:Triaged> <https://launchpad.net/bugs/1665787>
[17:13] <Chipaca> mvo: are you sure the error message is the same, from the store?
[17:14] <mvo> Chipaca: I think so, I did https://paste.ubuntu.com/26320508/
[17:14] <Chipaca> mvo: i seem to recall it being subtly different
[17:14] <mvo> Chipaca: oh, maybe too subtle for me, let me check
[17:14] <mvo> Chipaca: that would be great if so
[17:15] <Chipaca> mvo: yeah, the *message* is different
[17:15] <mvo> Chipaca: indeed, the "message" is different
[17:15] <Chipaca> which is rather brittle, but maybe enough until it's done properly
[17:15] <mvo> Chipaca: not sure if we can/should rely on this :/
[17:15] <mvo> Chipaca: yeah, I can add a store task to make this less brittle and run with it for now
[17:16] <Chipaca> (i mean: as i understand, we want to be told "this snap exists in stable on armhf, or in beta on amd64" or somesuch)
[17:16] <mvo> Chipaca: maybe, having a reliable way to just tell the user "try snap info <snap>" is already a big win
[17:16] <Chipaca> mvo: note the 'this context' includes architecture, so if you were only going to check channels it might be wrong
[17:16] <mvo> Chipaca: vs "not found"
[17:16] <mvo> Chipaca: autsch, ok
[17:16] <Chipaca> at least, i think it does
[17:16]  * Chipaca checks
[17:18] <Chipaca> mvo: yes, it includes arch
[17:18] <Chipaca> mvo: that is, there's no way to tell if it means 'other arch' or 'other channel'
[17:18] <Chipaca> mvo: however, if it doesn't say "in the given context", you know it's really not there
[17:18] <mvo> Chipaca: hm, I think that is unfortunate
[17:21]  * zyga -> tea
[17:39] <pedronis> the store doesn't know either, it would need to do the equivalent of some other queries as well
[17:39] <mup> PR snapcraft#1849 opened: tests: add snap not found tests <Created by daniellimws> <https://github.com/snapcore/snapcraft/pull/1849>
[17:54] <mup> PR snapd#4443 opened: snap: improve error for snaps not available in the given context <Created by mvo5> <https://github.com/snapcore/snapd/pull/4443>
[18:44] <kyrofa> elopio, I finally realized what you were talking about regarding needing to allow community contributions for CC on youtube
[18:45] <elopio> kyrofa: but I hate it, I want to move those contributions to github.
[18:45] <kyrofa> elopio, we can do that by having a repo for timing files
[18:45] <kyrofa> And then upload them ourselves
[18:45] <kyrofa> Have you ever made one of those?
[18:46] <elopio> kyrofa: working on that: https://github.com/elopio/snapcraft-videos
[18:46] <kyrofa> Great minds apparently
[18:46] <elopio> that's why I asked for your transcripts.
[18:59] <kyrofa> elopio, how would you like me to get those to you?
[18:59] <kyrofa> I have the latest one prepped
[19:00] <elopio> kyrofa: you can make a pull request, or send them to my email.
[19:01] <elopio> I have a big list of things pending to put in the repo, so both are fine.
[19:02] <kyrofa> elopio, is the description.txt the script?
[19:02] <kyrofa> Oh, I see script.txt in a few
[19:03] <kyrofa> elopio, can I get some guidance on what these various files are?
[19:04] <elopio> kyrofa: the idea is to have a readme per video, linking to a file with the description, a file with the script and a file with the english subtitiles
[19:05] <elopio> then, translations will be added as new files with the language suffix on the subtitle file name
[19:05] <elopio> the main readme is an index to all the videos.
[19:06] <kyrofa> Okay very good
[19:06] <kyrofa> Keep an eye out for PRs
[19:06] <elopio> I'm still playing with the format, and maybe, we can integrate with transifex
[19:06] <elopio> so if you want to move things around, go for it. It's still an early experiment
[19:07] <mup> PR # closed: snapcraft#1814, snapcraft#1820, snapcraft#1824, snapcraft#1841
[19:53] <mwhudson> mvo: i was sort of holding off snapd in debian because of that apparmor ptrace mess
[19:53] <mwhudson> did that get resolved in the end?
[19:53] <zyga> mwhudson: o/
[19:53] <mwhudson> zyga: yo
[19:54] <zyga> I don't know about that but I think just shipping more updates would help, our testing shows that 2.30 and master are pretty usable on sid
[19:54] <mwhudson> ok
[19:54] <mwhudson> tip of the branch on alioth has some updates that haven't been uploaded
[19:54] <mwhudson> to <IP_ADDRESS> or something
[19:55] <zyga> perhaps worth trying, also not sure if it's complex to go to .30
[19:57] <mwhudson> well it merges cleanly
[19:57] <mwhudson> where is the best place to get origs from for snapd?
[19:57] <mwhudson> from github?
[19:57] <zyga> yes, github release pages
[19:58] <mwhudson> oh look there is a watch file already
[19:58]  * mwhudson hits uscan with a stick until it does what he wants
[19:58] <mwhudson> ok building
[20:05] <mwhudson> zyga: dh_install: Cannot find (any matches for) "lib/udev/rules.d/80-snappy-assign.rules" (tried in ., debian/tmp)
[20:05] <mwhudson> zyga: has that just gone away?
[20:06] <jdstrand> that's weird
[20:06] <jdstrand> https://github.com/snapcore/snapd/pull/4399 makes that go away, but it isn't merged yet
[20:06] <mup> PR #4399: rewrite snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4399>
[20:07]  * jdstrand also updated the packaging for that
[20:07] <mwhudson> er
[20:07] <jdstrand> (but again, in the pr)
[20:07] <mwhudson> well this is debian packaging with is still out of tree
[20:07] <jdstrand> mwhudson: put more simply, that file should be there
[20:09] <mwhudson> jdstrand: does that file get created as part of the build?
[20:09] <mwhudson> it's not in the source tree nor has it ever been afaict
[20:10] <jdstrand> I'm trying to figure that out
[20:10] <jdstrand> $ dpkg -S /lib/udev/rules.d/80-snappy-assign.rules
[20:10] <jdstrand> snapd: /lib/udev/rules.d/80-snappy-assign.rules
[20:10]  * jdstrand looks in packaging
[20:12] <jdstrand> my memory is hazy. I seem to have removed it
[20:12] <jdstrand> mwhudson: gimme a sec
[20:13] <jdstrand> ah right
[20:13] <jdstrand> mwhudson: https://github.com/snapcore/snapd/pull/4374
[20:13] <mup> PR #4374: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4374>
[20:13] <mwhudson> oh it was in cmd/snapd-confine not data/lib/udev/rules.d
[20:13] <jdstrand> mwhudson: I was thinking I removed that file in 4399 and forgot about 4374
[20:13] <mwhudson> oh ok so just drop it from the .install?
[20:14] <jdstrand> mwhudson: so that file is now correctly gone
[20:14] <jdstrand> mwhudson: so for the momentary confusion
[20:14] <jdstrand> sorry*
[20:14] <mwhudson> no problem :)
[20:14] <mwhudson> bah the 'g' key on my keyboard is broken
[20:14]  * mwhudson switches everything back to bzr
[20:14] <jdstrand> haha
[20:15] <mwhudson> or alias it='git' i guess
[20:15] <jdstrand> lol
[20:15] <jdstrand> I sure that'll work great for you
[20:17] <mwhudson> building again
[20:24] <kyrofa> Alright elopio, you have your first PR
[20:24] <mwhudson> built successfully
[20:24] <mwhudson> zyga: should i test this or just upload it and let sid be sid? :)
[20:29] <kyrofa> cjwatson, my repo setup with build.snapcraft.io hasn't built the most recent commit that I made several hours ago (the most recent build was yesterday). Hitting the "build manually" button does nothing
[20:29] <kyrofa> Any ideas?
[20:30] <cjwatson> kyrofa: https://twitter.com/launchpadstatus/status/948688233029881856
[20:30] <kyrofa> Ah :)
[20:39]  * mwhudson uploads
[20:44] <sergiusens> kyrofa elopio have either of you had a chance to look at kalikiana's PRs?
[20:44] <kyrofa> Not yet, I will
[21:30] <kyrofa> sergiusens, can you take a look at my responses to snapcraft#1831? I don't have clear guidance on what you want done there
[21:30] <mup> PR snapcraft#1831: cli: add expiration option to export-login <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1831>
[21:34] <sergiusens> kyrofa I would honestly go with the included module; when I proposed making the expiration times look more friendly I was told the strict format was desired
[21:34] <sergiusens> we can improve it in the future if it comes to it; but this is not something one would do lightly anyways (and a very specific feature)
[21:36] <kyrofa> sergiusens, alright, I'll keep everything 8601
[21:39] <kyrofa> sergiusens, feel like commenting on the PR?
[21:39] <sergiusens> kyrofa this same comment you mean?
[21:39] <sergiusens> similar
[21:41] <kyrofa> sergiusens, haha, whatever you want, but right now it looks like an open conversation to anyone who's not part of this conversation
[21:41] <sergiusens> done
[21:44] <elopio> sergiusens: I'll get the pending reviews done tonight.
[22:01] <mup> PR snapcraft#1839 closed: kernel plugin: update initrd.img-core path to boot/initrd.img <bug> <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1839>
[22:34] <mup> PR snapcraft#1850 opened: pluginhandler: patch and handle elf files on glibc mismatch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1850>
[22:35] <sergiusens> kyrofa elopio I just pushed ^, while I didn't get a chance to write a unit test I did verify it works and if adt is enabled, the bionic tests should pass transparently now :-)
[22:35] <sergiusens> can you do a review considering I need to add some unit tests here and there?
[22:36] <sergiusens> the only thing that irks me is having to pass in another element into the plugin handler
[22:45] <kyrofa> sergiusens, sure
[23:19] <kyrofa> elopio, all the blog posts are done if you're up for a proof-reading session