[00:51] <redir> I assume we already have some tooling for storing time values as json on disk. Can someone point me at an example?
[00:53] <babbageclunk> going for a run, hope it doesn't all go wrong while I'm out!
[00:56] <voidspace> thumper: ping
[01:03] <thumper> voidspace: hey
[01:03] <voidspace> thumper: hey, hi
[01:04] <voidspace> thumper: I'm working on bug 1632362
[01:04] <mup> Bug #1632362: error during juju-wait ERROR cannot load cookies: file locked for too long; giving up: cannot acquire lock: resource temporarily unavailable <eda> <oil> <juju:Triaged by rharding> <Juju Wait Plugin:Invalid> <https://launchpad.net/bugs/1632362>
[01:04] <voidspace> thumper: which *appears* to be a problem with the juju/persistent-cookiejar library around the way it does file locking
[01:04] <voidspace> thumper: the suggestion in the bug is to switch to a many-readers-one-writer style lock
[01:05] <thumper> ugh, otp right now
[01:05] <voidspace> thumper: I'll email it
[01:05] <thumper> ack
[01:05] <voidspace> thumper: I hear you have "opinions" on file locking...
[01:05] <voidspace> thumper: :-)
[01:05] <thumper> :)
[01:05] <voidspace> thumper: although it seems like really we want a database...
[01:06] <voidspace> thumper: which may only be as complex as rewriting file locking from scratch
[01:06] <voidspace> or less...
[01:06] <voidspace> thumper: assuming that's the real bug...
[01:22] <redir> OK. I'm calling it. Time to go watch the incoming results.
[01:22] <voidspace> good luck America
[01:22] <voidspace> I'm also calling it time
[01:22] <voidspace> g'night all
[02:19] <alexisb> thumper, ping
[02:20] <thumper> alexisb: pong
[02:20] <alexisb> heya do you have a second to chat?
[02:20] <thumper> yep
[02:20] <thumper> hangout or bluejeans?
[02:20] <alexisb> k meet you in bluejeans
[02:20] <thumper> ack
[02:20] <alexisb> let me plug in my laptop
[04:23] <mup> Bug # changed: 1543362, 1544158, 1565943, 1607786
[04:51] <redir> someone shoot me
[05:24]  * anastasiamac does not want to shoot redir
[07:04] <rick_h> alexisb: ping, can you grab wallyworld for the session?
[07:08] <anastasiamac> rick_h: where r u?
[07:08] <rick_h> anastasiamac: in the bolero room for the cross cloud controller
[07:10] <anastasiamac> rick_h: we r in opereta, talking with uros
[07:10] <rick_h> anastasiamac: wallyworld is there as well? I've got some guests in here it'd be good to get backup here
[07:11] <anastasiamac> rick_h: come over here - the same conversation is taking place
[07:11] <anastasiamac> rick_h: yes, wallyworld is here
[07:11] <rick_h> anastasiamac: k, the calendar says this room so we've got 5 folks in here to talk about it
[07:12] <anastasiamac> rick_h: there is more here :D
[07:59] <cmars> good morning juju-land. can I get a review of https://github.com/juju/charm/pull/225 and https://github.com/juju/juju/pull/6549 to fix https://bugs.launchpad.net/juju-core/+bug/1639855 ?
[07:59] <mup> Bug #1639855: 2.0 metrics breaks 1.25 <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1639855>
[08:30] <redir> no seriously.
[08:30] <redir> Shoot me.
[08:32]  * redir goes to bed hoping not to have a 4 year hangover
[08:44] <hoenir> could someone review these patches? https://github.com/juju/juju/pull/6523 https://github.com/juju/utils/pull/249
[12:45] <voidspace> dooferlad: ping
[13:57] <voidspace> rick_h: we doing 1:1 today?
[14:00] <dooferlad> voidspace: how can I help?
[14:00] <voidspace> rick_h: I'll be a bit late anyway, nothing *burning* that I need to talk about that can't be done by email
[14:01] <voidspace> rick_h: so happy to skip, but also very happy to chat if you're around
[14:01] <voidspace> dooferlad: hey
[14:01] <voidspace> dooferlad: so I'm fixing the file locking to use juju/mutex instead of filelock
[14:01] <voidspace> dooferlad: which uses named pipes (etc) to do the locking instead of the filesystem
[14:01] <voidspace> dooferlad: but it has a 40 char max, and cookiejar uses full file paths which can exceed 40 chars
[14:02] <voidspace> dooferlad: so I'm thinking that a hash of the full path is the thing to do
[14:02] <voidspace> dooferlad: and am wondering which hashing algorithm to use - SHA1 looks promising in terms of a small output hash sized
[14:02] <dooferlad> voidspace: can you give me a path to the file that has the problem?
[14:02] <voidspace> dooferlad: but I thought you might have "opinions" that would be helpful
[14:02] <dooferlad> voidspace: :-)
[14:02] <voidspace> dooferlad: I'll have to dig to get that
[14:03] <voidspace> dooferlad: and my wife just got back, let me come back to you on it
[14:03] <dooferlad> voidspace: sounds good
[14:05] <voidspace> rick_h: I just got the MAAS storage email
[14:05] <voidspace> rick_h: I'm very close to a complete PR for the issue I'm on currently, so I'll complete that then switch to MAAS storage
[14:06] <voidspace> rick_h: I've not looked at storage before, but there are plenty of people to ask if I need to (most of them on sprint with you though...) :-)
[14:08] <rick_h> Voidspace thank you. Understand it's not an immediate turnaround.
[14:21] <dooferlad> voidspace: on the subject of locking I would say that looking at the persistent-cookiejar code we could name a mutex 'juju-cookies' as long as we only have one location for the cookie file (next to the Juju settings) and that we need to import any existing cookies from the current location (JUJU_COOKIEFILE, GOCOOKIES or $HOME) if
[14:21] <dooferlad> $HOME/.local/share/juju/cookies doesn't exist.
[15:35] <rick_h> jam: ping
[15:46] <voidspace> dooferlad: I think it's ok to use 29 character hash (of SHA256) : last ten chars of file path
[15:46] <voidspace> dooferlad: and as we're the only user for juju cookies I don't think the cross-version incompatibility will be a problem
[15:47] <dooferlad> voidspace: if we are the only users, why not just ask for a jar name on creation and use "juju/cookies/<name
[15:48] <dooferlad> sorry, juju/cookies as that name
[15:48] <dooferlad> when calling from our code
[15:48] <voidspace> dooferlad: because the underlying library needs to generate locks for arbitrary paths
[15:49] <dooferlad> voidspace: good point, well made :-)
[15:54] <dooferlad> this feels a lot like we forked the cookie code instead of implementing a library to wrap file access inside a juju/mutex
[16:00] <mup> Bug #1640521 opened: Unable to deploy Windows 2012 R2 on AWS <juju-core:New> <https://launchpad.net/bugs/1640521>
[16:18] <mup> Bug #1640521 changed: Unable to deploy Windows 2012 R2 on AWS <juju-core:New> <https://launchpad.net/bugs/1640521>
[16:21] <mup> Bug #1640521 opened: Unable to deploy Windows 2012 R2 on AWS <juju-core:New> <https://launchpad.net/bugs/1640521>
[19:08] <lazyPower> rick_h - correct me if i'm wrong, but to bootstrap a controller with proxy settings we just drop http-proxy|https-proxy flags in a config.yaml and bootstrap with --config=myfile.yaml?


[07:53] <zyga> hello
[07:55] <mvo> hey zyga
[08:11] <pstolowski> morning
[08:12] <kjackal> Hi, is there something wrong with the snap store? "error: unable to contact snap store " from my local machine and from aws when installing microk8s
[08:15] <mvo> kjackal: yeah, the store is not fully operating right now, see https://status.snapcraft.io/
[08:15] <zyga> kjackal: I'm seeing timeouts
[08:15] <pstolowski> kjackal: indeed - https://status.snapcraft.io
[08:31] <nekoseam> api.snapcraft.io is coming back up when?
[08:45] <mbeneto> Hi, is the Global Store down?
[08:47] <zyga> mbeneto: see status.snapcraft.io please
[08:49] <mbeneto> zyga: thanks, I didn't know about that
[08:52] <mup> PR snapd#6495 opened: many: collect time each task runs and display with `snap change <id>` <Created by mvo5> <https://github.com/snapcore/snapd/pull/6495>
[09:07] <sparkiegeek> we're actively working on bringing the store back up, please be patient with us
[09:12] <zyga> sparkiegeek: thank you :)
[09:39] <mvo> zyga: did you see that the statx syscall is getting backported to libseccomp in bionic? do you think this affects us?
[09:39] <zyga> mvo: it will affect us as follows:
[09:39] <zyga> (I saw some chatter over email)
[09:40] <zyga> mvo: statx is present in the default seccomp templatte
[09:40] <zyga> mvo: statx will no longer resolve to unknown system call
[09:40] <zyga> mvo: statx will become present in seccomp profiles
[09:40] <zyga> mvo: some tests may start passing  unexpectedly
[09:41] <mvo> zyga: thanks! but no ill effects for real-world workloads except tests?
[09:42] <zyga> no, things will only be better
[09:42] <mvo> I like the sound of that :)
[09:59] <pedronis> mvo: I marked #6495 blocked because I should review older things first, I don't think it can go in as is (I'm mostly worried that is a bit premature to put this in the main commands/API)
[09:59] <mup> PR #6495: many: collect time each task runs and display with `snap change <id>` <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6495>
[10:00] <mvo> pedronis: fair enough, would it help if I remove the client bits and move them into debug? or would you prefer to leave this all alone ?
[10:02] <pedronis> mvo: it's probably best to have a chat about this first
[10:03] <mvo> pedronis: ok
[11:02] <zyga> Chipaca, pedronis: can you please double check that this is what we want: https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/35?u=zyga
[11:04] <mup> PR snapd#6495 closed: many: collect time each task runs and display with `snap change <id>` <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6495>
[11:06] <zyga> FYI https://twitter.com/slpnix/status/1095640072999915520
[11:06] <zyga> pedronis: ^
[11:10] <Chipaca> zyga: what do you mean we can't return a synchronous error because we refresh assertions?
[11:11] <zyga> Chipaca: befure we  get to UpdateMany we block for a long time to do assertion refreshes
[11:11] <Chipaca> zyga: yes
[11:11] <zyga> I'm not an expert on this  part of the stack but this is what I found yesterday
[11:11] <Chipaca> zyga: but that's in the synchronous bit
[11:11] <zyga> ?
[11:12] <zyga> that is before we create tasks
[11:12] <zyga> and while the client waits for the response?
[11:12] <Chipaca> yes
[11:12] <pstolowski> hmm i'm still getting net/http: request canceled while... on api.snapcraft.io every time i run a spread test, even though status of the store is all green
[11:13] <zyga> Chipaca: that's unexpected and contrary to my assumptions about what should go where
[11:13] <Chipaca> pstolowski: yeah, store is not out of trouble yet
[11:13] <Chipaca> 'snap find' takes ages even when it works
[11:13] <Chipaca> zyga: ok
[11:13] <pstolowski> Chipaca: ack, thanks for confirming
[11:14] <Chipaca> zyga: I wasn't giving an opinion :-)
[11:14] <Chipaca> zyga: I was just stating a fact
[11:15] <Chipaca> zyga: now, ideally it would either be a lot faster, or be done in a task, but if moved to a task we lose the ability to error out entirely
[11:16] <Chipaca> the speed of refreshing assertions sucks
[11:16] <zyga> Chipaca: here I'm specifically after one aspect; gustavo wanted to have the refresh bail out synchronosuly (quickly)  when we can check that a snap is busy
[11:16] <Chipaca> zyga: yes
[11:16] <Chipaca> zyga: so check before the assertion refresh
[11:16] <pedronis> Chipaca: zyga: is something that we need to fix/improve but is not trivial and cannot be done before we have fixed other issues
[11:16] <zyga> AFAIK this is not possible today
[11:17] <Chipaca> zyga: why?
[11:17] <zyga> Chipaca: yesterday you or pedronis commented it should be even later, but perhaps I misunderstood
[11:17] <pedronis> zyga: fast is a relative concept, what is your concern?
[11:17] <zyga> Chipaca: that is  even before update is called, unless I'm missing something
[11:18] <pedronis> anything done in the sync part is considered "fast"
[11:18] <zyga> pedronis: synchronous error before we do anything
[11:18]  * pstolowski errand
[11:18] <zyga> pedronis: if I can place it before the assertion check that would be enough
[11:18] <Chipaca> zyga: if by fast you mean synchronous, snapstate.Update can and does do things before starting the change
[11:18] <pedronis> zyga: what is the problem putting it after?
[11:18] <zyga> pedronis: it's noticeably slow and feels like bad user  experience
[11:19] <pedronis> zyga: sorry, not relevant, other things are checked at that point
[11:19] <pedronis> as I said, not something we can fix *now"
[11:19] <zyga> sure, that's fine
[11:19] <zyga> so what is the design I should  pursue, is the one I drafted in the forum post acceptable?
[11:19] <Chipaca> zyga: so, as i was saying, if by fast you meant synchronous, snapstate.Update
[11:20] <pedronis> any point that is reasonable and not bug introducing is fine in Update
[11:20] <pedronis> we need to speed it up
[11:20] <zyga> ok
[11:20] <pedronis> but as I said it's orthogonal, not easy problem
[11:20] <zyga> Chipaca: I meant as in not involving any network IO but as I understand that is difficult now, we can improve it later
[11:20] <Chipaca> zyga: if by fast you meant *actually* fast, you can call something from daemon
[11:20] <Chipaca> er
[11:20] <Chipaca> zyga: you can't mean without any network io
[11:21] <Chipaca> without network you can't know if there is an update available
[11:21] <pedronis> Chipaca: please, don't suggest horrible things
[11:21] <zyga> Chipaca: yes, without any at all, if you say "snap refresh foo" you can bail out knowing that foo ruuns
[11:21] <Chipaca> zyga: there might not be any updates for foo
[11:21] <zyga> Chipaca: it obviously applies to a subset of cases
[11:21] <Chipaca> zyga: why would you bail in that case?
[11:22] <Chipaca> "close all your open windows for the update" "k" "no updates available" "HULK SMASH"
[11:22] <pedronis> let's not be silly here
[11:22] <zyga> Chipaca: I was trying to convey the discussions from cape town, in the case where you can check that nothing can be done locally, you can provide an appropriate message that teaches the uses about this mechanic
[11:23] <pedronis> zyga: I can only repeat  conceptually any point in Update is considered "fast"
[11:23] <zyga> OK
[11:23] <zyga> I think the draft I wrote now is actionable and in line with what we want
[11:24] <zyga> if you can give me a +1 on that I will carry on working towards that
[11:24] <Chipaca> pedronis: zyga: I'd suggest putting it at the top of `doUpdate`, fwiw
[11:24] <Chipaca> zyga: is the draft the forum post from where I came?
[11:24] <pedronis> Chipaca: that would be fine with me
[11:24] <zyga> Chipaca: yes, after iterating on this yesterday and today I moved all the logic into one helper that can be called from doUpdate
[11:25] <Chipaca> I somehow missed that we wanted to do this before knowing there was an update available and would like to express my concern about the ux of that
[11:25] <pedronis> Chipaca: I don't think that was the plan
[11:25] <pedronis> that doesn't make sense
[11:25] <pedronis> even
[11:25] <Chipaca> IKR
[11:25]  * pedronis -> lunch
[11:26] <zyga> hm
[11:26] <zyga> so +1 or -1?
[11:26] <pedronis> to what?
[11:26] <pedronis> checking in doUpdate ?
[11:26] <pedronis> +1
[11:26] <pedronis> afaiu right now
[11:26] <zyga> to all of https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/35
[11:26] <pedronis> ah, that's new
[11:27] <Chipaca> zyga: there are conceptual errors in that, which is what I opened with, so -1
[11:27] <pedronis> I need to read it :)
[11:27] <zyga> ok, please comment on it with clarifications
[11:27] <zyga> I will carry on with tests
[11:27] <zyga> the way I structured this is easy to change
[11:27] <zyga> so any changes are OK
[11:28] <Chipaca> zyga: nothing in /34 where you describe the thing implies "before checking the store for updates"
[11:32] <zyga> Chipaca: I tried to capture it in 'snap refresh s2' case
[11:32] <zyga> but I was aware of the logic around assertions so I made it clear that this is not happening
[11:49] <sparkiegeek> store is fully operational again
[11:50] <Chipaca> sparkiegeek: woo, thank you
[11:55] <sparkiegeek> Chipaca: np, repair work was handled by rest of the team
[11:56] <sparkiegeek> but if you could please give us batched assertion requests we would have a better chance of coming back up quicker :)
[12:02] <Chipaca> er
[12:02] <Chipaca> sparkiegeek: will do
[12:02]  * Chipaca puts a bow on it
[12:02] <Chipaca> or was that lipstick
[12:02] <Chipaca> eh
[12:02] <sparkiegeek> ⋈
[12:15] <Chipaca> mvo: did you see my question on https://github.com/snapcore/snapd/pull/6034#discussion_r256025287 ?
[12:15] <mup> PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
[12:18] <audiophilo> Hi, i'm using rhytm ferret extensively on acoustic drums. If i pick bass drum and snare drum as a reference for splitting i can have a problem when they are played at the same time by the drummer. Since it's unlikely that bass and snare are hit  at the very exact moment, rhytm ferret will create 2 very-close and unusefull regions (Attachment 1: https://imgur.com/pYpnYLd) that will create a more annoying behaviour when using P
[12:18] <audiophilo> osition -> Snap position to grid (Attachment 2: https://imgur.com/l5uwFmr). I thought that it would be great to add an option  in rhytm ferret where you can add a value in ms to determine a minimum distance from a cut to the other. Do you think this could be a nice idea?
[12:19] <Chipaca> audiophilo: are you in the right channel?
[12:20] <audiophilo> nope. LOL
[12:20] <Chipaca> audiophilo: phew
[12:20] <audiophilo> :D
[12:20] <Chipaca> for a moment I thought I'd lost it
[12:20] <audiophilo> too many tabs, i got confused. Sorry
[12:21] <Chipaca> audiophilo: good luck with your … ferret … snaring?
[12:21] <Chipaca> sounds like fun anyway
[12:22] <audiophilo> Chipaca, thank you very much. Well it's not very funny actually. But very usefull :D
[12:22] <cachio> mvo, hey
[12:22] <cachio> mvo, I am going to promote the snapd snap
[12:22] <cachio> I would like to know why those versions are not in beta right now
[12:25] <mvo> cachio: thank you
[12:25] <mvo> cachio: we can discuss why 2.37.2 is not in beta after lunch, gtg now, sorry. will be back soon
[12:26] <cachio> mvo, np, enjoy lunch
[12:26] <mup> PR snapd#6496 opened: many: collect time each task runs and display with `snap debug change-timings <id>` <Created by mvo5> <https://github.com/snapcore/snapd/pull/6496>
[12:30] <pedronis> mvo: could you merge master in #6404, it seems to still require old deps
[12:30] <mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
[12:40] <zyga> brb, taking a small break now
[12:41] <cachio> pstolowski, hey, yesterday I was running the hotplug test
[12:41] <cachio> I left a comment on the PR about the results
[13:00] <pstolowski> cachio: yes, thank you i saw it. i was trying to debug it today but store was mostly offline
[13:11] <pstolowski> cachio: did you run that test only on 16.04?
[13:26] <mup> PR snapd#6497 opened: features,cmd/libsnap: add new feature "refresh-app-awareness" <Created by zyga> <https://github.com/snapcore/snapd/pull/6497>
[13:32] <mup> PR snapd#6498 opened: cmd/libsnap: add cgroup-pids-support module <Refresh Awareness> <Created by zyga> <https://github.com/snapcore/snapd/pull/6498>
[13:33] <zyga> two early branches from the refresh app awareness work
[13:39] <cachio> pstolowski, yes, only on 16.04
[13:49] <mvo> pstolowski: 6404> sure
[13:51] <pstolowski> cachio: i've just run it on 16.04 (failed) and 18.04 (passed). i wonder if it's something qemu-related. it seems as unplugging and then re-plugging device back in qemu doesn't trigger the udev add event on 16.04, but i'll need to investigate this closer. qemu on 16.04 is 2.5, in 18.04 - 2.11
[13:55] <pstolowski> cachio: nb, running nested 16.04 vm under 18.04 (to have newer qemu) doesn't seem possible since we build snapd deb on the host, so dependencies are wrong
[13:56] <cachio> pstolowski, yes
[13:57] <cachio> pstolowski, how are you running this?
[13:59] <pstolowski> cachio: SPREAD_NESTED_TYPE=classic SPREAD_NESTED_ARCH=amd64 SPREAD_NESTED_SYSTEM=bionic spread -debug google-nested:ubuntu-18.04-64:tests/nested/classic/hotplug
[13:59] <pstolowski> cachio: SPREAD_NESTED_TYPE=classic SPREAD_NESTED_ARCH=amd64 SPREAD_NESTED_SYSTEM=xenial spread -debug google-nested:ubuntu-16.04-64:tests/nested/classic/hotplug
[14:00] <pstolowski> cachio: i once mixed that up accidently and that didn't work because of what i said above
[14:09] <Chipaca> zyga: wrt getting the apps from the check, earlyEpochCheck is already loading them, we can change it to either return or have it passed in
[14:29] <cachio> jdstrand, hey, could you please take a quick look to #6376?
[14:29] <mup> PR #6376: tests: split the test interfaces-many in 2 and remove snaps on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6376>
[14:29] <cachio> thanks
[14:31] <jdstrand> cachio: I will not be able to look at it for a little while, but will today. sorry for the delay
[14:32] <cachio> jdstrand, thanks
[14:47] <pstolowski> cachio: what's the new simple syntax for nested vm tests?
[14:47] <zyga> Chipaca: thanks for the hint, let me look :)
[14:48] <cachio> pstolowski, for xenial
[14:48] <cachio> spread -debug google-nested:ubuntu-16.04-64:tests/nested/classic/hotplug
[14:48] <cachio> for bionic
[14:48] <cachio> SPREAD_NESTED_SYSTEM=bionic spread -debug google-nested:ubuntu-18.04-64:tests/nested/classic/hotplug
[14:51] <pstolowski> cachio: thanks
[14:51] <cachio> pstolowski, taw
[14:51] <cachio> yaw
[15:28] <zyga> Chipaca: interesting, that is perfect
[15:40] <mup> PR snapd#6499 opened: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/6499>
[15:45] <zyga> jdstrand: hey
[15:45] <zyga> jdstrand: not sure if you are around but https://github.com/snapcore/snapd/pull/6499/files :)
[15:45] <mup> PR #6499: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/6499>
[15:48]  * cachio lunch
[16:00] <mup> PR snapd#6500 opened: dirs: add PidsCgroupDir <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6500>
[16:14] <mup> PR snapcraft#2468 closed: many: support for stage-snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2468>
[16:14] <zyga> Chipaca: can you please review the dirs change quickly
[16:14] <zyga> I can then propose more useful stuff
[16:15] <Chipaca> zyga: I've got to agree with mvo, no point to the pr on its own
[16:15] <zyga> there is a hidden point, I love reusing commit messages
[16:15] <zyga> no need to write "branch" description
[16:15] <zyga> but I can close it and merge it into the bigger one
[16:23] <pedronis> Chipaca: https://github.com/snapcore/snapd/pull/6501
[16:23] <mup> PR #6501:  tests/main/auto-refresh-private: make sure to actually download with the expired macaroon <Created by pedronis> <https://github.com/snapcore/snapd/pull/6501>
[16:23] <mup> PR snapd#6501 opened:  tests/main/auto-refresh-private: make sure to actually download with the expired macaroon <Created by pedronis> <https://github.com/snapcore/snapd/pull/6501>
[16:35] <mup> PR snapd#6500 closed: dirs: add PidsCgroupDir <Simple 😃> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6500>
[16:35] <mup> PR snapd#6502 opened: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
[16:36] <zyga> Chipaca: ^ :)
[16:36] <zyga> Chipaca: I mainly wonder if you will ask me to use a different type for PID
[16:37] <Chipaca> zyga: it's an int32, right?
[16:37] <zyga> int
[16:37]  * Chipaca looks
[16:37] <zyga> (because it was the easy choice)
[16:37] <zyga> we only read it from text files
[16:37] <zyga> and print
[16:38] <mup> PR snapcraft#2470 opened: Enable support for strictly confined multipass <Created by gerboland> <https://github.com/snapcore/snapcraft/pull/2470>
[16:39] <Chipaca> zyga: I'd be a teeny tiny bit happier if they were int32, mostly because that signals intentional...ness?]
[16:39] <zyga> do we have a type for that
[16:39] <Chipaca> zyga: 'int' in go often means "yeah it's a number but i didn't think too much about it'
[16:39] <zyga> so that I don't have to spell it everywhere?
[16:40] <Chipaca> zyga: no
[16:40] <Chipaca> zyga: grep -ri pid.int32 tho
[16:57] <t1mp> hello. I have a python+Qt app that works fine, but after snapping it, some dialogs don't open when I click the button to open them.
[16:57] <t1mp> How can I debug this? For example, how do I enter the snap container and then launch python inside?
[16:58] <pedronis> mvo: pstolowski: I did another pass over some of your PRs
[16:59] <pstolowski> pedronis: ty!
[17:00] <mvo> pedronis: \o/
[17:04] <zyga> t1mp: hey
[17:04] <t1mp> hello zyga
[17:04] <zyga> t1mp: you can run "snap run --shell snapname"
[17:04] <t1mp> I just did snap run --shell qmenta-uploader :)
[17:04] <zyga> and then look at wrapper scripts typically generated by snapcraft in $SNAP directory
[17:04] <t1mp> but I guess some env vars are missing
[17:04] <zyga> yeah
[17:04] <zyga> those are in the wrappers
[17:04] <t1mp> right :)
[17:04] <zyga> eventually it will all be inside a delcarative system but that's not done yet
[17:05] <t1mp> I think you told me once, last year, but I forgot since in the meantime I didn't have to worry about it
[17:06] <mvo> pstolowski: btw, I see a lot of "udev monitor observed ... event for ..." in my snapd from git - should we make this a debugf instead of a noticef
[17:07] <t1mp> strange. I am opening a QtQuick.Dialogs.FileDialog. It works when I run the app 'locally', but not when I run it from a snap.
[17:07] <pedronis> mvo: I think some of the new PRs turn some Noticef into Debugf, not sure if that is one of those
[17:07] <zyga> any denials/
[17:07] <zyga> I'm about to EOD (or at least break for dinner) but I can look later
[17:08] <mvo> pedronis: aha, thanks
[17:08] <t1mp> zyga: no errors/warnings at all. (I did get a bunch before, but I fixed them all and it still doesn't work, so that doesn't seem to be the problem).
[17:08] <t1mp> zyga: thanks, enjoy your dinner :)
[17:09] <t1mp> Speaking of which, I need to eat too.
[17:16] <pstolowski> cachio: ping
[17:25] <cachio> pstolowski, yes
[17:45] <mup> PR snapd#6503 opened: tests: use snap which takes 15 seconds to install on retryable-error test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6503>
[17:54]  * cachio afk
[18:23] <pstolowski> cachio: hey, sorry, fyi when you're back:
[18:24] <cachio> pstolowski, hey
[18:24] <pstolowski> cachio: i've made a quick hack to use qemu-virgil in nested.sh, but it needs more work - https://paste.ubuntu.com/p/t8tdRFCdyY/
[18:24] <pstolowski> cachio: hey
[18:25] <cachio> pstolowski, nice, test is passing with that change?
[18:26] <pstolowski> cachio: no, i think the failure on 16.04 is actual bug in hotplug code, i found one specific issue in the code and now checking a fix
[18:26] <pstolowski> cachio: i'm not sure if we will need newer qemu or not
[18:26] <cachio> pstolowski, ah, nice, that test worked in that case
[18:28] <pstolowski> cachio: if so, then it will need more work. the snap uses strict mode by default, but it's problematic because we use /dev/tty* for our virtual devices, so i used devmode. also i'm not sure if qemu-system-i386 is supported, there snap doesn't have binary for that
[18:28] <pstolowski> cachio: (the snap = the qemu-virgil snap)
[18:28] <pedronis> mvo: this is the question Chipaca was referring to in the standup:  https://github.com/snapcore/snapd/pull/6034#discussion_r255888988
[18:28] <mup> PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
[18:29] <cachio> pstolowski, ah, ok
[18:30] <cachio> pstolowski, otherwise we could continue using the current way
[18:31] <pstolowski> cachio: yes, i'll know by tomorrow if old qemu is ok
[18:40] <pstolowski> cachio: ok, 1 bug fixed and i hit another one, interesting those happened on 16.04! good! eod
[18:42] <mvo> pedronis: thank you, looking
[18:43] <cachio> pstolowski|afk, nice, thanks for fixing those ones, see you tomorrow
[19:00]  * Chipaca takes the walk for a dog
[19:05] <mup> PR snapd#6504 opened: tests: not checking 'tracking channel' after refresh core on nested execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6504>
[20:01] <Wimpress> Snapcraft pro tips is live streaming now!
[20:01] <Wimpress> https://www.youtube.com/watch?v=DtZySQgBxmM
[20:07] <t1mp> I guess that's useful, since the snapcraft docs are outdated. https://docs.snapcraft.io/debugging-building-snaps/6274 with snapcraft 3, there is no prime/ dir so those docs are not helpful
[20:09] <Wimpress> @degville ^
[20:11] <ijohnson> do we have a list anywhere of which distros enable re-exec for the core snap and which don't?
[20:14] <degville> thanks Wimpress. noted.
[20:35] <mup> PR snapcraft#2471 opened: test: test-beta <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2471>
[20:42] <t1mp> I can no longer let my snap open a file select dialog.. :s It works fine in my (python+QtQuick) app, but after snapping it, the new dialog simply doesn't show up any more. Did anyone else encounter this?
[20:47] <Facu> Hello! I'm stuck building a snap for my project (a pure Python one: `fades`)...
[20:47] <Facu> - if I try to build it in my desktop I get another weird error ( https://forum.snapcraft.io/t/the-linker-version-2-23-used-by-the-base-core-is-incompatible-with-files-in-this-snap/7430/13 )
[20:48] <Facu> - if I try to build it in my laptop I get another weird error ( https://forum.snapcraft.io/t/error-you-must-give-at-least-one-requirement-to-install-when-building-a-snap/9946 )
[20:49] <Facu> - if I try build.snapcraft.io to build it, I go and request it manually, it appears during some seconds the row (after past builds 7 months ago) "Number: requested" and "Build trigger: Manual build", but after those seconds that row disappears and it's as if I never tried to build it
[20:49] <Facu> is there anything else I could try? thanks!
[21:06] <NickZ> Facu: the first post is outdated; lxd is no longer required for building snaps. If you specify "base: core16" or "base: core18" in your snapcraft yaml, it'll build it in a VM
[21:06] <Facu> NickZ, I should use "base: core18", as I'm in Bionic, right?
[21:06] <NickZ> yeah, if you want your snap to target bionic, you should use that
[21:07] <Facu> NickZ, I want my snap to target everything
[21:07] <NickZ> Only for the build step; it makes sure that whereever you're building this snap, it will always use the bionic packages when pulling in dependencies and building
[21:07] <NickZ> you can use it everywhere
[21:09] <Facu> it's installing multipass now :o
[21:10] <NickZ> yup
[21:17] <Facu> NickZ, it's Launching a VM (retrieving an image, it seems), so I guess that unblocked the problem
[21:27] <Facu> NickZ, aaaaaand it looks it worked :)
[21:29] <Facu> NickZ, thanks!!!
[21:32] <mup> PR snapcraft#2472 opened: project loader: do not leak a part's build-environment <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2472>
[21:32] <NickZ> Facu: awesome, np man
[22:51] <mup> PR snapd#6034 closed: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6034>
[22:53] <Odd_Bloke> I have a single shell script that I want to include in a snap that is otherwise Python-only; how do I simply copy a file from my git repo somewhere in to my snap?
[22:53] <Odd_Bloke> (I've been trying to do this with arguments to the Python plugin, but perhaps this needs to be a separate part?)
[22:53] <stgraber> Odd_Bloke: separate part using the dump plugin
[22:53] <Odd_Bloke> Thanks!
[22:54] <stgraber> you could also use an override on your existing part and then use that to cp stuff around but that's gross :)