| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mborzecki | morning | 05:08 |
|---|---|---|
| mborzecki | brb, new kernel | 05:11 |
| zyga | good morninf | 05:52 |
| 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 | 05:58 |
| * zyga fights tab creep | 06:11 | |
| mborzecki | zyga: next step https://forum.snapcraft.io/t/do-snaps-apps-support-vulkan/10534/2 | 06:14 |
| 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:15 |
| zyga | fight tab creep, restore opengl part to working order, get cuda to work in confinement | 06:16 |
| mborzecki | mvo: morning | 06:20 |
| zyga | hey mvo :) | 06:20 |
| * zyga managed to reduce tab creep to ~ 10 tabs | 06:21 | |
| mvo | hey mborzecki and zyga good morning | 06:23 |
| 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:24 |
| zyga | mborzecki: question: why PositionedVolume contains a *Volume rather than Volume? | 06:25 |
| mborzecki | zyga: avoiding another copy, no other reason | 06:25 |
| 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:26 |
| 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:27 |
| zyga | commented | 06:28 |
| mborzecki | zyga: thanks | 06:28 |
| zyga | mborzecki: and then perhaps https://github.com/snapcore/snapd/pull/6788 :) | 06:28 |
| zyga | simple and just a 2nd +1 | 06:29 |
| mborzecki | mvo: lgtm, though i can only +1 the parts i didn't touch :) | 06:29 |
| zyga | woot, thank you! | 06:30 |
| mvo | mborzecki: that seems to be fine, I will +1 the parts you did touch | 06:30 |
| zyga | mborzecki, mvo: one simple argument removal https://github.com/snapcore/snapd/pull/6794 | 06:38 |
| mborzecki | zyga: more lines removed than added, +1 :) | 06:40 |
| 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:42 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/6782/files#diff-bdab0f3d09049605d4bd7bc4892a6a4bR91 !!! | 06:44 |
| zyga | was this always broken>? | 06:44 |
| mvo | probably :/ | 06:49 |
| zyga | but the test did not catch this before | 06:51 |
| zyga | interesting | 06:51 |
| mvo | zyga: yeah, definitely worth looking why | 06:56 |
| 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:58 |
| 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 | 06:59 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:00 |
| mborzecki | zyga: mvo: fwiw both -build-id and --build-id, the manpage though says --build-id | 07:01 |
| mvo | hey pstolowski | 07:03 |
| mvo | mborzecki: aha, nice | 07:03 |
| pstolowski | mvo: i saw your idea from yesterday, ty, i'm looking at it | 07:07 |
| pstolowski | (timing for state loading) | 07:09 |
| mvo | pstolowski: cool, thanks | 07:16 |
| zyga | did anyone restart https://github.com/snapcore/snapd/pull/6794 ? | 07:23 |
| * mvo didn't | 07:26 | |
| 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:27 |
| mvo | pstolowski: yes | 07:38 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | mvo, mborzecki: another simple chunk https://github.com/snapcore/snapd/pull/6796 | 08:01 |
| Chipaca | moin moin | 08:14 |
| niemeyer | mvo, mborzecki_: May I help somehow? | 08:16 |
| mborzecki_ | niemeyer: hi, mup is awfully silent | 08:16 |
| === mborzecki_ is now known as mborzecki | ||
| niemeyer | Sorry, I still haven't fixed its ability to self-identify | 08:16 |
| 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:17 |
| niemeyer | Hmm.. and somebody took over its nick | 08:18 |
| niemeyer | zyga: Heya | 08:18 |
| === mup_ is now known as mup | ||
| mvo | zyga: hey, do you have time for a quick about the static attibutes PR? | 08:46 |
| zyga | mvo: hey, sure | 08:46 |
| mvo | zyga: cool, lets hop to the standup channel, I will be there in 30s | 08:47 |
| zyga | mvo: sure | 08:47 |
| 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:04 |
| pstolowski | zyga: sure, coming | 09:05 |
| zyga | thank you Pawel! | 09:18 |
| * Chipaca hates 409s | 09:19 | |
| 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:24 |
| pstolowski | zyga, mvo: ^ | 09:37 |
| zyga | done | 09:40 |
| zyga | pstolowski: and update the bug report with additional information that this is unfixed | 09:40 |
| mvo | pstolowski: ta! | 09:40 |
| 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:41 |
| mvo | pedronis: its a re-exec thing but yeah, without it there is a (small) regression | 09:42 |
| 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:43 |
| pedronis | Chipaca: mvo: hi, is the cohort stuff in 2.39? what is still missing? | 09:48 |
| 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:49 |
| 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 | 09: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 | ||
| 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:09 |
| mborzecki | another bulky one ^^, fortunately tests are 75+% of the whole thing | 10:10 |
| mvo | pedronis: should I de-conflict 6747 for you? | 10:21 |
| mborzecki | mvo: can we just bump go to 1.10 in travis? iirc it's the oldest one we build with anyway | 10:27 |
| mvo | mborzecki: iirc EPL and RHEL were holidng us back, but if that got updated to 1.10 +1 | 10:33 |
| 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:34 |
| 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:35 |
| mup | PR snapd#6799 opened: travis: bump Go version to 1.10.x <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6799> | 10:37 |
| mvo | mborzecki: \o/ | 10:41 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:52 |
| mvo | pedronis: pushed the update for devicectx | 10:58 |
| mvo | 6747 needs a second review btw :) | 10:58 |
| mvo | (its this devicectx PR) | 10:58 |
| Chipaca | luuuuuuuunch | 11:25 |
| * Chipaca is zombie | 11:25 | |
| 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:35 |
| 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:53 |
| pedronis | heh, 2.39 | 11:54 |
| === ricab is now known as ricab|lunch | ||
| mborzecki | off to pick up the kids | 12:01 |
| 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:04 |
| 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:14 |
| 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:16 |
| 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:17 |
| pedronis | pstolowski: couple of comments, thank you | 12:20 |
| pedronis | mvo: thanks for #6771 , I was thinking about something like that | 12:22 |
| 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:23 |
| 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:24 |
| zyga | pedronis: 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 | ||
| 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:25 |
| 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:26 |
| pedronis | anyway that change needs reverting | 12:28 |
| pedronis | atm | 12:28 |
| 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:51 |
| 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:52 |
| * sergiusens scratches head as he does not see his replies from yesterday on this irc session | 12:55 | |
| 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 | 12:56 |
| 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:21 |
| Chipaca | tomwardill: hi! yes 1 sec | 13:22 |
| tomwardill | ta | 13:22 |
| Chipaca | tomwardill: SNAPD_DEBUG_HTTP, more in https://github.com/snapcore/snapd/blob/master/HACKING.md#testing-snapd | 13:23 |
| 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:24 |
| tomwardill | one sec :) | 13:25 |
| tomwardill | Chipaca: sorry, I was holding it wrong. | 13:25 |
| Chipaca | tomwardill: https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537 | 13:25 |
| === ricab|lunch is now known as ricab | ||
| 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:26 |
| mborzecki | cachio: is this what the stuck code is doing? http://paste.ubuntu.com/p/KpGxWdFfVJ/ | 13:30 |
| cachio | mborzecki, yes | 13:30 |
| 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:31 |
| mborzecki | cachio: hmm, bad news, seems to run fine locally, with that script i had ~2k iterations before i killed it | 13:32 |
| mborzecki | cachio: let me try that under spread | 13:33 |
| cachio | mborzecki, I can generate a debug session on gce | 13:33 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| cjwatson | I think in general gcc's multilib config is supported in Ubuntu only where there's been a positive need for it | 13:45 |
| 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:46 |
| cjwatson | perhaps that's actually its native architecture; try dpkg --print-architecture | 13:47 |
| jdstrand | $ dpkg --print-architecture | 13:47 |
| jdstrand | arm64 | 13:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| cjwatson | np, I think that's likely to be the best path | 13:52 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:58 |
| 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> | 13:59 |
| mborzecki | ps -ef | grep /sbin/strace shows that we're leaving some strace processes behind | 14:02 |
| sergiusens | jdstrand: I don't think we support commas there, have you tried multiple "on" statements? | 14:06 |
| 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:07 |
| mup | PR snapd#6801 opened: snapstate,devicestate: add snapstate.DeviceCtx to checkSnap* <Created by mvo5> <https://github.com/snapcore/snapd/pull/6801> | 14:09 |
| 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:12 |
| 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:14 |
| sergiusens | jdstrand: the "add ppa hack" from the forum could work by overriding the pull step and apt updating | 14:19 |
| 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:20 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:27 |
| mvo | sergiusens: I would not mind using gh projects, I just did not investigate this much yet | 14:28 |
| mvo | mborzecki: interessting | 14:28 |
| mvo | mborzecki: I guess its related to us no longer using cgo in some interessting and yet mysterious way | 14:29 |
| 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:32 |
| 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:33 |
| mborzecki | mvo: snap-exec is not a static binary | 14:40 |
| 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:46 |
| 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:47 |
| 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:48 |
| * 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:49 |
| mvo | mborzecki: now the question is how to pass -static to go without cgo | 14:50 |
| 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:52 |
| pedronis | Chipaca: in a meeting | 14:54 |
| 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:08 |
| pedronis | 2nd reviews of https://github.com/snapcore/snapd/pull/6731 would be appreciated | 15:09 |
| 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:10 |
| 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:11 |
| 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:15 |
| 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:49 |
| mup | PR snapd#6803 opened: daemon, o/snapstate, store: support for installing from cohorts <Created by chipaca> <https://github.com/snapcore/snapd/pull/6803> | 15:58 |
| 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:00 |
| jdstrand | kyrofa: that would explain while that wouldn't work there. it could never be true. thanks! | 16:07 |
| * zyga makes more progress :) | 16:12 | |
| zyga | ltrace was the missing link towards visibilty of what was going on | 16:12 |
| zyga | quick coffee break is deserved :) | 16:13 |
| mvo | pedronis: 6778 is green and I addressed your points, let me know if I can do more | 16:52 |
| pedronis | let me look | 16:54 |
| pedronis | mvo: it looks fine, I don't know how likely those files are to change soon? | 16:56 |
| mvo | pedronis: you mean the dbus ones? that is not likely but I was refering to the auto-install snapd when needed PR :) | 16:57 |
| mup | PR snapd#6800 closed: snapstate: revert "overlord/snapstate: remove PlugsOnly" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6800> | 16:58 |
| pedronis | mvo: there is the the question about the signature of coreSnapInstalled and snapdSnapInstalled | 17:01 |
| 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:02 |
| pedronis | mvo: I think it would be better to differentiate the errors | 17:03 |
| mvo | pedronis: ok, I will update the code (after dinner) | 17:04 |
| zyga | re | 17:08 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | Bike break | 17:52 |
| 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:28 |
| 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 | 18:29 |
| * cachio afk | 19:03 | |
| 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> | 19:58 |
| mup | PR snapd#6805 opened: interfaces/docker-support: support overlayfs on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6805> | 20:10 |
| mup | PR snapd#6806 opened: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6806> | 21:10 |
| mup | PR snapcraft#2545 opened: catkin plugin: use build-packages for compilers <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2545> | 23:05 |
| mup | PR 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!