| mup | PR snapd#5011 opened: data/selinux: Recognize more aspects that snapd needs access <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5011> | 00:54 |
|---|---|---|
| Son_Goku | zyga, ^ | 00:57 |
| eraserpencil | 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:23 |
| eraserpencil | The hardware is a Jetson TX2, the kernel is Linux4Tegra 28.2 | 04:24 |
| eraserpencil | am i getting this "mount snap core" error because of my kernel? or because I did smtg wrong | 04:24 |
| eraserpencil | it's running ubuntu | 04:25 |
| mborzecki | morning | 05:07 |
| zyga | good morning | 05:20 |
| zyga | Pharaoh_Atem: ack, thank you | 05:20 |
| zyga | Caelum: ack, trying | 05:20 |
| zyga | eraserpencil: perhaps missing squashfs support in the boot loader or the kernel, not sure thoguh | 05:21 |
| zyga | Caelum: ah, we need to adjust badness thing | 05:23 |
| zyga | Caelum: we should submit our policykit files somewhere to SUSE central packages to get rid of the problem | 05:23 |
| mborzecki | zyga: hey, morning | 05:30 |
| zyga | hey | 06:01 |
| eraserpencil | zyga: how is it that it can compress into squashfs it it didnt have squashfs | 06:10 |
| zyga | eraserpencil: compress? the kernel never works on the compression side | 06:13 |
| zyga | eraserpencil: also the boot loader and kernel have separate implementations | 06:14 |
| zyga | 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 |
| zyga | eraserpencil: I'm just saying it's possible, check your kernel configuration | 06:14 |
| eraserpencil | how? | 06:15 |
| eraserpencil | ahh custom kernel, ok nvm | 06:17 |
| zyga | eraserpencil: you are using your own kernel, right? | 06:20 |
| zyga | Caelum: fixed locally, will push when the package builds | 06:20 |
| eraserpencil | it's LInux4Tegra by Nvidia | 06:20 |
| eraserpencil | Asking the forum there now | 06:20 |
| zyga | eraserpencil: you may want to look at forum.snapcraft.io too | 06:22 |
| zyga | perhaps there's already a working kernel with snap support there | 06:22 |
| eraserpencil | kk | 06:22 |
| eraserpencil | thanks | 06:22 |
| mvo | mborzecki: hey, good morning. have you seen the feedback in 4942? | 06:33 |
| mborzecki | mvo: hey, yes, i'll be updating this shortly, got dug up in some rpm stuff | 06:35 |
| zyga | Hey mvo, welcome back | 06:36 |
| mvo | mborzecki: cool, thank you | 06:37 |
| mvo | zyga: hey, thank you! nice to be back :) how are you (and the rest of the gang)? any fires ? | 06:38 |
| zyga | I think we are good but we need 2.32.3 in stable ASAP | 06:38 |
| zyga | And we need .4 | 06:39 |
| === ejat_ is now known as ejat | ||
| mvo | zyga: sounds good | 06:40 |
| zyga | .4 must bring hook fixes and the new store api | 06:40 |
| mvo | zyga: we need .4 for the new api? or for moe? | 06:40 |
| mvo | zyga: have the hook fixes landed in 2.32 already? | 06:41 |
| zyga | Nope | 06:42 |
| zyga | But there is an initial or | 06:42 |
| zyga | PR | 06:42 |
| mvo | zyga: cool, I have a look now | 06:43 |
| mvo | zyga: do you think we should cherry-pick 5011? | 06:46 |
| mup | PR snapd#5011 closed: data/selinux: Give snapd access to more aspects of the system <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5011> | 06:46 |
| hamo | mvo: hi mvo, we want to enable one custom board with ubuntu core, I followed the guide on the website | 06:47 |
| hamo | mvo: but when I want to upload the kernel snap, it was rejected since kernel type is not allowed.. | 06:48 |
| hamo | mvo: so what should we do now to enable our device? | 06:48 |
| mvo | 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:50 |
| mvo | hamo: and good morning :) | 06:51 |
| mvo | zyga: 5006 looks like an easy win :) | 06:51 |
| zyga | yeah, I'll do Jamie's interface PRs now | 06:55 |
| hamo | mvo: haha.. It's afternoon here, good afternoon | 06:56 |
| zyga | mvo: oh, about ubuntu-image, there's a broken snap that should probably be disabled now | 06:57 |
| hamo | 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 |
| hamo | mvo: how could I delete the bad one and re-upload it? | 06:57 |
| zyga | hamo: exact same content? | 06:58 |
| zyga | it's already there | 06:58 |
| zyga | upload a different one | 06:58 |
| hamo | zyga: yep, the same snap to another channel | 06:58 |
| zyga | hamo: you don't need to upload it | 06:58 |
| zyga | hamo: just publish it | 06:59 |
| zyga | you can publish a revision into a channel | 06:59 |
| mvo | 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 |
| hamo | zyga: mvo Good... let me try it | 06:59 |
| mup | PR snapd#5006 closed: interfaces: misc updates for default, firewall-control, fuse-support and process-control <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5006> | 06:59 |
| zyga | mvo: I asked jdstrand about back ports of the interface PRs | 07:00 |
| zyga | ohhh | 07:00 |
| zyga | I'm blind :) | 07:00 |
| mup | PR snapd#5008 closed: interfaces: misc updates for default, firewall-control, fuse-support and process-control - 2.32 <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5008> | 07:00 |
| mvo | zyga: thank you! | 07:01 |
| mvo | zyga: what broken snap is there? a broken ubuntu-image snap? | 07:02 |
| mvo | zyga: if so, anything we need to do about it? | 07:02 |
| zyga | mvo: ubuntu-image is broken | 07:02 |
| zyga | I think someone from foundations should take action | 07:02 |
| hamo | zyga: mvo could I do release if the target package is in pending-review status? | 07:03 |
| zyga | hamo: I don't know | 07:03 |
| mvo | zyga: can you join #ubuntu-devel please ? not sure that sil2100 is aware of the issue | 07:04 |
| mvo | hamo: I think you need to wait until this is reviewed, but please try I'm not 100% certain myself | 07:04 |
| kalikiana | good morning | 07:08 |
| mvo | kalikiana: good morning | 07:10 |
| mvo | pedronis: \o/ for 5004 - you rock! | 07:10 |
| === pstolowski|eow is now known as pstolowski | ||
| pstolowski | morning | 07:11 |
| zyga | hey kalikiana, pstolowski :) | 07:14 |
| mup | PR snapd#4992 closed: tests/main/interfaces-opengl-nvidia: verify access to 32bit libraries <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4992> | 07:32 |
| mvo | mborzecki: woah, 4989 (arch) succeeded on arch?!? | 07:32 |
| mborzecki | mvo: yes :) | 07:32 |
| mborzecki | mvo: even not that many tests had to be disabled :P | 07:33 |
| mvo | mborzecki: nice job! | 07:34 |
| mborzecki | 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 |
| mvo | mborzecki: I really like this aspect of the PR :) | 07:35 |
| mup | PR snapd#5005 closed: interfaces/hostname-control: allow setting the hostname via syscall and systemd <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5005> | 07:39 |
| hamo | mvo: zyga another question, does snap/ubuntu core support boot from nand flash? | 07:46 |
| iMadper | hamo: Yoooooooooo | 07:47 |
| zyga | hamo: yes, it's just something that has to be handled by the gadget | 07:47 |
| zyga | hamo: to be precise, snapd doesn't care where it's booted from | 07:47 |
| hamo | zyga: really grea.....t, any example of nand gadget? | 07:48 |
| zyga | nope | 07:48 |
| zyga | I only work on reference devices | 07:48 |
| zyga | my point is that snapd doesn't constrain that | 07:48 |
| zyga | if you can boot from NAND on your board that's fine | 07:49 |
| zyga | mvo: about https://github.com/snapcore/snapd/pull/4987 -- I merged and then reverted your PR | 07:50 |
| mup | PR #4987: tests: add test to ensure `snap refresh --amend` works with different channels <Created by mvo5> <https://github.com/snapcore/snapd/pull/4987> | 07:50 |
| zyga | as AFAIK it was conflicting with pedronis' big activity PR and it was contained therein | 07:51 |
| iMadper | 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:51 |
| mup | PR snapd#4999 closed: advisor: use json for package database <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4999> | 07:52 |
| === JerryKao is now known as Jerry-Bluefin | ||
| mborzecki | do we have anything to manipulate/open file descriptors to journald? | 08:21 |
| Chipaca | mborzecki: via journalctl, in systemd (search for jctl) | 08:23 |
| Chipaca | mborzecki: all it does is use osutil.StreamCommand though | 08:23 |
| Chipaca | not sure that's what you mean | 08:23 |
| Chipaca | mborzecki: why? | 08:24 |
| doko | mvo, zyga: any idea about the snapd autopkg test failure on i386? the history doesn't look well in any case | 08:24 |
| zyga | hmm, no, could you please pass the link to the error? | 08:24 |
| mborzecki | 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:25 |
| mborzecki | Chipaca: in case of our autostart via `snap userd --autostart`, we end up with say `snap-userd-autostart.desktop: ...<logs from started app, eg. discord>` in the users journal, because the fd was open for snap-userd-autostart.desktop | 08:26 |
| mborzecki | 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:26 | |
| mborzecki | mvo: ^^ intersting in the context of app autostart | 08:27 |
| mvo | doko: last I looked at it we got random <kill-timeout reached> 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 |
| mvo | mborzecki: hm, interessting | 08:27 |
| Chipaca | mborzecki: is userd still short-lived? | 08:28 |
| mborzecki | Chipaca: yes, it just starts the apps and goes away | 08:29 |
| Chipaca | 'cause if it is, i'd say just build against libsystemd | 08:29 |
| Chipaca | and do the actual sd_journal_stream_fd call | 08:29 |
| mborzecki | Chipaca: that would drag in cgo | 08:29 |
| Chipaca | mborzecki: yes | 08:29 |
| Chipaca | mborzecki: our reticence to use cgo is mostly around memory leaks, and applies to long-lived processes | 08:30 |
| Chipaca | mborzecki: (that is outside of specific omg-needs-to-be-static cases =) ) | 08:30 |
| doko | 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:30 |
| Chipaca | 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 | |
| mborzecki | 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:31 |
| Chipaca | mborzecki: or | 08:32 |
| mvo | 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 |
| Chipaca | mborzecki: you could exec the command piped to systemd-cat | 08:32 |
| mvo | doko, Laney an interessting observation is that they all (the recent ones) die in "+ journalctl --sync\n\n<kill-timeout reached>". makes me wonder if something is wrong with the systemd setup on these instance | 08:33 |
| mborzecki | Chipaca: hm i could just reimplement this in Go: https://github.com/systemd/systemd/blob/97a33b126c845327a3a19d6e66f05684823868fb/src/journal/journal-send.c#L395 ;) | 08:33 |
| pedronis | 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 |
| zyga | we use themselves I believe but we hardly ever try | 08:34 |
| zyga | core is almost like a base snap (almost) so we don't exercise that code | 08:35 |
| pedronis | I'm not sure reading snap-confine code | 08:35 |
| mborzecki | alloca(l + 1 + 1 + 2 + 2 + 2 + 2 + 2) | 08:35 |
| mvo | pedronis: we do not prohibit them, but unless we have a use-case, maybe we should? | 08:35 |
| zyga | pedronis: note that base is conveyed from snap run | 08:35 |
| Chipaca | mborzecki: totally sane | 08:35 |
| mborzecki | Chipaca: this one is intersting too: header[l++] = '0' + !!level_prefix; | 08:35 |
| mborzecki | Chipaca: int level_prefix | 08:36 |
| Chipaca | mborzecki: I think rewriting that specific function in Go seems sane | 08:37 |
| Chipaca | mborzecki: but, maybe do it in a separate PR | 08:37 |
| mborzecki | Chipaca: agreed | 08:37 |
| zyga | mborzecki: are you reading kernel sources? | 08:38 |
| pedronis | 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 |
| zyga | ah, systemd | 08:38 |
| mborzecki | zyga: systemd, gnome-session and glib :P | 08:38 |
| zyga | pedronis: that feels like a bug then | 08:38 |
| mborzecki | because taking foo.desktop and starting an app cannot be trivial :) | 08:39 |
| pedronis | 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:39 |
| mvo | 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:40 |
| pedronis | mvo: for context I was looking at this because of the question of what waits to setup in UpdateMany | 08:41 |
| pedronis | 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 |
| mvo | pedronis: I think that this setup makes sense | 08:42 |
| Chipaca | snaps should wait for the things their default providers too | 08:43 |
| Chipaca | no? | 08:43 |
| pedronis | Chipaca: that's already done a bit differently | 08:43 |
| pedronis | Chipaca: here is the question of things for which snap-confine is unhappy if there's no current symlink | 08:44 |
| Chipaca | mborzecki: OTOH systemd-cat is literally prepending "systemd-cat" to the exec line | 08:44 |
| Chipaca | pedronis: ah | 08:44 |
| pedronis | 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 |
| Chipaca | yep yep | 08:45 |
| pedronis | 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:47 |
| mvo | 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 |
| mvo | pedronis: and agreed that we need to hold it back a little | 08:49 |
| mvo | pedronis: just double checked, we error if a base or an os snap has a base set | 09:14 |
| pedronis | 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 |
| pedronis | more | 09:20 |
| mvo | pedronis: maybe we talk about it in the standup but my preference for now would be to disable hooks/apps on bases | 09:23 |
| mvo | (unless we have a use-case) | 09:23 |
| mup | PR snapd#5012 opened: snap: fix `snap advise-snap --command` output to match spec <Created by mvo5> <https://github.com/snapcore/snapd/pull/5012> | 09:50 |
| pedronis | mvo: ok, it changes a bit the answer on what waiting needs to happen | 09:58 |
| mvo | pedronis: changed in what way? | 09:59 |
| pedronis | mvo: if bases don't have apps, services or hooks, we don't need to wait on anything for them | 10:00 |
| mvo | pedronis: indeed | 10:01 |
| alexlarsson | zyga: Do you guys expose host fonts to apps? | 10:08 |
| alexlarsson | zyga: i.e. https://github.com/flatpak/flatpak/issues/1563 | 10:08 |
| zyga | Yes, one of the interfaces does this | 10:08 |
| zyga | But we expose the fonts, not all of the guts | 10:09 |
| alexlarsson | same here | 10:09 |
| alexlarsson | but, the guts is unfortunately needed for some things | 10:09 |
| alexlarsson | thus that issue | 10:09 |
| alexlarsson | Of course, the guts are a total horrorshow | 10:09 |
| zyga | Yes, we | 10:10 |
| zyga | Know this are not abi stable | 10:10 |
| zyga | alexlarsson: re, so I think the fonts are the 1st best thing we can do | 10:13 |
| zyga | the "guts" (caches, config files) are a no-no for now | 10:13 |
| zyga | I'd be interested to understand more about when we need the config files | 10:13 |
| alexlarsson | We do expose the caches | 10:13 |
| alexlarsson | those are versioned | 10:13 |
| alexlarsson | I believe for intance https://github.com/flatpak/flatpak/issues/1556 is due to the lack of the conf.d files | 10:13 |
| alexlarsson | Hmm, interestingly that says snappy can display them :) | 10:14 |
| alexlarsson | But, the conf.d snippets has per-language additions to some standard font names | 10:15 |
| zyga | hmm, interesting | 10:15 |
| zyga | alexlarsson: so snaps do get most of /etc from the host | 10:15 |
| alexlarsson | so that you get glyphs picked from that font for e.g. sans- | 10:15 |
| zyga | so perhaps we just didn't notice the issue because we share /etc/fonts/ automatically | 10:15 |
| popey | The desktop helpers do some voodoo too. | 10:16 |
| popey | https://github.com/ubuntu/snapcraft-desktop-helpers/blob/a3de48097a4d7e81ef309e1b2c4eaea970ef88cc/common/desktop-exports#L166 | 10:16 |
| zyga | yes, the helpers massage the world into compliance | 10:16 |
| alexlarsson | Like, on fedora, 65-0-lohit-bengali.conf has: | 10:17 |
| alexlarsson | https://paste.fedoraproject.org/paste/-gRyyRM~iFjfyMWMJFAgmA | 10:17 |
| alexlarsson | Which i believe makes it pick that font for indic glyphs when showing sans-serif | 10:17 |
| * zyga refrains from commenting about XML as a imperative programming language | 10:18 | |
| alexlarsson | Or something like that (who knows how this shit really works) | 10:18 |
| zyga | but yeah | 10:18 |
| zyga | 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:18 |
| zyga | maybe fontconfig needs similar treatment, move most of that off to /lib and allow /etc for _optional_ overrides | 10:19 |
| alexlarsson | In fedora the files in there are symlinked from /usr/share/fontconfig/conf.avail/ | 10:19 |
| zyga | same on Debian | 10:19 |
| alexlarsson | But i think they need to be in one directory for the priority sort thing to work | 10:19 |
| zyga | well, almost | 10:19 |
| zyga | sorry, it's /etc/fonts/conf.avail | 10:20 |
| zyga | there's a swarm of symlinks to that go from /etc/fonts/conf.d/ to ../conf.avail/ | 10:20 |
| alexlarsson | The main problem i have with it is that it just randomly includes these snippets that can do *anything* | 10:20 |
| alexlarsson | like, set font directories, include other xml files, etc | 10:21 |
| alexlarsson | They just randomly reused the system config language for per-font tweaks | 10:21 |
| zyga | I think bringing those from the host is a mistak | 10:21 |
| zyga | mistake* | 10:21 |
| zyga | on our end it's just historic thing we want to undo | 10:21 |
| zyga | we should ship working configuration in a read-only place | 10:22 |
| zyga | and offer additional fonts from the host, but not their configuration | 10:22 |
| zyga | *until* fonts can be shipped by flatpaks/snaps | 10:22 |
| alexlarsson | But, if it is needed for e.g i18n, then we're kinda hosed | 10:22 |
| zyga | and something sane is done about the "configuration" (some form of validation of what is allowed) | 10:22 |
| alexlarsson | I'm lightly considering some kind of sanitizer thing to export the right things | 10:23 |
| alexlarsson | Just wanted to sync with you as it seems you'll have similar issues | 10:23 |
| zyga | so we are in the same boat, I think our setup works "more" but mostly by historic accident | 10:24 |
| zyga | I wonder if anyone ever edits those | 10:24 |
| zyga | and if we could really just make all of those configuration files immutable | 10:24 |
| alexlarsson | I don't think anyone edits the files | 10:24 |
| zyga | it might be a problem if the format changes (e.g. new syntax to do something new) | 10:24 |
| alexlarsson | but, the directory will change as you install font packages | 10:24 |
| zyga | and including the host's /etc causes problems | 10:25 |
| alexlarsson | In fact the font *did* just change | 10:25 |
| alexlarsson | eh, format | 10:25 |
| zyga | font or the config system? | 10:25 |
| zyga | oh | 10:25 |
| zyga | can you explain what changed? | 10:25 |
| alexlarsson | https://bugs.freedesktop.org/show_bug.cgi?id=105818 | 10:25 |
| alexlarsson | I think some translation thing changed | 10:26 |
| alexlarsson | so, chrome with statically linked fontconfig cannot read the fontconfig 2.13 conf files | 10:26 |
| alexlarsson | epic, eh? | 10:26 |
| zyga | yes, year of the linux desktop is surely not this year | 10:26 |
| alexlarsson | I think it is still backwards compat though | 10:27 |
| alexlarsson | so, a sanitizer could just ignore "new" stuff | 10:27 |
| zyga | 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 |
| zyga | 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:27 |
| alexlarsson | Yeah, the problem would be if the host font dropped a conf.d with some new config feature | 10:28 |
| zyga | one idea is to offer a filter | 10:28 |
| zyga | that takes an .xml config file | 10:28 |
| zyga | some extra hint as to which output format to create | 10:28 |
| zyga | and strip or translate some features into a compatible format for the given library | 10:28 |
| alexlarsson | In an ideal world the config format should be split into two things | 10:29 |
| zyga | that translator could run in a sandbox on export | 10:29 |
| alexlarsson | one that does system config | 10:29 |
| alexlarsson | and one that does per-font tweaks and that is minimal and stable | 10:29 |
| alexlarsson | But, thats not what we got... | 10:29 |
| alexlarsson | But yeah, we need some kind of xml-convertor/stripper like that | 10:30 |
| alexlarsson | But, one has to actually understand all this crack to write it... | 10:31 |
| zyga | alexlarsson: given the "track record" of xml I'd either sandbox the converter or write it in a safe language (preferably both) | 10:31 |
| alexlarsson | Well, it is the host | 10:31 |
| alexlarsson | like, the host is not going to be attacking the sandbox | 10:31 |
| alexlarsson | its normally the other way around | 10:31 |
| alexlarsson | So, i don't think that is the largest problem | 10:32 |
| alexlarsson | But it has to be very flexible in handling new, unknown format extensions | 10:32 |
| zyga | does flatpak allow flatpaks to ship fonts to the host? | 10:32 |
| alexlarsson | no | 10:33 |
| alexlarsson | runtimes can bundle fonts, and apps can bundle fonts | 10:33 |
| alexlarsson | So you have *some* guarantees | 10:33 |
| zyga | ok | 10:33 |
| alexlarsson | but normally the idea is to use system fonts | 10:33 |
| alexlarsson | For the apps | 10:33 |
| zyga | alexlarsson: when did this issue surface? | 10:35 |
| zyga | with the format chagne | 10:35 |
| alexlarsson | the chrome thing? | 10:35 |
| zyga | Antergos Linux, 4.15.15-1-ARCH | 10:35 |
| alexlarsson | when 2.13 was released, so like a month or so ago | 10:36 |
| zyga | ah, so probably some bleeding edge version of fontconfig | 10:36 |
| zyga | sorry, I wasn't clear, I was thinking about fontconfig itself | 10:36 |
| alexlarsson | fontconfig 2.13 | 10:36 |
| zyga | tumbleweed is at 2.12 | 10:37 |
| zyga | we will notice the issue soon then | 10:37 |
| zyga | interestingly on opensuse /etc/fonts/conf.d is full of symlinks to /usr | 10:38 |
| zyga | we can work around that to expose font configuration some other way but I worry that this is a ticking bomb | 10:39 |
| zyga | mvo: 2.32.3 failed to build in xenial | 10:40 |
| zyga | I see the build was restarted | 10:42 |
| mvo | zyga: failed in the PPA? | 10:46 |
| zyga | mvo: I noticed the build was restored and I removed the mail from my inbox, I don't recall | 10:46 |
| mvo | zyga: aha, ok | 10:49 |
| mvo | zyga: yeah, very rarely we get those | 10:50 |
| popey | 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:12 |
| ogra_ | 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:14 |
| ogra_ | (if the partition got resized but the filesystem has errors you wouldnt need gparted, just resize2fs) | 11:15 |
| ogra_ | s/has/had/ | 11:15 |
| popey | i think i know why it didn't | 11:16 |
| popey | i dd'ed onto a usb stick, then once setup, i dd'ed *that* to the hard disk | 11:16 |
| popey | so i guess it thinks it already ran once, so doesnt need to | 11:16 |
| ogra_ | well ... the script checks the partition size vs the device size and looks if there is free space after the writable partition | 11:18 |
| popey | ok, used resize2fs and its okay now | 11:18 |
| ogra_ | ok | 11:18 |
| popey | the partition was full size, but the filesystem wasnt | 11:18 |
| popey | thanks! | 11:18 |
| ogra_ | so the parttition was actually at full size | 11:18 |
| popey | (also is this the right place for core questions?) | 11:18 |
| ogra_ | *snap* | 11:18 |
| popey | I mean, we don't have a category on the forum? | 11:19 |
| ogra_ | sure | 11:19 |
| ogra_ | "device" is the core cateogory | 11:19 |
| ogra_ | but i have admittedly not had much time the last week to look at the forum | 11:19 |
| popey | ahh | 11:19 |
| === pstolowski is now known as pstolowski|lunch | ||
| katnip | does an app installed with snap update itself? | 11:19 |
| popey | if installed from the store, yes katnip | 11:19 |
| ogra_ | (got a big backlog i need to go through ... working for customers eats time :) ) | 11:20 |
| katnip | ok ty | 11:20 |
| popey | katnip: any snap in particular you're interested in? | 11:20 |
| katnip | it is hexchat | 11:20 |
| cachio | 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 |
| cachio | zyga, I mean, without the change to make it permissive | 11:20 |
| popey | katnip: ok, yes, when TingPing updates hexchat in the store, you'll get it | 11:21 |
| zyga | cachio: I don't think so | 11:22 |
| katnip | nice, thanks | 11:22 |
| mvo | kalikiana: hey, do you happen to know if there is a plan to support "refresh-mode" in the snapcraft.yaml json schema? | 11:23 |
| mvo | kalikiana: its a relatively new feature of snapd | 11:23 |
| pedronis | mvo: did I answer your question about test in 5004 ? | 11:31 |
| mvo | pedronis: let me quickly double check | 11:33 |
| mvo | pedronis: replied, it is indeed testing the thing I was looking for already | 11:40 |
| pedronis | thx | 11:40 |
| pedronis | looking into pawel comment atm | 11:40 |
| * Son_Goku groans into existence | 11:41 | |
| Son_Goku | 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 |
| Son_Goku | (if you were wondering why I hadn't been packaging the last few releases, that gives you an indicator of why...) | 11:43 |
| mup | PR snapd#5013 opened: cmd/snap-confine: ignore missing cgroups in snap-device-helper <Created by zyga> <https://github.com/snapcore/snapd/pull/5013> | 11:44 |
| mvo | Son_Goku: \o/ great to hear. it was the go-yaml breakage? | 11:44 |
| Son_Goku | yes | 11:44 |
| zyga | mvo: ^ trivial review | 11:44 |
| zyga | mvo: consider a .4 candidate PR | 11:45 |
| Son_Goku | 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 |
| Son_Goku | that was picked up by Koschei on April 7 | 11:45 |
| ogra_ | 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:46 |
| * cachio afk | 11:47 | |
| Son_Goku | mvo, root cause was that yaml was mispackaged (v1 had v2 and v2 had v1) | 11:47 |
| Son_Goku | * Fri Mar 30 2018 Robert-André Mauchin <zebob.m@gmail.com> - 1-22.gitcd8b52f | 11:48 |
| Son_Goku | - Fix mixed-up directories | 11:48 |
| mvo | Son_Goku: heh, ok | 11:49 |
| Son_Goku | I'm pushing new go-yaml updates to stable _now_ | 11:50 |
| Son_Goku | https://bodhi.fedoraproject.org/updates/FEDORA-2018-e05b554cb4 | 11:50 |
| Son_Goku | it should sync out in the next 12 hours | 11:50 |
| mvo | ogra_: not implemented afaict, what do you try to pass exactly? is the validation rejecting it? | 11:51 |
| Son_Goku | mvo, so we can turn CI back on for Fedora either later today or tomorrow | 11:51 |
| Son_Goku | we should also consider wiring up Fedora 28 CI | 11:51 |
| ogra_ | 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 | 11:52 |
| === pstolowski|lunch is now known as pstolowski | ||
| mvo | ogra_: yeah, we don't support this right now | 11:53 |
| ogra_ | 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:53 |
| ogra_ | i'll file a feature request on the forum ... | 11:54 |
| mborzecki | standup is at 3pm? | 11:55 |
| zyga | I think so, mvo? | 11:55 |
| mvo | zyga, mborzecki yes | 11:56 |
| mborzecki | ok | 11:56 |
| zyga | ok, I need to take the dog out, also visit the vet nearby | 11:56 |
| zyga | I may take the stand-up from my phone | 11:56 |
| mr_lou | Who will make a Snap of a Java Runtime, so other Snaps can get Java support? :-) | 11:59 |
| mr_lou | (Like VLC, to bring full Java menus to Blu-ray playback) | 12:00 |
| mborzecki | off to pick up the kids, will be back for standup | 12:05 |
| popey | ogra_: what do I have to do to get screen or tmux pre-installed on core? | 12:10 |
| popey | (screen is 560K, tmux is 345K) or so... | 12:11 |
| Chipaca | popey: bribery works | 12:17 |
| Chipaca | screen is probably more useful on core because of the serial port support (unless tmux also has it and i just don't know how to use it) | 12:18 |
| Chipaca | popey: OTOH, wouldn't a screen snap work? | 12:18 |
| popey | I suggested tmux because AIUI screen is ye olde and tmux is newer shiny | 12:18 |
| popey | would need classic which wouldn't work on core | 12:19 |
| Chipaca | why would it need classic? | 12:19 |
| Chipaca | hmm | 12:19 |
| * ogra_ never used tmux ... (i'm probably to old for that new fangled stuff :P ) ... but i'm alos wondering why a snap wouldnt work | 12:19 | |
| popey | run arbitrary binaries | 12:19 |
| popey | there is a tmux snap | 12:19 |
| popey | its classic | 12:19 |
| ogra_ | classic though | 12:19 |
| popey | hence why I'm asking | 12:19 |
| ogra_ | make a non-classic one ;) | 12:19 |
| popey | it wont work non-classic | 12:20 |
| popey | thats like saying have a bash non-classic, it would be moribund | 12:20 |
| ogra_ | screen definitely doesnt need to exec any arbitrary binaries | 12:20 |
| ogra_ | it just needs access to the tty's | 12:20 |
| Chipaca | popey: i hear ogra_ volunteering to write a non-classic screen snap | 12:21 |
| popey | screen also needs /var/run/screen to be 777 | 12:21 |
| ogra_ | haha, ayeh, in 6 months or so ... (totally swamped with customer work nowadays .. ) | 12:21 |
| popey | hah! I just copied the screen binary out of the deb and it works! | 12:22 |
| ogra_ | :) | 12:22 |
| Chipaca | popey: can it resume a session tho | 12:22 |
| popey | (it should still be built in imo) | 12:22 |
| ogra_ | nah | 12:22 |
| popey | yes | 12:22 |
| ogra_ | it should be snapped | 12:22 |
| popey | ok on it | 12:23 |
| Chipaca | popey: ogra_: probably with an ad-hoc interface | 12:23 |
| Chipaca | popey: ogra_: especially if there's a common (or common core + special for each) between screen and tmux | 12:23 |
| Chipaca | say screen uses /var/run/screen and tmux /var/run/tmux or sth | 12:23 |
| popey | I'll try screen first | 12:23 |
| Chipaca | I wonder what jdstrand thinks =) | 12:24 |
| popey | because I need something, having to use ALT+F(n) and keep logging in is getting me down | 12:24 |
| ogra_ | just patch it to use a proper $SNAP_* dir ... | 12:24 |
| ogra_ | cant be that hard | 12:24 |
| Chipaca | (tm) | 12:24 |
| pedronis | mvo: pstolowski: I updated 5004 | 12:25 |
| pstolowski | pedronis: thaks | 12:25 |
| pstolowski | *thanks | 12:25 |
| niemeyer | Hello all! | 12:27 |
| popey | niemeyer: welcome back | 12:28 |
| niemeyer | popey: Thanks! | 12:29 |
| Chipaca | niemeyer: are you really here? i thought you were conferencing this week | 12:31 |
| popeycore | \o/ offlineimap in one screen, mutt in another, cointop in another and irssi in the last \o/ Ubuntu Core "Workstation" done :D | 12:32 |
| ogra_ | yay ! | 12:32 |
| Chipaca | popeycore: sounds like you should snap bb | 12:33 |
| ogra_ | bb ? | 12:33 |
| popeycore | hehe | 12:33 |
| popeycore | or mplayer with aalib? | 12:33 |
| ogra_ | byobou ? | 12:33 |
| Chipaca | ogra_: apt show bb | 12:33 |
| pstolowski | niemeyer: hi! | 12:33 |
| pstolowski | pedronis: +1 with one question/suggestion | 12:33 |
| Chipaca | popeycore:¿por qué no los dos? | 12:34 |
| niemeyer | Chipaca: I'm really somewhat here today | 12:34 |
| niemeyer | Chipaca: Departing tomorrow | 12:34 |
| Chipaca | niemeyer: ah, ok =) | 12:34 |
| popey | alan@hal:~$ snap run screen | 12:37 |
| popey | Must be connected to a terminal. | 12:37 |
| popey | :( | 12:37 |
| Chipaca | popey: you probably got an apparmor denial there | 12:38 |
| popey | yeah | 12:38 |
| popey | one looking at /etc/shadow and one looking at /var/lib/extrausers/shadow | 12:38 |
| Chipaca | huh, that was not what i expected | 12:39 |
| ogra_ | we might need a tty interface for that | 12:39 |
| ogra_ | or a console one or whatnot | 12:39 |
| popey | jdstrand: good morning (when it's morning where you are). I am making a GNU Screen snap for core. Where should I request an interface/apparmor rules changes? :) | 12:41 |
| pedronis | pstolowski: added the logging | 12:46 |
| pstolowski | pedronis: awesome, ty! | 12:47 |
| pedronis | mvo: we want a backport of 5004 once it has landed, right? | 12:49 |
| jdstrand | popey: the forum is fine, but I would've thought you'd need classic | 12:56 |
| jdstrand | zyga: as for 5006 and 2.32-- I already requested and milestoned 5008. seems you saw that | 12:56 |
| zyga | yes, I saw that a moment after I asked | 12:56 |
| jdstrand | cool | 12:57 |
| mvo | pedronis: 5004> yes! but I can handle this as well if you want (ideally we squash the merge for easy cherry-pick) | 12:58 |
| pedronis | yes, I marked squash-merge | 12:58 |
| pedronis | marked it | 12:58 |
| mvo | ta | 12:59 |
| zyga | jdstrand: I don't know if you remember this issue: https://github.com/snapcore/snapd/pull/5013 | 12:59 |
| mup | PR #5013: cmd/snap-confine: ignore missing cgroups in snap-device-helper <Created by zyga> <https://github.com/snapcore/snapd/pull/5013> | 12:59 |
| zyga | jdstrand: we try to configure cgroups before we create them | 12:59 |
| jdstrand | I do. thanks for the PR | 13:00 |
| === mborzeck1 is now known as mborzecki | ||
| jdstrand | zyga: I approved. there is a comment suggestion to consider if you want | 13:06 |
| zyga | jdstrand: thanks you | 13:06 |
| jdstrand | zyga: fyi, for that comment: s/on start/after start/ | 13:07 |
| popey | jdstrand: there you go https://forum.snapcraft.io/t/screen-snap/4917 :) | 13:17 |
| ogra_ | popey, did you try adding and connecting account-control ? | 13:23 |
| ogra_ | might make the second denial go away | 13:23 |
| popey | yeah, but i still get the error and it's not working | 13:26 |
| BjornT_ | i'm having problems building the maas snap on bionic. it worked on friday, but today i get this error: https://pastebin.ubuntu.com/p/tSW5RrZMBd/ | 13:35 |
| seb128 | zyga, bug #1746710 is probably an issue in the desktop launcher and going to be fixed by the changes kenvandine is working on to handle real system & translated xdg dirs | 14:05 |
| mup | Bug #1746710: Snap creates redundant duplicate directories in home folder <amd64> <apport-bug> <artful> <bionic> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1746710> | 14:05 |
| jdstrand | pedronis: looking at asserts/* it seems that we do not yet support list alternations in the base declaration. Eg, this is not valid: | 14:10 |
| jdstrand | deny-auto-connection: | 14:10 |
| jdstrand | - on-classic: false | 14:10 |
| jdstrand | - plug-attributes: | 14:10 |
| jdstrand | read: all | 14:10 |
| jdstrand | pedronis: is that accurate? | 14:10 |
| pedronis | I need to look | 14:11 |
| jdstrand | well, there is a parseList... | 14:12 |
| pedronis | it seems strange, it should be supported | 14:14 |
| jdstrand | I end up seeing: | 14:14 |
| jdstrand | panic: cannot initialize the builtin base-declaration: invalid map entry key: " plug-attributes" | 14:14 |
| jdstrand | which has some weird whitespace issues.. | 14:15 |
| jdstrand | wait a sec | 14:15 |
| jdstrand | this is what I see: | 14:15 |
| jdstrand | panic: cannot initialize the builtin base-declaration: invalid map entry key: " read" | 14:15 |
| jdstrand | maybe it is just a missing left trim | 14:16 |
| pedronis | I never looked at the code that builds the base-decl from snippets | 14:16 |
| pedronis | whitespace issues seem more likey though | 14:16 |
| pedronis | because the code is the same for base-decl | 14:16 |
| pedronis | and normal decl | 14:16 |
| pedronis | and afaict they support alternation at that level | 14:16 |
| jdstrand | pedronis: ok, I did: | 14:20 |
| jdstrand | deny-auto-connection: | 14:21 |
| jdstrand | - on-classic: false | 14:21 |
| jdstrand | - plug-attributes: | 14:21 |
| jdstrand | read: all | 14:21 |
| jdstrand | pedronis: if I adjust that to: | 14:21 |
| jdstrand | deny-auto-connection: | 14:21 |
| jdstrand | - | 14:21 |
| jdstrand | on-classic: false | 14:21 |
| jdstrand | - | 14:21 |
| jdstrand | plug-attributes: | 14:21 |
| jdstrand | read: a;; | 14:22 |
| jdstrand | s/a;;/all/ | 14:22 |
| jdstrand | I get farther | 14:22 |
| pedronis | ah | 14:22 |
| pedronis | yes | 14:22 |
| pedronis | remember that syntanx is yaml (but not quite) | 14:22 |
| * jdstrand nods | 14:23 | |
| jdstrand | this is the first alternation in a base declaration | 14:23 |
| jdstrand | so I forgot about that point | 14:23 |
| pedronis | well, I forgot too | 14:24 |
| pedronis | and in the store it's JSON | 14:24 |
| pedronis | so we don't see it | 14:24 |
| * jdstrand nods | 14:24 | |
| jdstrand | pedronis: I think I'm good now. thanks! | 14:24 |
| pedronis | that's the correct synax for map inside list elem | 14:24 |
| pedronis | np | 14:24 |
| * jdstrand nods | 14:24 | |
| popey | zyga: i note you registered links. Do you fancy transferring it to snapcrafters so we can keep it up to date (yours is 2.12, latest is 2.15) | 14:25 |
| zyga | yes | 14:25 |
| zyga | popey: just tell me what to do | 14:25 |
| popey | zyga: email bret and ask to transfer the snap to snapcrafters please. | 14:26 |
| noise][ | zyga - better as a forum post, so my inbox isn't a bottleneck :) | 14:27 |
| popey | The reason I said email is because whenever I post on the forum about transferring, we end up having to send a mail to confirm email addresses | 14:28 |
| zyga | noise][: that's perfect | 14:28 |
| zyga | I'll make a thread about this now | 14:28 |
| popey | thank you! | 14:28 |
| noise][ | popey: true, but at least there are several people that can pick up the request vs emailing an individual | 14:29 |
| noise][ | at some point we'll need to make a web form on dashboard to initiate transfers | 14:29 |
| popey | ok | 14:30 |
| zyga | popey: https://forum.snapcraft.io/t/request-for-transfer-of-links-snap-to-snapcrafters/4919 | 14:31 |
| mup | PR snapd#5014 opened: overlord/snapstate: introduce envvars to control the channels for bases and prereqs <Created by pedronis> <https://github.com/snapcore/snapd/pull/5014> | 14:31 |
| pedronis | mvo: ^ | 14:32 |
| mvo | pedronis: thank you | 14:36 |
| mup | PR snapd#5015 opened: cmd/snap-confine: ignore missing cgroups in snap-device-helper (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/5015> | 14:46 |
| zyga | jdstrand: I see you noticed the thread where we discuss interface transactions | 14:47 |
| zyga | jdstrand: how do you feel about that concept in general. I think we could defer some operations and only do the costly one on "commit" | 14:49 |
| jdstrand | zyga: I gave it a heart :) | 14:57 |
| jdstrand | zyga: so, I like it. for performance, we should definitely not be recompiling the profile on each connection | 14:57 |
| jdstrand | zyga: this is going to be particularly noticeable on arm | 14:58 |
| zyga | even on intel it's noticeable when we do things for each interface connection | 14:59 |
| zyga | not once per snap | 14:59 |
| zyga | or even once per transaction involving a set of snaps | 14:59 |
| jdstrand | zyga: I know (I read the topic), but on arm it will be particularly painful | 15:00 |
| zyga | yes | 15:00 |
| Chipaca | that 'why are my fans spinning up? oh one of the cores has been at 100% for 2 minutes now running apport' moment | 15:14 |
| zyga | Chipaca: apport helps to make UK weather better by making some more winds ;-) | 15:18 |
| mup | PR snapd#5004 closed: daemon,overlord/hookstate: stop/wait for running hooks before closing the snapctl socket <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5004> | 15:21 |
| mr_lou | Can I install a 32bit version of VLC on my 64bit Ubuntu with Snap somehow? | 15:24 |
| zyga | mr_lou: no, not easily | 15:26 |
| zyga | mr_lou: is there a particular reason why you would like that? | 15:27 |
| mr_lou | zyga, Well.... wanted to try the --classic in order to let VLC be in contact with the outside world, and thus be able to utilize Java, which is needed for full Blu-ray playback (menus on Blu-ray's use Java). | 15:27 |
| mr_lou | Another option is for someone to make a Java Snap. Or at least I've heard so. | 15:28 |
| zyga | classic is not a magic bullet, it won't make a snap that doesn't anticipate that work | 15:28 |
| zyga | mr_lou: I'm afraid that that's now how things operate, there are plenty of java snaps around; what needs to happen is VLC upstream who control the VLC make that decision | 15:28 |
| mr_lou | I mean a Java Runtime Snap... a JVM. | 15:29 |
| zyga | yes, I understand what you mean | 15:29 |
| ogra_ | theoretically 32bit snaps should work on a 64bit host ... the core snap currently ships the 32bit libc alongside | 15:29 |
| zyga | mr_lou: you could make your own version of VLC that is compiled with java support, add java inside and try that | 15:29 |
| mr_lou | Oh | 15:30 |
| zyga | ogra_: yes but you cannot select a 32 bit snap if 64 bit snap is avaialable | 15:30 |
| ogra_ | (practically i'm not sure since vlc libs might call out to more than just libc) | 15:30 |
| cjwatson | On 18.04 I get a constant stream of gnome-shell notifications about apparmor denials of bits of spotify (although spotify seems to work anyway). Is this a snapd/apparmor/etc. bug or something that I should try to figure out how to report upstream? Two sample denials: | 15:30 |
| ogra_ | ah | 15:30 |
| cjwatson | type=AVC msg=audit(1523287531.978:16850): apparmor="DENIED" operation="mknod" profile="snap.spotify.spotify" name="/home/cjwatson/snap/spotify/6/.config/spotify/Users/colmmacuait-user/pending-messages.tmp" pid=21657 comm=436F726520546872656164 requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 | 15:30 |
| ogra_ | snapd limitation, k | 15:30 |
| cjwatson | type=AVC msg=audit(1523287596.759:16882): apparmor="DENIED" operation="truncate" profile="snap.spotify.spotify" name="/home/cjwatson/snap/spotify/6/.cache/spotify/Storage/index.dat" pid=21657 comm=4E6574776F726B20546872656164 requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 | 15:30 |
| zyga | truncate is interesting | 15:30 |
| zyga | we should support taht | 15:30 |
| zyga | jdstrand: ^ | 15:30 |
| cjwatson | I assume the mknod is for a pipe or something, not an actual device node | 15:30 |
| zyga | cjwatson: the mknod one is less fun, it's probably a socket | 15:30 |
| jdstrand | cjwatson: sounds like spotify got refreshed while it was running | 15:31 |
| zyga | H | 15:31 |
| zyga | ah, that's interesting | 15:31 |
| jdstrand | this is the bug | 15:31 |
| zyga | what's the revision you have now cjwatson? | 15:31 |
| jdstrand | open fds, etc | 15:31 |
| zyga | yes, it seems so | 15:31 |
| cjwatson | Ah, so it was | 15:31 |
| zyga | it's in my corner for sure | 15:31 |
| cjwatson | 810 Done 2018-04-09T14:53:59Z 2018-04-09T15:15:51Z Auto-refresh snap "spotify" | 15:31 |
| zyga | after user mount namespaces | 15:31 |
| cjwatson | rev 13 now | 15:31 |
| jdstrand | cjwatson: stop spotify and restart and it will go away. zyga has this assigned to him so hopefully 2.33 will have a fix | 15:32 |
| zyga | 2.34 more likely | 15:32 |
| zyga | 2.33 is all but ready but we need to release 2.32 that works first | 15:32 |
| jdstrand | or at least, have a way to handle this gracefully | 15:32 |
| cjwatson | jdstrand: thanks - I would never have guessed that | 15:32 |
| jdstrand | cjwatson: yeah, it is an annoying usability wart. it'll get addressed | 15:33 |
| mup | PR snapd#5015 closed: cmd/snap-confine: ignore missing cgroups in snap-device-helper (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5015> | 15:33 |
| mr_lou | zyga, Can't one Snap talk with other Snaps? If a JVM was a Snap of its own, it could be used by a lot of other Snaps? Like e.g. Android Studio too? | 15:36 |
| zyga | mr_lou: yes it can but there are specific safeguards in place. | 15:37 |
| zyga | mr_lou: the VLC snap would have to explicitly support this | 15:37 |
| zyga | mr_lou: and unless the JVM snap was from a source that was approved as a publicly available JVM snap then VLC maintainers would have to ship their own JVM snap for this purpose (at that time they could just bundle java inside VLC) | 15:38 |
| zyga | mr_lou: the goal is to avoid someone breaking lots of snaps that "depend" on the JVM | 15:38 |
| zyga | Chipaca: can I ask you for a review of https://github.com/snapcore/snapd/pull/4868 | 15:39 |
| mup | PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Squash-merge> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868> | 15:39 |
| zyga | it's got two +1s but I one is from me and I made some changes there | 15:39 |
| mup | PR snapd#5016 opened: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016> | 15:43 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/5016/files#r180139800 | 15:46 |
| mup | PR #5016: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016> | 15:46 |
| mr_lou | zyga, I see. So the best approach is to get VideoLAN to embed a JVM. | 15:47 |
| zyga | yes | 15:47 |
| === devil is now known as Guest20311 | ||
| mr_lou | zyga, Ok. Thanks. | 15:49 |
| Chipaca | zyga: sure | 15:51 |
| zyga | thanks! | 15:51 |
| Chipaca | uhhh | 15:51 |
| zyga | ? | 15:51 |
| Chipaca | in a bit though | 15:51 |
| zyga | sure, no rush :) | 15:51 |
| Chipaca | am in the middle of the refactor niemeyer asked for snapshot config to not be raw json | 15:52 |
| zyga | sure | 15:52 |
| zyga | no rush, it's not needed today | 15:52 |
| Chipaca | ah, ok | 15:52 |
| Chipaca | added to my TODO for tomorrow then | 15:52 |
| zyga | this is 2.33 material | 15:52 |
| zyga | thanks | 15:52 |
| mup | PR snapd#4977 closed: debian: add gbp.conf script to build snapd via `gbp buildpackage` <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4977> | 15:53 |
| pedronis | zyga: to be clear I would really like #5014 in 2.32.4, because otherwise the first snapd deb in bionic will also not be testable | 15:53 |
| mup | PR #5014: overlord/snapstate: introduce envvars to control the channels for bases and prereqs <Created by pedronis> <https://github.com/snapcore/snapd/pull/5014> | 15:53 |
| zyga | pedronis: +1 | 15:54 |
| zyga | pedronis: my comments about documentation were really orthogonal to the change, I think this should land | 15:54 |
| pedronis | zyga: but you didn't vote on the change | 15:54 |
| zyga | ah, indeed, I'm following notifications from GitHub and I was just reacting to the change | 15:54 |
| zyga | ok, more later | 15:57 |
| * zyga -> school | 15:57 | |
| popeycore | grrr. just had another occasion where doing "snap install" took out my entire x session | 15:57 |
| zyga | popey: snap install bullseye | 15:57 |
| mup | PR snapd#5017 opened: daemon,overlord/hookstate: stop/wait for running hooks before closing the snapctl socket (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5017> | 16:02 |
| jdstrand | zyga: wrt pr 5016 | 16:02 |
| mup | PR #5016: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016> | 16:02 |
| jdstrand | zyga: I used the same methodology that the existing browser-support uses | 16:03 |
| jdstrand | zyga: so, 'if r, ok := plug.Attrs["read"]; ok {' is supposed to see if it is there (ie, !ok returns nil, otherwise, go into the condition) | 16:04 |
| jdstrand | zyga: then '_, ok = r.(string)' checks if sees if a string | 16:04 |
| jdstrand | zyga: if it isn't or if it isn't and it isn't one of the allowed values, exit with error | 16:05 |
| jdstrand | zyga: what am I missing? | 16:05 |
| jdstrand | I don't see how 'r' is an interface{}... if it was, the testsuite would fail | 16:06 |
| jdstrand | r, ok := plug.Attrs["read"] | 16:06 |
| jdstrand | s/or if it isn't/or if it is/ | 16:07 |
| mup | PR snapcraft#2058 opened: Install python-distutils for the Python plugin on bionic <Created by bjornt> <https://github.com/snapcore/snapcraft/pull/2058> | 16:08 |
| zyga | jdstrand: What is the type of plug.Attrs | 16:09 |
| zyga | (Typing from my phone) | 16:11 |
| jdstrand | zyga: map[string]interface{} | 16:11 |
| zyga | So r must be interface{} | 16:12 |
| jdstrand | based on snap/info.go, PlugInfo | 16:12 |
| zyga | Perhaps go does the right thing | 16:12 |
| jdstrand | zyga: I mean, I'm just using what browser-support has always done | 16:12 |
| zyga | As I said I don’t know how == and != is implemented in different types | 16:12 |
| zyga | Yeah, registered that | 16:12 |
| zyga | I will check what happens after school meeting | 16:13 |
| zyga | Just wanted to point out that it may be subtly broken or cleverly correct :-) | 16:13 |
| jdstrand | zyga: I'm not a go expert yet, but my understanding was that for go json, map[string]interface{} is used to 'hold a map of strings to arbitrary data types' (see https://gobyexample.com/json), therefore, based on how the json decoding works, if it isn't there, it is null | 16:16 |
| === pstolowski is now known as pstolowski|afk | ||
| Chipaca | jdstrand: nil is typed though, fwiw | 16:18 |
| * Chipaca is probably missing context | 16:18 | |
| === nacc_ is now known as nacc | ||
| jdstrand | Chipaca: https://github.com/snapcore/snapd/pull/5016/files#r180139800 | 16:19 |
| mup | PR #5016: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016> | 16:19 |
| Chipaca | jdstrand: yeah, you need something like s, ok := r.(string) | 16:19 |
| Chipaca | jdstrand: and then s will be the string | 16:19 |
| jdstrand | Chipaca: it is the next line | 16:19 |
| pedronis | jdstrand: interface == string does the right thing though | 16:20 |
| Chipaca | jdstrand: no, i mean | 16:20 |
| Chipaca | jdstrand: you do: _, ok := r.(string) | 16:20 |
| Chipaca | jdstrand: and then in the next line you do if r == "all" | 16:20 |
| Chipaca | jdstrand: that r there is still an interface{}, not a string | 16:20 |
| Chipaca | so you can't compare it to a string | 16:21 |
| jdstrand | but it isn't | 16:21 |
| Chipaca | ? | 16:21 |
| jdstrand | it is only an interfacec{} if r, ok := plug.Attrs["read"] | 16:21 |
| jdstrand | is !ok | 16:21 |
| pedronis | Chipaca: you can | 16:21 |
| zyga | jdstrand: https://play.golang.org/p/ptO5oOH6daa | 16:21 |
| zyga | it looks ok | 16:22 |
| pedronis | A value x of non-interface type X and a value t of interface type T are comparable when values of type X are comparable and X implements T. They are equal if t's dynamic type is identical to X and t's dynamic value is equal to x. | 16:22 |
| jdstrand | I mean, I can change this, but again, why was the browser-support not an issue and why does the testsuite pass if this is wrong | 16:22 |
| zyga | yeah, | 16:22 |
| Chipaca | pedronis: !! | 16:22 |
| pedronis | basically comparing interfaces and non-interfaces does the reasonable thing | 16:22 |
| Chipaca | jdstrand: heh, if it compiles, i was wrong :-) | 16:22 |
| pedronis | (except nil is hard) | 16:22 |
| Chipaca | jdstrand: sorry for the noise then | 16:22 |
| Chipaca | jdstrand: so, about you not being a go expert yet | 16:23 |
| Chipaca | jdstrand: … :-) | 16:24 |
| pedronis | well, is a legitimate doubt | 16:24 |
| jdstrand | well, just cause I got the testsuite to pass doesn't mean I am an expert by any means! :) | 16:24 |
| pedronis | but indeed we use that in various places | 16:24 |
| pedronis | it's generally ok | 16:24 |
| pedronis | unless nil and pointers are involved | 16:25 |
| pedronis | then it's fun(tm) | 16:25 |
| pedronis | because nil of interface, and nil of pointer types are not the same | 16:25 |
| jdstrand | right. we don't compare to nil here | 16:25 |
| pedronis | and depending on return types of functions etc, is very easy to mix those up | 16:26 |
| pedronis | and it's only not only interface{}, error is also an easy one to get a mess with nil | 16:27 |
| === Guest20311 is now known as devil__ | ||
| pedronis | jdstrand: Chipaca: this illustrates the issue | 16:31 |
| pedronis | it also shows that is the source of the interface value that needs to be careful though (unless source and use are really connected/close) | 16:33 |
| cachio | niemeyer, if you could today create the secret for travis and spread should be great | 17:39 |
| niemeyer | cachio: I'm talking to cprov about Travis right now | 17:40 |
| cachio | niemeyer, great, thanks | 17:40 |
| niemeyer | cachio: This is not about spread, though | 17:40 |
| niemeyer | cachio: It's just the Travis token that for whatever reason stopped working | 17:41 |
| cachio | niemeyer, ahh, ok | 17:41 |
| niemeyer | (token for the travis API itself, that creates the request for building) | 17:42 |
| mup | PR snapd#5018 opened: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5018> | 18:26 |
| zyga | re! | 18:27 |
| * zyga is back from school | 18:27 | |
| mup | PR snapd#5013 closed: cmd/snap-confine: ignore missing cgroups in snap-device-helper <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5013> | 18:30 |
| Son_Goku | mvo, can we have https://github.com/snapcore/snapd/pull/5011 cherry-picked into 2.32? | 19:03 |
| mup | PR #5011: data/selinux: Give snapd access to more aspects of the system <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5011> | 19:03 |
| mup | PR snapcraft#2035 closed: ci: cache core and lxd to avoid redownloading <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2035> | 19:06 |
| zyga | mvo: looking | 19:08 |
| zyga | Son_Goku: yes sure | 19:08 |
| zyga | Son_Goku: do you want to make a backport or shall I quickly? | 19:09 |
| Son_Goku | zyga, also, bodhi just pushed updated golang-gopkg-yaml to master mirror: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e05b554cb4 | 19:09 |
| Son_Goku | zyga, you do it please | 19:09 |
| zyga | Son_Goku: ack | 19:09 |
| Son_Goku | I'm technically working still ;) | 19:09 |
| zyga | I will re-trigger the fedora CI PR | 19:09 |
| zyga | sure :) thank you for the fixes! | 19:09 |
| Son_Goku | np | 19:11 |
| mup | PR snapd#5019 opened: data/selinux: Give snapd access to more aspects of the system <Created by zyga> <https://github.com/snapcore/snapd/pull/5019> | 19:15 |
| zyga | Son_Goku: done | 19:15 |
| Son_Goku | awesome | 19:16 |
| kyrofa | cprov, got an error case to make you aware of, but LP isn't working right now so I'm reaching out directly | 19:49 |
| kyrofa | cprov, https://bugs.launchpad.net/snapcraft/+bug/1750177 | 19:50 |
| mup | Bug #1750177: When asking to release to a branch that's too long, a traceback is printed that gives no hints as to the source of the error. <stacktrace> <Snapcraft:New> <https://launchpad.net/bugs/1750177> | 19:50 |
| kyrofa | cprov, the error response from the store is HTML instead of json | 19:50 |
| kyrofa | (it's a 500) | 19:50 |
| cprov | kyrofa: otp, will be with you in a few. Thanks for the bug | 19:50 |
| kyrofa | cprov, sure thing. I'll add an "also effects" once LP lets me | 19:50 |
| cprov | kyrofa: oh, timeout error, wow | 19:52 |
| kyrofa | Yeah | 19:52 |
| kyrofa | cprov, if I print the entire error response from the store, will that include anything particularly sensitive? | 20:04 |
| kyrofa | Right now, when someone logs a bug, even if they run in debug mode we have no clue what the store handed them. I'd like to print the response in debug mode | 20:05 |
| cprov | kyrofa: no, it's a internal server error page, I suppose, nothing sensitive or useful (tbh) | 20:05 |
| kyrofa | cprov, I mean for ALL errors | 20:05 |
| cprov | kyrofa: I don't think we should do that, we can land fixes to prevent non-API errors then snapcraft failing to interpret that should bail | 20:07 |
| cprov | printing bad responses is as bad and printing traceback, isn't it ? | 20:07 |
| kyrofa | cprov, we traceback in debug mode as well | 20:08 |
| kyrofa | cprov, the primary experience (non debug mode) should be clean, of course | 20:08 |
| kyrofa | cprov, bug when someone logs a bug, I want to see the response we barfed on | 20:08 |
| kyrofa | Otherwise I have to try and duplicate it, and that's not always possible | 20:08 |
| cprov | kyrofa: it's not that terrible if it's only printed in debug mode | 20:10 |
| cprov | kyrofa: we have the error context logged server-side | 20:11 |
| kyrofa | cprov, okay, so error responses shouldn't include anything overly sensitive? | 20:11 |
| pedronis | jdstrand: Chipaca: seems I wanted to link to an example (about nil and interfaces) but didn't: I meant to share this: https://play.golang.org/p/0CGDjdMtcIS | 20:35 |
| jdstrand | pedronis: heh, I was wondering :) | 20:39 |
| jdstrand | roadmr: hi! fyi, https://bugs.launchpad.net/snapstore/+bug/1762544 | 20:39 |
| jdstrand | roadmr: I decided to enable the resquashfs sooner than later in the review tools in light of the upcoming sprint | 20:39 |
| roadmr | jdstrand: oy! let's see | 20:40 |
| jdstrand | ratliff: fyi, ^ | 20:41 |
| mup | PR snapcraft#2059 opened: storeapi: handle 500 error response when releasing snap <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2059> | 20:43 |
| pedronis | zyga: cachio: 2.32 is still configured to use mainly linode for tests and things don't seem to b working great there | 20:50 |
| j1mc | hi snappy people . . . is there a way to clear previous versions of an installed snap (other than uninstalling and re-installing the snap)? i've had three versions updates of the 'hugo' binary, and now have three loop mounted squashfs filesystems. | 20:51 |
| roadmr | jdstrand: so what happens now if I set SNAP_ENFORCE_RESQUASHFS=0? no change in behavior? | 20:51 |
| roadmr | (now == with the tools currently in the store, r1018 IIRC) | 20:51 |
| j1mc | that particular setup messes with commands like "lsblk" | 20:52 |
| jdstrand | roadmr: it will go back to how it acts today | 20:53 |
| jdstrand | roadmr: well, wait. if you do that *today* without 1021, it will actually turn on enforcement since the previous envvar check was dumb (only checked if SNAP_ENFORCE_RESQUASHFS was set) | 20:54 |
| jdstrand | roadmr: so, the feature flag should accompany r1021 | 20:54 |
| roadmr | jdstrand: OHH! yes, that's what I wanted to know | 20:54 |
| roadmr | jdstrand: ok hm... this'll let me reason about the logic I need to implement. I'd love to have the feature flag ready *before* rolling out r1021 but if they go out together that could also work | 20:55 |
| j1mc | i understand that the prior versions are in place to allow reverting to prior versions, but want to see if i can limit the number of prior versions / limit the number of prior loop-mounted snap / squashfs filesystems | 20:56 |
| jdstrand | roadmr: if you want, I can revert 1021, fix the env var check, then you can pull that revision. then add back the flipped logic | 20:56 |
| pedronis | j1mc: the limit is 3 (and at the moment is not configurable), there's also been some discussion to really mount only the last (at least for normal snaps) | 20:57 |
| Chipaca | j1mc: you can 'snap remove --revision=<an old one> yoursnap' to remove one of the old ones | 20:57 |
| j1mc | pedronis: thank you | 20:57 |
| Chipaca | j1mc: you can get the revision number from 'snap list --all yoursnap' | 20:58 |
| jdstrand | j1mc: you can't today. you might want to add your thoughts to https://forum.snapcraft.io/t/all-revisions-of-snaps-are-mounted-when-they-dont-need-to-be/2294 | 20:58 |
| jdstrand | and you can workaround as Chipaca mentioned | 20:58 |
| jdstrand | roadmr: shall I do that? | 20:58 |
| j1mc | thank you both | 20:59 |
| roadmr | jdstrand: was thinking... yes, that'd be great (i.e. if regardless of default behavior, they respond correctly to the env var being either =0 (off) or =1 (on), otherwise I don't have a way to preemptively add the feature flag | 20:59 |
| jdstrand | ok. I'll update the bug when I do that. should just be a few minutes | 21:00 |
| roadmr | jdstrand: the chances of a borked review-tools *and* a borked feature flag in the same rollout are slim but I'd prefer to be cautious | 21:00 |
| roadmr | many thanks | 21:00 |
| jdstrand | roadmr: ok, done. I updated the description to say r1022 has the default enforcement, and then added https://bugs.launchpad.net/snapstore/+bug/1762544/comments/1 | 21:28 |
| roadmr | jdstrand: gotcha! | 21:29 |
| roadmr | jdstrand: so am I clear to add r1021 to the store queue? no behavioral change wrt resquashing vs. what I have now? | 21:29 |
| jdstrand | roadmr: correct. please pull r1021 | 21:30 |
| roadmr | ok, incoming! | 21:30 |
| jdstrand | roadmr: thanks! | 21:31 |
| sergiusens | stgraber: hey, any reason why lxd on 2.0/stable is still 2.0.11? | 21:34 |
| cachio | pedronis, yes, we should port all the google changes to 2.32.x | 21:39 |
| cachio | I think we started moving to google after 2.32 was sent to beta | 21:39 |
| * cachio afk | 21:39 | |
| JonelethIrenicus | any steam snaps | 22:07 |
| stgraber | sergiusens: yes, because that's the latest 2.0.x stable release | 22:18 |
| sergiusens | stgraber: am I stuck and out of luck to use 2.21? | 22:20 |
| sergiusens | or is that an unsupported release? | 22:21 |
| stgraber | sergiusens: 2.21 is unsupported | 22:22 |
| stgraber | it's a feature release, we support those until the next one, which is out now (3.0) | 22:23 |
| stgraber | if they're in an Ubuntu release, then we will do security updates as required for that Ubuntu release, but that's the extend of what we do on a non-LTS release of LXD | 22:23 |
| kyrofa | stgraber, .0 are LTS releases? | 22:23 |
| stgraber | kyrofa: major bumps are LTS releaes, yes. 1.0.x, 2.0.x, 3.0.x | 22:24 |
| kyrofa | Gotcha | 22:24 |
| sergiusens | stgraber: ok, so is it going into backports? Just wondering as autopkgtest use 2.21. Aside from that, is there a migration guide to move from 2.0 to 3.0? Or anything in particular to take into account? | 22:26 |
| stgraber | sergiusens: it will, yes | 22:28 |
| kyrofa | stgraber, quick sidebar: I can't seem to be able to run snaps within nested containers, is that a known issue? | 22:29 |
| stgraber | kyrofa: snaps inside nested containers can't work because apparmor only allows for one level of nesting, so snapd in nested containers won't be able to load apparmor policies | 22:29 |
| mcphail_ | popey: o/ | 22:29 |
| kyrofa | Okay, that sounds familiar | 22:30 |
| stgraber | sergiusens: 2.0 to 2.21 and 2.0 to 3.0 is pretty much the same thing, there's no manual upgrade stage, the upgrade is handled for you. API is backward compatible so no API breakage. The CLI has a few changes but it's not considered API for us (though we obviously try to limit potential breakages to major releases as was done here) | 22:30 |
| sergiusens | stgraber: last time we talked you told me the REST API was more of internal thing and to stick to the CLI :-) I'll work out the quirks if it is not much | 22:31 |
| kyrofa | stgraber, looks like Sergio had some network issues, but yeah-- we were under the impression the the REST API was unstable, so we used the CLI instead. Is that not true? | 22:33 |
| stgraber | kyrofa: very much the other way around, API is only ever extended, things are never removed from it, same isn't guaranteed with CLI | 22:34 |
| kyrofa | Seems we got our wires crossed somewhere, then-- we'll have to rethink that, thank you | 22:34 |
| popey | mcphail: yay | 23:04 |
| diddledan | why are the desktop parts taking forever to pull these days?! | 23:50 |
| diddledan | s/pull/preparing to build/ | 23:51 |
| diddledan | i.e. what has changed recently that makes them take forever to do nothing? | 23:51 |
| kyrofa | diddledan, "preparing to build" just unpacks stage-packages | 23:52 |
| kyrofa | Perhaps more were added? | 23:52 |
| diddledan | so why does it take forever? | 23:52 |
| diddledan | https://usercontent.irccloud-cdn.com/file/8tUnpecv/image.png | 23:52 |
| diddledan | it's been sat there for ages. other parts don't do that. it is specific to the desktop parts | 23:52 |
| kyrofa | No idea | 23:53 |
| kyrofa | Well, desktop parts do tend to have a large number of stage-packages | 23:53 |
| kyrofa | But that's all I've got | 23:53 |
| diddledan | it's new behaviour tho | 23:53 |
| diddledan | something has changed | 23:53 |
| kyrofa | Try running in debug mode, see if that gives you anything different | 23:54 |
| diddledan | perhaps it's the extra checks for executable stacks et al?? | 23:57 |
| kyrofa | I don't believe that stuff happens until prime | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
