[00:54] PR snapd#5011 opened: data/selinux: Recognize more aspects that snapd needs access [00:57] zyga, ^ [04:23] Hey guys, Im trying to build my own snap for a custom Arm kernel of Ubuntu. It's build well, but i cant install it. I have a "mount snap core" error [04:24] The hardware is a Jetson TX2, the kernel is Linux4Tegra 28.2 [04:24] am i getting this "mount snap core" error because of my kernel? or because I did smtg wrong [04:25] it's running ubuntu [05:07] morning [05:20] good morning [05:20] Pharaoh_Atem: ack, thank you [05:20] Caelum: ack, trying [05:21] eraserpencil: perhaps missing squashfs support in the boot loader or the kernel, not sure thoguh [05:23] Caelum: ah, we need to adjust badness thing [05:23] Caelum: we should submit our policykit files somewhere to SUSE central packages to get rid of the problem [05:30] zyga: hey, morning [06:01] hey [06:10] zyga: how is it that it can compress into squashfs it it didnt have squashfs [06:13] eraserpencil: compress? the kernel never works on the compression side [06:14] eraserpencil: also the boot loader and kernel have separate implementations [06:14] eraserpencil: so perhaps it was the boot loader that got through the kernel but the kernel could not mount the root filesystem (squashfs) because it was not enabled in your kernel [06:14] eraserpencil: I'm just saying it's possible, check your kernel configuration [06:15] how? [06:17] ahh custom kernel, ok nvm [06:20] eraserpencil: you are using your own kernel, right? [06:20] Caelum: fixed locally, will push when the package builds [06:20] it's LInux4Tegra by Nvidia [06:20] Asking the forum there now [06:22] eraserpencil: you may want to look at forum.snapcraft.io too [06:22] perhaps there's already a working kernel with snap support there [06:22] kk [06:22] thanks [06:33] mborzecki: hey, good morning. have you seen the feedback in 4942? [06:35] mvo: hey, yes, i'll be updating this shortly, got dug up in some rpm stuff [06:36] Hey mvo, welcome back [06:37] mborzecki: cool, thank you [06:38] zyga: hey, thank you! nice to be back :) how are you (and the rest of the gang)? any fires ? [06:38] I think we are good but we need 2.32.3 in stable ASAP [06:39] And we need .4 === ejat_ is now known as ejat [06:40] zyga: sounds good [06:40] .4 must bring hook fixes and the new store api [06:40] zyga: we need .4 for the new api? or for moe? [06:41] zyga: have the hook fixes landed in 2.32 already? [06:42] Nope [06:42] But there is an initial or [06:42] PR [06:43] zyga: cool, I have a look now [06:46] zyga: do you think we should cherry-pick 5011? [06:46] PR snapd#5011 closed: data/selinux: Give snapd access to more aspects of the system [06:47] mvo: hi mvo, we want to enable one custom board with ubuntu core, I followed the guide on the website [06:48] mvo: but when I want to upload the kernel snap, it was rejected since kernel type is not allowed.. [06:48] mvo: so what should we do now to enable our device? [06:50] hamo: custom enablement is probably good to discuss with e.g. ogra_ (he will be around in ~2h or so usually). you can sideload the kernel via ubuntu-image. you can also request a manual review for a rejected snap. kernels are not auto-accepted into the store because of all the security implications that this has [06:51] hamo: and good morning :) [06:51] zyga: 5006 looks like an easy win :) [06:55] yeah, I'll do Jamie's interface PRs now [06:56] mvo: haha.. It's afternoon here, good afternoon [06:57] mvo: oh, about ubuntu-image, there's a broken snap that should probably be disabled now [06:57] mvo: another question, I see I can directly upload to edge channel, but when I want to upload this kernel to edge channel, it failed as "A file with this exact same content has already been uploaded" [06:57] mvo: how could I delete the bad one and re-upload it? [06:58] hamo: exact same content? [06:58] it's already there [06:58] upload a different one [06:58] zyga: yep, the same snap to another channel [06:58] hamo: you don't need to upload it [06:59] hamo: just publish it [06:59] you can publish a revision into a channel [06:59] hamo: yeah, it means the snap is already in the store, you can simply use "snapcraft release $your-snap $your-rev edge" (for example) [06:59] zyga: mvo Good... let me try it [06:59] PR snapd#5006 closed: interfaces: misc updates for default, firewall-control, fuse-support and process-control [07:00] mvo: I asked jdstrand about back ports of the interface PRs [07:00] ohhh [07:00] I'm blind :) [07:00] PR snapd#5008 closed: interfaces: misc updates for default, firewall-control, fuse-support and process-control - 2.32 [07:01] zyga: thank you! [07:02] zyga: what broken snap is there? a broken ubuntu-image snap? [07:02] zyga: if so, anything we need to do about it? [07:02] mvo: ubuntu-image is broken [07:02] I think someone from foundations should take action [07:03] zyga: mvo could I do release if the target package is in pending-review status? [07:03] hamo: I don't know [07:04] zyga: can you join #ubuntu-devel please ? not sure that sil2100 is aware of the issue [07:04] hamo: I think you need to wait until this is reviewed, but please try I'm not 100% certain myself [07:08] good morning [07:10] kalikiana: good morning [07:10] pedronis: \o/ for 5004 - you rock! === pstolowski|eow is now known as pstolowski [07:11] morning [07:14] hey kalikiana, pstolowski :) [07:32] PR snapd#4992 closed: tests/main/interfaces-opengl-nvidia: verify access to 32bit libraries [07:32] mborzecki: woah, 4989 (arch) succeeded on arch?!? [07:32] mvo: yes :) [07:33] mvo: even not that many tests had to be disabled :P [07:34] mborzecki: nice job! [07:35] mvo: even better, with all the gce support niemeyer it should have no impact on how long the tests take to run :P [07:35] mborzecki: I really like this aspect of the PR :) [07:39] PR snapd#5005 closed: interfaces/hostname-control: allow setting the hostname via syscall and systemd [07:46] mvo: zyga another question, does snap/ubuntu core support boot from nand flash? [07:47] hamo: Yoooooooooo [07:47] hamo: yes, it's just something that has to be handled by the gadget [07:47] hamo: to be precise, snapd doesn't care where it's booted from [07:48] zyga: really grea.....t, any example of nand gadget? [07:48] nope [07:48] I only work on reference devices [07:48] my point is that snapd doesn't constrain that [07:49] if you can boot from NAND on your board that's fine [07:50] mvo: about https://github.com/snapcore/snapd/pull/4987 -- I merged and then reverted your PR [07:50] PR #4987: tests: add test to ensure `snap refresh --amend` works with different channels [07:51] as AFAIK it was conflicting with pedronis' big activity PR and it was contained therein [07:51] currently ubuntu core try to extend / modify the partition layout at the first boot. Which doesn't work for NAND... Hi, ondra, Have you tried it on Nand device? [07:52] PR snapd#4999 closed: advisor: use json for package database === JerryKao is now known as Jerry-Bluefin [08:21] do we have anything to manipulate/open file descriptors to journald? [08:23] mborzecki: via journalctl, in systemd (search for jctl) [08:23] mborzecki: all it does is use osutil.StreamCommand though [08:23] not sure that's what you mean [08:24] mborzecki: why? [08:24] mvo, zyga: any idea about the snapd autopkg test failure on i386? the history doesn't look well in any case [08:24] hmm, no, could you please pass the link to the error? [08:25] Chipaca: something bothering me about app autostart, so gnome-session does `sd_journal_stream_fd("foo.desktop",..)` and uses that fd as stdout/stderr [08:26] Chipaca: in case of our autostart via `snap userd --autostart`, we end up with say `snap-userd-autostart.desktop: ...` in the users journal, because the fd was open for snap-userd-autostart.desktop [08:26] Chipaca: a way to fix it would be to open another set of fds just for the app and tag them [08:26] * Chipaca reads sd_journal_stream_fd(3) [08:27] mvo: ^^ intersting in the context of app autostart [08:27] doko: last I looked at it we got random reached during the tests. for some reason it looks like the autopkgtest VMs are slow(er) than the other machines? maybe overcommited more? [08:27] mborzecki: hm, interessting [08:28] mborzecki: is userd still short-lived? [08:29] Chipaca: yes, it just starts the apps and goes away [08:29] 'cause if it is, i'd say just build against libsystemd [08:29] and do the actual sd_journal_stream_fd call [08:29] Chipaca: that would drag in cgo [08:29] mborzecki: yes [08:30] mborzecki: our reticence to use cgo is mostly around memory leaks, and applies to long-lived processes [08:30] mborzecki: (that is outside of specific omg-needs-to-be-static cases =) ) [08:30] mvo: the queue is empty now, so I wouldn't expect that. but please could you address this with Laney and/or make the tests more conservative then? or is this a real issue with git? [08:31] mborzecki: OTOH it's quite likely the sd_journal_stream_fd call is really just calling dbus, so you could do it that way [08:31] * Chipaca doesn't know though [08:31] Chipaca: hm that might be a bit controversial, i'd rather land the PR as it is now and do a smaller iteration to address this incovenience [08:32] mborzecki: or [08:32] doko: I doubt its a real issue, this works fine in our GCE environment, we see close to 100% success there (sometimes network related failures). I will check with Laney. [08:32] mborzecki: you could exec the command piped to systemd-cat [08:33] doko, Laney an interessting observation is that they all (the recent ones) die in "+ journalctl --sync\n\n". makes me wonder if something is wrong with the systemd setup on these instance [08:33] Chipaca: hm i could just reimplement this in Go: https://github.com/systemd/systemd/blob/97a33b126c845327a3a19d6e66f05684823868fb/src/journal/journal-send.c#L395 ;) [08:34] mvo: zyga: hi, do we support hooks and applications in bases? I don't think we prohibit them? do we use themselves as the root filesystem or core if we run them? we should probably use themselves I suppose, execpt to get snapctl etc [08:34] we use themselves I believe but we hardly ever try [08:35] core is almost like a base snap (almost) so we don't exercise that code [08:35] I'm not sure reading snap-confine code [08:35] alloca(l + 1 + 1 + 2 + 2 + 2 + 2 + 2) [08:35] pedronis: we do not prohibit them, but unless we have a use-case, maybe we should? [08:35] pedronis: note that base is conveyed from snap run [08:35] mborzecki: totally sane [08:35] Chipaca: this one is intersting too: header[l++] = '0' + !!level_prefix; [08:36] Chipaca: int level_prefix [08:37] mborzecki: I think rewriting that specific function in Go seems sane [08:37] mborzecki: but, maybe do it in a separate PR [08:37] Chipaca: agreed [08:38] mborzecki: are you reading kernel sources? [08:38] mvo: zyga: we don't pass itself from snap run if the snap is a base, so I suppose we use core as the filesystem which is not correct [08:38] ah, systemd [08:38] zyga: systemd, gnome-session and glib :P [08:38] pedronis: that feels like a bug then [08:39] because taking foo.desktop and starting an app cannot be trivial :) [08:39] mvo: yea, I think either we should prohibit them, or bases should not have a base (I think that we might check already) and should be their own base [08:40] pedronis: yeah, I think we do not allow a base to have a base but worth double checking, I make a note to look at this [08:41] mvo: for context I was looking at this because of the question of what waits to setup in UpdateMany [08:42] mvo: snaps should wait for their base, and everything should wait for core (in theory, and in the future the snapd snap) as the source of snapctl, snap-exec etc [08:42] pedronis: I think that this setup makes sense [08:43] snaps should wait for the things their default providers too [08:43] no? [08:43] Chipaca: that's already done a bit differently [08:44] Chipaca: here is the question of things for which snap-confine is unhappy if there's no current symlink [08:44] mborzecki: OTOH systemd-cat is literally prepending "systemd-cat" to the exec line [08:44] pedronis: ah [08:45] Chipaca: basically snap-confine reads the current of core and base, and if the inactive we cannot really do things with services or hooks of a snap [08:45] yep yep [08:47] mvo: btw I prepared the backport of new api for 2.32, should wait until we are confident 2.32.3 is good before merging though [08:49] pedronis: yes, I saw it and will eyeball it today (it was already reviewed so I will just do a quick sanity check) [08:49] pedronis: and agreed that we need to hold it back a little [09:14] pedronis: just double checked, we error if a base or an os snap has a base set [09:20] mvo: ok, so either we fix snap run to send the --base to be base for a base, or we need to prohibit [09:20] more [09:23] pedronis: maybe we talk about it in the standup but my preference for now would be to disable hooks/apps on bases [09:23] (unless we have a use-case) [09:50] PR snapd#5012 opened: snap: fix `snap advise-snap --command` output to match spec [09:58] mvo: ok, it changes a bit the answer on what waiting needs to happen [09:59] pedronis: changed in what way? [10:00] mvo: if bases don't have apps, services or hooks, we don't need to wait on anything for them [10:01] pedronis: indeed [10:08] zyga: Do you guys expose host fonts to apps? [10:08] zyga: i.e. https://github.com/flatpak/flatpak/issues/1563 [10:08] Yes, one of the interfaces does this [10:09] But we expose the fonts, not all of the guts [10:09] same here [10:09] but, the guts is unfortunately needed for some things [10:09] thus that issue [10:09] Of course, the guts are a total horrorshow [10:10] Yes, we [10:10] Know this are not abi stable [10:13] alexlarsson: re, so I think the fonts are the 1st best thing we can do [10:13] the "guts" (caches, config files) are a no-no for now [10:13] I'd be interested to understand more about when we need the config files [10:13] We do expose the caches [10:13] those are versioned [10:13] I believe for intance https://github.com/flatpak/flatpak/issues/1556 is due to the lack of the conf.d files [10:14] Hmm, interestingly that says snappy can display them :) [10:15] But, the conf.d snippets has per-language additions to some standard font names [10:15] hmm, interesting [10:15] alexlarsson: so snaps do get most of /etc from the host [10:15] so that you get glyphs picked from that font for e.g. sans- [10:15] so perhaps we just didn't notice the issue because we share /etc/fonts/ automatically [10:16] The desktop helpers do some voodoo too. [10:16] https://github.com/ubuntu/snapcraft-desktop-helpers/blob/a3de48097a4d7e81ef309e1b2c4eaea970ef88cc/common/desktop-exports#L166 [10:16] yes, the helpers massage the world into compliance [10:17] Like, on fedora, 65-0-lohit-bengali.conf has: [10:17] https://paste.fedoraproject.org/paste/-gRyyRM~iFjfyMWMJFAgmA [10:17] Which i believe makes it pick that font for indic glyphs when showing sans-serif [10:18] * zyga refrains from commenting about XML as a imperative programming language [10:18] Or something like that (who knows how this shit really works) [10:18] but yeah [10:18] it seems that this font config is what over time moved to /lib as "configuration" for systemd units and other non-config things that need to be there by default [10:19] maybe fontconfig needs similar treatment, move most of that off to /lib and allow /etc for _optional_ overrides [10:19] In fedora the files in there are symlinked from /usr/share/fontconfig/conf.avail/ [10:19] same on Debian [10:19] But i think they need to be in one directory for the priority sort thing to work [10:19] well, almost [10:20] sorry, it's /etc/fonts/conf.avail [10:20] there's a swarm of symlinks to that go from /etc/fonts/conf.d/ to ../conf.avail/ [10:20] The main problem i have with it is that it just randomly includes these snippets that can do *anything* [10:21] like, set font directories, include other xml files, etc [10:21] They just randomly reused the system config language for per-font tweaks [10:21] I think bringing those from the host is a mistak [10:21] mistake* [10:21] on our end it's just historic thing we want to undo [10:22] we should ship working configuration in a read-only place [10:22] and offer additional fonts from the host, but not their configuration [10:22] *until* fonts can be shipped by flatpaks/snaps [10:22] But, if it is needed for e.g i18n, then we're kinda hosed [10:22] and something sane is done about the "configuration" (some form of validation of what is allowed) [10:23] I'm lightly considering some kind of sanitizer thing to export the right things [10:23] Just wanted to sync with you as it seems you'll have similar issues [10:24] so we are in the same boat, I think our setup works "more" but mostly by historic accident [10:24] I wonder if anyone ever edits those [10:24] and if we could really just make all of those configuration files immutable [10:24] I don't think anyone edits the files [10:24] it might be a problem if the format changes (e.g. new syntax to do something new) [10:24] but, the directory will change as you install font packages [10:25] and including the host's /etc causes problems [10:25] In fact the font *did* just change [10:25] eh, format [10:25] font or the config system? [10:25] oh [10:25] can you explain what changed? [10:25] https://bugs.freedesktop.org/show_bug.cgi?id=105818 [10:26] I think some translation thing changed [10:26] so, chrome with statically linked fontconfig cannot read the fontconfig 2.13 conf files [10:26] epic, eh? [10:26] yes, year of the linux desktop is surely not this year [10:27] I think it is still backwards compat though [10:27] so, a sanitizer could just ignore "new" stuff [10:27] yes the bug report comment says: "you could still use the older config files with newer library but the newer config files may not works with older library like that." [10:27] so we could offer a frozen view of older configuration syntax, if one was available with each and every font package on all the distributions (read: probably not) [10:28] Yeah, the problem would be if the host font dropped a conf.d with some new config feature [10:28] one idea is to offer a filter [10:28] that takes an .xml config file [10:28] some extra hint as to which output format to create [10:28] and strip or translate some features into a compatible format for the given library [10:29] In an ideal world the config format should be split into two things [10:29] that translator could run in a sandbox on export [10:29] one that does system config [10:29] and one that does per-font tweaks and that is minimal and stable [10:29] But, thats not what we got... [10:30] But yeah, we need some kind of xml-convertor/stripper like that [10:31] But, one has to actually understand all this crack to write it... [10:31] alexlarsson: given the "track record" of xml I'd either sandbox the converter or write it in a safe language (preferably both) [10:31] Well, it is the host [10:31] like, the host is not going to be attacking the sandbox [10:31] its normally the other way around [10:32] So, i don't think that is the largest problem [10:32] But it has to be very flexible in handling new, unknown format extensions [10:32] does flatpak allow flatpaks to ship fonts to the host? [10:33] no [10:33] runtimes can bundle fonts, and apps can bundle fonts [10:33] So you have *some* guarantees [10:33] ok [10:33] but normally the idea is to use system fonts [10:33] For the apps [10:35] alexlarsson: when did this issue surface? [10:35] with the format chagne [10:35] the chrome thing? [10:35] Antergos Linux, 4.15.15-1-ARCH [10:36] when 2.13 was released, so like a month or so ago [10:36] ah, so probably some bleeding edge version of fontconfig [10:36] sorry, I wasn't clear, I was thinking about fontconfig itself [10:36] fontconfig 2.13 [10:37] tumbleweed is at 2.12 [10:37] we will notice the issue soon then [10:38] interestingly on opensuse /etc/fonts/conf.d is full of symlinks to /usr [10:39] we can work around that to expose font configuration some other way but I worry that this is a ticking bomb [10:40] mvo: 2.32.3 failed to build in xenial [10:42] I see the build was restarted [10:46] zyga: failed in the PPA? [10:46] mvo: I noticed the build was restored and I removed the mail from my inbox, I don't recall [10:49] zyga: aha, ok [10:50] zyga: yeah, very rarely we get those [11:12] ogra_: i have a core system which doesn't seem to have resized the writable part. It's only 8GB on a 80GB disk. Is there some way to force it or do I need to bust out a live cd and gparted? [11:14] popey, well, it would be good to find out why it actually didnt resize (the resize code is pretty dumb, it should always work) ... can you re-flash and capture the log from /run/initramfs ? [11:15] (if the partition got resized but the filesystem has errors you wouldnt need gparted, just resize2fs) [11:15] s/has/had/ [11:16] i think i know why it didn't [11:16] i dd'ed onto a usb stick, then once setup, i dd'ed *that* to the hard disk [11:16] so i guess it thinks it already ran once, so doesnt need to [11:18] well ... the script checks the partition size vs the device size and looks if there is free space after the writable partition [11:18] ok, used resize2fs and its okay now [11:18] ok [11:18] the partition was full size, but the filesystem wasnt [11:18] thanks! [11:18] so the parttition was actually at full size [11:18] (also is this the right place for core questions?) [11:18] *snap* [11:19] I mean, we don't have a category on the forum? [11:19] sure [11:19] "device" is the core cateogory [11:19] but i have admittedly not had much time the last week to look at the forum [11:19] ahh === pstolowski is now known as pstolowski|lunch [11:19] does an app installed with snap update itself? [11:19] if installed from the store, yes katnip [11:20] (got a big backlog i need to go through ... working for customers eats time :) ) [11:20] ok ty [11:20] katnip: any snap in particular you're interested in? [11:20] it is hexchat [11:20] zyga, after the change introduced to make snapd work better with selinux, should we be able to run tests on the google fedora again? [11:20] zyga, I mean, without the change to make it permissive [11:21] katnip: ok, yes, when TingPing updates hexchat in the store, you'll get it [11:22] cachio: I don't think so [11:22] nice, thanks [11:23] kalikiana: hey, do you happen to know if there is a plan to support "refresh-mode" in the snapcraft.yaml json schema? [11:23] kalikiana: its a relatively new feature of snapd [11:31] mvo: did I answer your question about test in 5004 ? [11:33] pedronis: let me quickly double check [11:40] pedronis: replied, it is indeed testing the thing I was looking for already [11:40] thx [11:40] looking into pawel comment atm [11:41] * Son_Goku groans into existence [11:43] mvo, so it looks like my ability to compile snapd has been restored according to Koschei: https://apps.fedoraproject.org/koschei/package/snapd [11:43] (if you were wondering why I hadn't been packaging the last few releases, that gives you an indicator of why...) [11:44] PR snapd#5013 opened: cmd/snap-confine: ignore missing cgroups in snap-device-helper [11:44] Son_Goku: \o/ great to hear. it was the go-yaml breakage? [11:44] yes [11:44] mvo: ^ trivial review [11:45] mvo: consider a .4 candidate PR [11:45] as evidenced by https://apps.fedoraproject.org/koschei/build/4577065, the dependency of golang-gopkg-yaml-devel-v2 from 1-21 to 1-22 fixed it [11:45] that was picked up by Koschei on April 7 [11:46] mvo, pedronis, hmm, is there some special trick to set a password to expired via system user assertion or is that simply not implemented (pretty typical usecase to have something like "admin/admin" and force the user to set a new PW on first login) [11:47] * cachio afk [11:47] mvo, root cause was that yaml was mispackaged (v1 had v2 and v2 had v1) [11:48] * Fri Mar 30 2018 Robert-André Mauchin - 1-22.gitcd8b52f [11:48] - Fix mixed-up directories [11:49] Son_Goku: heh, ok [11:50] I'm pushing new go-yaml updates to stable _now_ [11:50] https://bodhi.fedoraproject.org/updates/FEDORA-2018-e05b554cb4 [11:50] it should sync out in the next 12 hours [11:51] ogra_: not implemented afaict, what do you try to pass exactly? is the validation rejecting it? [11:51] mvo, so we can turn CI back on for Fedora either later today or tomorrow [11:51] we should also consider wiring up Fedora 28 CI [11:52] mvo, not trying to pass anything ... for a pre-release image a customer is asking for a default user/passwd in the image we give them ... would be nice to have that PW expired by default to force an updated PW ... i was just going through the documentation and didnt find anything on that topic === pstolowski|lunch is now known as pstolowski [11:53] ogra_: yeah, we don't support this right now [11:53] they want a dev image along with the production one and dont want to force the developers to make their own assertion ... but a known fixed PW is rather insecure as you know :) [11:54] i'll file a feature request on the forum ... [11:55] standup is at 3pm? [11:55] I think so, mvo? [11:56] zyga, mborzecki yes [11:56] ok [11:56] ok, I need to take the dog out, also visit the vet nearby [11:56] I may take the stand-up from my phone [11:59] Who will make a Snap of a Java Runtime, so other Snaps can get Java support? :-) [12:00] (Like VLC, to bring full Java menus to Blu-ray playback) [12:05] off to pick up the kids, will be back for standup [12:10] ogra_: what do I have to do to get screen or tmux pre-installed on core? [12:11] (screen is 560K, tmux is 345K) or so... [12:17]