[01:51] PR snapd#6186 opened: interfaces/avahi_observe: Fix typo in comment [06:05] morning [07:15] PR snapd#6187 opened: packaging/fedora: use %_sysctldir macro [07:55] mvo: hey, we'll have some trouble with github.com/coreos/go-systemd/activation package, the changed the API of activation.Listeners(bool) to activation.Listeners() and the default is different now [07:56] mvo: any clue why we didn'g want to have go-systemd unset LISTEN_FDS, LISTEN_PID and LISTEN_FDNAMES ? [07:59] mborzecki: I don't know, maybe chipaca remembers [08:01] mvo: hm, from the looks of it, we could drop the activation package, our use case is super simple and could be easily done ourselves without external dep [08:02] mvo: and fedora has bumped their pacakge version in f29 and rawhide, soe snapd will not build there anymore without a patch [08:04] mborzecki: right [08:04] i'll prep a pr to unblock this [08:04] mborzecki: I'm inclined to just to our own implementation or is there another packaged option out there with a more stable api? [08:04] mborzecki: thank you === pstolowski|afk is now known as pstolowski [08:06] mornings [08:06] hey pstolowski - good morning [08:06] pstolowski: hey [08:14] Hey [08:15] Will start late, Iā€™m stuck in traffic [08:15] zyga: good morning [08:15] Had a late night :/ [08:16] zyga: I have a bit of a conundrum, maybe you have an idea. strace -f snap run test-snapd-tools.echo does not show snap-update-ns in my log, I wonder why [08:16] Please review my PRs if possible [08:16] zyga: yeah, I noticed some reviews were late. what happend, did you got carried away? [08:16] zyga: yeah, will do [08:17] Mvo: is the mount namespace ready? We only call s-u-n once [08:17] Combination of factors, I stopped after 3AM [08:18] Mvo: I merged one branch that had one review and was hanging for days [08:18] The one removing useless unshare [08:18] You asked it [08:18] Acknowledged it [08:18] zyga: I remember this one, iirc I reviewed it [08:18] Still in traffic [08:19] Yep [08:19] zyga: no worries [08:19] Just wanted to make sure you know [08:27] mvo: maybe it's because s-u-n goes through fexecve, you can actually see clone() and with -k you see which s-c function is calling it but not much more [08:28] mborzecki: yeah, its slightly annoying, I though internally this all goes through execve into the kernel but apparently not :/ [08:32] mborzecki: aha, apparently I can get execveat [08:33] * mvo reviews first [08:33] * mvo must resist temptation [08:34] mvo: hmm looking at glibc, there's a path for execvat and a separate one for that calls execve("/proc/self/fd/",..) where num is the fd [08:34] zyga: 6170 and 6181 were the critical ones? [08:35] mborzecki: interessting [08:35] mborzecki: what I see (just from experimenting) here on 18.10 is execveat [08:35] mborzecki: but maybe it depends on kernel or something? [08:35] mvo: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/fexecve.c;h=3560b711ca2c6d1a61330d91099a3fc2201c583e;hb=HEAD [08:35] mvo: yes, kernel and glibc [08:45] mborzecki: nice, thnak you [08:45] fedora is the only distro where deps aren't bundled, right? [08:46] mborzecki: debian too [08:46] ah [08:46] mvo: in 10 min [08:48] mvo: ok, so buster is a problem too then [08:51] mborzecki: the systemd stuff? [08:51] mborzecki: well, breaking api is not nice [08:51] bad people [08:51] mvo: yes, buster has v17 version which has the API change [08:51] mvo: coreos, move fast, break things, get bought :) [09:13] PR snapd#6188 opened: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes [09:17] mvo: sorry, now installed and ready for work [09:17] mvo: let me read the backlog now [09:17] mvo: so https://github.com/snapcore/snapd/pull/6170 is the snapd side part of features [09:17] PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features [09:18] I think it's not controversial [09:18] š”Šš”¬š”¬š”” š”š”¬š”Æš”«š”¦š”«š”¤ [09:18] it's the design gustavo wanted [09:18] holly smokes [09:18] now you must tell me, dir sir Chipaca, how that works [09:18] š¬š§ššš© š¢š§š¬š­ššš„š„ š®š§š¢šŸšØš§š­šžš« [09:18] wow [09:18] šššš‘ššŽ šš›ššŽššœšš šš’ššœ ššŽššŠššœšš¢ [09:19] Chipaca: but technically [09:19] are those just unicode glyphs that have a specific look? [09:19] yes [09:20] š“‰š’½ā„Æš“‡ā„Æ ā„Æš“‹ā„Æš“ƒ š’¾š“ˆ ā„“š“ƒā„Æ š“š’¾š“€ā„Æ š“‰š’½š’¾š“ˆ [09:20] mvo: https://github.com/snapcore/snapd/pull/6181 is the second part of that for Go programs [09:20] I wasn't sure where to put it [09:20] PR #6181: features: add feature test methods [09:20] As in, which package [09:21] zyga: in gucharmap, search for 'fraktur' to get to the majority of them [09:21] ahhh [09:21] fraktur, I love it [09:21] thank you :) [09:21] usage: unifonter [-h] [-i INPUT] [-o OUTPUT] [09:21] [-k {b,bc,bf,bi,c,d,f,i,m,s,sb,sbi,si,w}] [09:21] [text [text ...]] [09:21] unifonter: error: argument -k: invalid choice: 'k' (choose from 'b', 'bc', 'bf', 'bi', 'c', 'd', 'f', 'i', 'm', 's', 'sb', 'sbi', 'si', 'w') [09:21] augh [09:21] mvo: after writing the features/ PR I wanted to combine the two so that there's a canonical definition of features [09:21] (š”±š”„š”¦š”° š”¦š”° š”£š”Æš”žš”Øš”±š”²š”Æ) [09:21] so that coreconfig references the same names, I will do that as a follow-up [09:22] (š–™š–š–Žš–˜ š–Žš–˜ *š–‡š–”š–‘š–‰* š–‹š–—š–†š–š–™š–šš–—) [09:22] * Chipaca stops having fun and has coffee instead [09:23] zyga: ok, I just finished the first going to the second now [09:23] thank you, looking [09:23] mvo: I will kindly ask you to do more reviews after that - I really want to land this thing [09:26] mborzecki: can you do a quick check on https://github.com/snapcore/snapd/pull/6182 [09:26] PR #6182: Revert "cmd/snap-confine: don't allow mapping lib{uuid,blkid}" <āš  Critical> [09:26] this may fix the TW testing PR [09:27] PR snapd#6187 closed: packaging/fedora: use %_sysctldir macro [09:28] do we need CLA for a typo? [09:28] I guess not [09:28] I'm looking at https://github.com/snapcore/snapd/pull/6186 [09:28] PR #6186: interfaces/avahi_observe: Fix typo in comment [09:29] PR snapd#6182 closed: Revert "cmd/snap-confine: don't allow mapping lib{uuid,blkid}" <āš  Critical> [09:35] mvo: replied to https://github.com/snapcore/snapd/pull/6170 [09:35] let me know if the suggested comment is ok [09:35] PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features [09:36] I will update it quickly :) [09:38] zyga: ok, I am at the other one right now [09:38] mvo: if you still have a moment for reviews then please look at https://github.com/snapcore/snapd/pull/6147 next [09:38] PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces [09:38] I will work on the feedback [09:42] zyga: thanks, replied and added feedback for 6181 [09:42] thanks! [09:42] zyga: thanks for your patience [09:43] zyga: left some comments in #6170, sorry for the delay, had it opened in a tab a while now, buried among a bunch of other tabs [09:43] PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features [09:43] wish ff had a way to label/mark tabs, like TODO and so on [09:44] mvo: about the two feature PRs [09:44] shall I merge them together [09:44] or do you want to see a 3rd PR on top [09:47] mvo: I just saw your comment in the PR, I will do a follow up [09:47] is core snap needed when all installed snaps use core 18? [09:47] so quick pass over the simple feedback and then merge the two and continue [09:47] vidal72[m]: no but some bugs in stable mean that yes [09:47] vidal72[m]: in master this is (I believe) all fixed now [09:49] zyga: is there a way to remove core snap? [09:49] not at present [09:49] :( [09:51] https://github.com/snapcore/core/pull/99 <- needs a review from someone from the snapd team [09:51] PR core#99: snapcraft: add fc-cache-{6,7} [09:56] mvo: I had a look last night [09:56] but after midnight I didn't want to comment [09:56] vidal72[m]: is there an issue with that? [09:57] vidal72[m]: eventually the core snap will be phased out [09:57] vidal72[m]: snapd will install and remove required base snaps automatically [09:58] mvo: updated https://github.com/snapcore/snapd/pull/6181 - I think it's good to do now [09:58] PR #6181: features: add feature test methods [09:58] mvo: if this lands I can merge it into the other PR (snapd side) and remove the duplication there [10:00] why is the core configuration package called configcore and not coreconfig? [10:04] zyga: iirc gustavo liked the name better [10:06] zyga: re 6181> please push the followup once its ready I'm keen to see it playing together and I would love to also land it together [10:06] sure [10:07] uh [10:08] pedronis: replied to your comment on 6181 [10:08] pedronis: please let me know if you want to discuss this [10:10] mvo: wrt core#99, how's the insecure access thing going to be addressed? [10:10] PR core#99: snapcraft: add fc-cache-{6,7} [10:10] Chipaca: I thought I pushed the fix for this, let me double check [10:10] pedronis: so, can you help me understand please [10:11] Chipaca: uh, silly me [10:11] :-) [10:11] Chipaca: now the fix is pushed *cough* [10:11] pedronis: shall I merge 6170 into 6181 [10:11] * Chipaca sends mvo a 4x-strength green tea [10:11] Chipaca: actually - silly git and silly me to equal parts [10:11] pedronis: and have configcore use the features in one PR [10:11] pedronis: is that what you want? [10:11] Chipaca: heh, great! I need it, didn't sleep well [10:11] same [10:12] I tweaked my back yesterday again :-( [10:12] Chipaca: :( [10:13] mvo: is armhf security also on ports? [10:13] Chipaca: I am pretty sure it is, let me double check [10:13] k [10:14] Chipaca: http://ports.ubuntu.com/ubuntu-ports/dists/bionic-security/main/binary-armhf/ [10:14] \o/ [10:15] * zyga is unsure what to do about features now [10:15] eh [10:16] zyga: just make a combined PR with 6170, 6181 and the followup that uses features in configcore [10:16] mvo: and the package? [10:16] zyga: I think that the easiest way forward, then we can see the bigger picture [10:16] pedronis didn't want to add a new package but didn't respond to how to structure it [10:16] zyga: not sure, maybe it could be a sub-package of something? [10:17] like? [10:17] zyga: heh, you ask hard questions :) [10:17] zyga: let me look and think [10:19] zyga: I am not sure maybe a sub package of configstate ? otoh it has nothing to do with overlord. but then it fits the oconfig schema. its a bit of an import otoh :/ "overlord/configstate/features" [10:20] mvo: then we need to import that from snap-update-ns [10:20] mvo: I didn't want to do that [10:21] zyga: fair enough, but maybe we can move forward and do the other bits (using feature in corecfg etc) and address this package name/locaiton as the last step? [10:21] zyga: (assuming samuele is ok with this but I guess he will be) [10:21] mvo: yes, I'm working on that now [10:21] zyga: great, thank you [10:21] well, adding test that maciej requested firts [10:24] zyga: +1 [10:26] PR snapd#6188 closed: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes [10:26] mvo: left some comments under #6185, really like it [10:26] PR #6185: snap: add new `snap run --perf` call [10:29] mborzecki: thanks, I'm working on tests now [10:29] mborzecki: more [10:32] PR snapcraft#2415 opened: tools: pull in imporved cla_check.py from snapd [10:32] 'imporved' [10:33] šŸ¤¦ [10:33] * Chipaca leaves it [10:47] mvo: I addressed all comments in https://github.com/snapcore/snapd/pull/6170 [10:47] PR #6170: overlord,tests: expose enabled features to /var/lib/snapd/features [10:47] mvo: shall I close https://github.com/snapcore/snapd/pull/6181 now and merge it into 6170? [10:47] PR #6181: features: add feature test methods [10:51] PR snapd#6171 closed: tests: add SPREAD_JOB to the description of systemd_create_and_start_unit [10:52] mvo: ? [10:56] zyga: sorry, looking [10:56] thanks [10:59] zyga: how about just creating a new branch that combines 6181 and 6170 and build on top of that? [11:00] zyga: we can have a HO if you feel this is all a bit unclear [11:00] no, that's fine [11:00] let me make one [11:00] and the two branches can be closed, [11:01] zyga: yeah or just keep them for reference as they have useful comments and we close once the final one is in - but no strong preferences, if you just refer to them in the new PR thats fine as well of curse [11:01] course [11:02] PR snapd#6170 closed: overlord,tests: expose enabled features to /var/lib/snapd/features [11:02] PR snapd#6181 closed: features: add feature test methods [11:02] uh :) [11:02] too late [11:07] PR snapd#6189 opened: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes (2.36) [11:07] zyga: when you want a break from easy things, #6034 is ready for another look :-p [11:07] PR #6034: many: save media info when installing, show it when listing [11:07] Chipaca: I'll do that after the combination PR [11:08] zyga: :-) ok. No rush anyway, but didn't know if you'd seen that I'd pushed it. [11:14] PR snapd#6190 opened: overlord/configstate,features: expose features to snapd tools [11:15] mvo: https://github.com/snapcore/snapd/pull/6190 [11:15] this is the combination without the duplication [11:15] PR #6190: overlord/configstate,features: expose features to snapd tools [11:15] mvo: i've proposed a fix for kr/pretty https://github.com/kr/pretty/pull/58 , but the list of PRs there from the period of 2014-2017 is not encouraging :/ [11:15] PR kr/pretty#58: Fix infinite recursion when diffing structs with cycles [11:18] Chipaca: looking now [11:18] I re-read my comments to remind myself about that work [11:21] pstolowski: thank you! we can always use a fork if we have to (but it would suck) [11:22] mvo: yeah, i'm not sure the fix is 100% correct, the stuff is a bit tricky. for sure it fixes the case i hit in our tests, but i wonder if there are edge cases [11:22] mvo: so feedback from the author would be good [11:30] Chipaca: reviewed [11:32] zyga: thanks [11:34] mvo: about the features branch, all of the new code is here https://github.com/snapcore/snapd/pull/6190/commits/dddc6d68ee0f492a45b48e61431fa6d9f55e66b3 [11:34] PR #6190: overlord/configstate,features: expose features to snapd tools [11:39] PR snapd#6186 closed: interfaces/avahi_observe: Fix typo in comment [11:45] mborzecki: ping about https://github.com/snapcore/snapd/pull/6111 [11:45] PR #6111: packaging/opensuse: move most logic to snapd.mk [11:46] mvo: I don't know if this is the case for sure but perhaps 6110 is failing for the same general reason fedora29 does [11:46] mvo: we never addressed that issue in the end [12:02] mborzecki: I ran ubuntu-core-16-64:tests/regression/lp-1803542 alone and it obviously passed [12:02] I hate our test suite [12:02] it's a constant source of misery [12:03] eh [12:05] PR snapcraft#2414 closed: yaml_utils: allow unicode while encoding [12:05] PR snapd#6179 closed: snap: epoch lists must contain no duplicate entries [12:08] mvo: snapd update in suse shows some errors [12:08] syntax error in /var/lib/snapd/desktop/applications/test-snapd-policy-app-consumer_test-desktop.desktop, line 1 [12:08] the destkop file has no [Foo] section [12:08] is that something we mangle or is that a broken test def? (the snap is from the test suite) [12:10] zyga: no [Foo] section or no [Desktop] section? [12:11] no [Desktop] section [12:11] I will check if the original file has one [12:11] hm, the test snap has one [12:11] so that is odd [12:11] yes [12:11] it has one [12:11] something is borken [12:13] :( [12:13] mborzecki: https://github.com/snapcore/snapd/pull/6147#discussion_r235696283 [12:13] what did you mean there? [12:13] PR #6147: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces [12:14] PR snapcraft#2416 opened: yaml_utils: allow unicode while encoding (#2414) [12:15] zyga: whether it'd be possible to roll sc_setup_mount_profiles and that call into something generic that runs s-u-n [12:15] zyga: or s-d-n [12:15] in that case [12:16] one bigger function? [12:16] I'm sorry, I don't follow [12:18] zyga: yeah, like run_this_helper_for_snap(fd, snap_name, aa) === cpaelzer__ is now known as cpaelzer [12:19] yeah perhaps [12:19] the fork / exec /wait part could be shared [12:19] mhm [12:19] the arg handling could stay in each dedicated function [12:20] idk, soemthing to think about [12:20] although that doesn't strictly follow the rule of 3s :) [12:22] 3s? [12:23] zyga: https://erikbern.com/2017/08/29/the-software-engineering-rule-of-3.html [12:24] zyga: fwiw there's even a wikipedia page https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) :) [12:26] ah, cool [12:27] see :) [12:27] zyga: mvo: to be clear my point was more that it needs to do more, be more the one source of truth/authorative place to merit a top level package, and also that having two authorative places about the different bits of the same things is confusing [12:28] selinux makes my head hurt :/ [12:30] pedronis: the top-level package was just a quick idea since it has to be imported from snap-update-ns and I didn't want to drag all of configcore with it. I'm open to suggestions on where to place it [12:30] pedronis: the duplication aspect is addressed now [12:30] pedronis: though we don't have one element yet, the default if absent value (what does it mean for that value to be unset) [12:31] but this problem is only specific to snapd internals [12:31] the outside-of-snapd API is unambiguous [12:32] Hello there [12:32] hey! [12:32] FOlks, we need to rollback or improve that change of "snap info" that is highlighting a channel [12:32] is it breaking parsing of the input? [12:32] I would suggest just rolling it back for the time being [12:33] At least until we can discuss in more detail the design aspects involved [12:33] zyga: Not for me, at least, but it's very misleading [12:33] Here is an example from my terminal just now: [12:33] channels: [12:33] stable: 2.79b (20) 129MB classic < [12:33] candidate: ā†‘ [12:33] beta: ā†‘ [12:33] edge: 2.80-f021536babb (19) 106MB classic [12:33] installed: 2.80-f021536babb (19) 106MB classic [12:34] That "stable" line stands out from everything else in the output, for no good reason [12:34] This is not even my installed version [12:34] mmm, I see - I didn't notice that before [12:35] We have the fields tracking, installed, and channel map.. each with different meaning [12:37] I don't know what that landed, I don't remember that changed being discussed, or reviewing it [12:38] Chipaca: ^ is that something you did? or somebody else? when did it land? [12:38] related to this: https://bugs.launchpad.net/snapd/+bug/1795840 [12:38] 40e299154324315957d31eb89823c5267c0d9e85 [12:38] Bug #1795840: `snap info` highlights the wrong version as installed when `snap try`ing [12:38] https://github.com/snapcore/snapd/commit/40e299154324315957d31eb89823c5267c0d9e85 [12:39] pedronis: that's something I did yes [12:39] it highlights the current channel [12:39] Chipaca: mvo: it's 2.36 ? [12:40] Chipaca: current as in tracking? [12:41] yes [12:41] but not always ? [12:41] niemeyer said is highlighting not his installed version? [12:41] or is that because of a switch? [12:41] anyway is not very self explanatory [12:42] there was a request (somewhere) about highlighting current channel and current revision differently when they differend, i think [12:42] Right, it highlights the channel map, although this version is not the current one [12:42] either a switch, or an update not run [12:42] we are trying to pack too much stuff there [12:42] it's cute [12:42] but not sure learnable [12:43] if you're on core edge, 'snap info core' is the most likely to show a difference between highlighted and current revision [12:43] Which doesn't make much sense in that case it seems.. the "arrowing" and highlighting makes it standout more than anything else, even though that channel map entry is not current [12:44] Chipaca: so it's trying to pack snap refresh --list information into snap info? [12:44] no [12:44] but doesn't really tell? [12:44] what [12:44] no [12:45] then I'm very confused [12:45] that's not good :) [12:45] it just highlights the channel you are tracking [12:45] that's it [12:45] wich bit ? [12:45] the bold and the < [12:45] Chipaca: No, it highlights the content of the channel that you are tracking [12:45] they point at the same thing? or not? [12:45] bold and < are always the same right now yes [12:45] niemeyer: ah, so perhaps we could highlight the channel name alone [12:45] niemeyer: what [12:45] Chipaca: Strawman: how about dropping that arrow and making the highlighting on the channel *name* only [12:45] ha [12:45] zyga: ! :) [12:46] * zyga is happy to get something aligned for a change [12:46] niemeyer: Chipaca: yes, that would seem better, it's still a bit unclear how understanble it is [12:46] what's the "content of the channel that you are tracking" that isn't "the channel you are tracking"? [12:46] Chipaca: and then maybe also highlight the *value* of "installed" [12:47] maybe [12:47] I start to think we need to step back [12:47] Chipaca: I'm tracking stable, my version is not the one on stable.. [12:47] and pack less in there :) [12:47] name: foo \n installed: v123 from stable but tracking edge [12:47] Chipaca: The channel map shows the version that is in stable, not the one I have [12:47] Chipaca: Just confusing [12:47] * Chipaca was happy for a month [12:47] :) [12:49] niemeyer: just because you haven't refreshed lately, that does not change the channel map [12:50] Chipaca: well we are all confused what it means, that's the reality [12:50] that shows maybe we shouldn't do it [12:50] while on second though I agree it is confusing I must also say I like how it looks like [12:50] the output is long so visual cues like that help to find things [12:51] we just need to make it precise [12:51] maybe change the < to <- tracking [12:51] ? [12:51] šŸ›¤ [12:51] zyga: that's undistinguishable from a šŸ’© at least on xenial terminals [12:52] well, maybe not šŸ’© -- they got that one nice and distinctive [12:53] mvo: http://smackerelofopinion.blogspot.com/2018/11/high-level-tracing-with-bpftrace.html [12:53] mvo: I wanted to read this because, hey, tracing [12:53] maybe useful for snaps [12:53] look at what it says :D [12:54] mvo: i'm going to do some bug triaging, hope i'm not getting into your way again (anyone else doing this?) [12:55] zyga: :-D [12:55] zyga: well, that is cking's blog [13:03] off to pick up the kids [13:25] zyga: do you know if that exec call error reached any conclusion - https://bugs.launchpad.net/snapd/+bug/1705988 ? i think you were investigating this error at some point but maybe i'm wrong [13:25] Bug #1705988: snap install --classic juju fails [13:26] pstolowski: no [13:26] pstolowski: I mean, no conclusion [13:29] zyga: k thanks [13:29] pedronis: related to the snap info, there is also an old enhancement request from Mark https://bugs.launchpad.net/snapd/+bug/1758288 [13:29] Bug #1758288: 'snap info' should show date of release into channel [13:33] I see store errors in tests [13:33] timeouts [13:34] break / walk before the call [13:40] zyga: thanks for the ebpf pointer, this looks pretty cool [13:41] pstolowski: no bug triage right now on my side, go wild, and thank you! [13:44] PR snapd#6191 opened: cmd/snap: fix missing newline in "snap keys" error message [13:45] pstolowski: bug triage already successful :) [13:45] :) [13:47] PR core#99 closed: snapcraft: add fc-cache-{6,7} [13:51] PR snapd#6192 opened: overlord/snapstate: on refresh, check new rev can read current [13:52] zyga: links to logs for the store timeouts? [13:56] Er, gonsky [13:57] * cachio lunch [14:00] ha [14:00] reproduced [14:00] something buggy in test cleanup [14:02] mvo: hangous still buggy [14:02] I clicked join [14:02] see my camera [14:02] and nothing else happens [14:05] trying to join from regular account [14:05] same [14:05] eh [14:08] mvo: restarted browser, logged out [14:08] no change [14:09] how do I join from the phone? [14:13] Chipaca: Re. "niemeyer: just because you haven't refreshed lately, that does not change the channel map".. exactly.. the point is that the *channel map* is now highlighting a *version* and other details like "classic", etc, and it's very unclear why. It certainly doesn't feel like the reason why is "because you are tracking that channel and will eventually get that version, probably". [14:17] PR snapd#6178 closed: snap,snap-exec: add SNAP_DEBUG_START_TIME environment [14:18] pstolowski: oh, that missing newline [14:18] it was in the TW branch [14:18] forgot to push it separately [14:18] thanks for doing that! [14:25] PR snapd#6193 opened: spread: drop Fedora 27, add Fedora 29 [14:25] niemeyer: hi there, I would appreciate your opinion on https://forum.snapcraft.io/t/title-length-in-snapcraft-yaml-snap-yaml/8625 given that it seems we have no well defined length for the "title" field. [14:26] I think the Gnome Software screenshots there could be used as a guideline on what we want that value to be [14:27] sergiusens: Will discuss here and provide some feedback there, thanks for the pointer [14:28] thanks! [14:38] https://github.com/snapcore/snapd/pull/6190 is green :) [14:38] PR #6190: overlord/configstate,features: expose features to snapd tools [14:38] pstolowski: found a bug :) [14:38] 942 127 0:3 mnt:[4026532154] /run/snapd/ns/failing-config-hooks.mnt rw - nsfs nsfs rw [14:39] I bet that when the config hook fails [14:39] we don't cleanup after the snap :) [14:39] I'll look at fixing that [14:40] zyga: great, this is with relation to what? [14:42] zyga, https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394/9 [14:42] niemeyer, mborzecki, mvo: golang is moving back to Fedora EPEL [14:43] pstolowski: the bug I just mentioned in the call [14:43] Son_Goku: hey [14:43] Son_Goku: do you have a sec for a call? [14:43] Son_Goku: not urgent, just want to explain what that issue is about [14:43] sure [14:43] zyga: ah, that one about finding leftovers [14:43] I do now [14:44] Son_Goku: do you know if there's any immediate action needed for 7.6? [14:44] niemeyer, mborzecki, mvo: https://pagure.io/releng/issue/7919 [14:44] mborzecki, not yet [14:44] Son_Goku: https://meet.google.com/exu-zttk-ynz?authuser=0 [14:47] zyga: can you ack https://github.com/snapcore/snapd/pull/6191 ? [14:47] PR #6191: cmd/snap: fix missing newline in "snap keys" error message [14:49] Son_Goku: Nice! [14:49] sergiusens: Responded [14:59] FTR: diff-highlight rocks [15:11] pstolowski: looking [15:11] zyga: go +2, thanks [15:11] *got [15:26] zyga: I asked some question in the features PR [15:26] questions [15:26] I am a bit confused [15:27] about things that are not experimental anymore [15:27] and how the various bits should work for them [15:27] they don't seem consistent atm [15:44] * cachio lunch [15:48] if a snap uses a tar.gz as its source, and I want it to build via build.snapcraft.io, can I create a github repo with just the snap/snapcraft.yaml file whose source: points to the tar.gz upstream? [15:51] roadmr: aren't most of them that? [15:51] bah [15:51] change 'tar.gz' to 'github repo' and it's the majority of snapcrafters, afaik [15:51] roadmr: e.g. https://github.com/snapcrafters/offlineimap [15:51] (first one i clicked on) [15:52] Chipaca: but that's the thing - I don't want to change 'tar.gz' to 'github repo' [15:52] I specifically want to use the tar.gz because that lets me use the make plugin; the github repo requires some auto* evil I don't have time to wrestle right now [15:52] pedronis: thanks, I'll look [15:53] pedronis: we kept the experimental prefix for layouts for example [15:53] pedronis: but open to suggestions [15:54] roadmr: AIUI source: should work (maybe needs source-type:) [15:54] roadmr: source-type: tar [15:54] Chipaca: right; that looks like it'll work. I can fiddle with things from here :) thanks [15:55] roadmr: https://github.com/snapcrafters/postman does that [15:55] thanks for tracking down an example, Chipaca ! [15:55] np [15:59] PR snapd#6194 opened: snap: make description maximum in runes, not bytes [16:00] Network issues [16:01] zyga: I think the code doesn't behave correctly where things that were experimental but now default to on [16:01] Mvo, pedronis Iā€™m trying to answer from my laptop [16:01] I agree, I will fix that [16:01] zyga: maybe we should have a quick HO today or tomorrow on thhis [16:02] giggle [16:03] zyga: it seems we need files that mean negative for those, or we need run that Ensure were early in snapd, but we can't assume snapd will run before snaps [16:03] Chipaca: That reflects very well the state of my brain right now :) [16:06] re [16:06] reconnected [16:08] pedronis: gladly [16:09] pedronis: hopefully my network will behave [16:09] I have plenty of data left, just fiddled with the modem box [16:10] zyga: we can chat now [16:11] HO or here on IRC? [16:11] maybe meet, ho didn't work for me [16:11] meet is ok, but let me see if I can find a room for me here [16:13] zyga: I found a room (hopefully) [16:18] cachio: do you have 1910 images available for spread yet? [16:29] PR snapd#6195 opened: snapstate: update fontconfig caches on install [16:30] pedronis: ^- is probaly something you want to look at, its very simplistic right now, your input would be welcome what direction to take [16:30] pedronis: but no rush [16:32] mvo: thx, I'll try to look at it today or tomorrow [16:33] PR snapd#6196 opened: Validate title [16:35] sergiusens: ^ title validation as per forum topic [16:36] fwiw, fyi, tanstaaomb, etc [16:36] šŸ‘ [16:36] adding tests here as well [16:39] Heading home [16:42] PR snapcraft#2415 closed: tools: pull in imporved cla_check.py from snapd [16:42] Chipaca: https://github.com/snapcore/snapcraft/pull/2412 [16:42] PR snapcraft#2412: schema: add support for title [16:43] PR snapd#6197 opened: tests/lib: sync cla check back from snapcraft [16:50] PR snapd#6198 opened: Revert "cmd/snap, tests/main/snap-info: highlight the current channel" [16:53] PR snapd#6199 opened: Revert "cmd/snap, tests/main/snap-info: highlight the current channel" (2.36) [16:57] mvo: is that's what needed for 2.36 ^? [17:31] PR snapd#6191 closed: cmd/snap: fix missing newline in "snap keys" error message [17:47] re [17:47] arrived home [17:50] Chipaca: I think so [17:52] hey mvo [17:52] how's stuff? [17:53] zyga: good, good - how are you? [17:53] mvo: how's the experiment [17:55] zyga: the fc-cache work? a super simple version is up for review [17:57] oh [17:57] looking [17:57] just unpacking [17:58] found it [18:09] mvo: is that all? [18:09] feels like a file is missing [18:09] ah, link.go [18:10] zyga: well, its the most simple approach I could think of [18:10] zyga: and that means something ;) [18:10] review sent [18:15] ta [20:42] Zzzz === pstolowski is now known as pstolowski|afk [20:44] how do snapd tests test refresh? [20:44] do you have a fake store or something? [20:44] s/tests/integration tests/ [20:46] mwhudson, hi, there are many tests for refreshes [20:47] some of them use the fake store [20:47] others no [20:47] we test core refresh and snaps refreshes [20:47] mwhudson, what do you need? [20:48] cachio: well i'm just wondering how you arrange for snap refresh to do something [20:48] cachio: as that requires the store to have a new revision of a snap [20:48] in my understanding anyway [20:48] mwhudson, for that we use the fake store [20:48] (context here is that i am working on a subiquity feature to offer an upgrade to a new version) [20:48] cachio: is the fake store something i could run locally? [20:49] mwhudson, yes [20:49] cachio: is it documented? :) [20:49] there are some tests on snapd which show that [20:49] or at least, can you tell me where to find it [20:49] is it in the snapd tree? [20:50] tests/main/refresh/task.yaml [20:50] in the snapd project [20:50] ok [20:50] i can start from there thanks :) [20:50] basically it sets up a fake store which is configured with the snaps to refresh [20:51] mwhudson, perhaps you should see first the refresh-all test [20:51] tests/main/refresh-all/task.yaml [20:52] it is much simpler [20:53] is fakestore in test-snapd-tools ? [20:54] PR snapcraft#2416 closed: yaml_utils: allow unicode while encoding (#2414) [20:54] ah no [20:54] no [20:55] its in the snapd tree i see [20:55] oops gotta run for a call [20:55] test-snapd-tools is the snap to refresh [20:55] cachio: thanks for the pointers so far [21:04] mwhudson, np [21:04] yaw [21:20] PR snapd#6200 opened: tests: fix for tests test-*-cgroup