[06:13] morning [07:17] o/ [07:18] * zyga had a hard night [07:19] zyga: hey [07:20] hey [07:20] mborzecki: janek is 13 today [07:21] zyga: wow nice, best wishes for him :) [07:22] and iza turned her room upside down [07:22] being upset and angry well into midnight [07:22] because she wanted to have something for the sims and we said no, and it went downhill from there [07:22] hahaha ;) [07:22] * zyga is sleeeeeepy [07:22] (literally half of her stuff is downstairs as it slid down the stairs) [07:23] quick errand, need to drop by the town hall, back in 1h or so [07:23] she also tore our bed apart [07:23] good luch [07:23] luck I mean [07:23] I need to wake up [07:45] re for a little bit [07:48] i keep forgetting, why do we avoid using x/sys/unix? [07:50] mborzecki: no idea [07:52] I think it used to not support ppc [07:52] but now we don't support ppc eiter [08:05] mornings [08:05] pstolowski: hey [08:06] ok, trying the town hall once again [08:16] Hey [08:16] Is town hall today? [08:18] hey zyga [08:18] :-) [08:19] yeah i asked mborzecki the same, i don't have anything in my calendar [08:22] I see Oct 24th [08:23] nothing more? [08:28] zyga: same here [08:33] re [08:34] zyga: no, i mean my local council ;) dealing with some beaurocracy stuff here [08:45] ah ;D [09:20] * Chipaca coffees up [09:32] hey Chipaca :) [09:46] zyga: 'sup :) [09:46] good, sleepy [09:46] slow day [09:47] zyga: yup [09:47] zyga: feels like a saturday, here [09:51] Chipaca: hey, i'll re-request a review for snapctl is-connected from you; the core implementation didn't change, but there is new stuff wrt error propagation between api and client [09:51] Chipaca: and i feel it's a bit of muddy waters :} [09:51] pstolowski: ok [09:52] i'm going to push in a moment [10:05] Chipaca http://asciicker.com/y0/ [10:05] Chipaca try f1 / f2 [10:12] Hi. Isn't snapcraft 3.9.2 supposed to be in the stable channel already? [10:17] zyga-laptop: wow @asciicker [10:22] ppd1990: supposed by who? [10:23] Chipaca: https://forum.snapcraft.io/t/call-for-testing-snapcraft-3-9/13944/26 [10:26] ppd1990: hm. Maybe it's phasing, or maybe somebody found an issue and it had to be rolled back? [10:26] pstolowski: right? :) [10:26] brb [10:27] PR snapd#7824 opened: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap [10:27] just when i thought mpt doesn't work again [10:27] ? [10:28] mpt: sorry, meant mup :) [10:28] mborzecki: no rebooting mpt [10:28] without their consent at least [10:29] should rename mup to something more bot-like [10:29] 😴 [10:29] Chipaca: Probably :) [10:29] ppd1990: ask sergiusens in a few hours [10:30] ppd1990: (or, ask in that forum thread) [10:30] ppd1990: or ask on the forum [10:34] wow, the models used for CV are yuge [10:34] it's like 4GB of just models [10:35] what are you doing with CV? [10:35] osutil/stat.go:106:9: undefined: syscall.Faccessat on osx :/ [10:36] mborzecki: heh [10:36] mborzecki: one sec [10:37] yeah, no such syscall [10:38] mborzecki: macos doesn't have a stable syscall layer [10:38] so we should probably not use it [10:38] it only has a stable .dylib layer [10:45] zyga: can you check what value does R_OK have on osx? [10:52] heh it's in x/sys/unix [10:53] i mean, the Faccessat on osx [10:55] zyga: just trying to get https://github.com/sniklaus/3d-ken-burns to work, for now [10:58] aha [11:26] PR snapd#7825 opened: many: use transient scope for tracking apps and hooks [11:26] mborzecki: https://github.com/snapcore/snapd/pull/7825 [11:26] I decided to open it without larger changes [11:26] PR #7825: many: use transient scope for tracking apps and hooks [11:27] mborzecki: I think landing and iterating will be just easier [11:27] mborzecki: and will unlock more things to land in parallel [11:27] (smaller things) [11:39] * zyga is baby-sitting lucy [12:02] time for some reviews [12:24] cmatsuoka, hey [12:24] there is a bug that perhaps you could take a look https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852544 [12:24] Bug #1852544: uc20 grubenv block seems odd [12:24] it is related to UC20 [12:26] cachio: checking that [12:26] cmatsuoka, thanks [12:27] cachio: we're already working on that [12:27] cmatsuoka, nice [12:27] cmatsuoka, good to know [12:27] cmatsuoka, is there a priority to assign to the bug? [12:27] I believe it's already fixed but I didn't check the latest image to see how it's going [12:29] xnox: did we fix https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852544 already? I believe so since you have a booting image (which I didn't check yet but's in my todo list for this morning) [12:29] Bug #1852544: uc20 grubenv block seems odd [12:30] cmatsuoka: i believe that is still wrong [12:30] cmatsuoka: in the gadget snap, i'm importing all the environment blocks, both good and bad. [12:31] xnox: humm ok I'll check the plans with Michael [12:31] xnox: thanks [12:50] kenvandine, hi [12:51] kenvandine, I see and error when installing gimp in i386 [12:51] kenvandine, https://travis-ci.org/snapcore/spread-cron/builds/618422327#L3292 [12:51] is it being supoported right? [13:02] PR snapcraft#2827 closed: build providers: only set the snapd flag when installing snapd [13:09] ppd1990: there was an issue, I had to roll back temporarily https://github.com/snapcore/snapcraft/commit/1eebc27968e20e63ead11f7214c655284357fef2 [13:09] sergiusens: Thanks a lot for the info. Much appreciated! [13:11] getting a bug (in my human body) did not help in making this go faster, sorry about that [13:28] PR snapd#7726 closed: RFC: change how snapd tracks processes [13:29] PR snapd#7722 closed: cmd/snap-confine: add sc_join_sub_group [13:32] PR snapd#7486 closed: tests: add regression test for lp: #1844496 [13:32] zyga: we don't have a type for security tags do we? [13:33] zyga: i'm looking at #7825, and thiking that we may need a package to encode the ideas about naming things, like snap related cgroup, security tag and so on [13:33] PR #7825: many: use transient scope for tracking apps and hooks [13:33] mborzecki: nope [13:34] mborzecki: security tag is more of an interface [13:34] mborzecki: with a String() method [13:34] zyga: for instance, right now the scope name is in snap run where it's created, and then some bits are in snapstate where the cgroup name is interpreted [13:34] and a InstanceName() method [13:34] I think we can clean it up a lot but ... it's a long path [13:34] mborzecki: can you do a quick review on https://github.com/snapcore/snapd/pull/7784 [13:35] I can land it and iterate perhaps [13:35] PR #7784: cmd/snap-update-ns: adjust debugging output for usability [13:35] mborzecki: back to security tag, I think it ought to be an interface [13:35] mborzecki: because we have several kinds of security tags that are not alike [13:35] mborzecki: the concrete type of each could be string [13:36] mborzecki: but the wrapper type would be more useful .e.g. hook security tag, app security tag, that weird non-app-non-hook security tag for some udev things [13:36] mborzecki: it could have methods like SnapWideGlob() [13:36] zyga: and then the scope & cgroup names [13:36] and we could have a helper like GenrateScopeName(tag SecurityTag) [13:37] *Generate [13:38] mborzecki: how does that sounD? [13:38] sounD :) like systemD? :P [13:41] mborzecki: btw, offtopic, on fedora 31 I don't get snap icons in alt-tab in gnome [13:41] probably related to the centos bug [13:41] zyga: do you get them in the activities view? [13:41] yes i do [13:42] zyga: i suppose nothing in the logs? [13:42] zyga: btw. wayland or xorg? [13:43] wayland [13:43] logs are always full of garbage [13:43] lis 29 14:43:04 x240 gnome-shell[2041]: value "nan" of type 'gdouble' is invalid or out of range for property 'vignette-sharpness' of type 'gdouble' ;-) [13:43] lis 29 14:43:10 x240 systemd[1841]: dbus-:1.2-org.gnome.Boxes.SearchProvider@14.service: Succeeded. ;) [13:44] but nothing about the fact icons are gone [13:44] heh, at least it's no spamming the logs like it did a month ago [13:44] weirdish [13:44] oh it's full of junk really [13:44] right after 3.34 there'd be a constant 1-2kB/s of logs going to journal [13:45] heh [13:45] nvme pays for itself ;) [13:53] PR snapd#7784 closed: cmd/snap-update-ns: adjust debugging output for usability === ricab is now known as ricab|lunch [14:01] mborzecki: I cannot join yet [14:01] lucy is waking up now [14:01] mborzecki: my update is simple: working on more testing and follow-ups [14:01] I'll update the doc shortly [14:11] cmatsuoka: i did snap refresh of ubuntu-image & snapd [14:12] cmatsuoka: created a fresh image [14:12] it still has two copies of core & pc-kernel snaps [14:12] once in /snaps and ones in /var/lib/snapd/snaps/ [14:12] the second location is not used on UC20 seed partition [14:12] and grubenv is still in the wrong location at /boot/grub/ instead of at /EFI/ubuntu/ [14:14] cachio: afaik. diddledan see the question about gimp? [14:19] zyga: left some comments under 7825, need to play with this locally [14:19] kenvandine, taj, ok, thanks [14:20] what's the spread test trying to do with gimp? [14:22] mborzecki: sure, thank you [14:25] thanks, replied to most [14:25] I'll apply the trivials shortly [14:25] mborzecki: note, I'm running this on F31 and it's not exploding :) [14:28] it's pretty cool that I can see memory usage of my app [14:28] mborzecki: sublime-text instance from a snap https://www.irccloud.com/pastebin/M8V1r6t3/ [14:33] diddledan, it just installs gimp [14:35] are you sure that's _all_ it is doing? because there's weird messages about "Match"ing stuff [14:38] diddledan, this is the test https://github.com/snapcore/snapd/blob/master/tests/nightly/install-snaps/task.yaml [14:38] diddledan, the MATCH is used to detect the channel and other info about the snap to isntall [14:39] so what is the actual failure condition then? [14:41] diddledan, the test tries to install gimp in ubuntu 16.04 32bits [14:41] and this is happening [14:41] + snap install gimp --stable [14:41] error: cannot perform the following tasks: [14:41] - Ensure prerequisites for "gimp" are available (cannot install prerequisite "gtk2-common-themes": no snap revision available as specified) [14:42] cachio: that's weird, I'm not getting that [14:42] yes, well that's not my fault then. that's down to whoever unpublished gtk2-common-themes from the 32bit stable channel :-) [14:42] it affects other snaps too [14:42] e.g. audacity [14:43] diddledan, yes [14:43] (another of mine :-) [14:44] gtk2-common-themes is still available in 64bit so I'm assuming closing the 32bit stable channel was either a mistake or someone wasn't thinking things through [14:44] I could include audacity to the test if you want [14:44] to we detect this kind of errors on important snaps [14:45] in fact, gtk2-common-themes is _only_ availeble for amd64 now - it used to be available for i386.. https://snapstats.org/snaps/gtk2-common-themes [14:46] kenvandine: is this something for you to look into? [14:48] Not sure what happened to i386 [14:49] it is probably worth investigating adding armhf and arm64 too [14:50] for those of us that insist on using a pi as their desktop :-p [14:50] Yeah [14:50] I can't look at it today, but will on Monday [14:51] coolbeans :-) [14:51] ah, 32bit systems [14:51] interesting [14:54] * cachio lunch [14:58] zyga: 130MB for sublime? [14:58] all the MB! [15:00] heh, actually my emacs is using 250MB of heap so, maybe 130 isn't that much after all [15:12] mborzecki: yeah [15:12] mborzecki: I guess that's all the .so's loaded and stuff [15:12] mborzecki: but it's really neat [15:12] because we _can_ measure it === ricab|lunch is now known as ricab [15:21] finally #7824 is green [15:21] PR #7824: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap [16:05] * zyga participated in his son's birthday [16:07] cachio: 2 questions to #7815, once clarified i can +1 it [16:07] PR #7815: tests: reduce the complexity of the test-snapd-sh snap [17:33] i'ma gonna go ahead and EOW [17:33] * Chipaca just broke all the tests [17:33] see y'all monday [17:49] zyga: hi, Hope your day was better than the night. [18:23] sdhd-sascha: it was pretty calm :) [18:25] :) I had to help the in-laws today. [18:26] I had two small question, if you have time ? [18:27] sure [18:29] Is it possible to use a part only on a specific release (e.g. only on bionic) ? [18:30] are you asking about building in snapcraft? [18:30] i found the advanced-grammer - but until now no source code [18:30] yes [18:30] yeah [18:30] the source code is in a sister project, there are tests for this feature [18:30] which can be used as quick documentation [18:30] it's github.com/snapcore/snapcraft [18:31] ok, i have it already here [18:31] I don't know the details, I think it's meant for system packages that can be injected into a snap package [18:31] you can vary those depending on build architecture IIRC [18:31] but it's not for this-or-that release [18:31] because the release is fixed by the selection of the base snap [18:31] inside snap.yaml and snapcraft.yaml you can say base: foo [18:31] and foo is a base snap name that defines how to build it [18:31] and how to run it [18:31] there are two commonly used base snaps now [18:32] core, which is derived from ubuntu 16.04 [18:32] and core18 which is derived from ubuntu 18.04 [18:32] yes :-) [18:32] if you say base: core18 you will get binary packages from the matching architecture of that release [18:32] i found it inside git:snapcraft/internal/project_loader/grammer/_on.py [18:33] https://www.irccloud.com/pastebin/UecwmS5C/ [18:34] my problem is, that fontconfig of my 19.04 host is incompatible, with core18 ... Ok, i will try if a newer fontconfig inside a part is backward compatible [18:34] yeah, as I said it's for things like "on arm64 use this package" on "amd64 use that package" [18:34] wait wait [18:34] your host should not be a part of the build [18:34] when you build with snapcraft your tree should be transferred to a pristine vm managed by multipass [18:34] and built there [18:34] Yes, but /etc/fonts/font.conf is from the host and mounted inside the snap [18:34] the vm will match the base you picked [18:34] ah, yes [18:34] and what are you seeing? [18:34] we have some special handling for fontconfig [18:35] perhaps there's a bug or the current system is insufficient [18:35] i see: [18:35] Fontconfig error: "/etc/fonts/fonts.conf", line 6: invalid attribute 'translate' [18:35] can you please report that, along with the output of "snap version" on bugs.launchpad.net/snapd [18:35] we'll have a look on Monday [18:35] I have a plan to stop sharing /etc [18:35] as it was a mistake [18:36] but it's not urgent enough to push through [18:36] (there are higher priority topics first) [18:36] once that is done we can synthesize correct /etc/fonts and anything else that matches the base snap [18:38] ok. Also the goal is to not share /etc. right? (only i ask only for me, because i will experiment on this weekend) [18:38] that's my goal [18:38] it's not on the product roadmap [18:38] it will likely happen during the cycle [18:39] Why would it be bad, to build fontconfig into the snap? (not urgent this question, i will try this too) [18:39] you can [18:39] but it's just bigger [18:40] and usually there's a fontconfig around from other places [18:40] e.g. the gnome runtime content snap [18:40] ok [18:40] snaps don't have a "you must" policy usually [18:41] so if you want to showcase a cool feature of patched fontconfig [18:41] go for it :) [18:41] it's not like classic packaging [18:41] The second question was: What is the difference of plugs/slot inside apps and inside global? [18:41] right [18:41] so, in general, each app and hook can have any number of plugs and slots [18:41] if you define a plug at a level of a specific app or hook it is "bound" there [18:42] if you define it globally you add it to all the apps and hooks [18:42] except if you define it globally but then only mention it in a specific app or hook [18:42] ok. i understand. [18:42] the reason to define plugs and slots globally is so that you can use the richer syntax that has attributes [18:42] some interfaces require that [18:42] at app/hook level you can only use the abbreviated syntax [18:42] where just the name is given [18:43] and it defines a plug or slot with the same name and type [18:43] one example that is very common, that requires global definitions is the content interface [18:43] because it always requires some attributes [18:43] that's that [18:43] I think it's fairly documented on snapcraft.io/docs [18:43] but if you find something is missing or unclear please just say so [18:44] The docs have also hidden pages, which are not in the menu, only in the text... [18:44] About plugs/slots: [18:44] missing links are easy to fix [18:44] you can just go to the forum [18:45] and comment on the thread [18:45] there's a link on each doc page [18:45] Now if a snap provide wayland and can also run under wayland, how should this be defined ? I got a error, if i use the wayland plug/slot as both [18:45] or ping @degville about it, he's managing documentation [18:45] so interfaces have two sides, plugs and slots [18:45] :) [18:45] slots are the "providing" part, and plugs are the "consuming" side [18:45] having a plug or slot may already give you some permission [18:46] having a plug or slot connected to another slot or plug usually gives even more permissions [18:46] are you asking what is needed to run a wayland _server_? [18:47] Both, wayland as client under wayland. And wayland as server, and later as client for other snaps. [18:47] ahj [18:47] I see [18:47] so you need two interfaces [18:47] But we can delay this question. [18:47] plug and slot of wayland [18:47] they just need to have different names [18:47] Ah [18:47] plugs: wayland-client: interface: wayland [18:47] slots: wayland-server: interface: wayland [18:47] okay, then copy, paste the interface [18:47] (insert tabs and newlines as required) [18:48] yeah [18:48] i understand [18:48] we added a requirement for plugs and slots to have unique names [18:48] to avoid confusing situations [18:49] zyga: thank you. Now i have enough task, for the weekend ;-) [18:49] enjoy :) [18:51] :) [18:54] * cachio afk [23:51] PR snapd#7826 opened: tests: use on spread tests the test-snapd-sh snap