[00:53] cjwatson: sergiusens: Okay, so it seems the root difference is in ordering of the parts. For whatever reason on the builders the remote parts run first, while in my cleanbuild they run last. I copied the remote part and hardcoded its order, and things seem good now. [00:54] FWIW, only having single direction ordering made me have to copy. Where if I could have put a "before" in I could have achieved the result without the copy. [00:54] Probably not worth the work to add to snapcraft. [01:37] tedg: Glad you got it sorted out [01:39] cjwatson: thanks for the help, I was sure stuck! [04:32] PR snapcraft#1877 opened: tests: move test files out of the snapcraft dir [04:57] tedg so strange as we load everything into an OrderedDict (I haven't read through the full thread) [06:15] morning [07:21] Bug #1638537 changed: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 [07:24] Bug #1611638 changed: snap upgrade hook [07:30] Bug #1637325 changed: snapd provides no way to register a new account [07:33] o/ [07:33] mborzecki: some snow :) [07:33] zyga-ubuntu: mvo: morning [07:34] zyga-ubuntu: yeah, though it'll probably be gone in a matter of days [07:34] damn i hope it will be gone [07:35] otoh, at least driving a car if fun again :) [07:36] mborzecki: good morning! and good morning to zyga-ubuntu [07:38] PR snapd#4498 opened: debian/tests: add missing autopkgtest test dependencies for debian [07:40] good morning mvo :) === cpaelzer_ is now known as cpaelzer [07:42] Bug #1673539 changed: snapd doesn't clean up imported (snap) assertions [07:45] PR snapd#4499 opened: packaging/14.04: move linux-generic-lts-xenial to recommends [07:59] mborzecki: can you please do a 2nd review on 4495 [07:59] I provided some context that should make it easier [08:05] jdstrand: good morning [08:05] jdstrand: can you please have a loot at 4495 as well, it's based on your suggestion [08:06] morning! [08:07] o/ [08:08] pstolowski: hey [08:09] PR snapd#4493 closed: image: port ini handling to goconfigparser [08:10] mborzecki: 4492 can be rebased now, it should land ok [08:11] doing that right now [08:11] and pushed [08:13] thanks, I'm mid rebase myself so didn't want to do that [08:16] quick brainstorm: what would be a better sentence for "No snaps to auto-refresh found" apparently someone reads this as "my snaps cannot be auto-refreshed". but we want something like convey: "No new snap revisions to auto-refresh to found" - any ideas about a good sentence for this? [08:16] mvo: "all snaps are up-to-date" [08:16] mvo: "snap foo is already up-to-date" [08:16] mvo: "snaps foo, bar and froz are already up-to-date" [08:17] zyga-ubuntu: "auto-refresh: all snaps are up-to-date" ? [08:17] mvo: sounds good [08:17] mvo: +1 [08:17] thanks! [08:17] if you need the prefix for some reason, I think it's hard to misunderstand that "all up to date" message [08:17] mborzecki: if you run "snap version" on arch, do you get correct output? [08:18] zyga-ubuntu: its in the logs, this is why I think the prefix is since, to give context to the log message [08:18] snap 2.30.r545.g0d212818e-1 [08:18] snapd 2.30.r545.g0d212818e-1 [08:18] series 16 [08:18] arch [08:18] mborzecki: ta [08:18] kernel 4.14.13-1-ARCH [08:18] snap 2.30.r545.g0d212818e-1 [08:18] snapd 2.30.r545.g0d212818e-1 [08:18] series 16 [08:18] mvo: ah, I ee [08:18] arch [08:18] kernel 4.14.13-1-ARCH [08:18] *see [08:18] snap 2.30.r545.g0d212818e-1 [08:18] snapd 2.30.r545.g0d212818e-1 [08:18] series 16 [08:18] arch [08:18] kernel 4.14.13-1-ARCH [08:18] snap 2.30.r545.g0d212818e-1 [08:18] snapd 2.30.r545.g0d212818e-1 [08:18] series 16 [08:18] arch [08:18] kernel 4.14.13-1-ARCH [08:18] pff [08:18] glowing bear :/ [08:18] uff :) [08:18] heheheh [08:19] "once more with feeling" [08:20] PR snapd#4500 opened: snapstate: make no autorefresh message clearer [08:21] good(?) morning [08:22] kalikiana: hey, are you saying that good may be NULL? [08:22] kalikiana: it's snowing heavily here :) [08:22] * kalikiana still deciding if fit for work [08:23] Heh, yeah, good might be undefined [08:24] oh, digitalocean has updated their prices, there are much better droplet configurations for the same price available! [08:26] * zyga-ubuntu looks at wind blowing heavy snowfall [08:30] hey spineau [08:30] how are you doing? long time no see :) [08:31] hi zyga-ubuntu [08:31] very well, thx [08:32] zyga-ubuntu: and you, are you missing Spain those days ;) ? [08:34] zyga-ubuntu: DO adjusting their prices after meltdown/spectre? [08:39] spineau: some of us here are :-) [08:39] spineau: my daugther prefers Poland, my son prefers Spain [08:40] spineau: I miss the constant sunshine and good mood [08:40] mborzecki: they give x2 more for the same price [08:40] mborzecki: and some new features too, like spaces (kind of like volumes but not really), super cheap [08:41] zyga-ubuntu: sun helps, I miss it too since my recent move to French east border. I'm now very close to Switzerland [08:42] it's a drastic weather change, especially in January [08:42] spineau: oh, that's harsh, why did you move? [08:42] zyga-ubuntu: my wife's new job [08:42] spineau: I see, well [08:42] do you see any mountains or hills? :) [08:42] little hills :) [08:42] that's one of the things I miss as well, Poland is too flat for my taste [08:43] in Spain we could drive for 30 minutes and be at the base of serious mountains :) [08:43] Spain rocks, definitely [08:43] or go north for a little longer and have all the mountains and snow we'd ever need [08:43] well [08:43] maybe for holidays :) [08:44] hehe, it was good to hear some news from you. [08:44] ttl [08:44] same :) [09:06] PR snapd#4501 opened: configcore: ensure config.txt has a final newline [09:09] zyga-ubuntu: do we need a jamie review for 4329? [09:09] mvo: I think so [09:09] we need a formal one [09:09] he looked at it before [09:09] but I'd rather wait [09:10] zyga-ubuntu: ok [09:13] mvo: trying out the strace build and have some trouble with it, --strace no longer works [09:15] mvo: looks like the actual strace output was filtered out too [09:16] kalikiana hey, feeling better today? [09:16] mborzecki: uh, the first of the strace PRs? [09:17] hey sergiusens [09:17] mvo: #4491 [09:17] PR #4491: snap: allow options for --strace, e.g. `snap run --strace="-tt"` [09:17] mvo: looks like the 2nd strace loop filters everything out [09:18] sergiusens: Yeah, better so far [09:18] mborzecki: can you please apply https://paste.ubuntu.com/26403283/ [09:18] mborzecki: and pastebin the output? [09:18] mborzecki: did you add any specific option? [09:18] mvo: i have this diff http://paste.ubuntu.com/26403285/ and the log http://paste.ubuntu.com/26403287/ [09:19] * mvo looks [09:20] mborzecki: do you use /snap on your distro as prefix? [09:20] mborzecki: still filtering 2: "[pid 6906] execve(\"/snap/hello-world/27/bin/echo\", [\"/snap/hello-world/27/bin/echo\"], 0xc8200b4a00 /* 73 vars */ \n" is the line I see - but *maybe* thats the issue [09:21] mborzecki: i.e. that inside the snap env it is always /snap not dirs.SnapMountDir [09:21] mvo: inside the env it's always /snap [09:21] mvo: *except for classic [09:21] on any distro [09:21] mborzecki: you found a bug [09:21] yeah, looks like it ;) [09:21] sorry [09:22] mborzecki: haha, the opposite, you should be proud! [09:22] mborzecki: fixing, thank you! [09:22] mvo: yw [09:35] uh [09:35] thereare 4 CVEs on irssi [09:36] mborzecki: could you please "git pull; git checkout naive-strace" and see if the last commit fixes the issue? [09:38] mborzecki: ups, sorry, of course git fetch mvo5 etc [09:44] mvo: works now [09:47] mvo: and classic works too [09:51] Issue snapcraft#1876 closed: Cleanbuild doesn't work with SSH based Git repos [09:59] zyga-ubuntu: re 4495> added [10:00] jdstrand: thank you! [10:00] zyga-ubuntu: btw, I was looking at an unsupported distro for something unrelated and snapd is running. I installed a snap and was able to run hello-world on first invocation [10:00] jdstrand: nice :-) [10:01] zyga-ubuntu: but on second invocation, the mnt file in /run/snapd/ns is empty [10:01] oh [10:01] it got unmounted? [10:01] zyga-ubuntu: so the machinery tries to move into that namespace but fails [10:01] I don't know yet [10:02] my question is if this rings any bells on where to look. it is a 4.9 kernel if that helps [10:02] zyga-ubuntu: snap-discard-ns resolves the issue (of course) [10:02] jdstrand: what was the exact error message? [10:02] mborzecki: yay, thanks for double checking [10:02] jdstrand: there are several places where we want to jump into a namespace [10:03] jdstrand: and they should all handle this well [10:03] jdstrand: it doesn't ring any bells on first thought yet [10:03] zyga-ubuntu: unfortunately, I didn't write it down and it isn't at hand. I'll see if I can get more detail [10:04] jdstrand: if you give me the distro I can look [10:04] zyga-ubuntu: I don't really want to distract you, but it sorta sounded familiar to some old issues, but they've been long resolved so nothing came to mind otoh either [10:06] jdstrand: so, on 1st try it just constructs [10:06] jdstrand: on 2nd try it will inspect it (even if the outcome is unused today) [10:06] right [10:08] there was enough info that 'file' showed it was empty, which I thought was odd. but now looking at my 17.10 system, file shows them as empty, so file probably isn't dtrt [10:08] ok, I need to play more. thanks [10:23] jdstrand: yes, they are always empty [10:23] jdstrand: you want to "stat -f" them [10:32] PR snapd#4068 closed: interfaces/builtin: add support for content "source" section [10:32] not really here but https://travis-ci.org/snapcore/snapd/builds/329545603?utm_source=github_status&utm_medium=notification is very strange, there seems to be two runs in the log there [10:41] zyga-ubuntu: ah right. I forgot I needed to use stat on those [10:42] mborzecki: thanks for your feedback, I addressed your points for naive-strace-opts (which is not that naive anymore actually ;) [10:50] mborzecki, pstolowski: can you please look at 4502 [10:50] PR snapd#4502 opened: interfaces/builtin: add support for content "source" section (v2) [10:50] kk [10:50] pstolowski: for attribute / slot / plug usage (I think ok but just in case) [10:50] mborzecki: as a iteration of closed 4068 [10:51] looking [10:58] * zyga-ubuntu -> small break [11:01] actually, maybe in 15 minutes [11:04] can I somehow refresh from a "local" snap to a store one without purging data for the snap? I often have to move between a store snap and a local one for development and purging hundreds of megs of data every time is :( [11:05] Saviq: that's mvo's snap refresh --amend branch [11:05] with new name coming for amend [11:06] aha, glad it's coming [11:07] zyga-ubuntu: reviewed 4502, not sure about MountEntries() [11:09] mborzecki: good catch, it should be used in mount/backend.go but itsn't [11:09] mborzecki: i will fix that [11:09] great :) [11:09] mborzecki: I don't think the code should be in add mount entries, it may be needed to push it back even more to the backend [11:09] we'll see [11:10] this code didn't run with spread yet (it depends on other parts) so it's likely something is lurking [11:10] zyga-ubuntu: while at it, consider putting it into a helper func [11:10] mborzecki: declash? [11:10] this, in a clean xenial amd64 chroot this morning: https://pastebin.ubuntu.com/26403870/ [11:10] sergiusens: ^ [11:10] zyga-ubuntu: yeah [11:10] kalikiana: ^ [11:11] kyrofa: ^ [11:11] ok, I'll think [11:11] zyga-ubuntu: if you happen to move the declash into a place where snap names are known, it'd be great to log them [11:14] ppisati: you should be running from a python virtual env [11:14] is that the case? [11:14] kalikiana: let me try [11:14] hi does anyone know whether it would be possible to create a snap for this game? http://zod.sourceforge.net/ [11:14] ppisati: https://github.com/snapcore/snapcraft/blob/master/HACKING.md [11:15] Chipaca: does "src/github.com/snapcore/snapd/osutil/sys/sysnum_32.go:26:25: error: reference to undefined identifier ‘syscall.SYS_GETUID32’" ring any bells? build failure on powerpc on xenial [11:17] hi sergiusens. when the build servers are fully up and running again would it be ok if i ask you to keep https://bugs.launchpad.net/snapcraft/+bug/1718245 in mind? it would be great to get svn repos working [11:17] Bug #1718245: svn source-type not honoring proxies [11:18] mvo: iirc it was added for 32bit systems where they use SYS_GETUID32 instead of SYS_GETEUID on 64bit [11:19] mborzecki: ok, I think we need to do something about this if it is not defined [11:26] * kalikiana tea break, brb [11:43] sergiusens: Can I find you and get a few minutes of your time when you have a minute? [11:52] cory_fu where are you? [11:54] * zyga-ubuntu goes out [11:56] sergiusens: I'm in Hudson right now. I can meet in the plenary [11:58] cory_fu that's where I am, come over :-) [11:58] Hudson is freezing iirc :-) [12:11] * pstolowski lunch [12:24] Chipaca: fwiw, I poked a bit at the powerpc issue and my feeling is that for gccgo (powerpc) we need a different approach for osutil/sys/syscall.go. slightly sad but there seems to be no syscall.SYS_GETPID32 - I poke a bit more after lunch [12:27] Chipaca: but there is syscall.SYS_GETPID so maybe we need to make do with that. anyway, after lunch [12:29] sergiusens: In the original case there was no specified ordering between the parts, so I imagine they ended up in the map effectively randomly? [12:35] jdstrand: question for you: I'm snapping chromium-on-XWayland, to run with the mir-kiosk snap. I'm hitting issue with confinement where XWayland wants ability to bind sockets. Would adding that to the wayland interface be a bit much? [12:37] else I'll change tack and have mir-kiosk implement the x11 interface, and have XWayland in there instead. I'm less enthusiastic about this option due to X being harder to secure [12:43] mvo: remind me, is powerpc 32 bits? [12:44] greyback: does simply plugging the x11 interface not work? [12:45] greyback: if not, can you show me the denials? [12:45] greyback: note, I'm at a sprint and may be laggy. don't hesitate to ping me if I don't respond [12:45] jdstrand: ack. I'll try and let you know [12:46] greyback: we can look at the denials, but I consider Xwayland a special X server [12:47] so x11 seems like the first thing to at least think about if things are broken [12:53] * kalikiana going for lunch in a few and taking a break from fighting tar [12:56] re [12:56] Chipaca: yes [12:57] jdstrand: adding x11 plug doesn't help, as core has no x11 slot I can connect it to. x11 is classic only. It seems like a pity to expose that x11 is being used at all, ideally it is an internal implementation detail of the chromium snap [12:57] zyga-ubuntu: thanks [12:57] ah [12:57] Unable to process SAML login request [12:57] hmmm [12:57] this is me trying to open the calendar [12:58] jdstrand: denials & interfaces: https://pastebin.ubuntu.com/26404327/ [12:58] hmm, worked now [12:59] greyback: ah right. so if your snap provides xwayland, then (conceptually) it should 'slots: [ x11 ]', which would mean doing for the x11 interface what you did for the wayland. that said, let me look at your paste [12:59] jdstrand: the snap provides wayland, yes, but not in a way that other snaps should be able to conenct to. It shoud be exclusively for chromium (also in the snap) [13:00] s/wayland/xwayland/ [13:00] yeah, so that unix socket is exactly what is in the plugs of the x11 [13:00] right [13:00] PR snapd#4448 closed: Add rules for Media API to the BlueZ D-Bus policy [13:00] the shm denial is different [13:00] (though we need to handle it) [13:00] I've tried redirecting /dev/shm to /dev/shm/$SNAP.** with LD_PRELOAD, not had success yet [13:01] greyback: can you expand on 'exclusively for chromium'? [13:01] Chipaca: it is [13:02] greyback: I don't think that will work. that is the special mir socket from mirPermanentSlotAppArmor [13:02] (I think) [13:03] which, iirc, is a special kernel file that you can't adjust the path on [13:03] it just happens to show up as a regular file rule. Ideally we would have shm mediation that would handle that better. anyway... [13:04] jdstrand: sure. Desire is for single chromium snap to run on mir-kiosk. Chromium's wayland support is broken, so XWayland is needed. So I thought it sensible to have XWayland inside the Chromium snap, which exclusively Chromium can connect to with the X protocol. Xwayland then talks to mir's wayland interface. So from the outside you woudn't know/care xwaylad was involved at all [13:04] oh I see [13:05] greyback: I have to attend a meeting. let me ponder this. I may be laggy [13:05] blocker is that xwayland needs a socket for chromium to connect to, which seccomp isn't allowing [13:05] since most gui apps don't want that [13:05] jdstrand: no worries, please chew it over [13:06] in the mean time I'll see how terrible it is to have mir-kiosk implement the x11 slot itself [13:21] ok, actualy working this way is not too bad [13:22] I'm mounted via sshfs to my desktop and I can keep working on the same files :) [13:24] zyga-ubuntu, trying to join but no power at home [13:24] cachio_: we've finished now, no worries [13:24] cachio_: is everything ok? [13:25] zyga-ubuntu, yes, but electricity has gone during the night in all the neighborhood [13:26] mvo: it seems powerpc wasn't a thing before the uid_t became 32 bits, so getuid is the syscall we want [13:26] Chipaca: \o/ [13:26] mvo: want me to propose a pr? [13:26] Chipaca: yeah, unless you are busy please go ahead [13:26] zyga-ubuntu: all hail your lab :-D [13:26] :D [13:26] zyga-ubuntu, now I am using phone connection [13:26] mvo: raise your hand if you aren't busy [13:27] zyga-ubuntu: do you have a i386 hanging off of this? [13:27] zyga-ubuntu: otherwise I can take you an eeepc :-) [13:27] Chipaca: no but I have one and I can add it tomorrow [13:27] (real i386) [13:27] Chipaca: I also have a mips but it's not reliable (bad ddr) [13:27] zyga-ubuntu: well, i586 at least plz :-D [13:27] Chipaca: it's an atom [13:27] Chipaca: actually [13:27] 32bit only [13:27] nice [13:27] so, ... tomorrow :) [13:27] or later today [13:28] zyga-ubuntu: no hurries, it's mostly curiosity [13:28] I'll put classic on it as it has an PATA ssd that didn't work in core (no IDE support) [13:28] Chipaca: anything else? :D [13:28] zyga-ubuntu: uh.... no, it'd be greedy of me [13:29] also we don't support pep8 [13:29] pdp8 [13:29] that [13:29] hahaha :D [13:29] I was thinking about adding a server (UEFI) armv8 later [13:29] soon people will start to sell those first gen boxes [13:30] Chipaca: haha - point taken [13:31] * Chipaca squints at git [13:31] what's the point of doing 'gt mv' if it then just does whatever [13:32] ah no maybe it's just 'get status' that gets confused [13:32] eh [13:32] * Chipaca gets on with it [13:34] man [13:34] I'm so dumb [13:34] I was staring at a compile error, trying to understand it [13:34] when I typed "function() errror" instead of "func() error" [13:36] mvo: btw, any luck with that strace test failure? [13:37] zyga-ubuntu: not yet, let me run with -debug now [13:38] zyga-ubuntu: hm, no, some 2.31 prep first [13:38] mvo: 4503 is what it is [13:38] PR snapd#4503 opened: osutil/sys: ppc has 32-bit getuid already [13:38] greyback: I think the x11 slot implementation would actually be quite easy compared to wayland, but, I have a couple of questions [13:39] greyback: is a snap shipping Xwayland a common pattern, or something unusual? [13:41] Chipaca: typo [13:41] contsants [13:42] zyga-ubuntu: I don't know what you're takling about [13:42] jdstrand: the use-cases I have for it are things like chromium (for web kiosks) and electron (more kiosky bits) [13:43] jdstrand: wherever xwayland lives, is really just an implementation detail. [13:44] Chipaca: you made a typo in your PR [13:44] Chipaca: 4530 [13:44] 4503 [13:44] jdstrand: I leaned toward xwayland in the app snap, just for security reasons [13:44] zyga-ubuntu: i never make any typos, you're liying [13:44] but I'm not forcing that as the only option [13:45] Chipaca: drat, cosmic rays hit your keyboard then! [13:45] zyga-ubuntu: obviosuly [13:45] Chipaca: put tinfoil around your room ;-) [13:45] i've got a better idea [13:45] and it involves lunch [13:57] mvo, hey [13:57] pstolowski, mborzecki: https://github.com/snapcore/snapd/pull/4471 [13:57] PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS [13:57] updated, should be good now [13:57] mvo, sorry to skip the daily today [13:58] Chipaca: ^^ [13:58] I'll rebase stuff stacked on top of that to see if all the extensive unit tests (>>1K diff) passes [13:58] mvo, any idea why travis jobs are not starting? [14:00] cachio_: no worries about the standup, hope your elecricity is back. no idea about travis, let me check if I find anything out [14:01] zyga-ubuntu, thank you, will re-review soon [14:01] cachio_: mvo: https://www.traviscistatus.com/ show some major outage today [14:02] yeah, backlog of ~650 container jobs [14:02] ups. no, sorry [14:03] active builds, woah [14:04] zyga-ubuntu: I didn't mean for you to use my names for the helpers /o\ [14:05] cachio_: i'll close #4492 if #4336 is to be merged soon [14:05] PR #4492: spread: try to enable Fedora once more [14:05] PR #4336: spread.yaml: add fedora 27 [14:06] mborzecki, ok [14:06] Chipaca: better names welcome :) [14:06] mborzecki, thanks for the info [14:06] zyga-ubuntu: if I were good at names, I'd be good at names [14:09] ah [14:09] hm? [14:10] good morning! I will start a few minutes late today to take my girlfriend to her office. [14:10] bbs [14:11] re [14:11] mborzecki: there's no advantage from moving this into the backend [14:11] elopio: you're such a gentleman :-D [14:11] zyga-ubuntu: ok [14:11] mborzecki: it's a public thing so we need to declash in specification anyway [14:12] mborzecki: I'm trying to see how to make the logging friendlier [14:12] mborzecki: I think we can use the same trick that other backends use [14:12] mborzecki: store the snap as a hint [14:12] zyga-ubuntu: yeah, that would work [14:13] though need to think about the result first [14:13] what we want [14:13] (what the error message should look like [14:18] zyga-ubuntu: how about this: "detected a path conflict at '/some/path' coming from snaps 'foo' and 'bar', '/some/path' from snap 'bar' will be mounted at '/some/path-2'" ? [14:19] mborzecki: all of those are from one snap, the backend doesn't know enough to have that information [14:19] mborzecki: the spec is for a snap (always) [14:20] mborzecki: then each interface will influcnce it [14:20] mborzecki: we could look at connected plug/slot to get the 2nd snap info [14:20] mborzecki: but those are not conveyed by mount.Entry [14:20] mborzecki: we could patch it to do that (store some snap name hint in the mount entry) [14:20] mborzecki: but feels icky at that level [14:21] mborzecki: I could patch mount.Specification to instead remmeber this in a side table [14:21] mborzecki: not sure [14:22] zyga-ubuntu: and if you declash in AddMountEntry() ? [14:23] mborzecki: that's the same, those don't know anything about plug/slot [14:24] mborzecki: I could declash there, not sure what's best [14:24] mborzecki: but it doesn't help logging [14:25] zyga-ubuntu: AddMountEntry() could return a custom error, eg ErrMountPointConflict that has an extra method returning the path the conflict was resolved to, then you could log at least one snap [14:26] mborzecki: but then each caller would have to do that [14:26] mborzecki: I think the trick is to figure out how to give it context without making it annoying to use [14:26] mborzecki, I need to work on PR 4336 [14:26] PR #4336: spread.yaml: add fedora 27 [14:26] mborzecki, for some reason fedora 27 machines are not working at all [14:27] mborzecki, I'll merge with latest changes and research a bit about what's happeninig [14:27] cachio_: sounds like a plan :) [14:35] mborzecki: the changes i asked you to block #4464 are there now [14:35] PR #4464: overlord/snapstate: do a minimal sanity check on containers [14:35] mborzecki: sprinkle a 'for' into that sentence somewhere for it to make sense [14:36] or a comma [14:37] hmm, there's a glibc update with lots of security fixes, feels like new core snap is needed [14:38] zyga-ubuntu: indeed [14:40] * zyga-ubuntu gardens email [14:41] (using a scythe) [14:43] ppisati: did you get the env to work? [14:46] PR snapd#4498 closed: debian/tests: add missing autopkgtest test dependencies for debian [14:48] hello. is this hole in a random app something that highlights a way an application could bypass our sandbox? https://nvd.nist.gov/vuln/detail/CVE-2017-12904 [14:49] diddledan: looking [14:50] it's an interesting quesiton becuase theoretically the application developer opts-into the sandbox by distributing a snap but that vector could allow him to escape his self-imposed prison.. [14:51] diddledan: hmmm [14:51] diddledan: this is a bug in a particular app [14:51] yes. but it highlights that code can be executed via terminal escape sequences [14:51] diddledan: the app can be simply a "rm -rf /home/*" [14:51] diddledan: ah [14:51] hmm [14:52] it was just that it triggered me to thinking about vectors [14:52] it doesn't look like it [14:52] https://github.com/akrennmair/newsbeuter/commit/96e9506ae9e252c548665152d1b8968297128307 [14:52] this talks about subshell invocation [14:53] so it's not a bug in the way terminal emulators implement parsing of ansi escape codes and other magic [14:53] well yes, that one application fixes it [14:53] just in what this app wants to do [14:53] aha [14:53] diddledan: disclaimer, I'm not a security engineer so please ask someone from the security team for official confirmation [14:54] diddledan: but obviously the attack vector of printing stuff that chokes the terminal somehow is real [14:54] diddledan: and it would be some kid of sandbox escape, yes [14:54] I guess I misread the Gentoo securty advisory: "A remote attacker, by enticing a user to open a feed with specially crafted URLs, could possibly execute arbitrary shell commands with the privileges of the user running the application." [14:55] I read that as "escape sequences used for display" [14:55] "Newsbeuter does not properly escape shell meta-characters in the title and description of RSS feeds when bookmarking." [14:56] it's an age-old unsanitized variable used in command line then [14:56] that in itself wouldn't escape the sandbox [14:56] phew. crisis averted. [14:56] diddledan: meta-character != escape sequence though [14:56] this was a drill [14:57] there is NOT an ICBM heading to hawaii [14:58] that we know of. I mean there _might_ be an ICBM but we didn't alert you about that. We only alerted you about a fake ICBM that doesn't exist. If there is in fact an ICBM then as we didn't warn you: "our bad" [15:00] * zyga-ubuntu heads ohme [15:00] *home [15:00] ttyl [15:00] tata [15:08] * kalikiana thinks "ohme" should be the plural for units of resistance [15:12] Chipaca: posted random ideas about symlinks, feel free to ignore :) [15:12] mborzecki: I am going to ignore. [15:12] mborzecki: mostly because it's work that can be done iteratively [15:13] mborzecki: but partly because it'd need some more work to get some form of Readlink to work somehow [15:13] mborzecki: in any case, it's for a follow-up [15:15] Chipaca: yup, i'm not going to be adamant about it either :) [15:15] mborzecki: yeah, something like what you pasted would work [15:16] that and the extra check on things that go 'outside' are worth adding at some point [15:16] isn't an ohme a "brother from another mother" in London? [15:16] I is wiv me ohme's innit blood! [15:42] cachio_: I updated core for a new stable release and pushed the result to beta, could you please validate it? [15:43] cachio_: not sure we need the full validation as its just a respin with updated packages [15:43] mvo, seems the multi-volume fix doesnt work ... :/ [15:43] mvo, sure [15:43] ogra: oh? what is the error? [15:44] mvo, https://pastebin.canonical.com/207779/ [15:44] several OOPSIDs you can look up on errors.u.c [15:45] mvo, looks the same as before "ERROR cannot read gadget snap details: bootloader already declared" [15:46] ogra: it looks like snapd 2.30 runs on the image [15:46] (i used the core from edge from 15min ago) [15:46] ogra: but the fix is only in 2.30+git [15:46] ogra: before image building did not work, right? [15:46] oh, i thought that was in edge already [15:46] image building did always work [15:46] only device init after boot didnt [15:47] ogra: it should be in edge, I had 2.30 in edge for ~20min or so to build a new stable [15:47] same error as above [15:47] ogra: could you please double check, edge is edge again [15:47] ogra@localhost:~$ snap version [15:47] snap 2.30 [15:47] snapd 2.30 [15:47] hmpf [15:47] ok ... [15:48] seems we picked up the stable 2.30 in edge [15:48] ogra: sorry [15:49] i'll goback to my manual hack (i just had validated the image to give to the customer when LP started building core again ... had just hoped we could give them the fix) [15:50] * elopio is back and ready. [15:52] ogra: edge should be ok again, you can give it one more try [15:53] oh, did you re-build ? [15:53] ogra: re-published [15:53] ogra: the earlier core, not sure when exactly this one was build, I asked in between for a build, but not sure if it contains the fix or not [15:54] mvo, according to the manifest both have 2.30 [15:54] i think there is a 2.30 in the image PPA still [15:55] ogra: edge should be at 2.30+git497 - and yes, no new update in the ppa, I'm fixing this right now .) [15:57] yeah, dashboard only shows git477 for armhf ... 479 was only in x86 arches [15:59] Chipaca: could you please spare another look at 4471 [15:59] I really am blocked by that one landing so I'll be bugging you all until I get it resolved :) [15:59] mvo: if you want to use your voice in the naming / refactoring discussion there [16:00] once I get +2s from you I will ask gustavo to re-review [16:00] pstolowski: 4472 needs a 2nd review, should be good now [16:01] k [16:01] thank you [16:02] * zyga-ubuntu is still downtown [16:02] the traffic is bad and it will be an hour before I get home [16:04] +1 [16:05] thank you! [16:05] I will re-run integration tests in my main integration branch to see if anything broke [16:07] git doesn't respect file permissions, that's why my spread tests that check for them fail [16:11] Chipaca: it respects +x [16:11] Chipaca: what do you need [16:11] zyga-ubuntu: everything [16:11] zyga-ubuntu: also it respects +x in the sense that if it has any +x, it sets all +x and viceversa [16:11] also if i hadn't checked this out on another machine there was no way i'd've figured it out [16:11] because on my other machine everything works, with git saying 'yep no changes' [16:11] Chipaca: well, depending on system those are not representable much [16:11] >:-( [16:12] I think it's better to chmod yourself [16:12] chmod chmod chmod [16:12] I'll go to the tube now, let's hope it's not super crowded (it will be) [16:13] ttyl [16:25] PR core#74 opened: 10-remove-documentation: preserve changelogs [16:26] a quick review -^ would be appreciated, should be trivial (cc ogra) - this will give us changelogs again [16:27] cachio_: I will need to build another beta core, this one killed all changelogs which is a bit harsh, i.e. our http://people.canonical.com/~mvo/core-changes/html/stable/2.29.4.2_2.30.html will break for the "Package changelogs" section [16:27] cachio_: sorry for this [16:27] mvo, np [16:28] mvo, I'll download the new ones once they are ready [16:31] mvo, ack'ed [16:31] PR snapcraft#1878 opened: repo: use debian.arfile instead of dpkg-deb [16:32] ^^ sergiusens [16:32] PR core#75 opened: ensure that all live-build/hooks run with `set -e` [16:36] zyga-ubuntu, any idea if we could replace the dependency golang(github.com/Thomasdezeeuw/ini) with another on fedora? [16:37] zyga-ubuntu, we are having this error No match for argument: golang(github.com/Thomasdezeeuw/ini) [16:37] [16:37] after do dnf -y --refresh -v install 'golang(github.com/Thomasdezeeuw/ini)' [16:41] PR core#74 closed: 10-remove-documentation: preserve changelogs [16:43] cachio_: this has been resolved in master [16:45] cachio_: #4493 [16:45] PR #4493: image: port ini handling to goconfigparser [16:45] mborzecki, nice [16:46] thanks [16:48] mborzecki, ok, I'll make the change proposed by pedronis and pushe it to #4336 [16:48] PR #4336: spread.yaml: add fedora 27 [16:49] PR snapd#4483 closed: cmd/libsnap-confine-private: print failed mount/umount regardless of SNAP_CONFINE_DEBUG [16:51] mborzecki, testing now, it goes slow because I am using my phone connection [16:52] mborzecki, and I also have 2 hours of laptop battery [16:52] mborzecki, I hope electricity comes back soon [17:00] * kalikiana wrapping up for the day [17:01] How does snappy deal with custom configuration files? As a very simplified example, lets say I wanted to configure openssh to listen on a port other than 22. [17:03] leftyfb: so you mean a snapped ssh-server? [17:03] leftyfb: classic or confined? [17:04] probably classic to start with. But yeah. ssh server is just an example [17:04] leftyfb: if it's classic, the snap can read the host OS [17:04] wpasupplicant would be a better example in our case actually [17:05] leftyfb: so, in theory, given the same sort of options are passed to the build (i.e, read /etc/ssh/...), a classic snapped ssh server would be no different than a non-snap [17:05] as far as config goes, i mean [17:05] leftyfb: there's a wpa-supplicant snap, but I'm not sure it'll answer your question [17:05] we're looking to replace pxe/kickstart/ansible/catkin with a full snappy core + snaps. How would we deal with all the custom configs [17:06] leftyfb: if your question is how does "snap get" and "snap set" interact with a pre-existing software's configuration, that's up to the snap [17:06] if you were to confine it, i think you need to provide app(s) that expose the config you want to expose [17:06] Chipaca: ah yes, i forgot that `snap {set,get}` exist :) [17:06] leftyfb: so, e.g., a ssh server snap could expose a port config option [17:06] leftyfb: if your question is "how can i read/write etc", you typically don't; things can usually told to read their config from elsewhere [17:07] i meant "how can i read/write /etc/" in case that was unclear [17:07] I'm not sure I'm following. Basically I want to create a snappy core image to be dd'd onto a drive and have all the configs ready to go. wpasuppplicant being an example, how would I go about configuring the ssid/password during the creation of the snappy core image? [17:07] leftyfb: if it's your own wpasupplicant snap, just put it in your snap? [17:08] ok, so we can put custom configs in the snaps? [17:08] leftyfb: there's typically a factory setup step where you drop things like that in place, if I'm following you [17:08] what about if it's a config that is part of the core OS and we don't want to recreate a new snap just so we get a custom config? [17:08] leftyfb: ondra might have more experience with this than myself (I don't know what nacc works on :) ) [17:09] Chipaca: a little bit of everything :) [17:09] (it feels like) [17:09] leftyfb: what's the config? (it'll depend) [17:09] nacc: :-) [17:09] Chipaca: there's lots. We build robots :) [17:10] leftyfb: right, but not a lot in the core os is about robots [17:10] augh [17:10] leftyfb: not a lot in the core _snap_ is about robots [17:10] there, better [17:10] for example, with wpasupplicant we have a custom wpasupplicant.conf and a custom systemd unit file for it [17:10] leftyfb: right, so it's important to distinguish the bits here [17:10] core snap + app snaps [17:11] ugh, I have to step away for a bit. [17:11] I'll come back and try to come up with other examples [17:11] leftyfb: there is no wpa supplicant in the core os as far as i know [17:11] leftyfb: so that's from a snap :-) [17:11] (i could be wrong!) [17:11] and how or what you do with a config is totally up to that snap [17:12] granted if it's a service in the core os config can be tricky, but we've tried to keep that to a minimum [17:12] because of this trickiness :-) [17:12] ogra: do we ship wpa-supplicant in core? [17:13] Chindeed we do [17:13] geez [17:13] Chipaca, [17:13] lol === Chipaca is now known as Chindeed [17:13] get a bettar nick ! [17:13] ogra: ok [17:13] :) === Chindeed is now known as Chipaca [17:14] ogra: then I'm confused by the wpa-supplicant snap :) [17:14] Chipaca, but netplan only supports normal modes, no enterprise WPA or some such fancy stuff [17:14] ahh [17:14] NM and the wpa-suppl. snap solve that [17:14] ogra: netplan doesn't, or consoleconf doesn't? [17:14] ahh [17:14] netplan doesnt [17:14] theer was a recent discussion on the forum and with cyphermox about this [17:15] ogra: link? [17:15] * Chipaca so lazy [17:25] Chipaca, https://forum.snapcraft.io/t/standard-for-bootstrapping-network-on-raspberry-pi-and-similar-devices/3137 [17:26] leftyfb: ^ [17:30] PR snapd#4501 closed: configcore: ensure config.txt has a final newline [17:41] PR snapd#4419 closed: tests: fix snapctl configure core tests for rpi2 and 3 [18:29] mvo, are you uploading the new cores? [18:29] I just see the one for amd64 [18:32] cachio_: I can't :( the build farm is disabled because of spectre for most architectures. so I can only do amd64/i386 without help from the launchpad team. I was not able to reach someone this evening so I will try again tomorrow. [18:32] cachio_: you can poke a bit at the amd64 version but it should be fine [18:32] cachio_: here are the changes http://people.canonical.com/~mvo/core-changes/html/beta/2.30_2.30.html [18:33] mvo, ok, I'll try the amd64 [18:33] mvo, it should be quick [18:46] cachio_: thank you! [18:50] mvo, oh ... i thought we were already back in business for all arches ... [18:51] * ogra turns the daily core snap builds back off to not get bombed with build failure mails ... [19:15] mvo, my internet connection sucks today, still downloading the image [19:15] downlaoding at 19.7kB/s [20:17] arrrgh ROS changed how their CLI tools work between when I wrote the script and when I recorded the videos... [20:22] welcome to open source/api's :) [20:24] I was just getting a handle on init scripts when systemd became the thing ... I thought I mastered ifupdown and now netplan is the thing :/ [20:31] leftyfb, but those are different technologies! catkin_create_pkg suddenly works differently, in the same ROS release :P