[05:01] <mborzecki> morning
[05:06] <zyga> Good morning mborzecki
[05:07] <mborzecki> zyga: hey
[05:07] <zyga> Ries and shine,
[05:17] <zyga> s/ries/rise/i
[05:40] <mup> PR snapcraft#2563 closed: Release changelog for 3.5 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2563>
[07:03] <pstolowski> mornings
[07:12] <mborzecki> pstolowski: hey
[07:36] <mborzecki> hmm mirrors.fedoraproject.org does not resolve
[07:39] <mborzecki> pstolowski: can you try nslookup fedoraproject.org ?
[08:01] <Chipaca> bongiorno, principesse e principi
[08:02] <pstolowski> Chipaca: hey!
[08:02] <mborzecki_> Chipaca: hey, thought you're swapping today
[08:03] <Chipaca> I was talked into not doing so :-)
[08:03] <Chipaca> as in, not needing to swap
[08:03] <Chipaca> not as in not swapping
[08:03] <Chipaca> :)
[08:04] <Chipaca> had a very lazy weekend (where 'lazy' includes 'personal best 10k woo' but w/e)
[08:09] <mborzecki_> Chipaca: congrats
[08:10] <Chipaca> pstolowski: on Friday you said maybe we should add a flag to Done() to say whether the script had run or not, and I said maybe instead just don't run things (and we add the flag if/when we need the "run Done even with no script" feature instead), but I didn't understand your answer -- and didn't want to slow down the standup further
[08:10] <mborzecki> Chipaca: don't tell mvo though :)
[08:11] <Chipaca> mborzecki: about which part? =)
[08:11] <mborzecki> Chipaca: 10k personal best
[08:12] <Chipaca> mborzecki: :-) I'm more competitive than he is, but we both go to great efforts not to be competitive with each other
[08:12] <Chipaca> just don't play board games with me and you'll be fine
[08:12]  * Chipaca does not want to show that side of himself ever
[08:13] <Chipaca> pstolowski: could you tell me why the "don't run it" option is worse?
[08:14] <Chipaca> to me it seems like a win, there's a lot of stuff we'd avoid doing in the common case of 'no script'
[08:14] <Chipaca> (everything from the xxx on)
[08:16] <pstolowski> Chipaca: yes, sorry, I think I didn't understand your suggestion either. I think as long as we keep an option to run Done() even if there is no script, it's fine, that was my main point. Probably your idea is better to save some cycles indeed
[08:17] <Chipaca> pstolowski: I'll push a pr to add this, then
[08:17] <Chipaca> with a flag on the hook setup
[08:17] <Chipaca> just in case (tm)
[08:25] <pstolowski> Chipaca: thanks
[08:31] <mup> PR snapd#6862 opened: overlord/hookstate: don't run handler unless hooksup.Always <Created by chipaca> <https://github.com/snapcore/snapd/pull/6862>
[08:31] <Chipaca> pstolowski: ^^^
[10:07] <ackk> hi, I'm seeing a weird behavior with python deps building a snap non non-intel machines
[10:08] <ackk> https://launchpadlibrarian.net/423189074/buildlog_snap_ubuntu_bionic_arm64_maas_BUILDING.txt.gz is failing because cffi pulled from pipy differs from the one in bionic, but https://launchpadlibrarian.net/423191401/buildlog_snap_ubuntu_bionic_amd64_maas_BUILDING.txt.gz doesn't
[10:08] <ackk> and they have the same versions
[10:20] <Chipaca> ackk: ports.u.c. differing from the main archive?
[10:21] <Chipaca> or is that what you mean about the same versions
[10:21] <ackk> Chipaca, well it seems the python3-cffi-backend deb that get installed is the same version in both cases
[10:22] <ackk> 1.11.5, whereas the one from pypi is 1.12.3
[10:22] <ackk> so I'm not sure why it's failing in one case and not in the other
[10:23] <ackk> actually it fails on arm64 and ppc64 arches, works in i386 and amd64
[10:24] <Chipaca> ackk: so the deb is the same version, but the one in pipy is different, for those arches?
[10:24] <ackk> Chipaca, no, deb is 1.11.5 for all and pypi is 1.12.3 for all
[10:24] <ackk> but it only complains that the versions are different on non-intel
[10:25] <Chipaca> ackk: could it be because pipy does not have non-intel linux binaries of cffi?
[10:26] <ackk> Chipaca, ah. that's a good point
[10:26] <ackk> indeed it seems so
[10:26] <Chipaca> ackk: so maybe on non-intel it's trying to build it from source, and needs more stuff for that?
[10:27]  * Chipaca does not know
[10:27] <ackk> Chipaca, well I guess I can try to force cffi in requrements to match the ubuntu one
[11:00] <zyga> Hello
[11:08] <Chipaca> zyga: 'sup
[11:11] <pstolowski> zyga: hey!
[11:11] <pstolowski> zyga: how was the travel? how is the sprint going?
[11:33] <zyga> pstolowski: the travel was very good, the sprint is going on slowly, nothing eventful yet
[11:34]  * Chipaca lunches
[11:36] <zyga> pstolowski: some meetings about core20 but early early discussions
[11:51] <Saviq> zyga: https://git.launchpad.net/~saviq/+git/miral-framework?h=master is my test - didn't work with edge FWIW
[12:09] <mborzecki> cmatsuoka: pstolowski: please take another look at #6849, i've pushed an implementation that matches what libblkid does
[12:09] <mup> PR #6849: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>
[12:09] <mborzecki> (or systemd/udev for that matter)
[12:09] <mborzecki> off to pick up the kids
[12:12] <cmatsuoka> mborzecki: ack
[12:17] <pstolowski> mborzecki: k, will do after lunch
[12:43] <mborzecki> cmatsuoka: pstolowski: thx!
[12:55] <Chipaca> degville: what would be better: "Talk to apt via an apt hook", "Run as an apt hook", "Run in 'apt hook' mode", or "Be an apt hook" ?
[12:58] <zyga> mborzecki: quick one https://github.com/snapcore/snapd/pull/6863
[12:58] <mup> PR #6863: testutil: support sharing-related mount flags <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6863>
[12:58] <mup> PR snapd#6863 opened: testutil: support sharing-related mount flags <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6863>
[12:58] <degville> Chipaca: I think the second, or - 'via an apt hook'? (difficult without context). if we can link to something apt hook related, that would be good too.
[12:59] <Chipaca> degville: this is for 'snap advise-snap --from-apt', which is a bit backwards but also currently is wrong and also *also* currently upsets localisers because trying to fix it breaks our static lowercase-description rule
[13:00] <Chipaca> degville: it's a command that's hidden (so nobody ever sees this string! until we fix go-flags) and the option is only used from integration scripts
[13:00] <mup> PR snapd#6861 closed:  packaging/fedora: Merge changes from Fedora Dist-Git and drop EOL Fedora releases <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6861>
[13:01] <Chipaca> but, we smacked an i18n.G on it to be conscientious about it or sth
[13:02] <Chipaca> degville: apt runs this as a hook for suggestions, basically
[13:03] <Chipaca> "Run under apt" could also work, not mention hooks at all
[13:03] <Girtablulu> Save data of snap "retroarch" in automatic snapshot set #27 (cannot create archive: runuser: failed to user credentials: <-- someone knows what's the issue is?
[13:03] <degville> Chipaca: I'm just in our standup if you wanted to chat about it.
[13:03] <Chipaca> omw
[13:03] <Chipaca> was just about to ask about the standup :)
[13:04] <zyga> mborzecki: another one please https://github.com/snapcore/snapd/pull/6864
[13:04] <mup> PR #6864: cmd/snap-update-ns: fix golint complaints about variable names <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6864>
[13:04] <mup> PR snapd#6864 opened: cmd/snap-update-ns: fix golint complaints about variable names <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6864>
[13:06] <Chipaca> Girtablulu: ouch
[13:07] <Chipaca> Girtablulu: is there anything interesting about our user setup?
[13:08] <Girtablulu> define interesting? :), installment works fine just doesn't let me remove stuff :D
[13:08] <Chipaca> Girtablulu: anything other than the default /etc/passwd user
[13:09] <Girtablulu> nope, not that I'm aware of, using Solus
[13:09] <Chipaca> Girtablulu: on remove snapd now tries to archive the user data before deleting it, and for some reason your system doesn't support that
[13:09] <Chipaca> Girtablulu: you'll probably get the same error from 'snap save'
[13:10] <Girtablulu> yep correct
[13:10] <Chipaca> Girtablulu: you can disable these snapshots, to unblock you; pstolowski will know how to do that (it's in the forum otherwise)
[13:10] <Chipaca> Girtablulu: but something's funny with your system fwiw
[13:12] <Girtablulu> k thanks for the info
[13:17] <degville> Chipaca: if the way apt is probed doesn't matter to whoever is asking for help on advise-snap (would it help to know, for eg., when troubleshooting an integration script), I'd go with "Run under apt."
[13:18] <Chipaca> degville: the super-verbose one would be "This flag tells snap-advise that it is being run under apt, as a hook", or something like that
[13:19] <degville> Chipaca: +1 - sounds good to me!
[13:19] <Chipaca> degville: but that's too long :-D
[13:20] <Chipaca> bah,not really, but we usually get away with it being shorter
[13:20] <Chipaca> the "this flag tells <the command> that" is usually implied
[13:20] <Chipaca> but it's a bit weird, this one
[13:20] <Chipaca> dunno
[13:20] <degville> Chipaca: right, sorry. Thought there was going to be both a short and verbose version.l
[13:21] <Chipaca> omg no :)
[13:21]  * Chipaca suddenly imagined having to come up with short _and_ verbose versions of every flag help text
[13:23] <degville> Chipaca: ahaha! "Run  under apt using a hook", "Run via an apt hook."?
[13:23] <Girtablulu> Chipaca: thanks found the command
[13:24] <Chipaca> Girtablulu: snap set system somethingsomethingsomething?
[13:24] <Chipaca> degville: this is a flag apt uses to tell 'snap advise-snap' it is running under apt
[13:24] <Girtablulu> snap set core snapshots.automatic.retention=no
[13:24] <Chipaca> Girtablulu: that's what i said :-p (j/k, but note core and system are synonymous there)
[13:25] <Girtablulu> ah k :)
[13:25] <Chipaca> Girtablulu: out of curiosity if you could explore why runuser doesn't work for you I'd be grateful
[13:25] <Chipaca> Girtablulu: if you can't you can't :)
[13:27] <Girtablulu> I gonna poke the solus cores devs regarding this, for me is this a bit confusing :)
[13:27] <Chipaca> Girtablulu: it's a new feature so it's entirely possible we're needing to do something extra -- but it might be some wonky integration on solus's side. I really don't know.
[13:27] <Chipaca> Girtablulu: you can quote me on that (especially the last sentence is always true)
[13:28] <Girtablulu> yea
[13:28] <Girtablulu> that's why first poking solus devs :D
[13:28] <Girtablulu> quite possible that ikey build the snap package not correctly for solus and now it shows
[13:29] <Chipaca> degville: everything is terrible. I'm going with "Run as an apt hook" and hoping for the best.
[13:29]  * Chipaca misses ikey
[13:29] <degville> Chipaca: ok. :)
[13:36] <Chipaca> mborzecki: fedora 30 not having snap/bin on path was fixed somewhere, right?
[13:37] <mborzecki> Chipaca: is it about the warning in snap install?
[13:39] <Chipaca> mborzecki: ye s
[13:39] <Chipaca> mborzecki: see https://forum.snapcraft.io/t/how-to-fix-snap-binaries-not-found/9469
[13:40] <Chipaca> lots of federees
[13:40] <Chipaca> fedorees
[13:40] <Chipaca> fedorians
[13:40] <mborzecki> Chipaca: iirc, plain sudo would not load the whole profile, so no PATH entry
[13:40] <Chipaca> fedoralians
[13:40] <Chipaca> aliens
[13:40] <mborzecki> Chipaca: sudo -i worked though
[13:40] <mup> PR snapd#6865 opened: cmd/snap: allow option descriptions to start with the command <Created by chipaca> <https://github.com/snapcore/snapd/pull/6865>
[13:53] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6866
[13:53] <mup> PR #6866: cmd/snap-update-ns: allow changing mount propagation <Created by zyga> <https://github.com/snapcore/snapd/pull/6866>
[13:54] <zyga> I'll review with jdstrand locally
[13:54] <mup> PR snapd#6863 closed: testutil: support sharing-related mount flags <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6863>
[13:54] <mup> PR snapd#6866 opened: cmd/snap-update-ns: allow changing mount propagation <Created by zyga> <https://github.com/snapcore/snapd/pull/6866>
[13:55] <zyga> mborzecki: I force pushed because git add -p typo :P
[14:34] <mup> PR snapd#6858 closed: cmd/snap: unit tests for debug timings <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6858>
[15:09] <Chipaca> lol of course the only test that failed is the connectivity check
[15:14] <Chipaca> ogra: nethack 3.6.2 has been out for _ages_ and there's been no snap update! what is this! rabble rabble rabble
[15:16] <ogra> Chipaca, oh, geez ... thanks for the ping, will update it
[15:17] <Chipaca> ogra: :-) i wasn't looking for it, i just noticed the news
[15:17] <ogra> what is it that all of a sudden they make regular releases ? ...
[15:17] <ogra> one revision per dacade should be enough for everyone !
[15:17] <Chipaca> ogra: next up: nethack LTS
[15:17] <ogra> *decade
[15:28] <Chipaca> pstolowski: is there anything that sets hooksetup.revision? I somehow got it in there at _some_ point which led me to believe it worked, but i can't reproduce that now
[15:31] <pstolowski> Chipaca: it seems to be only used in tests if looking for all references doesn't lie
[15:33] <Chipaca> sigh
[16:27] <mup> PR snapd#6864 closed: cmd/snap-update-ns: fix golint complaints about variable names <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6864>
[16:45]  * cachio lunch