[05:55] morning [05:57] 54 PRs, not bad at all === mborzeck1 is now known as mborzecki [07:32] Good morning [07:33] zyga: hey [07:40] https://www.irccloud.com/pastebin/MMF5SCYo/ [07:42] zyga: no snapd-lib? [07:42] or some path component [07:42] zyga: looks like glob wasn't expanded by the shell [07:44] mborzecki: looks like teardown went south [07:45] anyway, that's just random noise today [07:45] hey zyga and mborzecki [07:45] mvo: hey :) [07:45] mvo: hey [07:45] mvo: ready to face the music? [07:46] mborzecki: can you please review https://github.com/snapcore/snapd/pull/6431 [07:46] PR #6431: snapcraft.yaml: fix snap building in launchpad <⚠ Critical> [07:48] mvo: updated https://github.com/snapcore/snapd/pull/6426 with a tiny comment tweak, I think it is ready now [07:48] PR snapd#6431 closed: snapcraft.yaml: fix snap building in launchpad <⚠ Critical> [07:48] PR #6426: cmd/snap-confine: refactor and cleanup of seccomp loading [07:49] mvo: also good news, https://tracker.debian.org/pkg/snapd will migrate tomorrow [07:53] zyga: thank you [07:56] PR snapd#6437 opened: snap/channel: improve channel parsing [07:58] mborzecki: school winter holidays started today [07:58] mborzecki: two weeks with all the kids at home :) [07:58] zyga: nice, it starts on 11.02 here, right before the sprint, i'll probably take the week before sprint off [07:59] bring them to malta :) [08:02] mvo: is the plan still to review PRs more than open new ones? [08:02] zyga: yeah, I think thats wise [08:05] PR snapd#6428 closed: interfaces: add display-control interface [08:05] PR snapd#6435 closed: interfaces: add display-control interface - 2.37 === pstolowski|afk is now known as pstolowski [08:07] mornings [08:07] hello pawel, welcome back [08:09] pstolowski: hey [08:10] hey pstolowski! welcome back [08:28] hm not that many reviews that aren't waiting for the author to address the feedback they got [08:28] i'll be looking into what's wrong with #6252 spread tests [08:28] PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS [08:33] mborzecki: this one is a good one to look at, thank you [08:34] mborzecki: I think the issue is that we need to either do more mocking or use less mocking :) I mean, we might look into using some real xdg helpers (less mocking) [08:36] looks like tests are unhappy right now in debian-9 (/me looks) === mvo_ is now known as mvo [08:47] hm, so stretch no longer has golang-1.10 (just 1.11) [08:48] * mvo scratches head [08:50] mvo: with integration of debian packaging we cannot assume to build for older releases [08:50] mvo: realistically we should target testing and sid [08:50] or really just sid perhaps [08:51] as soon as we fix lintian warnings we may start using standards version that is from the future from the perspective of debian-9 [08:51] pstolowski: hi, I did another pass on #6322 last week [08:52] hey pedronis [08:52] PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get [08:52] mvo: shall we sync with pedronis? [08:53] zyga: yeah, when he has time this morning we should have a quick HO [08:53] PR snapd#6438 opened: data/systemd: helper service to hold refreshes when waking up from suspend [08:55] mborzecki: did you see my small comment on #6016 ? [08:55] PR #6016: snap/naming: move various name validation helpers to separate package [08:55] *comments [08:56] pedronis: yes, pushing those soon [08:56] pedronis: i've pushed a PR to improve channel validation [08:57] pedronis: ah, i see you've already looked at it, thanks! [08:57] pedronis: hi! yes i saw that, thanks. btw, not sure if i was super clear when we talked last week, but 6106 is ready imo [09:00] mvo: zyga: is there a way to depend on golang-any 1.7+ and then use `go env` to discover things? [09:01] presumably, yes [09:01] mvo: is the problem to add the correct go things to path? [09:01] mborzecki: yes, reviewed that, but it's red [09:02] pedronis: yeah, debian doesn't build atm, Dependency is not satisfiable: golang-any|golang-1.10 [09:02] pstolowski: yes, you were clear, just didn't get to it yet [09:02] pedronis: ah, sure, ok [09:03] mborzecki: I need to look, not sure there is anything that references golang-1.11 in stretch [09:03] mborzecki: let me log into a debug system [09:04] mvo: log from a job on master branch: https://api.travis-ci.org/v3/job/485270403/log.txt [09:04] mborzecki: thanks! golang-any seems to be a confusing name, it seems to refer to gccgo ./ [09:04] w8, rly? [09:05] mvo: isn't that a golang-go or gccgo-go dependning on platform support? [09:05] mborzecki: aha, no [09:06] mborzecki: sorry, its just confusing on debian-9 because golang-1.11 comes via backports [09:06] mborzecki: so golang-any has no idea about its existance [09:09] zyga: mvo: I'm available to chat if needed [09:14] mborzecki, zyga I'm looking into this right now [09:15] thank you [09:20] mvo: need help? [09:25] mborzecki: reading the suspend refresh postponing PR [09:25] mborzecki: is there any way snapd could learn from systemd or from the system itself that the system was just resumed [09:25] to do this internally? [09:26] * zyga goes to make tea [09:27] zyga: yes, afaik dbus is the only way: https://www.freedesktop.org/wiki/Software/systemd/inhibit/ [09:28] mborzecki: should be fine, up for review now [09:28] zyga: a topic that we haven't looked into yet, is also inhibiting sleep during refresh [09:28] mborzecki: might be overkill (the fix) though, alternatively we could simple do "apt install -y golang-1.11" and fix it again in ~1-2y when go changes [09:28] PR snapd#6439 opened: tests: workaround missing go dependencies in debian-9 [09:31] mvo: wow :P so cool you know about python apt bindings [09:34] mborzecki: *cough* I do [09:37] mvo: failed on shellcheck [09:38] mborzecki: meh, silly me - let me check [09:39] mborzecki: zyga: I'm -1 on using a service to set refresh.hold from outside [09:39] PR snapd#6438 closed: data/systemd: helper service to hold refreshes when waking up from suspend [09:41] pedronis: should have added RFC there, i think we can discuss it during the sprint [09:42] mborzecki: it's ok, I appreciate having prototyped this, but we also don't need more open forever rfc PRs [09:46] mvo: do you know if there's a reason private-files can't be used yet? [09:47] Chipaca: that should work if 2.37 is installed [09:47] mvo: store says no [09:47] Chipaca: its very strict though, deny auto connect and connect [09:47] Chipaca: manual review? [09:47] Chipaca: or no in more ways? [09:48] mvo: ah, maybe [09:48] Chipaca: you need a snap declaration, otherwise it will not even install (unless --dangerous) [09:48] right, but I need it in the store to ask for that [09:48] but you're right, it's up [09:48] the error from snapcraft sounded too much like an outright rejection :-) [09:49] pstolowski: welcome back! [09:49] hey Chipaca! [09:49] pstolowski: thank you for the review [09:50] np [09:51] PR snapd#6414 closed: daemon: try to tidy up the icon stuff a little [09:54] Chipaca: hi, should we have a HO about epochs last PR ? [09:56] pedronis: I'm about to have a meet about coh* [09:57] Chipaca: ah, do you need me? [09:58] pedronis: not necessarily, but you're welcome if you're curious [09:59] Chipaca: coh? [09:59] zyga: cohorts and coherence [09:59] pedronis: it's more for me to sync with sparkiegeek and us to get a shared idea of timelines than anything else [09:59] ahh [09:59] zyga: carbon-oxygen-hydrogen compounds [10:01] Chipaca: hm, we talked recently about snap info foo.snap not returning the arch of the snap. what was the conclusion/workaround, do you remember? [10:06] mvo: will be added once info is nicer [10:07] Chipaca: ok, no worries, I need this too for something but its easy to workaround [10:13] there's some snap instance name validation weirdness, it's happening super late for installing from store now, so you can actually attempt to install hello-world_123__a and it fails as late as setting up mounts [10:27] PR snapd#6440 opened: Fix typo in cmd_wait.go [10:29] brb, need to pick up something [10:32] pedronis, mvo: wrt personal-files, https://forum.snapcraft.io/t/request-for-automatic-alias-and-connection-for-icdiff/9703 (weekend was fun) [10:32] don't tell sergio but that'll be my first snap to use snapcraft [10:36] Chipaca: good for you to have joined the parade 🙂 [10:37] sergiusens: btw is there a way to build using 3.0 without bases? [10:37] mvo: pedronis: OTOH, is it on purpose that core can't be used as an explicit base? [10:38] no, and the latter about core, I requested that 6 months ago 🙂 [10:39] but `base: core` is illegal for snapd [10:40] Chipaca: yes, core is not a base [10:40] sergiusens: pedronis: I guess #6418 makes it moot [10:40] PR #6418: many: allow core as a fallback for core16 [10:42] Chipaca: not entirely, as now I need to go into snapcraft and workaround the fact that when someone says `base: core16`, to say that `core` satisfies that requirement. [10:42] sergiusens: BTW², snapcraft doesn't understand license yet? [10:42] I thought that was Done [10:42] it should [10:43] PR snapd#6441 opened: overlord/snapstate: validate instance names early [10:43] using 3.0.1, using a base, had to put it in passthrough [10:43] there's even integration tests enabled for that [10:43] hmm [10:44] pedronis: you might be interested in 6441 [10:53] niemeyer: Would you consider adding a robots.txt to snapdocs.labix.org? It's coming up in google search results, and I don't think that's useful. [10:56] currently looking for robots.txt on the site redirects to the home page. [11:02] popey: I'm thinking of killing it actually [11:03] popey: The new docs site is already out [11:04] Awesome, even better :D [11:31] * Chipaca afk for a while [11:49] * Chipaca bok [11:49] bak? [11:50] mvo: a question on 6404 [11:50] pstolowski: thanks, I check in a sec [11:51] mvo: looks like we need to manipulate PATH in run-checks too [11:51] mvo: that's regarding #6439 [11:51] PR #6439: tests: workaround missing go dependencies in debian-9 [11:55] mborzecki: can you try fixing that? [11:57] zyga: yeah, in a couple of minutes, got some changes in snap connections i need to wrap up [12:19] Chipaca: yes, 6389 looked like my suggestion, it needs a 2nd review [12:28] pedronis: ack tks [12:29] hi, I was trying snap parallel installs on snaps and noticed some issues with hook not being found. is that something that's known? [12:36] ackk: we've addressed an issue regarding hooks and parallel installs last week or so, let me see [12:36] ackk: what is the problem that you see? [12:37] mborzecki, snapd says it can't find the hook [12:37] mborzecki, snap install --edge h2static_test === ricab is now known as ricab|lunch [12:43] mborzecki, ok that's just weird because it now worked [12:44] tried it different times and didn't seem to [12:53] Chipaca: can you look again at #6333 to consider the last changes [12:53] PR #6333: daemon: introduce /v2/connections snapd API endpoint [13:00] pedronis: in a bit [13:13] mvo: i'll look into #6439 if you don't mind [13:13] PR #6439: tests: workaround missing go dependencies in debian-9 [13:16] PR snapcraft#2452 closed: Fix typo in comments [13:19] PR snapcraft#2450 closed: pluginhandler: handle removal of inconsistent files [13:39] mborzecki: sure [13:40] mborzecki: its actually probably just a sed / on debina/control [13:40] mborzecki: like "sed -i s/golang-1.10/$best_golang/ debian/control" [13:40] mvo: yeah, and also need a correct symlink to /usr/bin/go [13:42] mborzecki: indeed [13:42] mborzecki: hopefully just ln -s /usr/lib/$best_golang/bni/go /usr/bin/go - should be all pretty uniform [13:43] mvo: actually it's /usr/lib/go-/bin/go :P [13:43] s/lang// [13:47] mborzecki: meh, ok [13:47] mborzecki: thanks for looking into it [13:52] Chipaca: there's a couple of nitpicks by mvo for 6411 that seems worth considering [13:52] mborzecki, so I've proposed this change to fedora-release: https://src.fedoraproject.org/rpms/fedora-release/pull-request/67 [13:52] yeah [13:52] Son_Goku: looking [13:53] Son_Goku: thank you, that's nice :) [13:53] the only thing is that I'm not sure if I should call the variant snappy, similar to Ubuntu Core [13:53] snap sounds... dumb [13:53] but snappy isn't that much better [13:54] Son_Goku: nice [13:54] Son_Goku: so the -snap variant would be included in fedora base then? [13:54] yes [13:55] this will also give us the key we need to make snapd aware of Fedora Snappy variant too [13:55] Son_Goku: perhaps ask pedronis for naming opinions [13:55] because the VARIANT_ID will allow us to identify a bootable Fedora Snappy variant [13:56] pedronis, should the variant for the base snap os-release be "Snap" or "Snappy? [13:56] Son_Goku: I think that's not required, snapd doesn't decide if a base snap is bootable based on this AFAIK [13:56] *"Snappy"? [13:56] but having a variant is good IMO [13:56] Son_Goku: my preference for the VARIANT_ID is lowercase word [13:56] Son_Goku: btw. does bluesilver have VARIANT_ID=flatpak? [13:56] zyga, there's a couple of os-release detection behaviors for handling normal systems and snappy-based systems [13:56] VARIANT can be anything nice [13:57] mborzecki: silverblue is variant silverblue [13:57] Son_Goku: yes but not for bootable vs non-bootable bases [13:57] Son_Goku: ah ok [13:57] unless someone here has an interesting marketing name for a snappy variant of Fedora, that's all I got [13:57] zyga: VARIANT_ID is lowercase === ricab|lunch is now known as ricab [13:59] mvo: if 18.04 gets go-1.11 will we continue building with 1.10? [13:59] Son_Goku: zyga: we distinguish current ubuntu core from the pre-snappy ubuntu core by calling the former "snappy ubuntu core" [13:59] we might need to check about whether the use of the brand is ok? [13:59] is it a brand? [14:00] * Chipaca has no idea [14:00] I think the brand is Snapcraft? [14:00] which I've deliberately avoided using [14:00] I'm sure somebody will have Opinions [14:00] * Son_Goku groans [14:00] should I ask? [14:01] as much as it pains me, we do need to know the answer to this [14:01] I need a name for the variant [14:01] a'ight [14:01] I think I'd prefer to use "snappy" rather than "snap", but I dunno [14:02] zyga: standup? [14:02] joining [14:09] How do they not go with fed-core-a [14:09] * cwayne will see myself out [14:38] jamesh: hell [14:39] hello :) [14:39] sorry, typo === ricab is now known as ricab|brb === ricab|brb is now known as ricab [15:22] Issue core18#56 closed: Sensible version number [15:22] Issue core18#86 closed: Ubuntu 18.10 [15:22] Issue core18#89 closed: bash completion not installed if "core" snap is not installed [15:22] PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98, core18#113 [15:23] Issue core18#56 opened: Sensible version number [15:23] Issue core18#86 opened: Ubuntu 18.10 [15:23] Issue core18#89 opened: bash completion not installed if "core" snap is not installed [15:23] PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98, core18#113 [15:30] are layouts still behind an experimental feature flag? [15:52] (yes, it seems, as snap install refuses to install my snap which uses them) [15:57] did you try with 2.37 ? iirc zyga said it was a 2.37 feature [15:57] popey: no [15:57] popey: they are available now [15:57] but there are weird conditions on snapcraft side [15:57] you must use bases [15:58] also, maybe you explicitly turned them off? [15:58] what does 'snap get system experimental' say [15:58] popey: ^ [16:06] ah, i wasn't using bases [16:07] error: snap "core" has no "experimental" configuration option [16:46] zyga: popey bases should not be required on snapcraft for a snap to work during runtime, passthrough will just allow it into `snap.yaml` and let by gones be by gones [16:49] sergiusens: hey, the autopkgtest results for 2.37 have some failures in the integration test for plainbox, I will give you a pastebin soon. do you know anything about those? [16:50] mvo: autopkgtests using the deb I suspect, something happened along the release line for plainbox that broke the test, we have not SRUed since, so should be safe to ignore, except, maybe you want to consult with cwayne just in case. [16:51] sergiusens: https://paste.ubuntu.com/p/GGm3mqvGgY/ (cc cwayne ) [16:52] cwayne: is the above plainbox/checkbox failure a reason for concern? just ensureing that the 2.37 release we want to push out soon (later tonight or tomorrow morning) can also be pushed to -updates [16:52] kissiel ^ [17:06] FYI: core snap with snapd 2.37 has been promoted to stable just now [17:07] Time to update the wikipedia page then! :D https://en.wikipedia.org/wiki/Snappy_(package_manager) [17:07] let me do that [17:07] huh [17:08] someone broke the version part and refers to snapcraft only and not snapd [17:08] hmm [17:08] 3.0.1? [17:08] mvo, zyga, pedronis: hey! Do we have an official model assertion in the store for pi3 arm64? Would be nice to have one if we don't [17:08] sil2100: I don't know, would love one if we did [17:08] The snap is in the store since a while (with a new one in the review queue) [17:08] yeah, they mistakenly changed the snapd to snapcraft versaion [17:09] mvo, zyga, pedronis: if we could get the assertion in, I could enable pi3 arm64 core18 as an official image we build and get that out for the .2 point release [17:09] ah [17:09] there's a confusion between snapd and snapcraft there :( [17:10] whole page needs a rewrite [17:10] I see someone re-added the critisism from the peek developer back in after it was removed [17:10] sil2100: we don't, we need to go through the process the get one signed [17:10] sil2100: that's something foundation drives [17:10] now [17:11] I think [17:11] * mvo afk [17:11] I could drive it if someone could point me to how! Didn't do that before, can you link me some docs? [17:11] or maybe mvo did it, but I don't think it should be mvo [17:12] Since I think none of the current core18 assertions have been done by Foundations [17:13] sil2100: they weren't but should I think [17:13] like you do fro cloud images [17:13] they are connected to the images [17:14] sil2100: let me forward you one of the relevant RTs [17:14] pedronis: thank you! [17:14] :) [17:15] sil2100: you also need a name, ubuntu-core-18-pi3 is the armhf ? [17:15] how do you plan to call the arm64 ? [17:16] I need to think about it still, not sure who invented the previous naming, I'd have to look at the other standards - first thing that comes into my mind is simply ubuntu-core-18-pi3-arm64, just like we had pc-amd64 and pc-i386 for 16 [17:16] (now we just have -i386 and -amd64 but yeah) [17:16] sil2100: forwarded [17:17] pedronis: thanks again o/ [17:23] sil2100: wrt docs, you should be in sync with degville === pstolowski is now known as pstolowski|afk [17:41] is my lxd busted, or my snapd busted? [17:41] $ lxc list [17:41] cannot read mount namespace identifier of pid 1: Permission denied [17:45] xnox: what if you "snap disable lxd && snap enable lxd"? [17:46] xnox in other words, have you tried to switch it off and back on? :D [17:46] popey, https://paste.ubuntu.com/p/N5yvH9CDyr/ [17:46] ondra, still bad https://paste.ubuntu.com/p/N5yvH9CDyr/ [17:47] but is it like lxd bad or snapd bad? =) is there anything else i can try to see if /all/ of snaps are broken, or just this one.... [17:47] xnox I was more laughing we are at that stage already when we try to remedy things by restarting them :) [17:48] $ /snap/bin/gnome-calculator [17:48] cannot read mount namespace identifier of pid 1: Permission denied [17:48] ok, i claim snapd is busted for me. [17:48] of all the things, gnome-calculator should work. [17:50] sergiusens here is bug we talked last week https://bugs.launchpad.net/snapcraft/+bug/1813634 [17:50] Bug #1813634: not reliable way to detect target architecture [17:51] sergiusens seems like SNAPCRAFT_ARCH_TRIPLET is also busted when cross compiling using build-on: run-on definition [17:51] Odd_Bloke, popey - sudo apt install --reinstall snapd => helped! [17:52] ondra: could you create a bug for that last one too? [17:52] sergiusens and new question I have, is maven supporting core18? I have change base snap in my snapcraft.yaml and my build is now failing [17:53] ondra: yes, look at the 3.0 release notes [17:53] ondra: https://github.com/snapcore/snapcraft/releases/tag/3.0 [17:53] sergiusens I added both (SNAPCRAFT_ARCH_TRIPLET and project.target_arch) to same bug, it seems related [17:53] sergiusens unless you tell me to split it [17:54] ok [17:54] sergiusens with snapcraft 3.0.1 I'm getting maven.py", line 263, in _create_symlinks IndexError: list index out of range [17:54] sergiusens and only thing I changed was base snap [17:54] cross compilation are low priority bugs, btw [17:54] ondra: please log a bug [17:54] or submit to sentry [17:55] sergiusens I did already uploaded traceback [17:55] ok [17:55] sergiusens same happens with edge and candidate [17:55] sergiusens BTW, this line is funny "if self.project.info.base not in ("core18", "core19"):" [17:56] hmm, that is a bug [17:56] sergiusens I know core18 made it out in 2019, but did not know we actually have core19 now :D [17:56] should be core16... not tests in place as core16 did not really exist then [17:56] sergiusens same in ant, maven gradle :) [18:00] ondra: I will need your snapcraft.yaml for the maven issue [18:02] sergiusens https://bugs.launchpad.net/snapcraft/+bug/1813636 [18:02] Bug #1813636: ant maven and gradle plugins referene mysterious core19