=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[05:08] <mborzecki> morning
[05:11] <mborzecki> brb, new kernel
[05:52] <zyga> good morninf
[05:58] <mborzecki> zyga: hey
[05:58] <zyga> hey hey
[05:58] <zyga> I'm trying to fix what I prepared yesterday and add the CUDA test as well
[06:11]  * zyga fights tab creep
[06:14] <mborzecki> zyga: next step https://forum.snapcraft.io/t/do-snaps-apps-support-vulkan/10534/2
[06:15] <zyga> mborzecki: yeah, I will find some hello-vulcan code
[06:15] <zyga> mborzecki: the interesting experience started when I removed various random bits of MESA from my test snap
[06:15] <zyga> it shrank significantly and no longer ran without the "driver" snap connected
[06:15] <zyga> but first things first
[06:16] <zyga> fight tab creep, restore opengl part to working order, get cuda to work in confinement
[06:20] <mborzecki> mvo: morning
[06:20] <zyga> hey mvo :)
[06:21]  * zyga managed to reduce tab creep to ~ 10 tabs 
[06:23] <mvo> hey mborzecki and zyga good morning
[06:24] <mborzecki> zyga: can you take a quick look https://github.com/snapcore/snapd/pull/6792 ? just renames and moving the code around
[06:24] <zyga> mborzecki: looking
[06:24] <zyga> I had a look last night but it was a bit more complex
[06:25] <zyga> mborzecki: question: why PositionedVolume contains a *Volume rather than Volume?
[06:25] <mborzecki> zyga: avoiding another copy, no other reason
[06:26] <zyga> are we mostly working with Positioned or the plain version?
[06:26] <mborzecki> zyga: depends where, validation works with Volume mostly, update works with Positioned*
[06:26] <zyga> a copy has its cost but also has the property of not being related to something anymore, so you can clobber the volume but the positioned volume stays intact
[06:26] <zyga> mmm
[06:27] <zyga> +1 but consider if it is easier to reason about this without the pointer
[06:27] <mvo> hm 6782 has no +1 but surely mborzecki has an opinion on this one :)
[06:27] <mborzecki> mvo: looking
[06:28] <zyga> commented
[06:28] <mborzecki> zyga: thanks
[06:28] <zyga> mborzecki: and then perhaps https://github.com/snapcore/snapd/pull/6788 :)
[06:29] <zyga> simple and just a 2nd +1
[06:29] <mborzecki> mvo: lgtm, though i can only +1 the parts i didn't touch :)
[06:30] <zyga> woot, thank you!
[06:30] <mvo> mborzecki: that seems to be fine, I will +1 the parts you did touch
[06:38] <zyga> mborzecki, mvo: one simple argument removal https://github.com/snapcore/snapd/pull/6794
[06:40] <mborzecki> zyga: more lines removed than added, +1 :)
[06:42] <mvo> zyga: 6782 had a +0.9 from you - is the final 0.1 there now? with that we can merge jamies 6759
[06:42] <zyga> Thanks guys!
[06:42] <zyga> mvo: looking
[06:44] <zyga> mvo: https://github.com/snapcore/snapd/pull/6782/files#diff-bdab0f3d09049605d4bd7bc4892a6a4bR91 !!!
[06:44] <zyga> was this always broken>?
[06:49] <mvo> probably :/
[06:51] <zyga> but the test did not catch this before
[06:51] <zyga> interesting
[06:56] <mvo> zyga: yeah, definitely worth looking why
[06:58] <zyga> mvo: and it was failing for you without this extra dash, right?
[06:58] <zyga> mvo: but not initially,
[06:58] <mborzecki> mup still silent?
[06:58] <mvo> zyga: I think mborzecki fixed this particular one
[06:58] <mvo> mborzecki: I think so
[06:59] <zyga> mvo: so something that changed in the patch caused it to fail
[06:59] <mborzecki> --build-id?
[06:59] <zyga> aha
[06:59] <zyga> yes
[06:59] <mvo> mborzecki: we probably need to poke gustavo about it
[06:59] <zyga> mup_: hello
=== pstolowski|afk is now known as pstolowski
[07:00] <pstolowski> morning
[07:01] <mborzecki> zyga: mvo: fwiw both -build-id and --build-id, the manpage though says --build-id
[07:03] <mvo> hey pstolowski
[07:03] <mvo> mborzecki: aha, nice
[07:07] <pstolowski> mvo: i saw your idea from yesterday, ty, i'm looking at it
[07:09] <pstolowski> (timing for state loading)
[07:16] <mvo> pstolowski: cool, thanks
[07:23] <zyga> did anyone restart https://github.com/snapcore/snapd/pull/6794 ?
[07:26]  * mvo didn't 
[07:27] <mvo> zyga: if you could add a test to 6751 this one is fine to go in, sorry that the review for this took so long, its nice and small and ready
[07:27] <zyga> checking
[07:27] <zyga> yes, I plan to
[07:27] <zyga> that's an early branch,
[07:27] <zyga> just didn't go anywhere last week
[07:27] <pstolowski> mvo: to clarify - the idea with timings is to measure state.ReadState() on startup correct?
[07:38] <mvo> pstolowski: yes
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[08:01] <zyga> mvo, mborzecki: another simple chunk https://github.com/snapcore/snapd/pull/6796
[08:14] <Chipaca> moin moin
[08:16] <niemeyer> mvo, mborzecki_: May I help somehow?
[08:16] <mborzecki_> niemeyer: hi, mup is awfully silent
=== mborzecki_ is now known as mborzecki
[08:16] <niemeyer> Sorry, I still haven't fixed its ability to self-identify
[08:17] <niemeyer> I'll poke it
[08:17] <mborzecki> niemeyer: thanks!
[08:17] <zyga> hello Chipaca, hey niemeyer :)
[08:17] <niemeyer> mup_: Should work now
[08:17] <mup_> niemeyer: In-com-pre-hen-si-ble-ness.
[08:18] <niemeyer> Hmm.. and somebody took over its nick
[08:18] <niemeyer> zyga: Heya
=== mup_ is now known as mup
[08:46] <mvo> zyga: hey, do you have time for a quick about the static attibutes PR?
[08:46] <zyga> mvo: hey, sure
[08:47] <mvo> zyga: cool, lets hop to the standup channel, I will be there in 30s
[08:47] <zyga> mvo: sure
[09:04] <zyga> pstolowski: hey
[09:04] <mvo> pstolowski: hey, want to join the standup channel?
[09:04] <zyga> pstolowski: we have the call about stale connection attributes
[09:04] <zyga> pstolowski: could you join us please
[09:04] <zyga> pstolowski: sorry for not pinging you earlier, but we just started a moment ago
[09:05] <pstolowski> zyga: sure, coming
[09:18] <zyga> thank you Pawel!
[09:19]  * Chipaca hates 409s
[09:24] <mup> PR snapd#6797 opened: overlord/ifacestate: revert the initial fix for lp #1825883 <Created by stolowski> <https://github.com/snapcore/snapd/pull/6797>
[09:37] <pstolowski> zyga, mvo: ^
[09:40] <zyga> done
[09:40] <zyga> pstolowski: and update the bug report with additional information that this is unfixed
[09:40] <mvo> pstolowski: ta!
[09:41] <pedronis> mvo: we still need to decide what to do with https://github.com/snapcore/snapd/pull/6638/files, no ?
[09:41] <mup> PR #6638: interfaces: add support for the snapd snap in the dbus backend  <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6638>
[09:41] <mvo> pedronis: yes
[09:42] <mvo> pedronis: its a re-exec thing but yeah, without it there is a (small) regression
[09:43] <mvo> pedronis: thinking about it, it might be racy but worst case is that the same file is written twice - unless I miss something
[09:48] <pedronis> Chipaca: mvo: hi, is the cohort stuff in 2.39? what is still missing?
[09:49] <Chipaca> pedronis: it is not in 2.39, no
[09:49] <Chipaca> pedronis: create-cohort landed just last night finally
[09:49] <Chipaca> pedronis: i'm working on install, tests are looking good and hoping to get it covered and up today
[09:50] <Chipaca> switch and refresh should be a small thing after that, and then commands to expose this to the user
[09:50] <Chipaca> still thinking about leave-cohort a bit, but expect it to emerge naturally as i get there
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[10:09] <mup> PR snapd#6798 opened: gadget: introduce checkers for sanitizing structure updates <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6798>
[10:10] <mborzecki> another bulky one ^^, fortunately tests are 75+% of the whole thing
[10:21] <mvo> pedronis: should I de-conflict 6747 for you?
[10:27] <mborzecki> mvo: can we just bump go to 1.10 in travis? iirc it's the oldest one we build with anyway
[10:33] <mvo> mborzecki: iirc EPL and RHEL were holidng us back, but if that got updated to 1.10 +1
[10:34] <mborzecki> mvo: it would also fix the madness with go fmt indent chnges in 1.10
[10:34] <mvo> mborzecki: what is the version in centos right now? (and rhel?)
[10:34] <mborzecki> mvo:  checking right now
[10:34] <mvo> mborzecki: ta
[10:35] <mvo> pedronis: fwiw, I have a PR almost ready to add deviceCtx to checkSnap* and update the tests (just the mechanics at this point, no functional changes)
[10:35] <mborzecki> mvo: golang-1.11.5-1.el7
[10:37] <mup> PR snapd#6799 opened: travis: bump Go version to 1.10.x <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6799>
[10:41] <mvo> mborzecki: \o/
[10:44] <Chipaca> mborzecki: I don't think the .x is literal
[10:44]  * Chipaca looks
[10:44] <Chipaca> well it worked ¯\_(ツ)_/¯
[10:44] <mborzecki> Chipaca: that should be last tagged patch release in given major.minor
[10:45] <Chipaca> mborzecki: isn't "1.10" the same?
[10:45] <mborzecki> Chipaca: i was bit surprised suprised that 1.10 is 1.10 exactly
[10:45] <Chipaca> that is surprising indeed
[10:46] <Chipaca> the documentation i saw didn't point this out either
[10:46] <Chipaca> hm
[10:46] <Chipaca> anyway, eh, if it works it works
[10:52] <pedronis> mvo: if you want/can, I'm trying to take care of errands and then do the 2.39 reviews
[10:52] <mvo> pedronis: thanks!
[10:58] <mvo> pedronis: pushed the update for devicectx
[10:58] <mvo> 6747 needs a second review btw :)
[10:58] <mvo> (its this devicectx PR)
[11:25] <Chipaca> luuuuuuuunch
[11:25]  * Chipaca is zombie
[11:35] <pedronis> mvo: gave some feedback on #6778
[11:35] <mup> PR #6778: [RFC] snapstate: auto-install snapd when needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/6778>
[11:53] <pedronis> mvo: commented also in #6638
[11:53] <mup> PR #6638: interfaces: add support for the snapd snap in the dbus backend  <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6638>
[11:53] <pedronis> marked it for 2.29 as well
[11:54] <pedronis> heh, 2.39
=== ricab is now known as ricab|lunch
[12:01] <mborzecki> off to pick up the kids
[12:04] <dot-tobias> kyrofa / sergiusens: Is it possible (and feasible) to use classic snaps as stage-snaps? The ruby snap seems to work fine so far, but suddenly the bundled libraries are not found by apps in the snap. I guess it has something to do with this snapcraft notification: “part X needs the following libraries that are not included in the snap or base: lib64/ld-linux-x86-64.so.2”
[12:14] <pedronis> pstolowski: question in #6755
[12:14] <mup> PR #6755: overlord/snapstate: tweak autorefresh logic if network is not available <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6755>
[12:16] <cmatsuoka> Chipaca: can the snapd snap be built with base: core? it could solve the snap dir clutter problem
[12:16] <mup> PR snapd#6799 closed: travis: bump Go version to 1.10.x <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6799>
[12:17] <pstolowski> pedronis: replied
[12:17] <mup> PR snapd#6797 closed: overlord/ifacestate: revert the initial fix for lp #1825883 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6797>
[12:20] <pedronis> pstolowski: couple of comments, thank you
[12:22] <pedronis> mvo: thanks for #6771 , I was thinking about something like that
[12:23] <mup> PR #6771: cmd: add `snap debug validate-seed <path>` cmd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6771>
[12:24] <pedronis> mvo: zyga: this is bad tough:  #6763
[12:24] <mup> PR #6763: overlord/snapstate: remove PlugsOnly <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6763>
[12:24] <zyga> pedronis: oh?
[12:24] <zyga> pedronis: can you clarify?
[12:24] <pedronis> zyga: it's needed for this at some point: https://forum.snapcraft.io/t/cross-snap-operations-bases-and-concurrency/5685
[12:25] <zyga> pedronis: I wasn't aware of this, is having just plugs somehow special though? (or having just slots?)
=== chihchun is now known as chihchun_afk
[12:25] <Chipaca> cmatsuoka: if that now works, yes
[12:25] <pedronis> zyga: yes, it's special, two snaps having only plugs can't interfere with each other
[12:26] <Chipaca> cmatsuoka: assuming base: core doesn't actually reach the snap.yaml
[12:26] <zyga> pedronis: how about two snaps with just slots?
[12:26] <pedronis> (unless they are a special snap like bases or kernel etc)
[12:26] <cmatsuoka> Chipaca: worked in a quick PoC, let me try with the real thing
[12:26] <pedronis> zyga: that's not as useful, they interfere each with snaps with plugs
[12:28] <pedronis> anyway that change needs reverting
[12:28] <pedronis> atm
[12:51] <sergiusens> dot-tobias: you will need to organize or set the library paths appropriately... I don't think the "fine" part has been nailed if libraries are not found
[12:51] <sergiusens> dot-tobias: also, if the publisher decides to change the base then when you stage that snap you will potentially have a broken snap, more than potentially, most likely as the path to the linker loader is fixed to the base
[12:52] <sergiusens> kyrofa: we do have a bug for that about the deb and bases... it just requires time... I am not missing the SRU process at all
[12:55]  * sergiusens scratches head as he does not see his replies from yesterday on this irc session
[12:56] <dot-tobias> sergiusens: Thanks for the info, I'll test if a fork of the snap works better (I haven't found an issue yet, but I guess somewhere down the road the ruby snap's classic confinement will break something?). Anyway, the snapcraft notice about ld-linux doesn't occur if I switch back to stage-packages and the ruby plugin, but still one service suddenly cannot find a library pulled in via stage-packages (not stage-snaps) … puzzles me
[13:21] <tomwardill> hi! Is there a snapd environment variable (or other method) that will get me the response payload from the store?
[13:21] <zyga> Chipaca: ^
[13:22] <Chipaca> tomwardill: hi! yes 1 sec
[13:22] <tomwardill> ta
[13:23] <Chipaca> tomwardill: SNAPD_DEBUG_HTTP, more in https://github.com/snapcore/snapd/blob/master/HACKING.md#testing-snapd
[13:24] <jdstrand> ogra: hey, I just noticed on my arm64 device, 'sudo classic' results in no /etc/alternatives, which causes anything you install with apt that uses alternatives to fail. have you seen this?
[13:24] <tomwardill> Chipaca: that doesn't appear to dump the response body
[13:24] <tomwardill> (Or I'm doing it wrong)
[13:24] <Chipaca> tomwardill: it does :-) how are you doing it?
[13:24] <tomwardill> oh, I might have the wrong number in the wrong place
[13:25] <tomwardill> one sec :)
[13:25] <tomwardill> Chipaca: sorry, I was holding it wrong.
[13:25] <Chipaca> tomwardill: https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537
=== ricab|lunch is now known as ricab
[13:26] <tomwardill> I had '9' rather than '7', because obviously a higher number is better...
[13:26] <Chipaca> :-D
[13:26] <cachio> mvo, https://paste.ubuntu.com/p/ztGGVFZsF6/
[13:26] <cachio> mvo, this is the output, last line is stuck
[13:26] <mvo> cachio: /o\
[13:30] <mborzecki> cachio: is this what the stuck code is doing? http://paste.ubuntu.com/p/KpGxWdFfVJ/
[13:30] <cachio> mborzecki, yes
[13:31] <cachio> mborzecki, for i in $(seq 130); do echo $i && snap run --strace="-tt" test-snapd-tools.echo "hello-world"; done
[13:31] <cachio> mborzecki, that was the line
[13:32] <mborzecki> cachio: hmm, bad news, seems to run fine locally, with that script i had ~2k iterations before i killed it
[13:33] <mborzecki> cachio: let me try that under spread
[13:33] <cachio> mborzecki, I can generate a debug session on gce
[13:40] <jdstrand> cjwatson: hey, so I've got this in my snapcraft.yaml (https://paste.ubuntu.com/p/kmCRMGGCkk/; note, I tried https://paste.ubuntu.com/p/WPSBFbbPhs/, but that didn't seem to work (didn't pull in gcc-multilib on either amd64 or arm64), but I digress)
[13:41] <cjwatson> jdstrand: this is all up to snapcraft I'm afraid; LP has no say in that
[13:41] <jdstrand> cjwatson: this successfully pulls in gcc-multilib on amd64 (good), but on arm64, it does not. it seems that gcc-multilib is gcc-multilib:armhf in the archive and the chroot in LP doesn't include armhf on arm64
[13:42] <cjwatson> jdstrand: LP chroots have indeed never had cross-architecture config, and are unlikely to
[13:42] <cjwatson> if snapcraft needs that then it has to set it up itself
[13:42] <jdstrand> cjwatson: on amd64 gcc-multilib is in gcc-multilib:amd64, not gcc-multilib:i386
[13:42] <jdstrand> in the archive
[13:43] <jdstrand> so I'm a bit puzzled by either snapcraft, the chroot or the archive
[13:43] <cjwatson> this is really just something we dispatch and let other tools deal with it.  I can only reiterate that nobody should be expecting the base image (chroot) to contain foreign-architecture config
[13:44] <jdstrand> interesting
[13:44] <jdstrand> so I'm just lucky that I could install gcc-multilib on amd64
[13:44] <mup> PR snapd#6800 opened: snapstate: revert "overlord/snapstate: remove PlugsOnly" <Created by mvo5> <https://github.com/snapcore/snapd/pull/6800>
[13:44] <cjwatson> I guess ... I've only used that in very limited cases
[13:44] <jdstrand> cjwatson: ok, thanks
[13:45] <cjwatson> I think in general gcc's multilib config is supported in Ubuntu only where there's been a positive need for it
[13:46] <cjwatson> I guess you'd need to talk to Matthias about that though
[13:46] <jdstrand> cjwatson: in my 'sudo classic' chroot on arm64 device, installing gcc-multilib works great, but it has armhf configured. interesting, in trying to reproduce this I see:
[13:46] <jdstrand> $ sudo dpkg --remove-architecture armhf
[13:46] <jdstrand> dpkg: warning: cannot remove non-foreign architecture 'armhf'
[13:47] <cjwatson> perhaps that's actually its native architecture; try dpkg --print-architecture
[13:47] <jdstrand> $ dpkg --print-architecture
[13:47] <jdstrand> arm64
[13:48] <jdstrand> which is why I came to you. things aren't quite lined up in all the different places
[13:48] <cjwatson> Uh.  Pass :)
[13:48] <jdstrand> I can accept that classic chroot is wrong
[13:48] <mborzecki> cachio: can reproduce that, somehow appears more often with --strace='-tt'
[13:49] <cjwatson> You do also get that message if the architecture hasn't actually been added to dpkg as a foreign architecture (try "dpkg --print-foreign-architectures")
[13:49] <jdstrand> but it seemed odd that gcc-multilib was in the amd64 part of he archive and not in arm64, but instead in armhf
[13:49] <cjwatson> I suppose it could be that the classic environment just crowbarred that package in
[13:49] <cjwatson> Well, that's entirely up to the gcc maintainers
[13:50] <jdstrand> dpkg --print-foreign-architectures prints nothing. anyway, like I said, I'm fine to accept the classic chroot is setup wrong
[13:50] <cachio> mborzecki, nice
[13:50] <cjwatson> And classically multilib has required non-trivial per-architecture effort to maintain
[13:50] <jdstrand> interesting
[13:51] <jdstrand> ok, well, now I'll ask kyrofa and sergiusens how I can setup snapcraft.yaml so it adds armhf lines if I use gcc-multilib:armhf
[13:51] <jdstrand> kyrofa, sergiusens: ^
[13:51] <jdstrand> cjwatson: thanks
[13:52] <cjwatson> np, I think that's likely to be the best path
[13:54] <jdstrand> kyrofa, sergiusens: recall that on arm64 I have a makefile that will detect the SNAPCRAFT_ARCH_TRIPLET and decide if it should build some binaries with -m32. I can't use -m32 without gcc-multilib, but I can't install gcc-multilib on arm64 in LP because the chroot doesn't have cross build env by design (see above) and sources.list doesn't include armhf lines
[13:55] <jdstrand> kyrofa, sergiusens: (this isn't an issue on amd64 since by chance, I only need amd64 configured to install gcc-multilib, but on arm64 I need gcc-multilib:armhf)
[13:56] <jdstrand> kyrofa, sergiusens: if there is a path forward today, I'd like to use it, but since I've got amd64 working with -m32, I can skip this on arm64 if I need to
[13:58] <jdstrand> kyrofa, sergiusens: as an aside, I thought this would (try to) install gcc-multilib on amd64 and arm64, but gcc was always installed: https://paste.ubuntu.com/p/WPSBFbbPhs/. I worked around it with this: https://paste.ubuntu.com/p/kmCRMGGCkk/
[13:59] <mup> PR snapd#6791 closed:  overlord: update static attrs when reloading connections (2.39) <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6791>
[14:02] <mborzecki> ps -ef | grep /sbin/strace shows that we're leaving some strace processes behind
[14:06] <sergiusens> jdstrand: I don't think we support commas there, have you tried multiple "on" statements?
[14:07] <sergiusens> I also don't think we ever tested the construct of having "on, else" statements with just plain packages listed, if that works, great I guess
[14:07] <mup> PR snapd#6741 closed: osutil,cmdutil: move CommandFromCore and make it use the snapd snap (if available) <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6741>
[14:09] <mup> PR snapd#6801 opened: snapstate,devicestate: add snapstate.DeviceCtx to checkSnap* <Created by mvo5> <https://github.com/snapcore/snapd/pull/6801>
[14:12] <jdstrand> sergiusens: multiple on works fine. I read the docs on advanced grammar and they suggested that would work. that isn't the part I care most about though. its installing gcc-multilib:armhf on arm64 in LP:
[14:12] <jdstrand> Could not find a required package in 'build-packages': gcc-multilib:armhf
[14:12] <jdstrand> Build failed
[14:12] <jdstrand> sergiusens: this is because the arm64 chroot in LP intentionally leaves out armhf. is there something I can do today to make this work in LP?
[14:14] <jdstrand> sergiusens: (again, it's ok if there isn't, I'll just move on, but if there is, I'd like to do it)
[14:19] <sergiusens> jdstrand: the "add ppa hack" from the forum could work by overriding the pull step and apt updating
[14:20] <sergiusens> jdstrand: I think that now that we assume all environments where run are disposable, we can certainly "try" and enable the arch from our repo handler
[14:20] <sergiusens> if you don't mind logging a bug, that would be great
[14:23] <mvo> mborzecki: 6759 keeps on giving - now it fails in google:centos-7-64 .../tests/main/base-snaps#
[14:23] <mvo> mborzecki: it seems to be a real issue
[14:24] <mvo> mborzecki: I see that it fails to exec snap-exec - https://paste.ubuntu.com/p/BZ5VQY2cjK/
[14:24] <jdstrand> sergiusens: do you use launchpad bugs or github issues?
[14:24] <mborzecki> mvo: hmm
[14:24] <mvo> mborzecki: which is strange as we did not change anything here
[14:24] <mvo> mborzecki: I have a meeting now so can't dig deeper
[14:24] <sergiusens> jdstrand: lp bugs, our issue tracker on github is closed
[14:25] <jdstrand> ok
[14:25] <sergiusens> that said, I have been looking into using github projects, need to convince mvo of something we can consolidate on
[14:27] <mborzecki> mvo: fails only on centos and amzn2, /etc/os-release is not a symlink on either distro, wonder if that could cause something (and wouldn't explain why it happens only now)
[14:28] <mvo> sergiusens: I would not mind using gh projects, I just did not investigate this much yet
[14:28] <mvo> mborzecki: interessting
[14:29] <mvo> mborzecki: I guess its related to us no longer using cgo in some interessting and yet mysterious way
[14:32] <sergiusens> mvo let's discuss in Lyon... I really like the cross project functionality of LP bugs, but it misses all the nice features of things built around 2010, like a nice dashboard to manage milestones and such... and since our code is on github, auto closing issues becomes much easier
[14:33] <jdstrand> sergiusens: ok, filed https://bugs.launchpad.net/snapcraft/+bug/1827067. let me know if you need anything else
[14:33] <mvo> sergiusens: sounds good, lets sit together in lyon
[14:33] <mup> Bug #1827067: need a way to add foreign architecture to sources.list for build-packages/stage-packages <Snapcraft:New> <https://launchpad.net/bugs/1827067>
[14:40] <mborzecki> mvo: snap-exec is not a static binary
[14:46] <cachio> jamesh, hi, could you please take a look to this change 6541
[14:46] <kyrofa> jdstrand, (cc sergiusens) regarding your last point first, we do support commas but the grammar enforces an AND relationship, not an OR
[14:46] <cachio> #6541
[14:46] <mup> PR #6541: tests: change how dir is umounted on desktop-portal.sh <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
[14:46] <kyrofa> e.g. `on amd64,ubuntu` or `on armhf,fedora`
[14:46] <cachio> jamesh, any suggestions about how to improve that, still failing sporadically
[14:47] <sergiusens> kyrofa: compressed nesting; I wish we had better syntax for that... I completely forgot about that scenario and assumed the opposite on first read
[14:48] <mvo> mborzecki: its not? hm, how did that work in the past then - I mean, this test?
[14:48] <kyrofa> sergiusens, maybe it SHOULD be... but yeah
[14:48] <mborzecki> mvo: idk, everything seems to be in order
[14:48] <mborzecki> mvo: /usr/lib/golang/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -buildmode=exe -buildid=tDnwG8u1pBmUWQO10qzA/_x6vj92SB3p958rhGThv/9RCsi
[14:48] <mborzecki> VE8AphCR9FsbPHc/tDnwG8u1pBmUWQO10qzA -B 0x2b904b806d8f25f00e904ab996b99be6dc650588 -extldflags "-Wl,-z,relro  -static" -extld=gcc $WORK/b001/_pkg_.a
[14:49]  * mvo weeps a bit in the corner
[14:49] <mborzecki> mvo: -static seems to be passed to gcc/ld
[14:49] <mvo> mborzecki: oh, so by not having gcc anymore we loose this? that makes sense
[14:50] <mvo> mborzecki: now the question is how to pass -static to go without cgo
[14:52] <mborzecki> mvo: CGO_ENABLED=0 basically :) but, ther's something fishy about that still
[14:52] <Chipaca> pedronis: silly question about context (the go one), as i've seen opinions on both sides: would it be the right place to use to store the client's user-agent to then send it to the store? that was my plan way back before i read people saying context was evil or sth
[14:52] <ogra> jdstrand, hmm, i think mvo added some code to fix alternatives in core itself in the past. perhaps the classic snap needs some adapting to that
[14:54] <pedronis> Chipaca: in a meeting
[15:08] <pedronis> Chipaca: I think the best use case is a layer talking to itself across others, but once context is around there be some other legitimate use cases
[15:08]  * zyga lunch
[15:08] <pedronis> or not too bad abuses
[15:09] <pedronis> 2nd reviews of https://github.com/snapcore/snapd/pull/6731 would be appreciated
[15:10] <mup> PR #6731: overlord: make the store context composably backed by separate backends for device asserts/info etc <Created by pedronis> <https://github.com/snapcore/snapd/pull/6731>
[15:11] <mborzecki> mvo: CGO_ENABLED=0 or -buildmode=pie seems to trigger the right behavior, but the PIE build fails as centos glibc-statc was not built with -fPIC
[15:11] <mborzecki> mvo: oh, and the same macro on fedora adds -buildmode pie
[15:15] <mup> PR snapd#6802 opened: overlord/ifacestate: update static attributes of "content" interface <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6802>
[15:49] <cachio> jamesh, hi
[15:49] <cachio> jamesh, could you please take a look to #6541
[15:49] <mup> PR #6541: tests: change how dir is umounted on desktop-portal.sh <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
[15:58] <mup> PR snapd#6803 opened: daemon, o/snapstate, store: support for installing from cohorts <Created by chipaca> <https://github.com/snapcore/snapd/pull/6803>
[16:00] <Chipaca> pedronis: i'll review composable thing this evening if nobody else has gotten to it
[16:00] <Chipaca> now i'm going for a run, i think
[16:07] <jdstrand> kyrofa: that would explain while that wouldn't work there. it could never be true. thanks!
[16:12]  * zyga makes more progress :)
[16:12] <zyga> ltrace was the missing link towards visibilty of what was going on
[16:13] <zyga> quick coffee break is deserved :)
[16:52] <mvo> pedronis: 6778 is green and I addressed your points, let me know if I can do more
[16:54] <pedronis> let me look
[16:56] <pedronis> mvo: it looks fine, I don't know how likely those files are to change soon?
[16:57] <mvo> pedronis: you mean the dbus ones? that is not likely but I was refering to the auto-install snapd when needed PR :)
[16:58] <mup> PR snapd#6800 closed: snapstate: revert "overlord/snapstate: remove PlugsOnly" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6800>
[17:01] <pedronis> mvo: there is the the question about the signature of coreSnapInstalled and snapdSnapInstalled
[17:02] <mvo> pedronis: if its considered important I can change it, the call side will become a bit more unwieldy - but happy to do that
[17:03] <pedronis> mvo: I think it would be better to differentiate the errors
[17:04] <mvo> pedronis: ok, I will update the code (after dinner)
[17:08] <zyga> re
=== pstolowski is now known as pstolowski|afk
[17:52] <zyga> Bike break
[18:28] <pedronis> mvo: I fixed an annoying spread failure in my other PR, let me know if you want me to re-review something else today
[18:29] <mvo> pedronis: 6778 should be ready in ~5min
[18:29] <mvo> pedronis: but given that things will not be ready tonight anyway its fine to do all of this tomoorow
[19:03]  * cachio afk
[19:58] <mup> PR snapd#6804 opened: [RFC] store,daemon,client: allow user-agent setting for Search() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6804>
[20:10] <mup> PR snapd#6805 opened: interfaces/docker-support: support overlayfs on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6805>
[21:10] <mup> PR snapd#6806 opened: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6806>
[23:05] <mup> PR snapcraft#2545 opened: catkin plugin: use build-packages for compilers <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2545>
[23:23] <mup> PR snapcraft#2546 opened: [legacy] catkin plugin: ensure cxxflags are consistent <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2546>