[04:52] PR snapd#8260 opened: tests: enable nested on core20 and test current branch [08:03] morning [08:46] PR snapd#8257 closed: tests: backport master test fixes [08:50] PR snapd#8241 closed: interfaces: work around apparmor_parser slowness affecting uio

[08:55] PR snapd#8261 opened: interfaces: work around apparmor_parser slowness affecting uio (2.44) [08:58] pstolowski: hi, I asked a question in #8235 [08:58] PR #8235: cmd/snap-preseed: handle --reset flag

[08:59] pedronis: yes, i saw it, thanks, will get to it soon [09:13] PR snapd#8255 closed: cmd/snap: make the portal-info command search for the network-status interface [09:20] pstolowski: can you look at #8248 if you have a moment, is not super urgent, OTOH is small [09:20] PR #8248: snap: introduce Container.RandomAccessFile [09:20] ok [09:21] also it relates (indirectly) to UC20 needs [09:24] PR snapd#8003 closed: o/ifacestate, api: implementation of snap disconnect --forget [09:26] pstolowski: thanks for landing that ^ [09:27] i'm equally happy about landing it finnaly === epod is now known as luk3yx [10:29] pstolowski: thansk for checking, we might do something also about fonts, but maybe we don't see changes because there are not fonts in the image? [10:29] pedronis: checking [10:36] pstolowski: ah, no, on ubuntu the cache for those is in var (it's in usr for some other distros) [10:36] yes, that's right [10:36] pstolowski: it's /var/cache/fontconfig but I'm not even sure we need to undo if we do something there, or whether we can [10:37] it's a cache and it's not just touched by snapd [10:39] pedronis: that's right. i don't think re-running fc-cache makes any sense [10:39] pstolowski: yea, agreed [10:39] / so yeah, spread test picked change to /usr.../completions [10:40] yes, that we need to fix [10:40] thanks for checking as I said [10:40] yep, on it [10:45] * zyga waves [10:45] everyone at home but me has a stomach bug [10:45] I suspect I got "lucky" because first symptoms started before I returned from Fra [10:46] so I may be off early next week as well, depending on how the situation develops [10:46] zyga: ironic..\ [10:46] right? [11:03] Hi, squashfs is read only. We are trying to make gluu snap package. As our previous experience showed that we may change any file in the snap for security or bug fixes. [11:03] Currently we trying to figure out any file/directory that gluu services want to write. [11:03] But this won't be enough for us. We may need to edit/replace any file inside the snap [11:04] We are using containers and everything is writable, when we switch to snap it will be read only [11:04] alvesadrian: that's pretty hard to do [11:04] alvesadrian: can you just ship a new snap revision? [11:04] alvesadrian: everyone will update anyway [11:04] snap reivsion? [11:04] wharts that? [11:04] alvesadrian: if you make a snap you get a blob which is the squashfs filesystem [11:05] alvesadrian: instead of making changes to the files at runtime (application files, not data) you can just make another blob [11:05] alvesadrian: and put that to the store [11:05] alvesadrian: delta downloads should be fast and efficient [11:05] alvesadrian: so instead of shipping a snap with a self-update mechanism [11:05] alvesadrian: just upload subsequent revisions of the snap [11:06] we still playing we dont have a full app ready [11:06] we found this squashfs issue [11:06] and we are not sure how to sort it [11:06] for writeable files [11:06] alvesadrian: my advice: disable the self-update [11:06] we dont even finish to build the app [11:06] alvesadrian: and let snapd handle that aspect [11:10] alvesadrian: how are you building the app? [11:10] zyga snapcrft command [11:11] alvesadrian: when you said "we dont even finish to build the app" does that mean you still are in progress of working on the packaging? [11:12] we are playing with parts of our big app [11:12] is a java app [11:12] I see [11:12] we are using parts to packafe it and see how it works [11:12] just a war file [11:12] with jetty [11:14] @zyga one momment a coworker is comming online [11:14] with more details [11:14] zyga : ^^^^^ [11:14] alvesadrian: I'm off today, just helping while I'm in the office [11:14] one moment [11:14] alvesadrian: I'm afraid I won't be around much longer [11:14] please [11:14] sure, [11:15] just saying I can respond more slowly [11:16] slvn_ mustafa is that u? [11:17] damn [11:26] zyga this is mbaser my co worker [11:26] zyga he has some concerns [11:26] zyga can u help us? [11:27] zyga can he ask u a few things? [11:27] zyga are you still around? [11:27] mbaser drop ur concern to zyga [11:29] just ask the questions please [11:30] mbaser are u reding us? [11:30] reading us? [11:30] perhaps forum.snapcraft.io might be easier? [11:32] zyga no worries we can back later [11:32] zyga he is having some connection issues [11:32] sure [11:32] thanks [11:32] I'm online 24/7 but not always reading [11:33] so try asking your questions and just check for answers later [11:33] the forum is easier to use [11:33] and better for asynchronous conversations [12:42] pstolowski: I made a comment in #8217 [12:42] PR #8217: o/devicestate: delay the creation of mark-seeded task until asserts are loaded [12:42] pedronis: ty. updated #8235 [12:42] PR #8235: cmd/snap-preseed: handle --reset flag

[12:55] pstolowski: thx, made a comment about the helper you are using there, it's actually a bit odd [12:59] pedronis: by that you mean to fix the helper to literally match on "snapd/complete.sh" right? [12:59] pstolowski: to match that the end of target is like that, yes [13:00] ok, makes sense [13:00] I mean /snapd/complete.sh [13:00] really [13:00] right [13:00] I don't know why the helper is like that [13:00] is used in a couple of places [13:00] but haven't closely at them [13:00] indeed, it's a bit naive [13:00] but I looked at the helper in dirs that makes the targets [13:01] and afaict they will always have snapd in them [13:02] PR snapd#8248 closed: snap: introduce Container.RandomAccessFile [13:07] cmatsuoka: thank for merging that [13:08] pedronis: thanks for the patch, that should help moving secboot ahead [13:08] we'll need it for our own cross checking bits as well I think [13:13] PR snapcraft#2972 opened: [rfc] catkin plugins: remove bash workaround for old catkin bug [13:31] PR snapcraft#2970 closed: providers: match build provider flag keys to envvar [15:11] cmatsuoka: I made a maybe annoying comment in #8159, I'm just a bit unsure why we need more passes on things [15:11] PR #8159: snap-bootstrap: remove created partitions on reinstall [15:13] pedronis: thanks, I'll check that right after lunch [15:13] cmatsuoka: let me know if you have questions [15:45] pedronis: search v2 is in production [16:01] PR snapcraft#2973 opened: specifications: add core20 plugin specification [16:06] PR snapd#8262 opened: interfaces/udisks2: also allow Introspection on /org/freedesktop/UDisks/** [16:43] PR snapd#8263 opened: interfaces/udisks2: also allow Introspection on /org/freedesktop/UDisks2/** - 2.44 [17:31] when I do snapcraft snap, would environment variables I set in my shell propagate to override-build: section in the snapcraft.yaml ? [17:36] thresh, well if you use override-build you can just export variables as part of that. otherwise you can use build-environment (see https://snapcraft.io/docs/parts-environment-variables) [17:37] ackk, I probably need to add some more context. I export some variables in the CI that I would like to check when I'm doing snapcraft snap (inside the yaml, so inside the override-build). [17:38] I guess my question is "does snapcraft snap sanitize env(1) when doing the builds?" [17:39] thresh, AFAIK it does [17:39] there's only one way to check. (which I'm doing right now) :-) [17:53] ok, I think it actually works and the variable is there [17:53] as in I can see it in "env" output when doing the build [18:21] thresh: if you are in --destructive-mode or not using bases, the env should make it through [19:08] PR snapcraft#2973 closed: specifications: add core20 plugin specification [19:26] PR snapcraft#2960 closed: specification: base plugin and plugins for core20 [19:38] sergiusens, I'm not using destructive mode, and my snapcraft.yaml has base: core18; env makes it through [19:39] so, eh. I'm on snapcraft 2.43.1+18.04 (from .deb) [20:12] thresh: oh, so no real support for bases then, environment should just passthrough [20:13] sergiusens, will it change when I upgrade? [20:13] I'm building inside (a somewhat outdated) 18.04 non-privileged docker container. [21:14] PR snapcraft#2974 opened: project_loader: use -isystem instead of -I for system include paths [21:47] thresh: if you are not using a base (in snapcraft.yaml), then I would recommend 16.04 as the container [21:48] thresh: this might help with what bases are https://snapcraft.io/docs/base-snaps (but you need snapcraft 3.x) [21:49] thresh: and docs on snapcraft 3.x with docker https://snapcraft.io/docs/build-on-docker