| === JanC_ is now known as JanC | ||
| mborzecki | morning | 05:11 |
|---|---|---|
| mborzecki | mvo: hi | 05:40 |
| mvo | hey mborzecki | 05:46 |
| mborzecki | mvo: https://github.com/snapcore/snapd/pull/5756 looks like an easy win | 05:46 |
| mvo | mborzecki: indeed, thank you. technically this needs a review from jamie from security but I'm not sure its really needed for such a trivial one | 05:47 |
| mvo | mborzecki: how are tests this morning? | 05:48 |
| mborzecki | mvo: yeah, those files are just manufacturer an product human readable strings :) | 05:48 |
| mborzecki | mvo: hard to tell, restarted a few jobs, but those were failures from yday | 05:49 |
| zyga | Good morning | 05:50 |
| zyga | Mborzecki I could use some HO time today | 05:52 |
| zyga | I found a case that doesn’t work (not trespassing, that is ok) | 05:52 |
| zyga | And I wanted to discuss if | 05:52 |
| zyga | It | 05:52 |
| mborzecki | zyga: ok | 05:52 |
| mvo | zyga: good morning | 05:53 |
| mvo | mborzecki: I will merge once tests are green | 05:54 |
| zyga | Essentially the case is this: you have a symlink a->b in writable space, you want a->c instead | 05:54 |
| zyga | Hey. School saga day two | 05:54 |
| zyga | Today we just bail | 05:54 |
| zyga | I was thinking we should I link and symlink | 05:55 |
| zyga | I link and symlink | 05:55 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | build has failed | 06:40 |
| mborzecki | Build #24748 was borken | 06:40 |
| mborzecki | hm we're not out of the woods yet | 06:40 |
| mborzecki | wonder if we could use the fakestore in those tests | 06:43 |
| mborzecki | mvo: can you upload the release files to github? | 06:49 |
| mvo | mborzecki: yes, sorry, will do so in a minute | 06:50 |
| mborzecki | mvo: thanks! | 06:50 |
| mvo | also looks like master has a problem building on various arches in master :/ oh well, I look at this in a little bit too | 06:51 |
| mvo | mborzecki: done | 06:57 |
| mborzecki | mvo: thank you | 06:57 |
| mborzecki | mvo: i'll drop snapd.failure.service and snap-failure at the package level for now | 06:58 |
| mvo | mborzecki: please do | 06:58 |
| mborzecki | a siminiar thing will be needed for fedora (neal if offline?) and opensuse (cc zyga) | 06:59 |
| mborzecki | arch package updated | 07:16 |
| zyga | re | 07:16 |
| zyga | what's the problem? | 07:16 |
| zyga | btw, I'm entirely re-working suse packaging | 07:16 |
| zyga | it's a bit of a sad/happy story that I can share during the standup | 07:17 |
| mborzecki | zyga: https://aur.archlinux.org/cgit/aur.git/commit/?h=snapd&id=a23bdc8eb207c2a1312d74377dfcf8e56e25094f | 07:19 |
| pstolowski | mornings | 07:19 |
| * zyga looks | 07:20 | |
| zyga | hey pawel :) | 07:20 |
| * zyga is working from a restaurant garden today | 07:20 | |
| zyga | ahhh | 07:20 |
| zyga | I see | 07:20 |
| zyga | thank you for sharing mborzecki | 07:20 |
| mborzecki | pstolowski: hey | 07:21 |
| mborzecki | btw. have you noticed something about ohmygiraffe, or maybe it's our pulseaudio interface | 07:21 |
| mborzecki | when i restart pulseaudio (pulseaudio -k) and start ohmygiraffe after that, there's no sound | 07:22 |
| zyga | mborzecki: probably different filename/cookie value | 07:23 |
| mborzecki | zyga: right, but it's read from .pulse-cookie | 07:24 |
| zyga | is it? | 07:25 |
| zyga | it's unlikely | 07:25 |
| mborzecki | zyga: i'd gues .pulse-cookie contains the cookie, it's different each time pulseaudio starts, but at the same time i'd expect libpulse to read and use the new cookie | 07:27 |
| zyga | but the cookie is in a dot file in HOME | 07:27 |
| zyga | so it's probably not read from that | 07:27 |
| zyga | probably read from the x server root window | 07:27 |
| mborzecki | the log with PULSE_LOG=4 shows it's trying /run/user/1000/snap.ohmygiraffe/pulse/native to no avail | 07:28 |
| mborzecki | and $XDG_RUNTIME_DIR/pulse is indeed empty | 07:29 |
| mborzecki | i have a vague recollection we fied that in desktop helpers? | 07:29 |
| zyga | maybe | 07:30 |
| zyga | but I'd look at xprops | 07:30 |
| mborzecki | heh, symlinked in in snap shell, works now | 07:30 |
| mborzecki | ln -s ../../pulse/native $XDG_RUNTIME_DIR/pulse/native and magically works :/ | 07:30 |
| mborzecki | zyga: xprop -root |grep -i pulse comes up empty | 07:31 |
| zyga | hmm | 07:32 |
| zyga | and without pulse? | 07:32 |
| zyga | anything else there? | 07:32 |
| mborzecki | zyga: with or without looks the same | 07:34 |
| zyga | are you on wayland? | 07:34 |
| mborzecki | zyga: no x11 | 07:37 |
| mborzecki | ok, so it'd be nice to rebuild the snap to pick up the fixes in snapcraft-desktop-helpers | 07:38 |
| zyga | in that case my theory is broken, no idea | 07:38 |
| mborzecki | we have a fix there already (apparently i was the one to add it) whcih exports PULSE_SERVER | 07:38 |
| mborzecki | popey: any chance you could rebuild ohmygiraffe using more recent snapcraft? | 07:40 |
| zyga | mborzecki: I'm re-working the restricted/desiredPath into a structure that holds the pair | 07:42 |
| mborzecki | need conffee | 07:45 |
| zyga | cofefe | 07:48 |
| Raboo | how do I figure out what settings a snap has? | 07:49 |
| Raboo | btw snapcraft.io times out alot since yesterday | 07:49 |
| Raboo | ah there is a get | 07:55 |
| zyga | Raboo: hey | 08:01 |
| zyga | yeah, the store was wonky yesterday, it's all resolved I heard though | 08:01 |
| zyga | Raboo: snap configuration doesn't have a schema yet but you can indeed use get to look at the data that is set right now | 08:01 |
| Raboo | zyga ok | 08:01 |
| mborzecki | zyga: doesn't look resolved to me | 08:01 |
| zyga | oh? | 08:02 |
| zyga | the store is still wonky? | 08:02 |
| Raboo | trying out the chromium-mir-store | 08:02 |
| Raboo | s/store/kiosk/ | 08:02 |
| mborzecki | zyga: afaict it is | 08:02 |
| Raboo | zyga still wonky | 08:02 |
| zyga | :/ | 08:02 |
| ppisati | ogra_: xenial or bionic only? if we could find a way to reproduce it, it would be nice | 08:02 |
| wgrant | zyga: It was all resolved, but is having some minor trouble now. Should be working again. | 08:04 |
| sparkiegeek | zyga: please just look at (and refer people to) https://status.snapcraft.io | 08:04 |
| zyga | thank you, will do | 08:05 |
| sparkiegeek | we (store team) will keep that up to date, and avoids "I heard" games of Telephone | 08:05 |
| Raboo | does the chromium-mir-kiosk people hang here? I'm wondering what I need to do to enable audio and webcam | 08:07 |
| mvo | Chipaca: good morning! | 08:09 |
| mvo | Chipaca: I think you tricked me into writing tests for store.go:download() ;) | 08:10 |
| Chipaca | mvo: morning! | 08:10 |
| mvo | Chipaca: we do not test this explicitly, do we? | 08:10 |
| Chipaca | mvo: only that if wasn't covered! | 08:10 |
| Chipaca | mvo: probably not explicitly, the tests will be fore Download | 08:10 |
| Chipaca | or whatever | 08:10 |
| Chipaca | mvo: can't you parametrise one of the existing tests? | 08:11 |
| Chipaca | mvo: as in, TestDownload(*C) -> testDownloadMaybeWithRateLimit(*C, bool) | 08:11 |
| mvo | Chipaca: not sure, afaict we mock func download away pretty much everywhere | 08:11 |
| Chipaca | hmm | 08:11 |
| * Chipaca looks | 08:11 | |
| mvo | Chipaca: I looked at storeTestSuite and in SetUpTest it mocks it away and I don't see where its unmocked :/ but again, maybe blind :) | 08:13 |
| zyga | hey John, good morning | 08:16 |
| zyga | mborzecki: hey | 08:16 |
| zyga | do you have a sec for HO? | 08:16 |
| mborzecki | sure | 08:16 |
| mborzecki | sec | 08:16 |
| mborzecki | zyga: ok, i'm there | 08:17 |
| zyga | k, joining | 08:17 |
| pedronis | Chipaca: mvo: we should have some tests for download, what I'm not sure is whether we have tests for Download calling download | 08:18 |
| Chipaca | pedronis: mvo: look for TestActualDownload | 08:18 |
| Chipaca | pedronis: mvo: there are a bunch | 08:18 |
| Chipaca | coverage is bright green, not the pale green of only-barely-covered | 08:19 |
| Chipaca | zyga: hey zyga | 08:19 |
| Chipaca | zyga: I'm assuming you mean me when you say 'hey John' :-) | 08:19 |
| pedronis | Chipaca: mvo: SetUp stores it away to restore, it doesn't mock it afaict | 08:20 |
| mvo | Chipaca: clearly the tea then, thanks, I will add | 08:20 |
| pedronis | s.origDownloadFunc = download | 08:21 |
| mvo | Chipaca: to that family plus adding one that does the download directly | 08:21 |
| Raboo | This is my interfaces http://termbin.com/nm9z, do I need to connect anything more to enable camera and audio for chromium-mir-kiosk? | 08:21 |
| mvo | pedronis: yeah, thanks. I see it now, sorry for the noise | 08:21 |
| pedronis | mvo: well store_test.go is a bit of a jungle | 08:21 |
| pedronis | but at least this bit is kind of straighforward | 08:22 |
| mvo | pedronis, Chipaca would you mind if I change this to use MockDownload ? to make it a bit more like the other parts? | 08:22 |
| mvo | pedronis: yeah, sorry again | 08:22 |
| mvo | (probably in a separate PR) | 08:22 |
| pedronis | I don't know | 08:22 |
| Chipaca | pedronis: mvo: it wasn't obvious fwiw, I had to add a panic() to the download() :-) | 08:22 |
| pedronis | it's a step in the right direction otoh I think that file needs a more general attack | 08:22 |
| mvo | Chipaca: heh, thanks for comforting me :) | 08:22 |
| mvo | pedronis: I would move the actual download tests into its own suite plus add mocking via export_test.go as a first step. but I'm fine leaving it if there is a bigger plan in place | 08:23 |
| pedronis | mvo: there are not bigger plans | 08:23 |
| pedronis | mostly noticing that Mock* is not used much around there | 08:24 |
| pedronis | mvo: the main issue is really that store_test.go is "package store" | 08:24 |
| pedronis | only unclarity comes from that | 08:25 |
| Chipaca | store really needs some love, yes | 08:25 |
| pedronis | it and daemon are the few places left doding that | 08:25 |
| mvo | pedronis: yeah | 08:25 |
| Chipaca | daemon is 100% my fault :-| | 08:25 |
| mvo | pedronis: I have a look | 08:25 |
| * pedronis is only morning and I cannot type | 08:25 | |
| mvo | Chipaca: its the fault of history | 08:25 |
| * mvo hugs Chipaca | 08:25 | |
| Chipaca | :-) | 08:26 |
| Chipaca | anyway, back to snapshotstate tests for me | 08:27 |
| popey | mborzecki: sure, what's the issue I'm solving by rebuilding omg? | 08:38 |
| Chipaca | HAH! found you, you nasty effluvia | 08:41 |
| ackk | hi. where is "snapctl" localed in the snap? it seems it's not in path by default in hooks | 08:43 |
| ogra | ppisati, ubuntu core 16 ... 4.4 kernel | 08:43 |
| Chipaca | ackk: /usr/bin/snapctl | 08:44 |
| ackk | Chipaca, oh, wait it seems it's missing in core18? | 08:44 |
| Chipaca | ackk: shouldn't be, but :-) | 08:45 |
| Chipaca | ackk: do you have core, or snapd snaps? | 08:45 |
| ogra | ppisati, the systems are all the same, running a webcam with mjpg-streamer (so there is a lot of data going over the net) ... | 08:45 |
| ackk | Chipaca, I have "core" but the snap I'm working on is based on core18 | 08:45 |
| ackk | Chipaca, confirmed, no snapctl in core18 | 08:46 |
| Chipaca | ackk: right, core18 doesn't ship any of snapd; that's shipped in the snapd snap (in the new world) or in the core snap (in the old world) | 08:46 |
| Chipaca | ackk: snapd should be smart enough to find it and put it where it's expected though | 08:46 |
| Chipaca | mvo: any issues here ^? | 08:46 |
| ackk | Chipaca, so how do I base a snap on core18 and use hooks? | 08:46 |
| Chipaca | ackk: as I say, it should just work -- you shouldn't need to care | 08:47 |
| Chipaca | ackk: you've found a bug, maybe | 08:47 |
| Chipaca | ackk: waiting for word from mvo who is the god of core18 and hugs | 08:47 |
| ackk | Chipaca, should I have a "snapd" snap as well? | 08:47 |
| ackk | I don't | 08:47 |
| Chipaca | ackk: no you should not need it | 08:47 |
| Chipaca | ackk: can you check if it's in /usr/lib/snapd/ ? | 08:47 |
| Chipaca | snapctl i mean | 08:48 |
| mvo | ackk: are you using the "beta" or "edge" of core18 ? if not, please try that | 08:48 |
| ackk | Chipaca, it's not | 08:48 |
| ackk | mvo, no I'm using stable, I'll try edge | 08:48 |
| ackk | mvo, that worked, thanks | 08:49 |
| ackk | mvo, btw are pre-refresh and post-refresh hooks already supported in released snapd? | 08:49 |
| mvo | ackk: that should work, yes | 08:49 |
| ackk | cool | 08:50 |
| ackk | Chipaca, mvo thanks | 08:50 |
| Chipaca | pedronis: that thing where the cleanup test would freeze that had me stumped? was an actual bug :-D | 08:55 |
| pedronis | Chipaca: ok | 08:55 |
| * pstolowski -> school run | 08:56 | |
| ackk | Chipaca, unrelated, do you know if it's possible to run ssh confied in a snap? I've been trying but it fails on setgroups call and I can't log in | 08:57 |
| Chipaca | ackk: ssh should work (there might even be an interface to let it get the host keys); sshd might need tweaking | 08:58 |
| mborzecki | popey: the one i know of is it'll get properly exported PULSE_SERVER, so even if you restart pulseaudio the sound will work | 08:58 |
| zyga | Chipaca: indeed | 08:58 |
| ackk | Chipaca, right, I want sshd | 08:58 |
| Chipaca | ackk: if you arm yourself with logs and patience jd_strand might be able to help | 08:58 |
| Chipaca | ackk: sshd has a lot of levers you can pull via config :-) | 08:59 |
| Chipaca | ackk: but: if it tries to setuid, it won't work | 08:59 |
| ackk | Chipaca, right, I've been trying that, including AllowedUsers/Group and so on, but I couldn't get it to work | 08:59 |
| Chipaca | setgroups sounds like part of that family | 08:59 |
| ackk | Chipaca, right, I suspect it would work if it could use a "nobody" user | 08:59 |
| ackk | Chipaca, basically I wanted an isolated sshd so that I can use it as a target for sshuttle-based VPNs | 09:00 |
| Chipaca | ackk: nice | 09:00 |
| ackk | Chipaca, it would be if it worked :) | 09:00 |
| Chipaca | ackk: https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461?u=chipaca fwiw | 09:01 |
| ackk | Chipaca, yeah I know about that thread, it's something we'd like for the maas snap too | 09:02 |
| Chipaca | k | 09:06 |
| niemeyer | ackk: We discussed the idea of introducing a "daemon" user early on, using the same model of the final design.. might work for those cases before the whole thing is fleshed out | 09:13 |
| niemeyer | Mornings, btw | 09:13 |
| ackk | hi niemeyer, yeah I think that would be enough for our use case | 09:16 |
| ackk | (daemons that refuse to run as root) | 09:16 |
| niemeyer | ackk: Yeah, that's indeed the reason why that idea came up | 09:17 |
| Chipaca | pedronis: Settle(t) always take t? I thought it was a maximum but in practice it looks like a mminimum (at least when there's cleanup involved) | 09:18 |
| thresh | popey, sparkiegeek ping vlc stuck in store | 09:19 |
| sparkiegeek | thresh: hmm, sorry about that :/ I've re-triggered the checks again on 3.0.4 | 09:20 |
| thresh | sparkiegeek, np and thanks! | 09:20 |
| pedronis | Chipaca: it's complicated, t doesn't cover time some scenarios | 09:24 |
| Chipaca | pedronis: hmm | 09:24 |
| Chipaca | pedronis: what I'm seeing is that cleanup gets called again and again | 09:24 |
| Chipaca | hmm | 09:25 |
| Chipaca | pedronis: if cleanup returns error it just gets called again? | 09:25 |
| pedronis | Chipaca: ah, yes, no basically cannot return errors from cleanups | 09:25 |
| pedronis | unless you think being called forever is what you want | 09:25 |
| Chipaca | pedronis: thank you for having me write these tests ;-) | 09:26 |
| dot-tobias | Hi everyone. Quick question concerning the Ruby plugin: Is there a way to preserve a built Ruby version across iterations as long as I don't change the ruby-version keyword? I'm experimenting with different stage-packages and the plugin rebuilds Ruby from source on every iteration. | 09:40 |
| sparkiegeek | thresh, popey: it is now unstuck | 09:58 |
| Chipaca | dot-tobias: I'm not sure who, short of sergiusens or kyrofa, can answer that | 09:59 |
| zyga | mborzecki: I think I found another logic quirk in my code | 10:11 |
| zyga | eh eh | 10:11 |
| zyga | but I'll commit everything and push it for review | 10:11 |
| mborzecki | ok | 10:11 |
| zyga | then work on your branch | 10:11 |
| zyga | mborzecki: essentially the call to LiftRestrictions is fine | 10:11 |
| zyga | mborzecki: but what if we did /rofs/<mimic>/a | 10:11 |
| zyga | mborzecki: and want to make /rofs/b then? | 10:11 |
| zyga | mborzecki: we remember that /rofs is a tmpfs we made | 10:11 |
| zyga | mborzecki: so we'll make b | 10:12 |
| zyga | that will work | 10:12 |
| zyga | mborzecki: but /rofs/a/c | 10:12 |
| zyga | mborzecki: that will go to rofs, it's a tmpfs so we carry on, then we will see an _existing_ directory a and bail out | 10:12 |
| zyga | (because we may not attempt writes there) | 10:12 |
| zyga | it's non-trivial :/ | 10:12 |
| zyga | mborzecki: because as I coded it so far, we only lift restrictions when making a new directory on top of a tmpfs mount point | 10:13 |
| zyga | mborzecki: to allow /rofs/a/c we'd have to keep track of other mount ops and ensure that /rofs/a/ is not populated | 10:13 |
| zyga | mborzecki: it can be a fix on top of this branch I suspect | 10:13 |
| zyga | but meh, this is hard stuff | 10:13 |
| mborzecki | heh, maybe we should try whiteboard instead :P | 10:14 |
| zyga | mborzecki: we need the "are you evil" bit | 10:15 |
| mborzecki | zyga: it feels like you'd need to comb through the ops and match the longest prefix of current path | 10:16 |
| zyga | mborzecki: we also need to keep track of mount changes we started with (current mount profile) | 10:16 |
| zyga | mborzecki: well, not sure, it's all complex (you can have filesystems and symlinks there) | 10:16 |
| mborzecki | zyga: we could track just the current state, but then symlinks don't show up because it's kind of side channel | 10:19 |
| zyga | mborzecki: we cannot track just the current state, we are called _update_ ns for a reason | 10:19 |
| mborzecki | zyga: i meant tracking the 'current state' after each change, but that's not helping either | 10:21 |
| mborzecki | zyga: btw. what if symlinks were applied last? | 10:22 |
| zyga | mborzecki: we know in order | 10:22 |
| zyga | mborzecki: I mean, we know it all | 10:22 |
| zyga | but it's hard to come up with an algorithm can respond reliably to the set of questions we have | 10:23 |
| zyga | mborzecki: pushed! | 10:31 |
| zyga | I'm making the PR now, | 10:33 |
| zyga | mborzecki: I have an idea how to fix /rofs/a/c | 10:36 |
| zyga | if we know /rofs/a and we can fstat it we can check the device major number | 10:36 |
| zyga | (and the magic/type value) | 10:37 |
| zyga | *fstatfs | 10:37 |
| zyga | Then we can fstatfs /rofs/a/c and also allow it iff it is still a tmpfs and has a major number that matches one of the past ones we've checked | 10:37 |
| zyga | since we must have traversed /rofs/a/ we will know the major number | 10:37 |
| zyga | anyway | 10:38 |
| zyga | that's a follow-up | 10:38 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/5760 | 10:43 |
| zyga | mborzecki: I'll look at your PR now | 10:43 |
| zyga | mborzecki: just to double check: https://github.com/snapcore/snapd/pull/5758 | 10:48 |
| zyga | this one? | 10:49 |
| mborzecki | zyga: https://github.com/snapcore/snapd/pull/5713 | 10:54 |
| mborzecki | zyga: well, you can do both :) | 10:54 |
| zyga | ok | 10:55 |
| zyga | mborzecki: quick question: why didn't you make the changes to apparmor? | 10:59 |
| zyga | mborzecki: there are some typos in parallel in the PR :) | 10:59 |
| mborzecki | zyga: default template? | 11:07 |
| zyga | or instance specific template, either way | 11:08 |
| zyga | anyway, reading on | 11:08 |
| mborzecki | pedronis: hi, another one for you https://github.com/snapcore/snapd/pull/5761 :) this is first step to get the stable instance key across refresh requests (cc wgrant) | 11:17 |
| wgrant | ooh | 11:19 |
| baimafeima | hello, I'm curious whether it'll be possible to get snaps to run on Haiku OS: https://www.haiku-os.org/ | 11:20 |
| zyga | baimafeima: hey, that's unlikely as snaps rely on a number of linux technologies | 11:20 |
| zyga | baimafeima: I'm not a haiku expert but I don't suppose haiku can run unmodified linux executables today | 11:21 |
| baimafeima | Yeah | 11:21 |
| zyga | baimafeima: so apart from the extra requirements of snapd (related to container technologies and sandboxing) you would have existing problems of just running unmodified apps that people release | 11:21 |
| baimafeima | I just wonder whether there's any ambition among snap developers to even move beyond the linux ecosystem | 11:21 |
| baimafeima | to make it more "universal" | 11:22 |
| zyga | baimafeima: one by one ;) | 11:22 |
| zyga | baimafeima: I think the answer is that it's unreasonable outside of "let's run it in a VM" | 11:22 |
| zyga | baimafeima: I doubt the number of users there would justify the engineering work required to attempt that | 11:23 |
| zyga | baimafeima: allowing snaps on windows would be more interesting for example | 11:23 |
| baimafeima | zyga, yeah, I just happen to be really fascinated about haiku :D | 11:24 |
| baimafeima | and well, they really lack software | 11:24 |
| zyga | baimafeima: I understand that | 11:29 |
| zyga | baimafeima: good luck with haiku! | 11:29 |
| pedronis | mborzecki: ack | 11:30 |
| baimafeima | zyga, thanks for the info though | 11:31 |
| === pstolowski is now known as pstolowski|lunch | ||
| zyga | mborzecki: wow, https://github.com/snapcore/snapd/pull/5760 is green on first go :) | 11:36 |
| zyga | no need to re-trigger tests | 11:37 |
| zyga | that's fun :) | 11:37 |
| wgrant | mborzecki: RequestSeed will be persisted in state somewhere, I guess? | 11:42 |
| wgrant | I suppose it needn't be a per-snap value. Machine-global would be fine. | 11:42 |
| mborzecki | wgrant: i planned to use seed-time which is machine global for that | 11:42 |
| mborzecki | off to pick up the kids | 11:45 |
| * zyga preps for lunch | 11:48 | |
| zyga | mborzecki: review of 80% sent, I'll grab some food now | 11:49 |
| zyga | mborzecki: and there are lots of conflicts in that PR | 11:49 |
| zyga | anywAY | 11:49 |
| === chihchun is now known as chihchun_afk | ||
| zyga | re :) | 12:30 |
| zyga | mborzecki: resuming the review | 12:30 |
| pstolowski|lunch | a lot of "error: unable to contact snap store" today, still | 12:34 |
| noise][ | pstolowski|lunch: we are still battling some performance issues so having internmittent timeouts | 12:35 |
| pstolowski|lunch | noise][: ack, thanks | 12:35 |
| === pstolowski|lunch is now known as pstolowski | ||
| pstolowski | niemeyer: thanks for the yesterday's udev review! the followup https://github.com/snapcore/snapd/pull/5632 is now much smaller (and also finally green again) | 12:36 |
| mborzecki | re | 12:39 |
| niemeyer | pstolowski: Thanks! | 12:41 |
| mborzecki | zyga: yeah, the conflicts are expected, parts of the PR were landing independently | 12:41 |
| Chipaca | state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic" | 12:44 |
| Chipaca | :'( | 12:44 |
| Chipaca | noise][: ^ is that another form of intermittent timeout? | 12:44 |
| noise][ | yes, we lock you up until the timeout is reached | 12:45 |
| pedronis | Chipaca: we should move catalog fetching to a task btw | 12:46 |
| ogra | noise][, given that https://forum.snapcraft.io/t/solved-request-failures-to-the-store/7177/6 claims "solved" perhaps someone from store could answer here https://forum.snapcraft.io/t/snapd-not-connecting-to-the-store-what-to-test-do/7190 | 12:49 |
| ogra | (since the latter one is more specific) | 12:49 |
| Chipaca | ogra: "solved" y un jamón :-) | 12:52 |
| jdstrand | I'm here | 12:52 |
| noise][ | yes, we'll get the notices updated, sorry for the delay on those | 12:52 |
| ogra | jdstrand, do you highlight "jamón" lately ? | 12:53 |
| jdstrand | no | 12:53 |
| ogra | :) | 12:53 |
| jdstrand | I saw the store failures bit | 12:53 |
| ogra | ah | 12:53 |
| jdstrand | but seems you are talking about different things | 12:53 |
| zyga | jdstrand: hello | 12:54 |
| ogra | yeah ... the review-tools are fine on 16.04 ... 18.04 still fails though | 12:54 |
| jdstrand | I'll sync with roadmr when he is online. a new revision of the review tools should've hit prod yesterday but it doesn't seem to have | 12:54 |
| zyga | ogra: jamon? :D | 12:54 |
| jdstrand | ogra: yeah | 12:54 |
| ogra | zyga, see Chipaca's last line :) | 12:54 |
| zyga | jdstrand: I revived the trespassing fix for layouts, some churn still but at some point I'll ask you to sanity check | 12:54 |
| jdstrand | ogra: so, depending on what he says, I'll do the same for 18.04 that I did for 16.04 | 12:54 |
| jdstrand | zyga: hey, sure | 12:54 |
| zyga | jdstrand: there's also some related change in mount table sorting we are doing for instances | 12:55 |
| zyga | jdstrand: I'll go through it now, to poke holes | 12:55 |
| zyga | jdstrand: but if I fail I'll ask you to double check that aspect | 12:55 |
| jdstrand | roadmr: good morning! what is the status of getting r1123 of the tools into prod? | 13:07 |
| roadmr | hi jdstrand ! we've had some issues with breakage in the store since yesterday which have preempted any rollouts :/ | 13:07 |
| roadmr | jdstrand: but once the fire is out, rolling r1123 and a couple of other changes is highest priority for us | 13:08 |
| jdstrand | roadmr: should I roll a downgraded deb for bionic or does that fire seem to be out? | 13:09 |
| jdstrand | roadmr: (I can do the same for base: core18 snaps as I did for regular snaps. that would help some, but then there are non-LP/snapcraft.io builds that need r1123) | 13:10 |
| jdstrand | (I can't do anything about those) | 13:10 |
| roadmr | jdstrand: it's probably still affecting users building on 18.04 | 13:11 |
| jdstrand | roadmr: which 'it'? I know lack of r1123 is affecting users (that is what I'm wondering about with uploading a downgraded bionic). ie, is the fire almost out and therefore r1123 will make it in the next few hours, or should I prepare that downgraded deb? | 13:12 |
| roadmr | jdstrand: it == the new snapcraft that emits those new keys :) | 13:17 |
| roadmr | jdstrand: we might be able to do the rollout this afternoon but no promises - it might be reasonable to downgrade bionic :( | 13:17 |
| jdstrand | roadmr: right, ok | 13:17 |
| * jdstrand does that | 13:17 | |
| roadmr | jdstrand: because it'll be a couple of hours before we know more, and what we end up finding out may be "it's all still borked, we can't roll out yet" | 13:18 |
| roadmr | jdstrand: sorry - this issue we've hit had particularly bad timing :( | 13:18 |
| jdstrand | no worries | 13:18 |
| === sparkieg` is now known as sparkiegeek` | ||
| mvo | niemeyer: the snapd snap failover test: https://github.com/snapcore/snapd/blob/master/tests/core18/snapd-failover/task.yaml | 13:59 |
| mvo | niemeyer: sorry that I did not find it earlier, it is under the core18 subsection, I forgot about this | 13:59 |
| niemeyer | mvo: Thanks! | 14:02 |
| niemeyer | mvo: and np at all | 14:02 |
| ogra | mvo, https://forum.snapcraft.io/t/core18-included-binaries/7191 ( <-- and probably also niemeyer ) | 14:10 |
| sergiusens | kjackal: hey there, can you direct me to where the microk8s project lives? | 14:12 |
| Chipaca | niemeyer: wrt changing 'okay' to 'ack', was your expectation also that the user-facing command would become 'ack'? | 14:12 |
| Chipaca | (maybe as an alias for 'acknowledge'? | 14:12 |
| Chipaca | ) | 14:12 |
| pedronis | Chipaca: snap ack exists already, for assertions | 14:12 |
| niemeyer | Right, on both counts | 14:12 |
| pedronis | that's why we went with okay here originally, I think | 14:13 |
| niemeyer | Oh, wait.. the command doesn't work.. :( | 14:13 |
| mvo | ogra: ta | 14:14 |
| niemeyer | It's a bit awkward to see it as a verb.. it was also unexpected to see it mixed | 14:14 |
| niemeyer | Hmmmmm | 14:14 |
| Chipaca | niemeyer: 'snap okay' comes straight from the whiteboard fwiw | 14:14 |
| niemeyer | Ack | 14:14 |
| niemeyer | (or okay? :P) | 14:15 |
| zyga | "snap dismiss" | 14:16 |
| zyga | snap read NN (like in gentoo) | 14:16 |
| Chipaca | snap conform | 14:18 |
| niemeyer | zyga: That's pretty good, but as something we need to type out often "okay" feels practical, and sort of okay | 14:19 |
| niemeyer | I cannot find any better options right away, unsurprisingly.. | 14:19 |
| roadmr | haha so just like typing any two letters on a unix system does *something*, snap $ANY_VERB is bound to eventually also do something :D | 14:19 |
| niemeyer | We probably spent a good while finding it in the sprint | 14:19 |
| pedronis | looking at synomyms of "acknowledge" there is nothing useful that is not many word, or long and uncommon | 14:20 |
| Son_Goku | does anyone know why the forums are inaccessible? | 14:22 |
| Son_Goku | hmm | 14:22 |
| Son_Goku | was a blip | 14:22 |
| Son_Goku | it works now | 14:22 |
| niemeyer | Chipaca, pedronis: alright, I we want to go with "okay", indeed it sounds better to go end-to-end with it so we use the same terminology everywhere | 14:26 |
| niemeyer | Chipaca: sorry for the false lead.. I forgot we had such a strong meaning for ack already | 14:26 |
| roadmr | jdstrand: hey! the script that sends USN notifications for snaps, that lives in the reviewer-tools repo, right? | 14:32 |
| zyga | niemeyer: yeah, I think okay is okay :) | 14:38 |
| niemeyer | Okay then! | 14:39 |
| Chipaca | zyga: I think ack is ack | 14:42 |
| zyga | ack, okay | 14:48 |
| zyga | meh | 14:48 |
| zyga | can we have "snap meh" | 14:48 |
| zyga | doing something useful? :) | 14:48 |
| pedronis | snap blink and snap nod | 14:49 |
| zyga | snap wink wink wink | 14:49 |
| * mvo likes snap nod | 14:52 | |
| mborzecki | snap aye, snap nay? | 14:55 |
| zyga | snap popey the sailor | 15:09 |
| diddledan | https://www.youtube.com/watch?v=grtchH6SfGE | 15:19 |
| jdstrand | Saviq: hey, can you trigger a new build for subsurface? LP/snapcraft.io should now have a downgraded snapcraft to work around the review issue | 15:21 |
| jdstrand | roadmr: the meat of the script is there, yes. there is a small cron script that drives it that is not | 15:22 |
| roadmr | jdstrand: ok... but the cron script mostly calls the usn script itself, right? does it by chance do a snap search to the /api/v1/snaps/search endpoint? (I think not, but checking something) | 15:23 |
| sergiusens | jdstrand, roadmr: I am about to dput a new snapcraft, is the review thing resolved? If not I will git revert the version thing and leave it to you guys to add back when ready | 15:25 |
| roadmr | sergiusens, jdstrand : I'm about to request the rollout with tools r1123, very likely that'll be out today | 15:25 |
| sergiusens | roadmr: ok, sounds good | 15:26 |
| Saviq | jdstrand: ack | 15:27 |
| jdstrand | roadmr: thanks! that'll help people directly uploading with 'snapcraft push' | 15:43 |
| roadmr | yep, sorry it took so long :/ | 15:44 |
| roadmr | but... fire :) | 15:44 |
| jdstrand | roadmr: sorry, let me check | 15:44 |
| roadmr | jdstrand: (it's not there yet :) | 15:44 |
| roadmr | rollout has been requested, but takes a while to process/run/etc | 15:44 |
| jdstrand | I understand | 15:44 |
| * jdstrand is getting you the answer to your question | 15:44 | |
| roadmr | thanks :) | 15:47 |
| ogra | mvo, did you see my last comment on the core18 binaries thread ? where are netplan and console-conf in core18 ? are they not supposed to be included anymore | 16:21 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| * Chipaca wanders off | 17:13 | |
| * anarcat waves | 17:14 | |
| anarcat | so what should i do with this bug report? https://forum.snapcraft.io/t/apparmor-error-after-debian-buster-upgrade/7026 | 17:15 |
| anarcat | it still, as far as i know, affects debian | 17:15 |
| cyphermox | ogra: could you please clarify? netplan and console-conf not supposed to be included? I expect that's a mistake | 17:34 |
| jdstrand | sergiusens: I see you closed https://github.com/snapcore/snapcraft/pull/2234. I commented there since I was reading backscrolled and asked to do so | 17:36 |
| sergiusens | jdstrand: yeah, I reopened another one | 17:37 |
| sergiusens | jdstrand: https://github.com/snapcore/snapcraft/pull/2235 | 17:37 |
| sergiusens | but I will look into your comments | 17:37 |
| jdstrand | anarcat: I think zyga is looking at that | 17:37 |
| sergiusens | jdstrand: good comments, these are the smallest snaps we can come up with to trigger each scenario as we do like our speed | 17:39 |
| sergiusens | jdstrand: this will not however give us a 100% coverage on all the possible scenarios for keys to be generated. But we should strive to keep the ones you care about compatible, we do not plan on making backwards incompatible changes, but you never know when taking on new dependencies :-) | 17:40 |
| jdstrand | sergiusens: are you planning on adding new keys? maybe I should adjust the tools to not care about unknown ones | 17:42 |
| jdstrand | it isn't as interesting to report unknown manifest.yaml keys | 17:43 |
| sergiusens | jdstrand: no, no plans; I just worry that someone will create a snap that triggers things you have not seen yet (like source-commit or those keys that only show up on very special occasions) | 17:43 |
| jdstrand | possibly | 17:44 |
| sergiusens | jdstrand: that said, maybe you cover everything already and I just need to check | 17:44 |
| sergiusens | jdstrand: but, the case can be made that the snap directory of a snap is not part of the snap format | 17:45 |
| jdstrand | sergiusens: https://git.launchpad.net/review-tools/tree/clickreviews/sr_common.py#n67 | 17:45 |
| sergiusens | it is just an artifact that snapcraft creates | 17:45 |
| jdstrand | right | 17:45 |
| jdstrand | I mean, snapd doesn't look at it | 17:45 |
| jdstrand | looks like I do not have source-commit | 17:45 |
| sergiusens | right, anything part of the snap format is in meta | 17:46 |
| jdstrand | sergiusens: how about I add all the missing keys, but then I make it non-fatal if something is added? | 17:46 |
| sergiusens | jdstrand: source-commit is part of snapcraft.yaml inside snap (alongside manifest.yaml) | 17:46 |
| sergiusens | you may not be checking it at all from a quick search | 17:47 |
| jdstrand | sergiusens: we don't look at snapcraft.yaml at all | 17:47 |
| jdstrand | sergiusens: only manifest.yaml and only because our tool looks at it | 17:47 |
| sergiusens | jdstrand: that's perfect, I would still treat it as json API, ignoring what you do not know about to be able to add new keys we agree upon | 17:48 |
| jdstrand | sergiusens: ok, am I missing anything from manifest.yaml? is there somewhere I should look? | 17:48 |
| sergiusens | well, your choice, we will most likely only add keys there that make sense to you and maybe when we decide to tackle reproduceable builds for real | 17:48 |
| anarcat | jdstrand: cool | 17:49 |
| sergiusens | jdstrand: it is pretty much hand crafted to not sneak in things https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/meta/_manifest.py#L28 | 17:50 |
| jdstrand | ok, thanks | 17:53 |
| sergiusens | jdstrand: I will let you know if anything changes | 17:54 |
| jdstrand | sergiusens: thanks. the added tests will be very worthwhile in that regard. I'm also removing the unknown check | 17:55 |
| mvo | ogra: are you looking at stable? that is very small right now, beta/edge should be more current | 17:58 |
| pedronis | mvo: is version really intended to be just "18" in edge? | 18:00 |
| ogra | mvo, aha, i'll make the same list fro edge then, thanks | 18:03 |
| ogra | *for | 18:03 |
| mvo | pedronis: there is an open pr to make it date based we could make it month based | 18:13 |
| mvo | ogra: yw, sorry that its a bit confusing currently | 18:13 |
| kyrofa | Hey mvo, although the yaml spec doesn't guarantee it, will the `environment` dict be evaluated in order? | 18:46 |
| kyrofa | I assume so, just want to double check | 18:52 |
| * cachio afk | 18:59 | |
| ogra | jdstrand, i see very curious things in my log from the hexchat snap ... | 19:36 |
| ogra | kernel: audit: type=1400 audit(1536089686.295:34656): apparmor="DENIED" operation="open" profile="snap.hexchat.hexchat" name=2F686F6D652F6F6772612F736E61702F686578636861742F33392F2E636F6E6669672F686578636861742F7363726F6C6C6261636B2F7562756E747520736572766572732F23626561676C652E747874 pid=4797 comm="hexchat" requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000 | 19:36 |
| ogra | (hexchat obvously works just fine ... as i'm just typing in it ... but this line repeats every 10 sec or so, growing my logs) | 19:37 |
| ijohnson | ogra: you can decode the name there using aa-decode from the apparmor-utils package | 19:39 |
| ogra | ijohnson, ! | 19:41 |
| ogra | ijohnson, thanks a lot, that helps | 19:43 |
| mvo | kyrofa: hey, sorry for the slow reply. iirc the goyaml we use gives us a stable ordering, I can double check tomorrow | 20:12 |
| niemeyer | It does.. | 20:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!