=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
mborzeckibrb, new kernel05:11
zygagood morninf05:52
mborzeckizyga: hey05:58
zygahey hey05:58
zygaI'm trying to fix what I prepared yesterday and add the CUDA test as well05:58
* zyga fights tab creep06:11
mborzeckizyga: next step https://forum.snapcraft.io/t/do-snaps-apps-support-vulkan/10534/206:14
zygamborzecki: yeah, I will find some hello-vulcan code06:15
zygamborzecki: the interesting experience started when I removed various random bits of MESA from my test snap06:15
zygait shrank significantly and no longer ran without the "driver" snap connected06:15
zygabut first things first06:15
zygafight tab creep, restore opengl part to working order, get cuda to work in confinement06:16
mborzeckimvo: morning06:20
zygahey mvo :)06:20
* zyga managed to reduce tab creep to ~ 10 tabs 06:21
mvohey mborzecki and zyga good morning06:23
mborzeckizyga: can you take a quick look https://github.com/snapcore/snapd/pull/6792 ? just renames and moving the code around06:24
zygamborzecki: looking06:24
zygaI had a look last night but it was a bit more complex06:24
zygamborzecki: question: why PositionedVolume contains a *Volume rather than Volume?06:25
mborzeckizyga: avoiding another copy, no other reason06:25
zygaare we mostly working with Positioned or the plain version?06:26
mborzeckizyga: depends where, validation works with Volume mostly, update works with Positioned*06:26
zygaa 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 intact06:26
zyga+1 but consider if it is easier to reason about this without the pointer06:27
mvohm 6782 has no +1 but surely mborzecki has an opinion on this one :)06:27
mborzeckimvo: looking06:27
mborzeckizyga: thanks06:28
zygamborzecki: and then perhaps https://github.com/snapcore/snapd/pull/6788 :)06:28
zygasimple and just a 2nd +106:29
mborzeckimvo: lgtm, though i can only +1 the parts i didn't touch :)06:29
zygawoot, thank you!06:30
mvomborzecki: that seems to be fine, I will +1 the parts you did touch06:30
zygamborzecki, mvo: one simple argument removal https://github.com/snapcore/snapd/pull/679406:38
mborzeckizyga: more lines removed than added, +1 :)06:40
mvozyga: 6782 had a +0.9 from you - is the final 0.1 there now? with that we can merge jamies 675906:42
zygaThanks guys!06:42
zygamvo: looking06:42
zygamvo: https://github.com/snapcore/snapd/pull/6782/files#diff-bdab0f3d09049605d4bd7bc4892a6a4bR91 !!!06:44
zygawas this always broken>?06:44
mvoprobably :/06:49
zygabut the test did not catch this before06:51
mvozyga: yeah, definitely worth looking why06:56
zygamvo: and it was failing for you without this extra dash, right?06:58
zygamvo: but not initially,06:58
mborzeckimup still silent?06:58
mvozyga: I think mborzecki fixed this particular one06:58
mvomborzecki: I think so06:58
zygamvo: so something that changed in the patch caused it to fail06:59
mvomborzecki: we probably need to poke gustavo about it06:59
zygamup_: hello06:59
=== pstolowski|afk is now known as pstolowski
mborzeckizyga: mvo: fwiw both -build-id and --build-id, the manpage though says --build-id07:01
mvohey pstolowski07:03
mvomborzecki: aha, nice07:03
pstolowskimvo: i saw your idea from yesterday, ty, i'm looking at it07:07
pstolowski(timing for state loading)07:09
mvopstolowski: cool, thanks07:16
zygadid anyone restart https://github.com/snapcore/snapd/pull/6794 ?07:23
* mvo didn't 07:26
mvozyga: 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 ready07:27
zygayes, I plan to07:27
zygathat's an early branch,07:27
zygajust didn't go anywhere last week07:27
pstolowskimvo: to clarify - the idea with timings is to measure state.ReadState() on startup correct?07:27
mvopstolowski: yes07:38
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
zygamvo, mborzecki: another simple chunk https://github.com/snapcore/snapd/pull/679608:01
Chipacamoin moin08:14
niemeyermvo, mborzecki_: May I help somehow?08:16
mborzecki_niemeyer: hi, mup is awfully silent08:16
=== mborzecki_ is now known as mborzecki
niemeyerSorry, I still haven't fixed its ability to self-identify08:16
niemeyerI'll poke it08:17
mborzeckiniemeyer: thanks!08:17
zygahello Chipaca, hey niemeyer :)08:17
niemeyermup_: Should work now08:17
mup_niemeyer: In-com-pre-hen-si-ble-ness.08:17
niemeyerHmm.. and somebody took over its nick08:18
niemeyerzyga: Heya08:18
=== mup_ is now known as mup
mvozyga: hey, do you have time for a quick about the static attibutes PR?08:46
zygamvo: hey, sure08:46
mvozyga: cool, lets hop to the standup channel, I will be there in 30s08:47
zygamvo: sure08:47
zygapstolowski: hey09:04
mvopstolowski: hey, want to join the standup channel?09:04
zygapstolowski: we have the call about stale connection attributes09:04
zygapstolowski: could you join us please09:04
zygapstolowski: sorry for not pinging you earlier, but we just started a moment ago09:04
pstolowskizyga: sure, coming09:05
zygathank you Pawel!09:18
* Chipaca hates 409s09:19
mupPR snapd#6797 opened: overlord/ifacestate: revert the initial fix for lp #1825883 <Created by stolowski> <https://github.com/snapcore/snapd/pull/6797>09:24
pstolowskizyga, mvo: ^09:37
zygapstolowski: and update the bug report with additional information that this is unfixed09:40
mvopstolowski: ta!09:40
pedronismvo: we still need to decide what to do with https://github.com/snapcore/snapd/pull/6638/files, no ?09:41
mupPR #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
mvopedronis: yes09:41
mvopedronis: its a re-exec thing but yeah, without it there is a (small) regression09:42
mvopedronis: thinking about it, it might be racy but worst case is that the same file is written twice - unless I miss something09:43
pedronisChipaca: mvo: hi, is the cohort stuff in 2.39? what is still missing?09:48
Chipacapedronis: it is not in 2.39, no09:49
Chipacapedronis: create-cohort landed just last night finally09:49
Chipacapedronis: i'm working on install, tests are looking good and hoping to get it covered and up today09:49
Chipacaswitch and refresh should be a small thing after that, and then commands to expose this to the user09:50
Chipacastill thinking about leave-cohort a bit, but expect it to emerge naturally as i get there09:50
=== 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
mupPR snapd#6798 opened: gadget: introduce checkers for sanitizing structure updates <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6798>10:09
mborzeckianother bulky one ^^, fortunately tests are 75+% of the whole thing10:10
mvopedronis: should I de-conflict 6747 for you?10:21
mborzeckimvo: can we just bump go to 1.10 in travis? iirc it's the oldest one we build with anyway10:27
mvomborzecki: iirc EPL and RHEL were holidng us back, but if that got updated to 1.10 +110:33
mborzeckimvo: it would also fix the madness with go fmt indent chnges in 1.1010:34
mvomborzecki: what is the version in centos right now? (and rhel?)10:34
mborzeckimvo:  checking right now10:34
mvomborzecki: ta10:34
mvopedronis: 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
mborzeckimvo: golang-1.11.5-1.el710:35
mupPR snapd#6799 opened: travis: bump Go version to 1.10.x <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6799>10:37
mvomborzecki: \o/10:41
Chipacamborzecki: I don't think the .x is literal10:44
* Chipaca looks10:44
Chipacawell it worked ¯\_(ツ)_/¯10:44
mborzeckiChipaca: that should be last tagged patch release in given major.minor10:44
Chipacamborzecki: isn't "1.10" the same?10:45
mborzeckiChipaca: i was bit surprised suprised that 1.10 is 1.10 exactly10:45
Chipacathat is surprising indeed10:45
Chipacathe documentation i saw didn't point this out either10:46
Chipacaanyway, eh, if it works it works10:46
pedronismvo: if you want/can, I'm trying to take care of errands and then do the 2.39 reviews10:52
mvopedronis: thanks!10:52
mvopedronis: pushed the update for devicectx10:58
mvo6747 needs a second review btw :)10:58
mvo(its this devicectx PR)10:58
* Chipaca is zombie11:25
pedronismvo: gave some feedback on #677811:35
mupPR #6778: [RFC] snapstate: auto-install snapd when needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/6778>11:35
pedronismvo: commented also in #663811:53
mupPR #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
pedronismarked it for 2.29 as well11:53
pedronisheh, 2.3911:54
=== ricab is now known as ricab|lunch
mborzeckioff to pick up the kids12:01
dot-tobiaskyrofa / 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:04
pedronispstolowski: question in #675512:14
mupPR #6755: overlord/snapstate: tweak autorefresh logic if network is not available <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6755>12:14
cmatsuokaChipaca: can the snapd snap be built with base: core? it could solve the snap dir clutter problem12:16
mupPR 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:16
pstolowskipedronis: replied12:17
mupPR 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:17
pedronispstolowski: couple of comments, thank you12:20
pedronismvo: thanks for #6771 , I was thinking about something like that12:22
mupPR #6771: cmd: add `snap debug validate-seed <path>` cmd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6771>12:23
pedronismvo: zyga: this is bad tough:  #676312:24
mupPR #6763: overlord/snapstate: remove PlugsOnly <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6763>12:24
zygapedronis: oh?12:24
zygapedronis: can you clarify?12:24
pedroniszyga: it's needed for this at some point: https://forum.snapcraft.io/t/cross-snap-operations-bases-and-concurrency/568512:24
zygapedronis: I wasn't aware of this, is having just plugs somehow special though? (or having just slots?)12:25
=== chihchun is now known as chihchun_afk
Chipacacmatsuoka: if that now works, yes12:25
pedroniszyga: yes, it's special, two snaps having only plugs can't interfere with each other12:25
Chipacacmatsuoka: assuming base: core doesn't actually reach the snap.yaml12:26
zygapedronis: how about two snaps with just slots?12:26
pedronis(unless they are a special snap like bases or kernel etc)12:26
cmatsuokaChipaca: worked in a quick PoC, let me try with the real thing12:26
pedroniszyga: that's not as useful, they interfere each with snaps with plugs12:26
pedronisanyway that change needs reverting12:28
sergiusensdot-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 found12:51
sergiusensdot-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 base12:51
sergiusenskyrofa: we do have a bug for that about the deb and bases... it just requires time... I am not missing the SRU process at all12:52
* sergiusens scratches head as he does not see his replies from yesterday on this irc session12:55
dot-tobiassergiusens: 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 me12:56
tomwardillhi! Is there a snapd environment variable (or other method) that will get me the response payload from the store?13:21
zygaChipaca: ^13:21
Chipacatomwardill: hi! yes 1 sec13:22
Chipacatomwardill: SNAPD_DEBUG_HTTP, more in https://github.com/snapcore/snapd/blob/master/HACKING.md#testing-snapd13:23
jdstrandogra: 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
tomwardillChipaca: that doesn't appear to dump the response body13:24
tomwardill(Or I'm doing it wrong)13:24
Chipacatomwardill: it does :-) how are you doing it?13:24
tomwardilloh, I might have the wrong number in the wrong place13:24
tomwardillone sec :)13:25
tomwardillChipaca: sorry, I was holding it wrong.13:25
Chipacatomwardill: https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c653713:25
=== ricab|lunch is now known as ricab
tomwardillI had '9' rather than '7', because obviously a higher number is better...13:26
cachiomvo, https://paste.ubuntu.com/p/ztGGVFZsF6/13:26
cachiomvo, this is the output, last line is stuck13:26
mvocachio: /o\13:26
mborzeckicachio: is this what the stuck code is doing? http://paste.ubuntu.com/p/KpGxWdFfVJ/13:30
cachiomborzecki, yes13:30
cachiomborzecki, for i in $(seq 130); do echo $i && snap run --strace="-tt" test-snapd-tools.echo "hello-world"; done13:31
cachiomborzecki, that was the line13:31
mborzeckicachio: hmm, bad news, seems to run fine locally, with that script i had ~2k iterations before i killed it13:32
mborzeckicachio: let me try that under spread13:33
cachiomborzecki, I can generate a debug session on gce13:33
jdstrandcjwatson: 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:40
cjwatsonjdstrand: this is all up to snapcraft I'm afraid; LP has no say in that13:41
jdstrandcjwatson: 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 arm6413:41
cjwatsonjdstrand: LP chroots have indeed never had cross-architecture config, and are unlikely to13:42
cjwatsonif snapcraft needs that then it has to set it up itself13:42
jdstrandcjwatson: on amd64 gcc-multilib is in gcc-multilib:amd64, not gcc-multilib:i38613:42
jdstrandin the archive13:42
jdstrandso I'm a bit puzzled by either snapcraft, the chroot or the archive13:43
cjwatsonthis 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 config13:43
jdstrandso I'm just lucky that I could install gcc-multilib on amd6413:44
mupPR snapd#6800 opened: snapstate: revert "overlord/snapstate: remove PlugsOnly" <Created by mvo5> <https://github.com/snapcore/snapd/pull/6800>13:44
cjwatsonI guess ... I've only used that in very limited cases13:44
jdstrandcjwatson: ok, thanks13:44
cjwatsonI think in general gcc's multilib config is supported in Ubuntu only where there's been a positive need for it13:45
cjwatsonI guess you'd need to talk to Matthias about that though13:46
jdstrandcjwatson: 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 armhf13:46
jdstranddpkg: warning: cannot remove non-foreign architecture 'armhf'13:46
cjwatsonperhaps that's actually its native architecture; try dpkg --print-architecture13:47
jdstrand$ dpkg --print-architecture13:47
jdstrandwhich is why I came to you. things aren't quite lined up in all the different places13:48
cjwatsonUh.  Pass :)13:48
jdstrandI can accept that classic chroot is wrong13:48
mborzeckicachio: can reproduce that, somehow appears more often with --strace='-tt'13:48
cjwatsonYou 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
jdstrandbut it seemed odd that gcc-multilib was in the amd64 part of he archive and not in arm64, but instead in armhf13:49
cjwatsonI suppose it could be that the classic environment just crowbarred that package in13:49
cjwatsonWell, that's entirely up to the gcc maintainers13:49
jdstranddpkg --print-foreign-architectures prints nothing. anyway, like I said, I'm fine to accept the classic chroot is setup wrong13:50
cachiomborzecki, nice13:50
cjwatsonAnd classically multilib has required non-trivial per-architecture effort to maintain13:50
jdstrandok, well, now I'll ask kyrofa and sergiusens how I can setup snapcraft.yaml so it adds armhf lines if I use gcc-multilib:armhf13:51
jdstrandkyrofa, sergiusens: ^13:51
jdstrandcjwatson: thanks13:51
cjwatsonnp, I think that's likely to be the best path13:52
jdstrandkyrofa, 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 lines13:54
jdstrandkyrofa, 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:55
jdstrandkyrofa, 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 to13:56
jdstrandkyrofa, 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:58
mupPR 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>13:59
mborzeckips -ef | grep /sbin/strace shows that we're leaving some strace processes behind14:02
sergiusensjdstrand: I don't think we support commas there, have you tried multiple "on" statements?14:06
sergiusensI also don't think we ever tested the construct of having "on, else" statements with just plain packages listed, if that works, great I guess14:07
mupPR 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:07
mupPR snapd#6801 opened: snapstate,devicestate: add snapstate.DeviceCtx to checkSnap* <Created by mvo5> <https://github.com/snapcore/snapd/pull/6801>14:09
jdstrandsergiusens: 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
jdstrandCould not find a required package in 'build-packages': gcc-multilib:armhf14:12
jdstrandBuild failed14:12
jdstrandsergiusens: 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:12
jdstrandsergiusens: (again, it's ok if there isn't, I'll just move on, but if there is, I'd like to do it)14:14
sergiusensjdstrand: the "add ppa hack" from the forum could work by overriding the pull step and apt updating14:19
sergiusensjdstrand: I think that now that we assume all environments where run are disposable, we can certainly "try" and enable the arch from our repo handler14:20
sergiusensif you don't mind logging a bug, that would be great14:20
mvomborzecki: 6759 keeps on giving - now it fails in google:centos-7-64 .../tests/main/base-snaps#14:23
mvomborzecki: it seems to be a real issue14:23
mvomborzecki: I see that it fails to exec snap-exec - https://paste.ubuntu.com/p/BZ5VQY2cjK/14:24
jdstrandsergiusens: do you use launchpad bugs or github issues?14:24
mborzeckimvo: hmm14:24
mvomborzecki: which is strange as we did not change anything here14:24
mvomborzecki: I have a meeting now so can't dig deeper14:24
sergiusensjdstrand: lp bugs, our issue tracker on github is closed14:24
sergiusensthat said, I have been looking into using github projects, need to convince mvo of something we can consolidate on14:25
mborzeckimvo: 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:27
mvosergiusens: I would not mind using gh projects, I just did not investigate this much yet14:28
mvomborzecki: interessting14:28
mvomborzecki: I guess its related to us no longer using cgo in some interessting and yet mysterious way14:29
sergiusensmvo 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 easier14:32
jdstrandsergiusens: ok, filed https://bugs.launchpad.net/snapcraft/+bug/1827067. let me know if you need anything else14:33
mvosergiusens: sounds good, lets sit together in lyon14:33
mupBug #1827067: need a way to add foreign architecture to sources.list for build-packages/stage-packages <Snapcraft:New> <https://launchpad.net/bugs/1827067>14:33
mborzeckimvo: snap-exec is not a static binary14:40
cachiojamesh, hi, could you please take a look to this change 654114:46
kyrofajdstrand, (cc sergiusens) regarding your last point first, we do support commas but the grammar enforces an AND relationship, not an OR14:46
mupPR #6541: tests: change how dir is umounted on desktop-portal.sh <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>14:46
kyrofae.g. `on amd64,ubuntu` or `on armhf,fedora`14:46
cachiojamesh, any suggestions about how to improve that, still failing sporadically14:46
sergiusenskyrofa: compressed nesting; I wish we had better syntax for that... I completely forgot about that scenario and assumed the opposite on first read14:47
mvomborzecki: its not? hm, how did that work in the past then - I mean, this test?14:48
kyrofasergiusens, maybe it SHOULD be... but yeah14:48
mborzeckimvo: idk, everything seems to be in order14:48
mborzeckimvo: /usr/lib/golang/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -buildmode=exe -buildid=tDnwG8u1pBmUWQO10qzA/_x6vj92SB3p958rhGThv/9RCsi14:48
mborzeckiVE8AphCR9FsbPHc/tDnwG8u1pBmUWQO10qzA -B 0x2b904b806d8f25f00e904ab996b99be6dc650588 -extldflags "-Wl,-z,relro  -static" -extld=gcc $WORK/b001/_pkg_.a14:48
* mvo weeps a bit in the corner14:49
mborzeckimvo: -static seems to be passed to gcc/ld14:49
mvomborzecki: oh, so by not having gcc anymore we loose this? that makes sense14:49
mvomborzecki: now the question is how to pass -static to go without cgo14:50
mborzeckimvo: CGO_ENABLED=0 basically :) but, ther's something fishy about that still14:52
Chipacapedronis: 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 sth14:52
ograjdstrand, hmm, i think mvo added some code to fix alternatives in core itself in the past. perhaps the classic snap needs some adapting to that14:52
pedronisChipaca: in a meeting14:54
pedronisChipaca: 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 cases15:08
* zyga lunch15:08
pedronisor not too bad abuses15:08
pedronis2nd reviews of https://github.com/snapcore/snapd/pull/6731 would be appreciated15:09
mupPR #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:10
mborzeckimvo: 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 -fPIC15:11
mborzeckimvo: oh, and the same macro on fedora adds -buildmode pie15:11
mupPR snapd#6802 opened: overlord/ifacestate: update static attributes of "content" interface <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6802>15:15
cachiojamesh, hi15:49
cachiojamesh, could you please take a look to #654115:49
mupPR #6541: tests: change how dir is umounted on desktop-portal.sh <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>15:49
mupPR snapd#6803 opened: daemon, o/snapstate, store: support for installing from cohorts <Created by chipaca> <https://github.com/snapcore/snapd/pull/6803>15:58
Chipacapedronis: i'll review composable thing this evening if nobody else has gotten to it16:00
Chipacanow i'm going for a run, i think16:00
jdstrandkyrofa: that would explain while that wouldn't work there. it could never be true. thanks!16:07
* zyga makes more progress :)16:12
zygaltrace was the missing link towards visibilty of what was going on16:12
zygaquick coffee break is deserved :)16:13
mvopedronis: 6778 is green and I addressed your points, let me know if I can do more16:52
pedronislet me look16:54
pedronismvo: it looks fine, I don't know how likely those files are to change soon?16:56
mvopedronis: you mean the dbus ones? that is not likely but I was refering to the auto-install snapd when needed PR :)16:57
mupPR snapd#6800 closed: snapstate: revert "overlord/snapstate: remove PlugsOnly" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6800>16:58
pedronismvo: there is the the question about the signature of coreSnapInstalled and snapdSnapInstalled17:01
mvopedronis: if its considered important I can change it, the call side will become a bit more unwieldy - but happy to do that17:02
pedronismvo: I think it would be better to differentiate the errors17:03
mvopedronis: ok, I will update the code (after dinner)17:04
=== pstolowski is now known as pstolowski|afk
zygaBike break17:52
pedronismvo: I fixed an annoying spread failure in my other PR, let me know if you want me to re-review something else today18:28
mvopedronis: 6778 should be ready in ~5min18:29
mvopedronis: but given that things will not be ready tonight anyway its fine to do all of this tomoorow18:29
* cachio afk19:03
mupPR snapd#6804 opened: [RFC] store,daemon,client: allow user-agent setting for Search() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6804>19:58
mupPR snapd#6805 opened: interfaces/docker-support: support overlayfs on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6805>20:10
mupPR snapd#6806 opened: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6806>21:10
mupPR snapcraft#2545 opened: catkin plugin: use build-packages for compilers <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2545>23:05
mupPR snapcraft#2546 opened: [legacy] catkin plugin: ensure cxxflags are consistent <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2546>23:23

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!