[06:09] <mup> PR snapd#6731 closed: overlord: make the store context composably backed by separate backends for device asserts/info etc <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6731>
[08:35] <pedronis> there are also problems with the centos repos: https://api.travis-ci.org/v3/job/526762904/log.txt
[08:47] <mup> PR snapd#6807 opened: tests:  reduce snapcraft leftovers from PROJECT_PATH,  temp disable centos <Created by pedronis> <https://github.com/snapcore/snapd/pull/6807>
[08:51] <pedronis> Chipaca: hi, could you look at ^
[08:54] <Chipaca> yes
[08:56] <Chipaca> I should make a PR with just the cleanups from the invariant pr, until i can get the pr to pass fully
[08:56] <Chipaca> pedronis_: why the convoluted logic of '! command -v snapcraft >/dev/null || snapcraft clean'?
[08:57] <Chipaca> pedronis_: I suspect you didn't mean to write that :-| but if you did i'd like to understand why
[09:19] <pedronis> Chipaca: #6803 looks reasonable, some lateral comments
[09:19] <mup> PR #6803: daemon, o/snapstate, store: support for installing from cohorts <Created by chipaca> <https://github.com/snapcore/snapd/pull/6803>
[09:19] <Chipaca> woo
[09:20] <Chipaca> pedronis: thanks
[10:05] <mup> PR snapd#6807 closed: tests:  reduce snapcraft leftovers from PROJECT_PATH,  temp disable centos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6807>
[10:20] <pedronis> Chipaca: #6447 also needs/can be reviewed, a bit big
[10:20] <mup> PR #6447: polkit: cast pid to uint32 to keep polkit happy for now <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6447>
[10:20] <Chipaca> that's merged tho
[10:21] <Chipaca> #6747 ?
[10:21] <mup> PR #6747: many:  make access to the device model assertion etc contextual via a DeviceCtx hook/DeviceContext interface <Created by pedronis> <https://github.com/snapcore/snapd/pull/6747>
[10:21] <pedronis> yes, sorry
[11:01] <Chipaca> pedronis: bit of a cow to review, but, done! and, nice. thank you.
[11:02] <pedronis> Chipaca: thank you
[11:02] <Chipaca> pedronis: none of those nits are worth another spread run on their own, fwiw
[11:03] <Chipaca> if you happen to do one, fine; otherwise i am content
[11:03] <pedronis> Chipaca: let's see how it goes, anyway there's already an immediate follow up by mvo
[11:03] <pedronis> that needs tweaks
[11:03] <pedronis> so it could go there
[11:04] <pedronis> Chipaca: we should try to land #6806
[11:04] <mup> PR #6806: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6806>
[11:05] <Chipaca> i was wondering if that was the best approach
[11:05] <Chipaca> probably fine for now tho
[11:06] <Chipaca> but i'd rather ship static binaries than the whole of libc
[11:06] <Chipaca> just for those two binaries i mean
[11:06] <pedronis> Chipaca: I see, reasonable but is a larger change
[11:06] <pedronis> atm snapd snap was breaking hard a bunch of spread tests
[11:07] <pedronis> mvo had to revert it in edge
[11:07] <pedronis> also a bit weird why the tests were using the snapd from edge
[11:07] <pedronis> and not something built then
[11:11] <mup> PR snapd#6806 closed: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6806>
[11:15] <pedronis> Chipaca: is your thinking to have again a single Install later taking a struct?
[11:15] <Chipaca> pedronis: yes
[11:15] <pedronis> but is a big refactor
[11:15] <Chipaca> exactly
[11:15] <Chipaca> didn't want to do it as part of cohort work
[11:15] <Chipaca> but it clearly needs to move to be that way
[11:15] <pedronis> Chipaca: in that case either name is fine for the new helper
[11:15] <pedronis> s/helper/taskset producing function/
[11:16] <Chipaca> in fact i'd expect InstallPath to also get absorbed into the new thing
[11:16] <Chipaca> at which point Try is probably on the chopping board too :-)
[11:16] <Chipaca> we'll see (installpath does a bunch of stuff that needs dissecting at this point)
[11:17] <pedronis> not sure it will be worth trying to merge back Path or Try
[11:17] <pedronis> it might make things less readable actually
[11:18] <pedronis> Chipaca: anyway I think it would be good to add some // TODO: merge back with Install taking a struct
[11:18] <pedronis> explicitly though
[11:18] <Chipaca> didn't i?
[11:18]  * Chipaca thought he had
[11:18]  * Chipaca checks
[11:18] <Chipaca> / TODO: refactor things so there's a single install that takes a struct, mayeb a bit more like doInstall but public-er.
[11:18] <pedronis> you did
[11:18] <pedronis> but maybe s/install/Install/ there
[11:19] <pedronis> actually s/install/Install again/
[11:19] <pedronis> I read that commented and thought it meant that but wasn't super clear
[11:19] <Chipaca> ok
[11:19] <pedronis> s/commented/comment/
[11:20] <Chipaca> pedronis: wrt leave-cohort, should I declare a special cohort that means 'leave' internally, or should i have a flag for it?
[11:20] <Chipaca> on the fence on that
[11:21] <pedronis> it will not be store in SnapState to be celar
[11:21] <pedronis> it will remove what is there
[11:21] <pedronis> s/celar/clear/ ...
[11:21] <Chipaca> yes, it'd be in SnapSetup but not in SnapState
[11:22] <Chipaca> in the client action structs, from there to snapInstruction, from there to SnapSetup
[11:24] <pedronis> Chipaca: I fear on the API side a different flag seems better
[11:25] <pedronis> Chipaca: unless we  go dinstihishgin  no cohort-key  vs cohort-key: null vs cohort-key: string
[11:25] <pedronis> (which is doable but a bit annoying in go9
[11:25] <Chipaca> ew
[11:26] <Chipaca> leave-cohort: true seems weird tho :-)
[11:26] <pedronis> cohort-key: "<leave>" is also weird
[11:26] <Chipaca> yes, yes it is
[11:26] <Chipaca> error: you can't leave a cohort, it's for life
[11:27] <Chipaca> \o/
[11:27] <pedronis> Chipaca: 6747 is green, so I'm going to merge it, and take care of you remark at the start of tweaking the follow up
[11:28] <pedronis> *remarks
[11:28] <Chipaca> pedronis: np
[11:28] <Chipaca> pedronis: did you see what i meant about cohort-key + revision being ok in context?
[11:29] <Chipaca> as opposed to in action
[11:31] <pedronis> yes
[11:31] <Chipaca> k
[11:32] <mup> PR snapd#6747 closed: many:  make access to the device model assertion etc contextual via a DeviceCtx hook/DeviceContext interface <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6747>
[12:16] <Chipaca> grmbl out-of-space errors
[12:32]  * Chipaca lunch quick before standup
[12:34] <pedronis> Chipaca: where, I thought I fixed some of those
[12:44] <Chipaca> pedronis: in cross-compiling
[12:44] <Chipaca> pedronis: merged master in case it was in that delta
[12:44] <pedronis> Chipaca: I landed a fix for that, or so I hope
[12:44] <pedronis> this morning
[12:48] <mup> PR snapd#6808 opened: overlord: pass a DeviceContext to the CheckSnap implementations <Created by pedronis> <https://github.com/snapcore/snapd/pull/6808>
[12:49] <pedronis> Chipaca: ^  it's small, follow up  to previous and adding deviceCtx arg to checkSnap, otoh the test changes maybe are too noisy, don't know
[12:50] <Chipaca> pedronis: looks like a lot of the 'noise' is to pass an argument that isn't used?
[12:51] <pedronis> Chipaca: it will be used, but I can simply merge this in the next one
[12:51] <Chipaca> ah because. got it.
[12:51] <pedronis> that one will be big(tm) though
[12:52] <pedronis> if you prefer
[12:52] <Chipaca> CheckSnapCallback
[12:52] <pedronis> yes
[12:52] <pedronis> but it would make mvo and my self harder
[12:52] <Chipaca> nah it's fine
[12:52] <Chipaca> also, TMI
[12:52] <pedronis> because we are both working in different areas at intersection of this
[12:52] <pedronis> oops
[12:52] <pedronis> missing a life there
[12:53] <Chipaca> :-)
[12:53] <Chipaca> +1, looks good
[13:01] <pedronis> Chipaca: standup?
[13:02] <Chipaca> yep
[13:21] <pedronis> Chipaca: seems bundling the libc in snapd didn't quite work, we get segfaults now, fun
[13:21] <Chipaca> pedronis: segfaults are libc's way of telling you it loves you
[13:22] <Chipaca> or was it that it hated you and wanted you dead
[13:22] <Chipaca> one of those
[13:37] <tooijar> If I run `snapcraft init` in folder B, then `snapcraft` in folder A no longer looks at folder A/snap. It builds from folder B.  I was expecting the snapcraft command to look for `snap/` in the current directory.
[13:37] <tooijar> Is this expected?
[13:41] <pedronis> Chipaca: I reverted snapd edge for now
[13:41] <pedronis> and pinged mvo
[13:43] <Chipaca> tooijar: wat
[13:43] <Chipaca> pedronis: ack
[13:45] <Chipaca> tooijar: what does running 'snapcraft init' in folder B have to do with running 'snapcraft' in folder A?
[13:54] <tooijar> Chipaca: That's what I'm wondering. When I run snapcraft in folder A, it builds from the snapcraft.yaml in folder B (!)
[13:56] <Chipaca> tooijar: are these two projects using base: <something>, and are they called the same?
[13:58] <tooijar> Chipaca they're both using base: core18
[13:59] <brlin> tooijar: Are you running these commands in a snap build environment?  Snapcraft handles directories quite differently in a build environment
[13:59] <tooijar> Their name fields are different.
[13:59] <tooijar> I'm running in Ubuntu 1804
[14:01] <tooijar> Maybe cleanbuild will fix it?
[14:03] <Chipaca> tooijar: could you pastebin the console output of running snapcraft in both directories?
[14:05] <Chipaca> tooijar: it would be very interesting to get a way to reproduce this
[14:05] <Chipaca> tooijar: if you are able to get those steps, file it in a bug please
[14:08] <tooijar> https://pastebin.com/LpMdFWsf
[14:09] <tooijar> The output is identical in both directories. Problem is the ./snap/snapcraft.yaml in directory A is not 'my-snap-name'
[14:25] <tooijar> fixed with snapcraft clean && snapcraft build
[14:27] <diddledan> tooijar: sounds like your "folder A" and "folder B" are named the same but in different locations?
[14:28] <diddledan> if so it is expected that you'll get into a confused mess because the VM name is set to the folder name
[14:30] <tooijar> diddledan: they're both different folders in my home directory
[14:31] <tooijar> Of course the snapcraft.yaml is in a directory named "snap" in both folders.  And they're both set to use base: core18
[14:33] <Chipaca> tooijar: how do we reproduce the issue?
[14:34] <Chipaca> i've run multiple snapcrafts simultaneously before now and things work fine, so i'm puzzled
[14:34] <Chipaca> tooijar: is one a subdirectory of the other?
[14:34] <tooijar> Chipaca: I've corrected it now with snapcraft clean
[14:34] <tooijar> no, they're both in ~
[14:35] <tooijar> So ~/A and ~/B
[14:35] <Chipaca> tooijar: did you copy one to the other?
[14:35] <tooijar> no
[14:35] <tooijar> I'll try to reproduce
[14:35] <Chipaca> tooijar: ie did you 'snapcraft' and then copy the snap/ directory
[14:36] <tooijar> Chipaca: no, but there are no hidden files in the snap folder. Why would copying break things?
[14:40] <Chipaca> ah, that's right, the state is kept in the vm
[14:48]  * Chipaca hates spread
[14:48] <Chipaca> only worse thing than spread is everything else that tries to do the same thing it tries to do
[14:55] <tooijar> Chipaca: Since running snapcraft clean I can't reproduce anymore.
[15:03] <alan_g> jdstrand, could you clarify your seccomp denial question here? https://github.com/snapcore/snapd/pull/6790#discussion_r279408775 (I just need it explained to an idiot).
[15:03] <mup> PR #6790: interfaces: add login-session-control interface <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/6790>
[15:04] <jdstrand> alan_g: yes, I plan to go through that again today
[15:04] <mup> PR snapcraft#2547 opened: [legacy] catkin spread test: allow python2 as well as python <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2547>
[15:05] <alan_g> jdstrand, thanks. I don't know if this should be related, but you were mentioned: https://forum.snapcraft.io/t/installing-a-desktop-file-in-usr-share-wayland-sessions/11173
[15:08] <jdstrand> that's another on my todo for today
[15:08] <alan_g> \o/
[15:27] <mup> PR snapd#6699 closed: daemon: add RootOnly flag to commands <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6699>
[15:34] <tooijar> How can I install a library into a prime/ directory for faster testing?  I don't want to add to stage-packages and re-run snapcraft over and over until the last unmet dependencies is added.
[15:40] <brlin> Simply copy them into it and run `snapcraft pack prime`
[15:43] <kyrofa> tooijar, actually, modifying stage-packages and re-running is a good way to do it, but you may need to restructure your project ever so slightly. Does your snapcraft.yaml specify a `base`?
[15:44] <tooijar> kyrofa: yes, base is core18
[15:44] <tooijar> Reason I don't want to re-run is ...it just takes a long time.
[15:44] <kyrofa> tooijar, I assume you have a part that takes a while to build, and you're adding the stage-packages to that part? Modifying the list means it needs to rebuild, yada yada
[15:45] <kyrofa> tooijar, correct so far?
[15:46] <tooijar> kyrofa: source-type is local so it's not building as in compiling / linking....but it does take a long time at "snapping test-snap". I'm not sure what it's doing that's taking so long.
[15:48] <kyrofa> tooijar, that's creating the squashfs image out of the priming area. If you're creating a snap you'll always pay that cost regardless of how you choose to get the lib into the priming area
[15:49] <tooijar> kyrofa: yeah, 'snapcraft pack prime' doesn't speed things up much
[15:50] <tooijar> I guess I should find a better way of identifying all dependencies rather than just building / running and waiting to see what shared library error is thrown.
[15:53] <kyrofa> tooijar, are you using multipass, then?
[15:54] <tooijar> kyrofa: Not specifically by choice, but yes, I believe snapcraft is using multipass on my Ubuntu1804 machine.
[15:54] <kyrofa> tooijar, how are you accessing the prime directory?
[15:55] <tooijar> I had done `snapcraft try prime` and it put prime/ in my current directory
[15:55] <tooijar> Then I just cd'd into it
[15:55] <kyrofa> Ah! I didn't realize sergiusens had implemented that yet, very nice
[15:55] <kyrofa> tooijar, so then, here's what you need to do
[15:56] <kyrofa> Stop messing about with the prime directory, and stop running `snapcraft` with no args. Basically, stop creating a snap
[15:56] <kyrofa> Alter the stage-packages as necessary, and run `snapcraft prime` only
[15:56] <kyrofa> That will do everything EXCEPT create a snap
[15:56] <kyrofa> Since you have `snapcraft try` already, all you need to do at that point is try running the app again
[15:56] <kyrofa> The libs will be in prime
[16:03] <pedronis> Chipaca: we have never used the internal package mechanism right, how do you feel about it?
[16:12] <tooijar> kyrofa: that works, but because stage-packages has changed, it does a build, then stage, then prime when I run `snapcraft prime` so it's not much faster than just running snapcraft.  What I was hoping what that it could load the new libraries into the existing image, and be done. Without then having to build/stage/prime.
[16:14] <tooijar> I just want to do the equivalent of `sudo apt install missing-lib` in the already built prime folder
[16:16] <tooijar> Maybe I just need a better build machine.
[16:21] <diddledan> dang, I missed the dockercon keynote
[16:21]  * diddledan makes a note to watch that later
[16:22] <brlin> tooijar: You can put the `stage-packages` entries under another fake part, in this case changing them won't clean the entire part's progress
[16:23] <diddledan> hmm, come on travis-ci!!
[16:23]  * diddledan pokenprod mit deine pokiestick
[16:25] <tooijar> brlin: that sounds promising, thanks.
[16:26] <diddledan> I'd recommend merging that fake part back into the part you're not wanting to rebuild once you have the right packages sorted so that it's obvious which part they really belong to :-)
[16:27] <diddledan> but while you're working out what you need brlin 's idea is solid to prevent long waits
[16:28] <tooijar> ok, thanks for the help folks.
[17:09] <mup> PR snapd#6808 closed: overlord: pass a DeviceContext to the checkSnap implementations <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6808>
[17:14] <Chipaca> pedronis: I wish we had used internal
[17:14] <Chipaca> pedronis: I'd like to transition to it yesterday
[17:14] <Chipaca> pedronis: failing that, tomorrow is ok
[17:15] <Chipaca> pedronis: further I think some things are internal-internal, but dunno if go supports that or even if it's a good idea
[17:15] <pedronis> Chipaca: ok, I have I use in current refactoring, actually a slightly strange use but seems to work
[17:15] <Chipaca> pedronis: e.g. some things in *util only meant to be used from overlord
[17:16] <Chipaca> pedronis: >shocked pikachu<
[17:17] <Chipaca> pedronis: if it's "use internal because it has a side effect that the compiler does things in reverse order so things no longer segfault" then i'm against it
[17:17] <Chipaca> pedronis: :-)
[17:18] <Chipaca> but also ha-ha-but-seriously
[17:18] <pedronis> Chipaca: no, is to have something that is exposed to tests via a *test package but otherwise not accesible except in its home package
[17:18] <pedronis> the only other solution I could think of would need repeating the impl twice
[17:20] <Chipaca> pedronis: what do we say to the god of repeating ourselves?
[17:22]  * Chipaca came back from the gym more memetic than usual
[17:26] <tooijar> Can someone clarify why "allow-sandbox" is defaulted to "false"?  "The allow-sandbox attribute may be used to give the necessary access to use the browser’s sandbox functionality."
[17:27] <tooijar> Given that the browser sandbox is a security measure, shouldn't it default to true?
[17:32] <Chipaca> tooijar: AIUI, it's because it weakens the snap's security, in exchange for trusting the browser to enforce it
[17:32] <Chipaca> tooijar: jdstrand might be able to explain more, but that's my understanding
[17:33] <Chipaca> tooijar: also see https://forum.snapcraft.io/t/sandboxing-with-the-browser-support-interface/1984/2
[17:34] <Chipaca> degville: jdstrand: what happened to the "Note:" in that ^ topic, that is no longer in https://docs.snapcraft.io/the-browser-support-interface/7775 ?
[17:37] <tooijar> Chipaca: Thanks for the link....this explains it well enough to satisfy my curiosity: "Since the browser’s internal sandbox requires a lot of privileged security policy rules to work, use of --allow-sandbox=true is limited to trusted publishers"
[17:37] <Chipaca> tooijar: in other words, it needs manual review
[17:38] <tooijar> Chipaca: Would be good to have that same explanation on the main docs here https://docs.snapcraft.io/the-browser-support-interface/7775
[17:38] <Chipaca> tooijar: the funny thing is that that is a quote from the docs, hence my question to jdstrand & degville
[17:38] <Chipaca> we've lost something in a cleanup somewhere
[17:38] <degville> (looking)
[17:39] <Chipaca> as they stand the docs don't say that allow-sandbox:true is privileged
[17:39] <Chipaca> anyway, i need to go to the shops before they close
[17:39] <Chipaca> ttfn, ttyl
[17:40] <degville> Chipaca:see you! I'll look into the docs.
[17:44] <jdstrand> Chipaca: that note never made it to https://forum.snapcraft.io/t/the-browser-support-interface/7775. I'll let degville decide how to incorporate it
[17:44] <jdstrand> degville: if you do, feel free to drop the reference to oxide
[17:45] <degville> jdstrand: thanks - not sure what happened, but I'll re-instate it now and drop the oxide reference.
[17:47] <jdstrand> tooijar: Chipaca is right. the snap sandbox and the browser sandbox have different ideas about things. outside of snapd, the browser is considered trusted and may even have a setuid binary to setup its sandbox, or use kernel features like user namespaces that are well mediated with current LSM, seccomp, etc yet
[17:48] <jdstrand> tooijar: within sanpd, allowing anyone to use that functionality without explicit permission means that snaps could abuse the system or break out of the sandbox
[17:48] <jdstrand> tooijar: so allow-sandbox: true is reserved for major browsers from established publishers
[17:49] <kenvandine> jdstrand: i got a USN email about the gtk-common-themes snap
[17:49] <kenvandine> Revision r1198 (all; channels: stable)
[17:49] <kenvandine>  * libpng16-16: 3962-1
[17:49] <jdstrand> tooijar: your typical electron app gets plenty of security from the snapd sandbox, for example
[17:49] <kenvandine> jdstrand: but that snap doesn't actually contain any libs
[17:49] <jdstrand> tooijar: so allow-sandbox: false is fine for all of them
[17:49] <tooijar> jdstrand: Thanks. That's even more helpful. Would be nice to have that level of explanation in https://docs.snapcraft.io/the-browser-support-interface/7775
[17:49] <jdstrand> kenvandine: I'm guessing your manifest.yaml says something different
[17:50]  * kenvandine looks
[17:50] <jdstrand> tooijar: that is what degville is looking at fixing
[17:50] <tooijar> jdstrand: My only concern is that chromium states that -no-sandbox is only for testing. That's from their point of view. Which is fine. But I wonder if they might one day decide that even for testing it shouldn't be used.
[17:51] <tooijar> And then disable that option altogether.
[17:51] <jdstrand> tooijar: sure. the chromium snap is allowed to use allow-sandbox: true
[17:51] <kenvandine> jdstrand: so that's the installed packages at build time right?
[17:51] <jdstrand> tooijar: so is brave
[17:52] <jdstrand> kenvandine: yes. ie, what is in stage-packages
[17:52] <jdstrand> kenvandine: you might 'organize' things away, but the tool doesn't know about all that
[17:52] <kenvandine> sure
[17:52] <kenvandine> ok
[17:53] <kenvandine> for gtk-common-themes i can ignore these then :)
[17:53] <jdstrand> kenvandine: you might spot check that someone didn't change the snapcraft.yaml, but sure, it is up to you to decide if you need to do anything
[17:53] <kenvandine> i did
[17:54] <jdstrand> this is but one reason of many why we don't do a report card on snaps or publishers
[17:54] <kenvandine> and there are no libs at all in the installed snap
[17:54] <kenvandine> which i confirmed
[17:54] <jdstrand> kenvandine: yeah, I meant going forward if you get it, just double check someone didn't change it out from under your expectations
[17:54] <kenvandine> will do
[18:03] <mup> PR snapcraft#2548 opened: integration tests: use correct series in get_package_version <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2548>
[18:04] <jdstrand> roadmr: hey, I don't recall if you responded to my request to pull r1226
[18:04] <roadmr> jdstrand: oh! I didn't :( r1225 was deployed yesterday. I'll put r1226 in the usual queue
[18:05] <mup> PR snapd#6809 opened: snapcraft.yaml: fix links ld-linux-x86-64.so.2/ld64.so.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6809>
[18:06] <jdstrand> roadmr: thanks! :)
[18:06] <Chipaca> jdstrand: that's the *second* time I get to quote you as '<jdstrand> Chipaca is right'
[18:06] <Chipaca> not that I'm keeping a tally or anything
[18:06] <mup> PR snapd#6801 closed: snapstate,devicestate: add snapstate.DeviceCtx to checkSnap* <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6801>
[18:14] <jdstrand> Chipaca: \o/ :)
[18:14] <jdstrand> roadmr: actually, I'm going to have an r1227 for a new override in a moment
[18:14] <roadmr> jdstrand: oh! I haven't done r1226 because $reasons, so I might as well wait for that :)
[18:22] <jdstrand> roadmr: ok, can you pull r1228* ? (I forgot r1227 had a new override from yesterday)
[18:23] <roadmr> lol :)
[18:23] <roadmr> sure
[18:27] <mup> PR snapcraft#2549 opened: [legacy] integration tests: use correct series in get_package_version <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2549>
[18:32] <jdstrand> degville: curious, is the updating of https://docs.snapcraft.io/the-*-interface automatic from https://forum.snapcraft.io/t/the-*-interface? do you get a report and manually update?
[18:32] <jdstrand> degville: there is no problem. I see that my recentish changes to the personal-files docs in the forum are represented in docs.snapcraft.io so was just curious
[18:33] <degville> jdstrand: it's automatically updated. The delay is usually less than 5 mins.
[18:33] <jdstrand> nice
[19:22] <mup> PR snapd#6810 opened: many:  do without device state/assertions accessors based on state only outside of devicestate/tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/6810>
[21:52] <mup> PR snapcraft#2548 closed: integration tests: use correct series in get_package_version <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2548>
[21:58] <mup> PR snapcraft#2549 closed: [legacy] integration tests: use correct series in get_package_version <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2549>
[23:56] <mup> PR snapd#6811 opened: tests: make create-user test support managed devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6811>