| mborzecki | morning | 05:50 |
|---|---|---|
| mup | PR snapd#4726 opened: [2.31] systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4726> | 06:38 |
| mborzecki | mvo: morning | 06:39 |
| mvo | hey mborzecki, good morning | 06:39 |
| mvo | mborzecki: thanks for opening this pr! | 06:39 |
| mborzecki | mvo: do we have any idication that we'll be doing another point release? | 06:40 |
| zyga | good morning | 06:41 |
| mvo | hey zyga, good morning | 06:42 |
| mborzecki | zyga:hey | 06:42 |
| zyga | hey guys | 06:42 |
| zyga | mvo did the release happen | 06:42 |
| zyga | there were some issues last night | 06:42 |
| mvo | zyga: yeah, it happened but according to bret they use phased updates to push it out | 06:43 |
| zyga | mvo +1 to merge 4724 | 06:43 |
| zyga | mvo ah, good, I stopped following at around midnight | 06:44 |
| mborzecki | btw. i was browsing archlinxu forum the other day, and noticed this: https://bbs.archlinux.org/viewtopic.php?id=234301 apparently thre's a problem installing snaps when behind a firewall | 06:46 |
| mborzecki | i think we could set HTTP_PROXY in /etc/environment (or an equivalent) but that would be inconvenient if you change networks, eg. there's a need for a proxy on one network but not on another | 06:47 |
| mvo | mborzecki: hm, yeah, so I think one fix would be that snap (the client) passes the clients proxy env to snapd and snapd uses that. should be simple | 06:48 |
| zyga | mvo I think the way this is handled in real networks is different | 06:49 |
| mvo | mborzecki: iirc I talked to gustavo about it but he did not like it, but I don't remember why | 06:49 |
| zyga | mvo there's a function to call for each URL that gives you proxy data | 06:49 |
| mvo | zyga: thats how libproxy will do it | 06:49 |
| zyga | (or information not to proxy) | 06:49 |
| zyga | exactly | 06:49 |
| zyga | so depending on how far we are willing to go with it | 06:49 |
| mvo | tricky for us to do because of the snapd daemon restriction | 06:49 |
| zyga | I think it's still a bit simplistic as in corporations the auth is integrated but at least it is better than all-or-nothing | 06:50 |
| mborzecki | looked through stdlib source code, and it seems that HTTP_PROXY is supported | 06:50 |
| mvo | mborzecki: yes, but snapd will only read it from /etc/environment | 06:51 |
| mvo | there is a forum discussion but unfortunately inconclusive | 06:51 |
| mborzecki | uhh right, i meant i used that as indication that net/http can do proxy | 06:51 |
| mvo | aha, yes :) | 06:51 |
| mvo | https://forum.snapcraft.io/t/improve-proxy-configuration-for-snapd/942 fwiw | 06:52 |
| mborzecki | heh, all this proxy stuff is actually a bit awkward to me, i'm used to this being handled transparently by whatever trickery cisco or netgear employed | 06:54 |
| mborzecki | can #4719 be merged? | 07:09 |
| mup | PR #4719: timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4719> | 07:09 |
| mvo | mborzecki: how is the autostart going? anything interesting new here? | 07:12 |
| mup | PR snapd#4719 closed: timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4719> | 07:13 |
| mborzecki | mvo: trying to finish with timer services first, maybe i'll look into autostart a bit later today | 07:13 |
| mvo | mborzecki: yeah, timers are more important. thank you | 07:14 |
| mborzecki | linode:ubuntu-14.04-64:tests/main/refresh-all-undo failed again https://paste.ubuntu.com/p/wGwqr8MDSp/ | 07:19 |
| === Beret- is now known as Beret | ||
| pstolowski | heyas! | 07:59 |
| mvo | hey pstolowski ! good morning | 07:59 |
| zyga | hey :) | 07:59 |
| mvo | pstolowski: thanks for your review, I love the attrer stuff, much nicer than the naked map access | 08:00 |
| pstolowski | mvo, cool! | 08:00 |
| mborzecki | pstolowski: hey | 08:01 |
| pstolowski | #4716 anyone? it's trivial | 08:05 |
| mup | PR #4716: tests: make sure snapd is running before attempting to remove leftover snaps <Created by stolowski> <https://github.com/snapcore/snapd/pull/4716> | 08:05 |
| mvo | pstolowski: looking | 08:11 |
| pstolowski | mvo, ty! | 08:12 |
| mup | PR snapd#4716 closed: tests: make sure snapd is running before attempting to remove leftover snaps <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4716> | 08:12 |
| zyga | mvo can I land 4724 | 08:18 |
| zyga | it's just a trivial preparation for upcoming cleanup | 08:18 |
| kalikiana | good morning | 08:19 |
| zyga | hey kalikiana | 08:19 |
| mup | PR core#81 closed: 14-set-motd.chroot: updated based on the suggestions from Mark <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/81> | 08:21 |
| mup | PR snapd#4726 closed: [2.31] systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4726> | 08:23 |
| zyga | thanks mvo! | 08:24 |
| mup | PR snapd#4724 closed: osutil: aggregate mockable symbols <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4724> | 08:24 |
| zyga | hmm I think chipaca already mentioned this before | 08:25 |
| zyga | but I'm getting this | 08:25 |
| zyga | advisor/backend.go:199: literal copies lock value from *db: github.com/snapcore/snapd/vendor/github.com/snapcore/bolt.DB contains sync.Pool contains sync.noCopy | 08:25 |
| mvo | pstolowski: do you think we can get the limited reader into 2.32? would be nice to have that fix | 08:30 |
| mvo | pstolowski: is the status that it just needs a re-review? | 08:30 |
| pstolowski | mvo, yes, it needs re-review from Gustavo, but I applied the snippet he suggested (with only minor change), so perhaps you can make a call | 08:36 |
| mvo | pstolowski: thanks, this now looks very nice, I think its uncontroversial | 08:36 |
| mup | PR snapd#4584 closed: hooks/strutil: limit the number of data read from the hooks to avoid oom <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4584> | 08:36 |
| pstolowski | \o/ | 08:37 |
| pstolowski | mvo, shall I cherry-pick it and prepare a PR? | 08:37 |
| mup | PR snapd#4727 opened: many: simplify mocking of home-on-NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4727> | 08:37 |
| zyga | mvo this is a mostly red follow up I was talking about | 08:37 |
| zyga | this should also help with one of jdstrand's branches that adds overlayfs data to system key | 08:38 |
| mvo | zyga: my understanding is that 4140 just needs the rename and then things are ok? if so, sounds like something worth doing for 2.32 - wdyt? | 08:38 |
| mvo | zyga: it has +1 from jamie and you already and gustavo only objected the name afaict | 08:39 |
| zyga | yes, I agree | 08:39 |
| zyga | I can handle that if you want | 08:39 |
| zyga | ok, I'll carry on with mount business | 08:44 |
| mvo | zyga: either way is fine | 08:45 |
| pedronis | mvo: hi, how are things? when will we cut 2.32 ? | 08:54 |
| mvo | pedronis: once tests are green for the default-provider PR, looks like the store is a bit unhappy currently, but maybe it fixed itself | 08:56 |
| mvo | pedronis: anything you want in there? | 08:56 |
| pedronis | mvo: no, mostly wondering about my reorg/refactor PR that are green, whether I should hold them for post 2.32 | 08:58 |
| pedronis | or not | 08:58 |
| pedronis | mvo: you can look, #4715 #4722 | 08:58 |
| mup | PR #4715: store: reorg auth refresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/4715> | 08:58 |
| mup | PR #4722: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references <Created by pedronis> <https://github.com/snapcore/snapd/pull/4722> | 08:58 |
| mvo | pedronis: holding it for a little bit would be great | 08:59 |
| mup | PR snapd#4728 opened: store: move infoFromRemote into details.go close to snapDetails <Created by pedronis> <https://github.com/snapcore/snapd/pull/4728> | 09:05 |
| Chipaca | mo'in peeps | 09:08 |
| mvo | hey Chipaca ! good morning | 09:09 |
| pedronis | Chipaca: hi, if I understood the discussion yesterday, this would make refreshed/InstalledDate report a value closer to the intention: https://pastebin.ubuntu.com/p/4G8TDSQFsr/ | 09:12 |
| pedronis | ? | 09:13 |
| pedronis | as you said with that change no test fails, at least in daemon | 09:13 |
| pedronis | :/ | 09:17 |
| mvo | jdstrand: I was renaming the gnome-online-accounts-service to accounts-services as requested by gustavo. it looks like the store (basedeclartion) and review tools need an update (store is rejecting my test snap right now) | 09:19 |
| mvo | zyga: do you know if it is safe to just override this via manual review -^ | 09:19 |
| zyga | mvo I don't know if it is safe but I suspect that's what manual review is for | 09:21 |
| Chipaca | pedronis: I've got a branch already on spread for this | 09:24 |
| Chipaca | pedronis: and, well, close | 09:24 |
| Chipaca | pedronis: that'd work for squashes | 09:24 |
| Chipaca | pedronis: for it to work for everything you'd want it to be Lstat | 09:24 |
| Chipaca | my branch does that, but … then it takes a stand :-) | 09:25 |
| pstolowski | any known issue with lxd today? got 2 failures https://api.travis-ci.org/v3/job/345155633/log.txt | 09:25 |
| pedronis | Chipaca: anyway probably time to move this to methods on snap.Info I think | 09:25 |
| pedronis | whatever the stand | 09:25 |
| pedronis | Chipaca: I'm mostly interested in installedDate for snaps from the store | 09:26 |
| pedronis | fwiw | 09:26 |
| Chipaca | pedronis: I think you'll like my PR | 09:27 |
| zyga | pstolowski look at this | 09:27 |
| zyga | E: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list | 09:27 |
| Chipaca | mborzecki: why do you sometimes ask 'merge?' on PRs that are green and have two +1s? | 09:27 |
| zyga | "security" became "curity" | 09:27 |
| mborzecki | Chipaca: ahh, cause there's +1 with some comments, so just double checking that the changes i pushed are ok for those who reviewed | 09:29 |
| pstolowski | zyga, missed that, thanks. interesting | 09:29 |
| Chipaca | mborzecki: for myself, if I've +1'ed it with nits, it's because (a) i won't block the landing even if you don't fix them, and (b) i trust you to fix them; also (c) i'll shout if you mess it up and (d) git reset --hard @^^^^^ | 09:29 |
| mborzecki | hahah ok :) | 09:29 |
| pstolowski | zyga, that's inside the container, i don't think we generate sources.list do we? | 09:31 |
| zyga | I don't know | 09:31 |
| mup | PR snapd#4103 closed: snapstate: auto install default-providers for content snaps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4103> | 09:33 |
| mup | PR snapd#4677 closed: cmd/snap: introduce `snap run --timer` <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4677> | 09:34 |
| mup | PR snapd#4680 closed: snap: pass full timer spec in `snap run --timer` <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4680> | 09:35 |
| mup | PR snapd#4729 opened: many: drop snaps' InstallDate, introduce Updated <Created by chipaca> <https://github.com/snapcore/snapd/pull/4729> | 09:39 |
| Chipaca | pedronis: ^_^ | 09:39 |
| mborzecki | zyga: pstolowski: can you take another look at #4695 ? | 09:40 |
| mup | PR #4695: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695> | 09:40 |
| pedronis | Chipaca: I have bad news for you | 09:40 |
| Chipaca | pedronis: is it about potato fungus | 09:41 |
| pedronis | Chipaca: you expect last updated to be the creation time of the revision? | 09:43 |
| pedronis | on the store | 09:43 |
| Chipaca | pedronis: it … seemed to be; isn't it? | 09:44 |
| pedronis | I don't know | 09:47 |
| Chipaca | pedronis: bah, I guess it might be the creation time of the last revision, which might not be the one being pointed at? | 09:47 |
| pedronis | bu that's what the new api has | 09:47 |
| Chipaca | pedronis: that == creation time of the revision? | 09:47 |
| Chipaca | that's perfect :-) | 09:47 |
| pedronis | yes, but for the new api | 09:47 |
| Chipaca | right | 09:47 |
| pedronis | the old I don't know | 09:47 |
| pedronis | I can check | 09:48 |
| pstolowski | mborzecki, sure | 09:48 |
| pedronis | just that this value might be a bit confusing for remote for a bit | 09:48 |
| Chipaca | pedronis: please check (no rush); depending on what it is, the confusion might not be terrible | 09:48 |
| Chipaca | for example if it's the timestamp of the latest revision, i don't mind | 09:49 |
| Chipaca | if it's the timestamp of the last time you changed something via the web, i do mind :-) | 09:49 |
| pedronis | Chipaca: no, it's the timestamp of the creation of the revision under consideration also for the old api | 09:51 |
| pedronis | at least as server by modern infra | 09:52 |
| * Chipaca dances | 09:52 | |
| pedronis | (it might have been something else at some point in the past) | 09:52 |
| pedronis | Chipaca: your PR and my last PR will conflict :/ | 09:52 |
| Chipaca | pedronis: I don't mind deconflicting | 09:52 |
| Chipaca | pedronis: hurry up and land it :-D | 09:52 |
| Chipaca | mine is small (if spread out) | 09:53 |
| pedronis | mvo told me to wait | 09:53 |
| pedronis | anyway I need reviews, but is trivial: #4728 | 09:53 |
| mup | PR #4728: store: move infoFromRemote into details.go close to snapDetails <Created by pedronis> <https://github.com/snapcore/snapd/pull/4728> | 09:53 |
| Chipaca | psh, who listens to mvo | 09:53 |
| Chipaca | pedronis: conflict! :-) | 09:53 |
| pedronis | not on that PR | 09:53 |
| pedronis | I suppose on the based one | 09:54 |
| pedronis | or maybe yes | 09:54 |
| pedronis | ah, conflict with mvo stuff | 09:54 |
| pedronis | I'll have fun for a bit I fear | 09:54 |
| pedronis | mmh, not, it's really only this one | 09:55 |
| pedronis | I'll just wait at this point | 09:55 |
| Chipaca | I could stack mine on yours | 09:56 |
| Chipaca | that'd make it a fun review for people | 09:56 |
| Chipaca | I hear they really like wading through huge changes | 09:56 |
| pedronis | Chipaca: my in progress new api stuff is +-3000 lines (I will split it, but a chunk will still be +1000 mostly tests) | 09:57 |
| Chipaca | I shall endeavour to nitpick it to death in detail | 09:58 |
| mborzecki | prereqSuite.TestDoPrereqRetryWhenBaseInFlight failed on master https://paste.ubuntu.com/p/qwbkSCGm3K/ | 10:06 |
| mborzecki | i've restarted the travis build, see if reproduces again | 10:07 |
| zyga | I saw a few failures related to store hicckups todaty | 10:08 |
| zyga | *today | 10:08 |
| zyga | but nothing major | 10:08 |
| zyga | (just annoying) | 10:08 |
| Chipaca | fatal: unable to access 'https://go.googlesource.com/crypto/': The requested URL returned error: 502 | 10:10 |
| Chipaca | if that's any consolation, I've got a failure related to google hiccup | 10:10 |
| pedronis | Chipaca: couple of initial small comments | 10:12 |
| Chipaca | pedronis: I'm not sure my 'open question' is clear: I thought of having it show "updated" (or even "last-updated") for remotes, but that leaves locals with "refreshed" which IMHO isn't ideal either | 10:12 |
| pedronis | update is strange for remotes | 10:12 |
| pedronis | let me think | 10:13 |
| * Chipaca lets pedronis think, and goes off to physio | 10:13 | |
| pedronis | Chipaca: I don't think we want to print something for remotes | 10:13 |
| pedronis | we would want dates in the channel | 10:13 |
| pedronis | s | 10:13 |
| pedronis | we don't print a top revision either | 10:14 |
| pedronis | for remote infos | 10:14 |
| pedronis | it's a bit strange to put a date there without the revision | 10:14 |
| pedronis | Chipaca: are you seeing what I'm referring to? | 10:16 |
| Chipaca | I think we do want dates in the map, yes | 10:17 |
| pedronis | I'm saying if you put a date at top-level | 10:17 |
| Chipaca | the confusing munge of revisioned and revisionless info in the store results is confusing, yes | 10:17 |
| pedronis | is very unclear what it refers to | 10:17 |
| pedronis | unless you mention the channel | 10:18 |
| zyga | Chipaca on your way, can you look at the idea behind https://github.com/snapcore/snapd/pull/4727 | 10:18 |
| mup | PR #4727: many: simplify mocking of home-on-NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4727> | 10:18 |
| Chipaca | but I do think having it is valuable, as long as it refers to what the user gets when they just ask for the snap without qualifying it | 10:18 |
| Chipaca | (which is, i think, what it does) | 10:18 |
| zyga | just mocking the function instead of what the function depends on | 10:18 |
| pedronis | Chipaca: last-stable-updated ? | 10:18 |
| pedronis | I just fear whatever we do right now, we will regret/have to change it again | 10:19 |
| pedronis | Chipaca: or you could think how you want dates in the channels, and start putting in only the one for stable? | 10:20 |
| Chipaca | that'd work rather well actually | 10:21 |
| Chipaca | bah | 10:21 |
| Chipaca | sorta-kinda | 10:21 |
| pedronis | but also I don't know | 10:21 |
| pedronis | how to add a date | 10:21 |
| pedronis | there | 10:21 |
| pedronis | without thinking as breaking format | 10:21 |
| Chipaca | pedronis: note I try to use the exact same layout for 'installed:' as I do for channels | 10:21 |
| Chipaca | but it'd be weird for that to change when you installed the snap | 10:21 |
| Chipaca | hmmmm | 10:22 |
| pedronis | yes, it's a bit the problem I mentioned, it is strange to use one field for a value that is available remotely | 10:22 |
| pedronis | but turns into a different value locally | 10:22 |
| Chipaca | pedronis: how about, for local snaps just leave it as 'refreshed', and for remotes just add the one for the latest stable as a comment to channels | 10:23 |
| pedronis | might be ok | 10:23 |
| Chipaca | ie: channels: # latest stable from YYYY-mm-ddTHH:MM:SSZZZ | 10:23 |
| pedronis | ah | 10:24 |
| pedronis | like that | 10:24 |
| * pedronis was confusing notes and comments | 10:24 | |
| Chipaca | pedronis: do you think 'updated' is ok in the api? | 10:24 |
| pedronis | it's getting a baroque | 10:24 |
| * Chipaca prefers the term 'neo-rococo' | 10:24 | |
| pedronis | :) | 10:25 |
| pedronis | Chipaca: my question is whether we want different fields for local vs remote | 10:26 |
| pedronis | that's annoying in different ways though | 10:27 |
| Chipaca | I mean, if we're going for full clarity we'd go with "last-stable-revision-created-on" and "snap-downloaded-on" and "try-created-on" | 10:28 |
| Chipaca | ¯\_(ツ)_/¯ | 10:28 |
| zyga | 4th failure on trivial PR :/ | 10:31 |
| zyga | oh, this time racy unit tests | 10:31 |
| zyga | FAIL: handlers_prereq_test.go:155: prereqSuite.TestDoPrereqRetryWhenBaseInFlight | 10:31 |
| zyga | handlers_prereq_test.go:186: | 10:32 |
| zyga | // check that t is not done yet, it must wait for core | 10:32 |
| zyga | c.Check(t.Status(), Equals, state.DoingStatus) | 10:32 |
| zyga | ... obtained state.Status = 4 ("Done") | 10:32 |
| zyga | ... expected state.Status = 3 ("Doing") | 10:32 |
| mborzecki | ok, so it's only me seeing this | 10:32 |
| mborzecki | reproducible locally | 10:34 |
| ogra_ | mvo, pedronis https://forum.snapcraft.io/t/using-content-for-a-role-system-data-partition-makes-it-not-be-system-data-anymore | 10:43 |
| pedronis | sounds a ubuntu-image issue | 10:46 |
| pedronis | I don't think prepare-image deals at level | 10:46 |
| mvo | mborzecki: uh, that race looks like I caused it. sorry for this | 10:47 |
| pedronis | *at that level | 10:47 |
| mborzecki | mvo: are you looking into it or should i? | 10:53 |
| mvo | mborzecki: I am not looking right now, need to prepare lunch in a wee bit :( | 10:53 |
| mborzecki | mvo: ok, i'll take a look then | 10:53 |
| zyga | mborzecki I'm not looking either, sorry | 10:54 |
| mvo | mborzecki: thank you! if you get stuck let me know | 11:01 |
| mup | PR snapd#4730 opened: userd/tests: Test kdialog calls and mock kdialog too to make tests work in KDE <Created by stolowski> <https://github.com/snapcore/snapd/pull/4730> | 11:19 |
| pstolowski | mvo, can you take a look at #4730 ^ ? | 11:19 |
| mup | PR #4730: userd/tests: Test kdialog calls and mock kdialog too to make tests work in KDE <Created by stolowski> <https://github.com/snapcore/snapd/pull/4730> | 11:19 |
| pstolowski | we fail on KDE currently :} | 11:19 |
| zyga | sigh | 11:31 |
| zyga | (not about kde) | 11:31 |
| zyga | gaaah | 11:38 |
| pstolowski | mvo, the prereq unit test seems to be flaky | 11:39 |
| pstolowski | mvo, https://pastebin.ubuntu.com/p/k5MpksjvrN/ | 11:39 |
| zyga | so | 11:39 |
| pstolowski | mvo, (this is from master) | 11:39 |
| zyga | I now feel I need to implement a little bit of path traversing, mount table traversing logic in userspace | 11:39 |
| pstolowski | mvo, also got this failure in travis a moment ago on my pr - https://api.travis-ci.org/v3/job/345185500/log.txt | 11:40 |
| zyga | the simple check grew a little bit that I started to write prose comment that barely fits on my 27" screen :/ | 11:40 |
| zyga | pstolowski mborzecki ran into it too | 11:41 |
| zyga | (and me too) | 11:41 |
| pstolowski | zyga, ah indeed, just looked at the backlog | 11:41 |
| mborzecki | pstolowski: i'm looking into it atm | 11:41 |
| pstolowski | mborzecki, great, thanks | 11:41 |
| zyga | jdstrand I'm a bit depressed again :) | 11:42 |
| zyga | about that mount verification | 11:42 |
| zyga | it's one notch harder than I thought yesterday | 11:42 |
| zyga | and that's with constraints I don't know if are reasonable (not a generic solution for sure) | 11:42 |
| zyga | this is all because there's no frelling MS_NOFOLLOW in mount | 11:43 |
| * cachio_ afk | 11:44 | |
| mborzecki | ok, so here's a small problem with that test, it assumes that tasks are run in the runner in a specific order, however the runner takes the list of tasks to run by calling State.Tasks(), interlly State.tasks is a map, so when you range the order is not guaranteed, and so it happens that sometimes one task runs before the other | 11:56 |
| pstolowski | mborzecki, is there a reason we don't translate mon-fri to mon..fri, but expand all the days? not biggie at all, just curious; i guess it's just more straightforward to always expand? | 11:56 |
| mborzecki | pstolowski: yes, easier to expand | 11:57 |
| pstolowski | mborzecki, in certain cases we force the order by task.WaitFor(another task) | 11:57 |
| pstolowski | mborzecki, ack, that's fine, thanks | 11:58 |
| mborzecki | pstolowski: i think the idea in this case is not to use waitfor, but rather detect that a change we need is in flight and retry later | 11:58 |
| pstolowski | mborzecki, right, i see that now | 11:59 |
| pstolowski | mborzecki, perhaps we need a dummy task that holds link-snap task, then we mark it done in a controlled way, and that unblocks prereq task | 12:01 |
| zyga | mborzecki nice analysis | 12:01 |
| * pstolowski lunch | 12:08 | |
| Chipaca | zyga, ondra: bug#1750059 might be of interest to you | 12:23 |
| Chipaca | for different reasons | 12:23 |
| Chipaca | you know that thing where you plan to replace a bit of hardware because it's getting old, and it immediately starts showing even more signs of old age, as if resenting its replacement? my notebook now chirps when i adjust the brightness | 12:25 |
| ondra | Chipaca :) | 12:25 |
| ondra | Chipaca thanKs for bug info! | 12:25 |
| Chipaca | ondra: integration-y thing with a workaround, thought you'd like to have it on the radar | 12:26 |
| pedronis | mborzecki: pstolowski: I think s.snapmgr.AddAdhocTaskHandler can probably be abused to get a controllable link-snap | 12:29 |
| pedronis | for that test | 12:29 |
| zyga | Chipaca ack, queued | 12:31 |
| mborzecki | pedronis: and return state.Retry{} in the handler? | 12:31 |
| pedronis | mborzecki: or wait on a channel before returning | 12:31 |
| mborzecki | pedronis: right, i've started adding some mocks to taskrunner, but your suggestion may be better | 12:32 |
| zyga | Chipaca interesting | 12:32 |
| Chipaca | I wonder if there's a way to tell systemd "this service uses that path" | 12:33 |
| pedronis | mborzecki: is just a way to get to call AddTaskHandler again, that is already there... the latter seems not to worry about overriding. is used in a very controlled way so seems fine as is | 12:34 |
| pedronis | sorry AddHandler | 12:34 |
| mborzecki | Chipaca: one of the BindsTo or one of it's friends perhaps? | 12:35 |
| ogra_ | pedronis, so looking through the sources i'm not that sure it is an ubuntu-image issue ... prepare-image unpacks the gadget but does not move the content to the "image" dir ... https://paste.ubuntu.com/p/6MbNxJ6574/ | 12:35 |
| Chipaca | mborzecki: MagicallyFrobnicatesInto | 12:36 |
| Chipaca | mborzecki: somebody should write https://git-man-page-generator.lokaltog.net/ but for systemd directives | 12:37 |
| zyga | jdstrand around? | 12:40 |
| pedronis | ogra_: afaik the only bit that prepare-image is the bootloader conf, and cloud bits | 12:42 |
| pedronis | *prepare-image copies | 12:42 |
| ogra_ | pedronis, right thats the issue i guess | 12:42 |
| ogra_ | if i'm allowed to define "content:" in the yaml for the writable partition it should copy that too ... | 12:43 |
| pedronis | it does even look at Volumes | 12:43 |
| ogra_ | ... and if i'm not allowed it should error out and not silently swallow the files | 12:43 |
| pedronis | it's a ubuntu-image problem | 12:43 |
| pedronis | as far as I understand | 12:43 |
| pedronis | content: is definitely a problem of ubuntu-image | 12:44 |
| pedronis | we don't even read the gadget.yaml afaict | 12:44 |
| pedronis | anyway, mvo may be a better person to discuss this with | 12:44 |
| ogra_ | k | 12:44 |
| zyga | anyone interested in reading a bit of prose about an algorithm I'm writing | 12:48 |
| zyga | to spot any logic holes? | 12:48 |
| Chipaca | zyga: o/ | 12:49 |
| mvo | pstolowski: thanks, I will look at the prereq unit test, mborzecki did some analyisis as well | 12:50 |
| mvo | ogra_: I have a look at the forum post in a little bit | 12:50 |
| zyga | Chipaca https://pastebin.ubuntu.com/p/Jnw6KSHsrj/ | 12:53 |
| ogra_ | mvo, thx | 12:54 |
| zyga | Chipaca this will be in a PR sometime after standup, I'm still working on the logic below the comment | 12:54 |
| zyga | s/ant/and/ | 12:54 |
| zyga | (in the text) | 12:54 |
| ogra_ | btw .. for everyones friday entertainment ... https://github.com/npm/npm/issues/19883 | 12:54 |
| mborzecki | ogra_: sudo thing? | 12:55 |
| ogra_ | mborzecki, well, npm thing :) | 12:55 |
| ogra_ | (randomly changing permissions if it can ... if sudo is used it changes them to the uid of the calling user, not to root ... if you do it as root user everything becomes 777 root:root ) | 12:56 |
| pstolowski | wow | 12:58 |
| pstolowski | havoc | 12:59 |
| Chipaca | zyga: is the second column in mountinfo the minor? | 13:00 |
| zyga | no | 13:00 |
| zyga | parent mount id | 13:00 |
| Chipaca | zyga: ah, mount id, parent, major:minor? | 13:00 |
| zyga | correct | 13:00 |
| Chipaca | zyga: I followed that explanation | 13:01 |
| zyga | Chipaca standup :) | 13:01 |
| Chipaca | zyga: as an intro it's nice | 13:01 |
| Chipaca | zyga: missing chapter 2, the attack, and chapter 3, the narrow escape | 13:01 |
| niemeyer | Sorry, running late for the standup | 13:02 |
| niemeyer | Will be there in ~2min | 13:02 |
| zyga | Chipaca and I should name characters better | 13:02 |
| Son_Goku | zyga, did you get a chance to fix the new error from gcc8? | 13:05 |
| zyga | Son_Goku no, sorry, I will task switch to that as soon as the standup is over | 13:09 |
| zyga | I'm sorry about that, I'll ensure it builds on f27 | 13:09 |
| jdstrand | mvo: yes, they would. let me look | 13:19 |
| zyga_ | jdstrand hey :) | 13:19 |
| zyga_ | jdstrand I will have some things to discuss with you today | 13:19 |
| zyga_ | one more important than other, let me know when it would be a good time for you | 13:19 |
| jdstrand | zyga_: hey, saw your pings | 13:19 |
| jdstrand | gimme a little bit (just came online) | 13:20 |
| zyga_ | sure, no rush :) | 13:20 |
| mup | PR snapd#4729 closed: many: drop snaps' InstallDate, introduce Updated <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4729> | 13:21 |
| jdstrand | mvo: can you request a manual review of the snap? | 13:24 |
| * kalikiana lunch time, omnomnom | 13:25 | |
| mup | PR snapcraft#1950 closed: elf: better debug messages <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1950> | 13:27 |
| ogra_ | wow | 13:33 |
| ogra_ | so my hexchat just stopped working out of the blue ... | 13:34 |
| ogra_ | ... window greying out being completely unresponsive | 13:34 |
| ogra_ | (this is the snap ) | 13:34 |
| jdstrand | zyga_: MS_NOFOLLOW - tell me about it | 13:34 |
| ogra_ | checking syslog is see: | 13:34 |
| ogra_ | Feb 23 14:32:46 acheron kernel: [88729.701886] audit: type=1326 audit(1519392766.679:127): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=8453 comm="hexchat" exe="/snap/hexchat/17/bin/hexchat" sig=31 arch=c000003e syscall=93 compat=0 ip=0x7f11a51c0337 code=0x0 | 13:34 |
| jdstrand | zyga_: ok, I read backscroll and the paste | 13:35 |
| zyga_ | jdstrand haha, it's just my wish for a simpler life | 13:35 |
| ogra_ | jdstrand, how can that happen ^^^... i'm using that snap since over a month without probs | 13:35 |
| zyga_ | jdstrand so, my main request to you is to look at the pastebin you have to see if the text makes sense | 13:35 |
| zyga_ | jdstrand my 2nd request is to look at this denial | 13:35 |
| zyga_ | [13:08:31] <sparkiegeek>[341123.064261] audit: type=1400 audit(1519387698.054:1895): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-snapstore-clean-test_</var/lib/lxd>" name="/tmp/snap.rootfs_XZQtTO/var/lib/snapd/lib/vulkan/" pid=11221 comm="snap-confine" flags="ro, remount" | 13:35 |
| jdstrand | ogra_: it took a code path that you never hit before. maybe it rotated a log or something? | 13:35 |
| zyga_ | this is inside a container on 17.10 (the container is 16.04) | 13:35 |
| jdstrand | ogra_: chown strikes again | 13:36 |
| zyga_ | we can discuss that separately | 13:36 |
| jdstrand | ogra_: snapcraft-preload may help. but tyhicks and mvo are discussing the eperm PR trying to come up with how to land it | 13:36 |
| zyga_ | jdstrand or and just 3rd thing that came up a second ago: https://forum.snapcraft.io/t/screen-inhibit-control-denial-interface-broken/4173/5?u=zyga | 13:36 |
| * zyga_ gets back to the standup | 13:37 | |
| jdstrand | zyga_: I read the pastebin. I think it is pretty ingenious tbh. I want to think about it a little | 13:37 |
| zyga_ | that last thing is a one character patch for the interface rules | 13:37 |
| * zyga_ blushes | 13:37 | |
| jdstrand | I thought I fixed that interface with a one char patch! dang it | 13:37 |
| zyga_ | jdstrand not in master :) | 13:37 |
| jdstrand | zyga_: I didn't fix that one. I'm happy to send that up as penance if you haven't already | 13:38 |
| zyga_ | no, I haven't yet :) | 13:38 |
| zyga_ | I'm bad at keeping multiple git trees and I don't like to stash mid-patch like that | 13:39 |
| ogra_ | (i actually had to install the deb to chat here now ... the snap worked fine for the time i use it and there are no other denials like this before it started to hang hard) | 13:39 |
| ogra_ | (syscall 93 is fchown ... it doesnt call that usually) | 13:39 |
| ogra_ | (neither core nor the snap were updated either) | 13:39 |
| ogra_ | jdstrand, well, i'm only a user of that snap ... but it is a really bad experience if your app all of a sudden turns unresponsive (in the middle of typing) without and error or anything ... and also doesnt start anymore | 13:40 |
| ogra_ | (i know that snapcraft-preload helps .. but how would my mom know that if her app suddenly stops working ) | 13:41 |
| ogra_ | we might need to make snapcraft-preload mandatory .. | 13:41 |
| ogra_ | (i.e. a builtin thing that everyone uses) | 13:41 |
| jdstrand | zyga_: sparkiegeek should file a snap bug, with exact steps to reproduce, including kernel version, lxd version, distro, core snap version, command, etc | 13:43 |
| zyga_ | jdstrand ack, I will reproduce this and explore | 13:45 |
| zyga_ | jdstrand I don't understand why that profile name shows up running snap-confine there | 13:45 |
| zyga_ | I was expecting snap-confine's profile | 13:45 |
| jdstrand | ogra_: your mom isn't expected to fix that. the developer of the snap is expected to make sure the snap is usable. forcing existing applications that weren't designed to run in a sandbox is always going to be tricky, and applications are complex | 13:45 |
| ogra_ | i totally understand that ... but even a developer wouldnt know ... | 13:46 |
| jdstrand | ogra_: so your snap unfortunately hit a code path it never did before. you could grep the source looking for chown, but it might be in a lib | 13:46 |
| ogra_ | and an enduser would probably not even report it to upstream or the dev | 13:46 |
| jdstrand | I would report it. "my snap all of a sudden stopped working". just like you did :) | 13:46 |
| jdstrand | I mentioned the PR for a reason though | 13:47 |
| jdstrand | the snap, today, isn't in a position to handle the kill signal | 13:47 |
| ogra_ | right ... if i run it from a terminal i cant even ctrl-c it | 13:47 |
| ogra_ | (killing the pid from another terminal works) | 13:48 |
| jdstrand | but the pr I mentioned turns the kill into an eperm which means that if the snap didn't check the error code (many don't with chown(myuid, mygroup)) then it continues to work | 13:48 |
| jdstrand | if it does check the error code, it can bubble that up to the user | 13:48 |
| ogra_ | thats good | 13:48 |
| jdstrand | that pr got hung up, but I started poking people about it and they're thinking about ways to unwedge it | 13:49 |
| jdstrand | the real fix will be the user/group stuff | 13:49 |
| jdstrand | because part of that work will be allowing the use of chowning to yourself unconditionally | 13:50 |
| ogra_ | right ... | 13:50 |
| jdstrand | (since, why not?) | 13:50 |
| ogra_ | i just wouldnt want to see random desktop snaps to just stop working like that | 13:50 |
| jdstrand | but that is dependent on a tricky issue that is fixable in libseccomp | 13:50 |
| jdstrand | of course | 13:50 |
| ogra_ | if there is a fix in the works that is acting globally thats fine i guess | 13:50 |
| jdstrand | chown aside, unless you have full coverage in your blackbox testing, you'll never *really* know if the application-not-designed-for-confinement doesn't have a lurking bug in a rarely used code path | 13:52 |
| ogra_ | indeed | 13:52 |
| Chipaca | niemeyer: mborzecki 1.9 added monotonic clocks | 13:53 |
| Chipaca | fwiw | 13:53 |
| mup | PR snapd#4731 opened: overlord/snapstate: fix task iteration order in TestDoPrereqRetryWhenBaseInFlight <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4731> | 13:54 |
| mborzecki | mvo: ^^ | 13:54 |
| mup | PR snapd#4140 closed: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4140> | 13:55 |
| ogra_ | ogra@acheron:~/Devel/branches/hexchat$ grep -r chown * | 13:55 |
| ogra_ | ogra@acheron:~/Devel/branches/hexchat$ | 13:55 |
| ogra_ | *sniff* ... | 13:55 |
| ogra_ | no obvious chown call in the source | 13:56 |
| jdstrand | probably in an underlying lib | 13:57 |
| jdstrand | does it use sqlite? | 13:57 |
| ogra_ | not by what i can see from the deb dependencies | 13:58 |
| ogra_ | Depends: hexchat-common (= 2.10.2-1ubuntu3), libc6 (>= 2.14), libcanberra0 (>= 0.2), libdbus-glib-1-2 (>= 0.88), libgdk-pixbuf2.0-0 (>= 2.25.2), libglib2.0-0 (>= 2.41.1), libgtk2.0-0 (>= 2.24.0), libnotify4 (>= 0.7.0), libpango-1.0-0 (>= 1.29.4), libproxy1v5 (>= 0.4.11), libssl1.0.0 (>= 1.0.0) | 13:58 |
| Chipaca | of those, i'd start looking at libproxy | 13:58 |
| ogra_ | funnily if i wipe all user data it works | 13:59 |
| ogra_ | so it must try to move something around in the cache, logs or whatnot i guess | 13:59 |
| niemeyer | Chipaca: But was the bug really only fixed in 1.9? | 14:00 |
| Chipaca | niemeyer: it's not a bug | 14:00 |
| niemeyer | I had secret hopes that the bug would have been fixed earlier | 14:00 |
| Chipaca | :-) | 14:00 |
| Chipaca | the kernel has two clocks, before 1.9 go only used the one that goes to sleep with the machine | 14:01 |
| Chipaca | after it, every time.Time is _two_ times | 14:01 |
| niemeyer | Chipaca: It is a bug from the perspective of the Go API specifically, in the sense of breaking the most obvious expectation | 14:01 |
| mvo | niemeyer, pedronis desktop team meeting? | 14:01 |
| Chipaca | niemeyer: yes, obviously | 14:01 |
| Chipaca | niemeyer: I was more making fun at googlers never putting their servers to sleep | 14:02 |
| pedronis | mvo: there's no HO specified afaict | 14:02 |
| niemeyer | mvo: Where is it? | 14:02 |
| mvo | pedronis: I /msged it | 14:03 |
| mup | PR snapd#4732 opened: [2.31] timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4732> | 14:12 |
| jdstrand | mvo: fyi, I updted the review-tools for accounts-service. please request a manual review for the snap (I still don't see it). it won't be in prod til next week | 14:20 |
| mborzecki | Chipaca: is the snapd.refrehs.timer enabled by default on ubuntu? | 14:20 |
| jdstrand | ah, roadmr must've sensed I was looking for him | 14:20 |
| jdstrand | roadmr: good morning! :) | 14:20 |
| roadmr | hi jdstrand :) | 14:21 |
| zyga_ | jdstrand I'm going ahead with implementation and tests, if you find a loophole in the idea please let me know | 14:21 |
| roadmr | how can I help? | 14:21 |
| jdstrand | roadmr: can you make that r1005 instead? | 14:21 |
| roadmr | jdstrand: totally! | 14:21 |
| jdstrand | roadmr: just a small rename of an interface | 14:21 |
| Chipaca | mborzecki: it is, or it has been at some point | 14:21 |
| jdstrand | zyga_: getting back to it now | 14:21 |
| roadmr | jdstrand: sure thing! | 14:21 |
| cjwatson | ~/wg 40 | 14:22 |
| cjwatson | gah, sorry | 14:22 |
| * jdstrand wonders why *every* morning has a gagillion little things | 14:22 | |
| zyga_ | not every morning, just weekdays :-) | 14:22 |
| === zyga_ is now known as zyga | ||
| jdstrand | zyga: well, they are there on the weekends too. monday is a 1/2 to 3/4 of a day of little things. some not so little ;) | 14:23 |
| roadmr | jdstrand: I bet because people in Europe spend *their* morning devising ways to make yours more interesting ;) | 14:23 |
| jdstrand | haha | 14:23 |
| jdstrand | roadmr: sometimes I really do wonder about that :) | 14:23 |
| zyga | haha, that's actually regularly true :) | 14:23 |
| * zyga loves the moment when jdstrand joins | 14:23 | |
| jdstrand | zyga: let me summarize the paste so I have it all straight | 14:24 |
| jdstrand | zyga: before doing anything, you snag mountinfo. you reconstruct it in the way described. we know that we can depend on st_dev because the kernel keeps track of that sensibly | 14:27 |
| jdstrand | zyga: so we can map the st_dev to the mount from before. we do the operation, and check that we have a (st_dev)/thing | 14:28 |
| jdstrand | if we do, then we're good, if we don't, it 'mismounted' | 14:28 |
| jdstrand | (or failed, but we would've already died if we failed) | 14:29 |
| zyga | more or less yes | 14:29 |
| jdstrand | yes, I was summarizing | 14:29 |
| zyga | the reconstruction happens on the "after" []mountinfo | 14:29 |
| jdstrand | so, all of this is happening on tmpfs, which is the problem | 14:29 |
| zyga | we use before and after together to see what is new | 14:29 |
| zyga | and only consider those entries as possible solutions | 14:29 |
| jdstrand | and XDG_RUNTIME_DIR is tmpfs | 14:30 |
| jdstrand | so /run/user/uid needs to be mapped to the st_dev | 14:30 |
| zyga | yeah, that's fine | 14:30 |
| jdstrand | zyga: doesn't this lift the requirement that it must not be a mount point? | 14:30 |
| zyga | yes, it does | 14:31 |
| zyga | I dropped that | 14:31 |
| jdstrand | right | 14:31 |
| zyga | oh | 14:31 |
| zyga | it's not in the paste :D | 14:31 |
| zyga | https://pastebin.ubuntu.com/p/bPZv9mPnxk/ | 14:31 |
| zyga | those are the new rules | 14:31 |
| zyga | 3 is the "no race" thing | 14:31 |
| zyga | and that's all | 14:31 |
| jdstrand | zyga: ok | 14:32 |
| zyga | I dropped the writability and mount entry constraints | 14:32 |
| zyga | as the race detector should be a superset of that anyway (for malicious intents) | 14:32 |
| zyga | jdstrand I'll break for lunch now but if you think about anything that I missed just drop me a note please | 14:33 |
| Chipaca | pedronis: have you an opinion on where 'InstallDate' should live, if I were to add it to something info-ish? | 14:33 |
| Chipaca | otherwise I'll keep this PR super-minimal | 14:34 |
| jdstrand | zyga: so, you are using the diff between before and after to narrow down what you need to look at, correct? | 14:34 |
| jdstrand | zyga: so for something like /some/arbitrary/mount/point, you'll see /some/arbitrary/mount/point show up, so then you look for /some/arbitrary/mount, /some/arbitrary, /some and / to calculate the st_dev to look for? (in that order) | 14:35 |
| * Chipaca goes with minimal | 14:37 | |
| pedronis | Chipaca: I'm in a meeting | 14:40 |
| Chipaca | pedronis: no worries | 14:40 |
| Chipaca | i can do followups | 14:40 |
| kalikiana | re | 14:43 |
| mvo | jdstrand: ta, I can accept those too | 14:51 |
| mvo | jdstrand: thanks for adding it | 14:51 |
| mvo | jdstrand: I will later push s390x, armhf etc binaries for testing | 14:51 |
| jdstrand | mvo: if you request the manual review, you can't accept it yourself | 14:51 |
| jdstrand | mvo: or if you do the upload | 14:51 |
| jdstrand | so, if you need me, ping me | 14:52 |
| mvo | ta | 14:52 |
| zyga | jdstrand the before after view is indeed to look at the diff and constraint the set of allowed solutions to the diff | 14:53 |
| brunosfer | Does anyone knows where to find good documentation regarding the upload of snaps to the store? | 14:53 |
| jdstrand | zyga: and you go bottom up looking for the parent st_dev? | 14:54 |
| zyga | jdstrand as for the second question, if I understand you correctly that is indeed how we find what is /some/arbitrary/mount/point | 14:54 |
| zyga | yes | 14:54 |
| jdstrand | right | 14:54 |
| zyga | when thinking about this I also considered something else: | 14:54 |
| zyga | using mount id, parent id to construct a tree of mounts | 14:54 |
| zyga | but I don't know if that is needed for any of the results yet (maybe it is but we haven't seen a case that shows this) | 14:55 |
| pedronis | Chipaca: I think it should go at the level of Broken | 14:56 |
| jdstrand | ok. please proceed. this is a nice idea considering the limitation of the mount api | 14:56 |
| jdstrand | zyga: I don't think that is necessary otoh | 14:57 |
| zyga | thanks! :-) | 14:57 |
| jdstrand | zyga: I'm probably going to ask Tyler to do a final review after you and I are happy | 14:57 |
| zyga | thanks | 14:57 |
| zyga | I also wondered if anyone else solved this | 14:57 |
| zyga | it seems like a common problem for software | 14:58 |
| roadmr | software sucks? | 14:58 |
| zyga | roadmr without doubt :) | 14:58 |
| zyga | if it was a hardware problem we could recycle it | 14:59 |
| zyga | in software we have to support it :) | 14:59 |
| roadmr | hah well my mom has this ancient PC from the 1990s and I have to support it :( | 15:01 |
| roadmr | probably the last PC on the planet with a 5.25" floppy drive | 15:01 |
| ikey | s/5.25"// | 15:04 |
| zyga | I have a USB floppy drive | 15:05 |
| ikey | that seems wrong | 15:05 |
| ikey | lol | 15:05 |
| zyga | I could plug it to my thunderbolt port via an adapter | 15:05 |
| zyga | :D | 15:05 |
| zyga | thunderfloppy | 15:05 |
| ikey | hispeed ™ | 15:05 |
| zyga | feeling the 40GB/s bandwidth right | 15:05 |
| zyga | of that *high-density* floppy | 15:05 |
| ogra_ | you typoed a G there .. | 15:05 |
| ikey | xD | 15:06 |
| zyga | I think that's hippiespeed :) | 15:06 |
| ikey | ah they were simpler times | 15:06 |
| ikey | when tapes and floppies challenged us with write protect tabs and we lol'd | 15:06 |
| zyga | and we had non-rootkit copy protection :) | 15:06 |
| ikey | ah see we approached that idea differently there :P | 15:06 |
| zyga | and computer magazines (and no interneet) | 15:06 |
| ikey | i thought i was a yuppie the first time i ever burnt a CD | 15:07 |
| ikey | tbf i had to "save up" all the things i wanted downloaded before i used the CD to transfer them | 15:07 |
| ikey | cuz CD-Rs were expensive >_> | 15:07 |
| ikey | im not proud to admit the JDK was on that. | 15:07 |
| zyga | I paid a colleague who carried the money to a guy across town, who had a recorder | 15:07 |
| ikey | like the instrument or an actual recorder? | 15:08 |
| ikey | cuz one makes more sense | 15:08 |
| zyga | I mean a CD recorder :) | 15:08 |
| ikey | xD | 15:08 |
| ikey | sorry having a friday yolo mood here. :p | 15:08 |
| zyga | that's all right | 15:08 |
| zyga | I deal with mount tables | 15:08 |
| zyga | I have that mood all the time | 15:08 |
| ikey | yeah saw the tweet | 15:08 |
| zyga | :D | 15:08 |
| ikey | my heart goes out to you | 15:08 |
| zyga | but hey | 15:08 |
| zyga | I'm proud I wrote something nice for a change | 15:09 |
| zyga | https://pastebin.ubuntu.com/p/Jnw6KSHsrj/ | 15:09 |
| ikey | "pls mount read-only" "yes i will" "why is it writable" "remount as RO pls" | 15:09 |
| zyga | or why kernel should have gotten that flags argument on mount to support MS_NOFOLLOW but.. yeah | 15:09 |
| ikey | mm | 15:09 |
| ikey | broken heap of ouch | 15:09 |
| ikey | that.. is quite the doc | 15:09 |
| zyga | yeah, would be easier to add MS_NOFOLLOW | 15:10 |
| ikey | anyone else ever read that MS as.. yknow.. that MS? | 15:11 |
| roadmr | multiple sclerosis? :( | 15:12 |
| Pharaoh_Atem | I know it as Mississippi mostly :P | 15:13 |
| ikey | nah | 15:13 |
| ikey | (my cousin has that so i wouldnt personally make that connection in that sense) | 15:13 |
| ikey | nah i meant Microsoft | 15:13 |
| roadmr | I see :) yes, sometimes | 15:14 |
| === ikey is now known as ikey|afk | ||
| zyga | jdstrand drat | 15:35 |
| zyga | jdstrand we need the parent-child association | 15:35 |
| zyga | man, I will write a paper about this | 15:36 |
| jdstrand | zyga: what is the test case that blew up? | 15:36 |
| zyga | (irc doesn't like leading slashes) | 15:36 |
| zyga | /foo/bar | 15:36 |
| mup | PR snapcraft#1951 opened: repo: do not pull in libc6-dev by default for stage-packages <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1951> | 15:37 |
| zyga | /foo | 15:37 |
| zyga | (those are mountinfo entries) | 15:37 |
| zyga | now we look for /foo/bar/froz | 15:37 |
| zyga | we need to model /foo/bar being shadowed by /foo | 15:37 |
| mvo | pedronis: do you think you could have a look at 4731? the last piece for 2.32 afaict | 15:37 |
| zyga | and I think we need to model child-parent to understand what path traversal means | 15:37 |
| jdstrand | isn't it sufficient to know that /foo/bar and /foo/bar/baz are the same st_dev? /foo will have a different st_dev, no? | 15:38 |
| zyga | unless I can do some simpler check that /foo is shorter than /foo/bar and it is later in the table so it hides /foo/bar (which can be ignored now) | 15:38 |
| zyga | they could all have same st_dev sadly | 15:38 |
| zyga | /foo/bar can be a mount entry for /foo/unrelated | 15:39 |
| Chipaca | pedronis: hmm. Right now what I've done is given Info a CurrentTimestamp(), which seems to avoid the issue of having it in info when it's only there for local | 15:39 |
| zyga | and /foo can be a bind mount of the original device | 15:39 |
| zyga | so you effectively unmount /foo/bar | 15:39 |
| jdstrand | oh, cause /foo might be tmpfs (new st_dev), but /foo/bar might be a bind mount (same st_dev)? | 15:39 |
| zyga | this is a contrived example that preserves same st_dev | 15:39 |
| zyga | yes | 15:39 |
| jdstrand | right | 15:39 |
| zyga | isn't this stuff fun :) | 15:39 |
| zyga | :-) | 15:39 |
| jdstrand | I was just thinking | 15:39 |
| jdstrand | "fun!" | 15:40 |
| pedronis | Chipaca: that works too | 15:40 |
| jdstrand | zyga: I think that the before/after diff is really key here since this is happening within the ns and an unpriv user isn't going to be able to fiddle with the mount table for this (non-user mount) namespace | 15:42 |
| jdstrand | zyga: so you're able to trust that before and after are ok | 15:43 |
| jdstrand | we may want to consider fusermount (eg, user races with fusermount instead of just a symlink), but that might just be verifying that after doesn't have any fuse* mounts | 15:46 |
| jdstrand | that said... | 15:46 |
| jdstrand | zyga: before and after should only have a diff of '1' if you call before just before the mount, right? (ie, we're in the ns) | 15:47 |
| zyga | yes, that's correct | 15:47 |
| zyga | well | 15:47 |
| zyga | hmmm | 15:47 |
| zyga | no? | 15:47 |
| zyga | there are two cases that would change that: | 15:48 |
| zyga | 1) /media mounts can happen asynchronously | 15:48 |
| zyga | 2) interface connections can be inherited from the parent ns | 15:48 |
| zyga | and by 2) I mean we are in a MS_SLAVE ns but we will see mount events propagating into us | 15:48 |
| jdstrand | so an interface connection happens at the time of the mount? | 15:48 |
| zyga | yes | 15:49 |
| jdstrand | right | 15:49 |
| zyga | realistically I think the /media case is more likely to happen | 15:49 |
| pedronis | Chipaca: we don't seem to use Timestamp much outside of assertions, typically we have Time ort nothing | 15:49 |
| jdstrand | sure | 15:49 |
| jdstrand | but either are possible | 15:49 |
| zyga | diff will *usually* be 1 but it may be legitimately longer | 15:49 |
| pedronis | Chipaca: I mean in method/field names | 15:49 |
| * Chipaca nods | 15:50 | |
| zyga | jdstrand I'll think about how to model shadowing best | 15:50 |
| zyga | shadowing beast :) | 15:50 |
| jdstrand | zyga: with the parent child tree, then that should detect any weird fusermount stuff too | 15:50 |
| pedronis | Chipaca: LinkTime ? too obscure | 15:51 |
| jdstrand | zyga: cause we are looking for a specific child with a specific parent, so if it isn't found, die | 15:51 |
| pedronis | Chipaca: sadly Current and CurrentTime have both the wrong connotation | 15:51 |
| * jdstrand notes this underscores the complexities of root messing around in user owned dirs | 15:52 | |
| zyga | yeah | 15:52 |
| jdstrand | it's just like a thousand times more difficult with the crappy mount api | 15:52 |
| zyga | I don't understand how the mount maintainer cannot see that perfect is the enemy of good here, waiting for some mythical mount design we have to pay the price of MS_NOFOLLOW not being a thing | 15:53 |
| zyga | Pharaoh_Atem fedora 27 looks good in 5K :) | 15:54 |
| ogra_ | 5k ? is that dual monitor ? 4K + VGA ? | 15:56 |
| zyga | 5K screen | 15:57 |
| ogra_ | i didnt know thats a thing | 15:57 |
| zyga | yeah :) | 15:57 |
| ogra_ | (only know 4K) | 15:57 |
| zyga | oops | 15:59 |
| zyga | imgur crashes on 5K images ?:D | 15:59 |
| zyga | https://twitter.com/zygoon/status/967066654785056774 | 16:00 |
| zyga | not sure if there's a "get original" thing in twitter | 16:01 |
| nacc | when a part has a relatively unstable (it seems in practice) http server/git server, does it make sense to ship the tarball in the snap directory directly? | 16:06 |
| nacc | and is there a 'best practice' doc for doing so (cough anonscm cough) | 16:06 |
| mvo | anyone up for review for 4731? | 16:16 |
| mup | PR snapd#4733 opened: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4733> | 16:18 |
| zyga | yep | 16:19 |
| jdstrand | mvo: is there going to be another 2.31? (thinking of ^) | 16:19 |
| mvo | jdstrand: maybe, there are some indication for it | 16:20 |
| mvo | jdstrand: but not urgent | 16:20 |
| jdstrand | mvo: what we have in 2.31 isn't a regression, just an incomplete fix (therefore also not urgent imo) | 16:20 |
| jdstrand | mvo: ok, I'll create a branch and milestone it, then you can do with it what you will | 16:21 |
| jdstrand | mvo: incidentally, does this ring any bells: | 16:21 |
| mvo | jdstrand: ta | 16:21 |
| jdstrand | $ ./run-checks | 16:21 |
| jdstrand | ... | 16:21 |
| jdstrand | Running vet | 16:21 |
| jdstrand | overlord/ifacestate/handlers.go:580: github.com/snapcore/snapd/overlord/state.Retry composite literal uses unkeyed fields | 16:21 |
| jdstrand | exit status 1 | 16:21 |
| mvo | (in a meeting right now so might be slow) | 16:21 |
| jdstrand | mvo: no worries. this is my 16.04 dev environment in lxd if you recall | 16:22 |
| mvo | jdstrand: does not ring a bell right now | 16:22 |
| mup | Issue snapcraft#1952 opened: add support for in test release information <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1952> | 16:25 |
| mup | Issue snapcraft#1953 opened: Add in test architecture <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1953> | 16:25 |
| mup | PR snapd#4734 opened: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4734> | 16:25 |
| zyga | hmm hmm hmm | 16:26 |
| zyga | https://pastebin.ubuntu.com/p/VwtktKq7cc/ | 16:26 |
| jdstrand | mvo: fyi, 4734 for 2.31 | 16:26 |
| zyga | jdstrand both +1'd | 16:26 |
| jdstrand | yep, thanks! | 16:26 |
| zyga | I pasted something that shows the problem we talked about earlier | 16:27 |
| zyga | and found something unexpected | 16:27 |
| mup | Issue snapcraft#1704 closed: Add unit tests for error classes <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1704> | 16:28 |
| mup | Issue snapcraft#1954 opened: Implement support for `common-id` <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1954> | 16:28 |
| mvo | jdstrand: \o/ | 16:28 |
| mup | PR snapd#4731 closed: overlord/snapstate: fix task iteration order in TestDoPrereqRetryWhenBaseInFlight <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4731> | 16:28 |
| zyga | heh | 16:31 |
| zyga | so the kernel does allow a mount event to propagate back to ... itself | 16:32 |
| zyga | kind of | 16:32 |
| zyga | I just realized this by reading parent ids | 16:32 |
| zyga | jdstrand in the paste above mount 405 (/tmp2) is mounted on top of 390 which is /tmp2 | 16:34 |
| Chipaca | pedronis: vvv | 16:34 |
| mup | PR snapd#4735 opened: daemon, snap: fix InstallDate, make a method of *snap.Info <Created by chipaca> <https://github.com/snapcore/snapd/pull/4735> | 16:34 |
| pedronis | in another meeting | 16:35 |
| * Chipaca hugs pedronis | 16:36 | |
| jdstrand | zyga: yeah | 16:45 |
| jdstrand | zyga: so, an unpriv user isn't going to sneak a bind mount in there. what does a fuse mount look like in that situation? | 16:46 |
| zyga | hmm, what can I mount | 16:47 |
| zyga | any fuse mount? | 16:47 |
| jdstrand | sure | 16:47 |
| zyga | holly crap | 16:48 |
| zyga | there's bindfs | 16:48 |
| zyga | which is like mount --bind | 16:48 |
| jdstrand | they look like this: | 16:48 |
| zyga | and it's FUSE | 16:48 |
| jdstrand | $ grep fuse /proc/self/mountinfo | 16:48 |
| jdstrand | 53 22 0:45 / /sys/fs/fuse/connections rw,relatime shared:31 - fusectl fusectl rw | 16:48 |
| jdstrand | 3500 1411 0:97 / /run/user/1000/gvfs rw,nosuid,nodev,relatime shared:428 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=1000,group_id=1000 | 16:48 |
| jdstrand | zyga: yeah, we talked about that once before | 16:48 |
| jdstrand | for remapping uids | 16:48 |
| jdstrand | (but discarded it) | 16:49 |
| zyga | jdstrand fuse looks mostly like a normal filesystem | 16:50 |
| jdstrand | zyga: my line of thinking was that *perhaps* we don't have to worry about a bind mount getting snuck in, but if a fuse one did, die | 16:50 |
| jdstrand | zyga: fstype is going to have 'fuse' in the name though | 16:51 |
| zyga | well, it doesn't have to, does it? | 16:54 |
| jdstrand | zyga: yes, it does | 16:55 |
| jdstrand | zyga: fuse.sshfs, fuse.gfvsd-fuse, etc | 16:55 |
| zyga | is that done by the kernel or just a convention by each fuse process? | 16:56 |
| jdstrand | zyga: this is why in the fuse-support interface we use: mount fstype=fuse.* ... | 16:56 |
| zyga | I see | 16:56 |
| zyga | cool, I didn't know that | 16:56 |
| zyga | so, back to your idea | 16:56 |
| zyga | why are fuse mounts more dangerous than bind moutns? | 16:57 |
| zyga | because we don't know what they can bring? | 16:57 |
| jdstrand | zyga: in and of themselves, they aren't | 16:57 |
| jdstrand | zyga: what is different is that a normal user needs privs to do a bind mount. fusermount is setuid, so a normal user can use it | 16:57 |
| zyga | ah, I see | 16:58 |
| zyga | another snap-confine situation | 16:58 |
| zyga | ok, I'll look at the algorithm for what we talked about so far | 16:58 |
| jdstrand | zyga: all this is about is a non-root unconfined user playing tricks to escalate | 16:59 |
| jdstrand | zyga: we aren't worried about unconfined root | 16:59 |
| ogra_ | just bundle fuse with npm (that apparently just does a chmod -R 777 /* ... all security issues fixed) | 16:59 |
| zyga | I'd patch npm to use 2777, the colors in ls are nicer, presentation matters! | 17:00 |
| Chipaca | ogra_: there's a lesson in there about running npm as root, but it's not a new lesson and I doubt many people care | 17:00 |
| ogra_ | yeah, just send a patch for https://github.com/npm/npm/issues/19883 | 17:00 |
| ogra_ | Chwell, there might be a lesson for people reading the bug ... people reading that howto they found on this internet thing will just follow it and use sudo npm | 17:01 |
| jdstrand | zyga: for completeness, there are also user mount namespaces, but they shouldn't be in play because snap-update-ns is already in a system mount namespace, and the user won't be able to affect it | 17:01 |
| ogra_ | bah | 17:01 |
| ogra_ | Chipaca, ^^^ | 17:01 |
| === Chipaca is now known as Chwell | ||
| Chwell | there, fixed it | 17:02 |
| ogra_ | lol | 17:02 |
| zyga | user mount namespaces | 17:02 |
| zyga | or user namespaces | 17:02 |
| jdstrand | oh that is an awesome bug | 17:03 |
| zyga | :D | 17:03 |
| * kalikiana wrapping up for the week | 17:03 | |
| jdstrand | too bad npm as a snap is classic | 17:03 |
| ogra_ | jdstrand, i knew you would love it | 17:03 |
| zyga | and here I was thinking the kernel was coming to address our issues :) | 17:03 |
| jdstrand | s/npm/node/ | 17:03 |
| === Chwell is now known as Chipaca | ||
| Chipaca | zyga: cp `which false` `which npm` | 17:05 |
| jdstrand | zyga: the mount user namespace? :) | 17:06 |
| zyga | jdstrand the cake namespace | 17:07 |
| jdstrand | per-user mounts in the snaps system mount namespace aren't affected by mount user namespaces | 17:07 |
| zyga | jdstrand so the thing you stated for completeness, what did you mean there | 17:07 |
| jdstrand | how is that for a parseable sentence? | 17:07 |
| zyga | that user namespaces are not a risk? | 17:07 |
| zyga | it's okay but I have a question | 17:07 |
| zyga | what are mount user namespaces? | 17:07 |
| jdstrand | zyga: I'm saying that user namespaces shouldn't be in play, because be the time we do before, mount, after, s-u-n is in the system mount namespace of the snap, so the user shouldn't be able to fiddle with it | 17:08 |
| jdstrand | and we already unshared | 17:08 |
| zyga | ahh, ok | 17:08 |
| zyga | :) | 17:08 |
| zyga | man, the adjective order in english | 17:09 |
| jdstrand | right | 17:09 |
| zyga | with a few cases like in polish it would be easier to parse :) | 17:09 |
| jdstrand | it is all messy | 17:09 |
| jdstrand | mount namespace (system, need privs), mount user namespace (don't need privs), and snap namespace (system) | 17:10 |
| jdstrand | user namespaces are what lxd uses these days by default | 17:10 |
| zyga | we should call those rooms, not namespaces | 17:12 |
| zyga | it's such a geeky thing | 17:12 |
| zyga | my root user in this room is not the same as the root user in that room | 17:12 |
| zyga | and there's a root user in the room that contains the other two rooms | 17:12 |
| zyga | it almost sounds sensible! | 17:12 |
| Chipaca | zyga: I think somebody took “Namespaces are one honking great idea -- let's do more of those!” a bit too much to heart | 17:13 |
| zyga | and you can say "go to your room" if your kids are naughty and don't want to do homework | 17:14 |
| Chipaca | zyga: and you can shuffle the whole bunch of groups around every time somebody tries to change rooms | 17:18 |
| * Chipaca wonders if 'the cube' is too old | 17:19 | |
| zyga | Chipaca ooh | 17:20 |
| zyga | yes | 17:20 |
| zyga | the cube is the perfect analogy | 17:20 |
| niemeyer | Saviq: ping | 17:25 |
| Saviq | niemeyer: as you were, looks like they had some kind of hiccup | 17:37 |
| mvo | just fyi - I branched 2.32 and will hopefully do a beta later tonight | 17:47 |
| niemeyer | Saviq: Hm? | 18:00 |
| niemeyer | Saviq: Not sure if my IRC client is buggy.. but it looks like I'm missing part of the sentence | 18:00 |
| niemeyer | Saviq: I was going to talk about the image.. did you sort it out? | 18:01 |
| Saviq | niemeyer: thought you were pinging about my issue yesterday (missing 17.10 images) | 18:01 |
| niemeyer | Saviq: Yeah, it was about it indeed | 18:01 |
| Saviq | Right, yes, that - it was a hiccup on their side | 18:01 |
| Saviq | So we're back in business, thanks | 18:02 |
| niemeyer | Saviq: I wouldnt' be surprised if they just removed the image | 18:02 |
| niemeyer | Saviq: and then people complained | 18:02 |
| Saviq | Possible, yeah | 18:02 |
| niemeyer | Saviq: Our experiences with dynamic usage in Linode show they're not quite there yet | 18:03 |
| niemeyer | Saviq: They still hold a lot of the old school way of thinking, where you create a machine and hold it | 18:03 |
| Saviq | I went to their IRC channel, someone said the image was still there in new API, but missing in old or something of the sort | 18:03 |
| niemeyer | Saviq: The other day I got a Terms Violation notice, for example, for a machine that we used for 23 minutes.. the timing of abuse report was off for several hours from our use | 18:04 |
| niemeyer | Saviq: We're also observing corruption of machine state when we do a lot of API calls next to each other | 18:04 |
| Saviq | Aha... We've had some intermittent issues, but it's been fine overall | 18:04 |
| niemeyer | Saviq: For that sort of reason, I have a Google Compute Engine backend pretty much good to go | 18:05 |
| niemeyer | Saviq: Preliminar tests look very promising | 18:05 |
| Saviq | Nice! | 18:05 |
| niemeyer | Saviq: Other than the image itself being perhaps slightly different, you shouldn't have to change anything on your end | 18:05 |
| Saviq | Let me know if you want us to test anything | 18:07 |
| niemeyer | Thanks, will do | 18:07 |
| Chipaca | niemeyer: the forum is saying it's offline | 18:15 |
| niemeyer | WAT? I'm typing on it! | 18:15 |
| * niemeyer looks | 18:16 | |
| mvo | Chipaca: hm, same here, it does not respond | 18:16 |
| niemeyer | The machine looks completely down.. | 18:17 |
| niemeyer | (speaking of Linode...) | 18:17 |
| niemeyer | https://usercontent.irccloud-cdn.com/file/44QXUsr8/image.png | 18:18 |
| mvo | cachio_: hey, I was just looking at the SRU of snapd, lets plan to do the sru verification early next week | 18:21 |
| cachio_ | mvo, hey, sure | 18:21 |
| cachio_ | which version 2.31.1? | 18:22 |
| mvo | cachio_: yes | 18:22 |
| mvo | cachio_: I push 2.32~pre1 to beta hopefully tonight but no need to validate that before monday, its just there for people to play with | 18:25 |
| cachio_ | mvo, sure | 18:26 |
| cachio_ | mvo, let's validate it on monday in that case | 18:26 |
| mvo | cachio_: yes | 18:26 |
| mvo | cachio_: that is what I was trying to say :) | 18:26 |
| cachio_ | :) | 18:27 |
| cachio_ | mvo, 2.32 contains layouts, right? | 18:30 |
| mvo | cachio_: yes and autoconnect tasks and auto install of default providers | 18:31 |
| mvo | cachio_: some dangerous stuff :) | 18:31 |
| cachio_ | rotundo82 | 18:33 |
| cachio_ | mvo, yes | 18:35 |
| niemeyer | What.. | 18:35 |
| niemeyer | error: cannot read snap file: app description field 'command' contains illegal "bin/gopkg | 18:35 |
| niemeyer | -acme=$SNAP_DATA/certs -http=:80 -https=:443" (legal: '^[A-Za-z0-9/. _#:$-]*$') | 18:35 |
| niemeyer | What happened there!? | 18:35 |
| niemeyer | Chipaca: Do you know anything about this? | 18:36 |
| niemeyer | Ah, I disabled the adapters.. | 18:37 |
| niemeyer | Looks like we need to make this logic a bit more flexible | 18:37 |
| Chipaca | niemeyer: I don't know what happened there, that doesn't contain anything that doesn't match | 18:38 |
| niemeyer | Chipaca: Yeah, we probably have something to fix.. | 18:38 |
| === ubott2 is now known as ubottu | ||
| happyaron | hey the forum seems to be down... | 18:40 |
| Chipaca | niemeyer: do you have the snap handy? | 18:40 |
| happyaron | and my edit get lost... | 18:40 |
| === JamieBennett_ is now known as JamieBennett | ||
| === Dmitrii-Sh_ is now known as Dmitrii-Sh | ||
| === luk3yx- is now known as luk3yx | ||
| === Abhishek__ is now known as Abhishek_ | ||
| === andyrock_ is now known as andyrock | ||
| === coreycb_ is now known as coreycb | ||
| Chipaca | happyaron: I think that's what niemeyer is on | 18:49 |
| niemeyer | Phew.. ok.. gopkg.in is up on the secondary | 18:49 |
| mup | Issue snapcraft#1819 closed: Detect and clear executable stack binaries <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1819> | 18:50 |
| mup | PR snapcraft#1945 closed: elf: clear execstack by default <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1945> | 18:50 |
| happyaron | long fight, :( | 18:51 |
| pedronis` | mvo: will you branch 2.32 tonight ? | 18:53 |
| sergiusens | niemeyer: I thought `S` was now allowed, we discussed it with jdstrand and mvo and agreed it was good | 18:54 |
| sergiusens | there must be a forum post somewhere but I cannot search it now | 18:54 |
| Chipaca | pedronis`: <mvo> just fyi - I branched 2.32 and will hopefully do a beta later tonight | 18:55 |
| Pharaoh_Atem | zyga: \o/ | 18:55 |
| pedronis` | Chipaca: ah, cool | 18:55 |
| pedronis` | can land some of my stuff | 18:55 |
| Chipaca | pedronis`: :-) | 18:55 |
| === pedronis` is now known as pedronis | ||
| Chipaca | niemeyer: when you have a moment, the snap.yaml that threw that error would help | 18:59 |
| mvo | pedronis: yes, I branched it now | 18:59 |
| mvo | s/now/some minutes ago/ | 19:00 |
| mup | PR snapd#4715 closed: store: reorg auth refresh <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4715> | 19:01 |
| pedronis | mvo: thank you | 19:01 |
| mvo | yay, thank you for all the nice PRs that can land now | 19:02 |
| mup | PR snapd#4722 closed: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4722> | 19:08 |
| niemeyer | Chipaca: Thanks, will reproduce once I take my head above the water | 19:09 |
| Chipaca | niemeyer: no probs | 19:10 |
| niemeyer | Chipaca: https://gist.github.com/niemeyer/8270aeb96b6facd8ee1bc2129086e4b3 | 19:32 |
| niemeyer | Forum is back up | 19:37 |
| niemeyer | Or, stating more correctly, the entire data center has connectivity again | 19:37 |
| niemeyer | Chipaca: Also: https://forum.snapcraft.io/t/better-field-name-for-refreshed-in-snap-info-output/4150/6 | 19:42 |
| Chipaca | niemeyer: hah | 19:45 |
| Chipaca | niemeyer: I had that change in the PR that I closed during the standup :-) | 19:45 |
| Chipaca | glad we're aligned | 19:45 |
| niemeyer | Chipaca: Which of the three? :P | 19:48 |
| Chipaca | niemeyer: https://github.com/snapcore/snapd/pull/4729/files#diff-6ac026a08342873c6b9ada7333f66224R378 | 19:48 |
| mup | PR #4729: many: drop snaps' InstallDate, introduce Updated <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4729> | 19:48 |
| Chipaca | niemeyer: moving installed to the bottom | 19:48 |
| niemeyer | \o/ | 19:48 |
| pedronis | Chipaca: so refreshed is not defined if the snap is inactive? | 19:48 |
| Chipaca | pedronis: correct | 19:49 |
| pedronis | it's ok in info, it's a bit strange in the snap api | 19:49 |
| pedronis | heh | 19:49 |
| pedronis | I mean daemon api | 19:49 |
| Chipaca | pedronis: if you have a good definition of this for when the snap is inactive, I can implement it, no problem :-) | 19:50 |
| pedronis | Chipaca: mtime of the revision snap blob? | 19:50 |
| pedronis | we have a Current even if we are inactive nowadays | 19:51 |
| Chipaca | pedronis: that's hard to explain, though: enable the snap, its 'refreshed' changes | 19:53 |
| pedronis | Chipaca: we are still mixing concepts I fear | 19:54 |
| pedronis | the current link is a good approx of installe-date, only ignoring revert, enable/disable etc | 19:55 |
| pedronis | something got to give | 19:55 |
| niemeyer | Chipaca's take sounds reasonable to me as well.. what are we missing | 19:55 |
| niemeyer | ? | 19:55 |
| niemeyer | I mean, if you have three different snap revisions and they are all disabled, it's hard to argue that a particular one of them should be shown there | 19:56 |
| pedronis | I'm not unhappy about the snap info display, my issue is with the rest api field which is still called installed-date | 19:56 |
| niemeyer | That said, do we show the version? | 19:56 |
| niemeyer | Chipaca: ? | 19:56 |
| niemeyer | In "installed" that is | 19:57 |
| Chipaca | niemeyer: yes | 19:57 |
| niemeyer | Okay, it seems a bit inconsistent | 19:57 |
| pedronis | niemeyer: we do show a version in installed even if the snap is disabled | 19:57 |
| Chipaca | niemeyer: but | 19:57 |
| niemeyer | Then I agree with pedronis | 19:57 |
| Chipaca | but maybe we shouldn't | 19:57 |
| pedronis | because we have a current concept (that is different from active) | 19:57 |
| Chipaca | i mean, maybe we shouldn't show 'installed' if it's disabled | 19:57 |
| pedronis | well, it's what you would get | 19:58 |
| pedronis | if you did snap enable | 19:58 |
| niemeyer | Chipaca: pedronis has a point I think.. maybe that's just fighting against the real model we have, which in general means we'll have cascading issues | 19:58 |
| niemeyer | Chipaca: e.g. it's also what we show in "snap list" isn't it? | 19:58 |
| pedronis | the line is like this: installed: 0.2.26 (8) 2MB disabled | 19:59 |
| pedronis | we say disabled there | 19:59 |
| pedronis | but there is also a version | 19:59 |
| pedronis | (what you get if you enable) | 19:59 |
| Chipaca | so. | 19:59 |
| niemeyer | Yeah, so showing the refreshed time at all times sounds right | 19:59 |
| jdstrand | zyga: arg 4727 makes me have to redo a bunch of stuff | 19:59 |
| niemeyer | It's consistent with everything else at least | 19:59 |
| Chipaca | niemeyer: but what is the refresh time of a disabled snap? | 19:59 |
| pedronis | what is a refresh time of a reverted snap | 20:00 |
| niemeyer | Chipaca: It's the refresh time of the _current_ revision | 20:00 |
| Chipaca | pedronis: the timestamp of current | 20:00 |
| pedronis | that our current interpretation | 20:00 |
| pedronis | usually refreshed means from the store | 20:00 |
| pedronis | not strobed client side | 20:00 |
| pedronis | though we have corner cases | 20:01 |
| pedronis | you can refresh to revisions you already have | 20:01 |
| ackk | hi, is it possible to specify version constraints on "stage-packages" ? | 20:01 |
| Chipaca | niemeyer: we don't have the 'refresh time' anywhere, though | 20:01 |
| Chipaca | pedronis: yep, and in this context i don't think there's a non-weird answer for revert | 20:02 |
| niemeyer | Chipaca: Agreed | 20:03 |
| Chipaca | bah, the non-weird thing would be to keep (last action, timestamp) and show that | 20:03 |
| niemeyer | Chipaca: So isn't it the timestamp of the link anyway? | 20:03 |
| Chipaca | so you get installed/enabled/disabled/reverted/refreshed: <timestamp> | 20:03 |
| niemeyer | Chipaca: When we disable, do we kill the link? I thought we had changed that | 20:03 |
| Chipaca | niemeyer: the link isn't there if the snap is disabled | 20:03 |
| pedronis | we kill the link | 20:03 |
| Chipaca | niemeyer: we keep 'current' in the state | 20:03 |
| niemeyer | Chipaca: Except installed is taken.. oops :) | 20:04 |
| niemeyer | Chipaca: I almost wrote as part of that post that we should change the field name at the same time we fix its meaning | 20:04 |
| niemeyer | For that reason | 20:04 |
| Chipaca | niemeyer: the revision descriptions are growing a timestamp, it all lines up | 20:04 |
| Chipaca | :) | 20:05 |
| niemeyer | Chipaca: I'm sold ;) | 20:05 |
| Chipaca | OTOH we could go with 'current' for the current version description line | 20:05 |
| Chipaca | s/version/revision/ | 20:05 |
| niemeyer | Chipaca: I like that.. | 20:05 |
| === cory_fu_ is now known as cory_fu | ||
| Chipaca | ok, so, baby steps | 20:06 |
| niemeyer | Chipaca: So, just to go back to that point I'm still missing: you say we currently use the link time | 20:06 |
| Chipaca | niemeyer: yes | 20:07 |
| niemeyer | Chipaca: Isn't the link always there even when it's disabled? | 20:07 |
| Chipaca | bah, in the PR that's up | 20:07 |
| Chipaca | niemeyer: no, the link is not there if it's disabled | 20:07 |
| niemeyer | Ah, pedronis also answered that.. I missed it, okay | 20:07 |
| Chipaca | long week, and long day :-) | 20:07 |
| niemeyer | Chipaca: So.. I think we can fix the output, and if we cannot find the proper data for all cases, we can approach it and have more data as we find the time to polish it up | 20:08 |
| niemeyer | Chipaca: But, I suggest we do those fixes at once.. at least the key ones | 20:08 |
| Chipaca | I can rename it to 'current' as part of the move | 20:08 |
| pedronis | that seems a big change | 20:08 |
| pedronis | but I don't know if people parse it a lot (or not) | 20:09 |
| Chipaca | it's ok, i'll change it one letter at a time | 20:09 |
| pedronis | :) | 20:09 |
| Chipaca | :-D | 20:09 |
| niemeyer | LOL | 20:09 |
| Chipaca | pedronis: I hope they aren't, because I'm pretty sure there are more corner cases than not where it's not valid yaml | 20:09 |
| niemeyer | It's not the kind of change we should be doing very often for sure | 20:09 |
| mup | PR snapd#4736 opened: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4736> | 20:09 |
| niemeyer | But I think it's worth it doing it if we plan to have more times there, which I think we do | 20:10 |
| pedronis | Chipaca: I didn't say they parse as yaml | 20:10 |
| Chipaca | pedronis: (but the change is still going to disorient people that rely on it) | 20:10 |
| pedronis | those people could use the api | 20:10 |
| Chipaca | pedronis: ah | 20:10 |
| pedronis | I'm more thinking the grep and cut and awk sort of people | 20:10 |
| Chipaca | pedronis: i gotcha | 20:10 |
| niemeyer | It's just awkward to have refreshed next to installed with completely different meanings, and it's double awkward because installed could actually BE A TIMESTAMP | 20:10 |
| jdstrand | zyga: oh I thought you said it was committed | 20:12 |
| Chipaca | pedronis: do you reckon a heads-up forum post would be enough? | 20:12 |
| pedronis | it's a start | 20:13 |
| jdstrand | zyga: if your pr is committed, I'll update mine, but I don't want to mix in an unapproved approach at this time | 20:14 |
| === chiluk_ is now known as chiluk | ||
| Chipaca | pedronis: niemeyer: and because this is for snap info, we can make an additive change to SnapState to keep track of (last action, timestamp), and have code that grabs it if it exists but doesn't die if it doesn't, and we'll be set | 20:16 |
| Chipaca | that's a change for next week though | 20:16 |
| Chipaca | although knowing us, it should probably be a map[action]timestamp | 20:18 |
| pedronis | heh | 20:18 |
| pedronis | and then you sort them, and take the last? | 20:18 |
| Chipaca | pedronis: unless the last is $x that we later decided to ignore :-) | 20:19 |
| pedronis | last action timestamp, download time, revision creation time, release timestamp | 20:20 |
| pedronis | Chipaca: I also wonder whether we should start from thinking what I user might really find useful | 20:21 |
| Chipaca | pedronis: I thought we were (in a bumbling, chatty kind of way) | 20:22 |
| Chipaca | niemeyer: btw in https://forum.snapcraft.io/t/4150/6 you had installed twice in the first example, and with me having moved it to the bottom I'd gotten used to seeing it there so it took me a bit to understand what you meant | 20:23 |
| pedronis | Chipaca: one of my questions is that is unclear those times help answering, is the thing I have here old | 20:23 |
| niemeyer | Chipaca: Oops, sorry.. cleaned it | 20:24 |
| pedronis | Chipaca: refreshed is sort of that (except if you strange local refreshes) | 20:24 |
| Chipaca | pedronis: that you can only answer with the store's timestamps though | 20:24 |
| pedronis | the ones we don't plan to show anywhere :) | 20:25 |
| Chipaca | pedronis: oh? i thought we were going to have a day in the chan map | 20:25 |
| pedronis | yes | 20:25 |
| Chipaca | 16-2.31.1+git587.d3e52a0 (4133, from 2018-09-24) 85MB core | 20:25 |
| Chipaca | or sth | 20:25 |
| pedronis | though we haven't decided what that date is here yet | 20:25 |
| pedronis | it can be the revision date, or the release date | 20:26 |
| Chipaca | hopefully, gregorian | 20:26 |
| pedronis | or we need both (oh my) | 20:26 |
| pedronis | star date | 20:27 |
| Chipaca | internet time! | 20:28 |
| * pedronis should go afk | 20:28 | |
| niemeyer | popey: ping | 20:32 |
| popey | niemeyer: pong | 20:33 |
| niemeyer | popey: Heya | 20:33 |
| niemeyer | popey: Would you have 5~10mins for a quick catch up? | 20:33 |
| popey | Sadly not right this second. I need to go out and get my daughter from dance class. | 20:33 |
| popey | But I'll be back a little later | 20:34 |
| niemeyer | popey: Sounds good, I'll be around, so will ping you again later | 20:34 |
| niemeyer | popey: Talk soon | 20:35 |
| popey | kk, will let you know when I'm back | 20:35 |
| niemeyer | Thanks! | 20:35 |
| === pbek_ is now known as pbek | ||
| === bashfulrobot_ is now known as bashfulrobot | ||
| mup | PR snapcraft#1955 opened: meta: make sure adapter does not propagate <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1955> | 20:47 |
| mup | PR snapd#4737 opened: cmd/snap: tweaks to 'snap info' (feat. installed->current rename) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4737> | 21:04 |
| Chipaca | huh, why did i think snap names had max length 40 | 21:10 |
| Chipaca | niemeyer: I can't do the alignment you're now asking for in the pr, without a ton of work | 21:11 |
| niemeyer | Chipaca: My naive mind reacts in disbelief about adding a couple of spaces in a line being a ton of work. | 21:12 |
| Chipaca | niemeyer: ok | 21:13 |
| niemeyer | That's such a great conversation.. it must be Friday :P | 21:13 |
| Chipaca | niemeyer: i was just writing | 21:13 |
| Chipaca | niemeyer: it's friday and i'm very tired, so maybe it's easy and i'm not seeing it, but i'm going to call it mostly-eod right here | 21:14 |
| niemeyer | Type faster! <GIF of someone typing really fast> | 21:14 |
| niemeyer | Chipaca: Certainly sounds fair | 21:14 |
| Chipaca | niemeyer: snap info is messy; if it were nice and clean this would be easy | 21:14 |
| niemeyer | Chipaca: Agreed.. we can look into it again with fresh post-weekend eyes on Monday | 21:15 |
| Chipaca | I did see the problem with the alignment when the channel map is missing, fwiw, and looked at fixing it, and noped out | 21:15 |
| niemeyer | Chipaca: We might hack it by tuning the spacing specially for that line, and serializing it independently | 21:16 |
| niemeyer | Or something something | 21:16 |
| Chipaca | niemeyer: yeah, that's the nope scenario (you'd have to keep track of what the last thing you printed even was) | 21:16 |
| Chipaca | (there are a ton of "if it has this, then print this") | 21:17 |
| Chipaca | (and people care about the order, wouldn't you know :-) ) | 21:17 |
| niemeyer | Chipaca: Not printed, but whether a channel map exists.. we have semantic context at hand in the info impl itself | 21:17 |
| niemeyer | Chipaca: Yeah, I know.. I'm sure we could spent 5 years on a modern yaml parser and do it very nicely | 21:17 |
| Chipaca | actually, i can show you a diff that would do the job, and you tell me if it's worth it | 21:19 |
| Chipaca | niemeyer: https://pastebin.ubuntu.com/p/4xRZx4vdyH/ | 21:20 |
| niemeyer | Chipaca: WFM! | 21:21 |
| Chipaca | niemeyer: iterated it a bit though, because i can't help myself | 21:29 |
| Chipaca | niemeyer: pushed | 21:50 |
| popey | niemeyer: i assume the catch up was regarding the various docs threads. It's late here. Shall we catch up early next week? | 22:18 |
| zyga | dooooh | 22:36 |
| * zyga solved a bug :) | 22:36 | |
| Chipaca | no snapcrafters around! and me with a bug | 22:54 |
| * zyga hugs Chipaca | 23:01 | |
| zyga | I found a super silly bug in my code | 23:01 |
| zyga | and I found out why core and layouts didn't work | 23:01 |
| Chipaca | zyga: yay? | 23:04 |
| Chipaca | zyga: zyga! zyga. Are you on bionic? | 23:04 |
| zyga | I have a VM on bionic available | 23:04 |
| zyga | but I'm on artful | 23:04 |
| Chipaca | I don't think it'll work in artful yet | 23:05 |
| Chipaca | zyga: bionic ships with "ls --hyperlink" | 23:05 |
| zyga | what are you thinking about? | 23:05 |
| Chipaca | gnome terminal | 23:05 |
| Chipaca | in bionic | 23:05 |
| Chipaca | supports hyperlinks | 23:05 |
| Chipaca | it's weird, and exciting, and wrong :-) | 23:05 |
| * zyga checks | 23:05 | |
| Chipaca | and of course coreutils use them | 23:06 |
| zyga | wait, WAT! | 23:06 |
| * zyga doesn't believe this | 23:06 | |
| Chipaca | hahah | 23:06 |
| Chipaca | zyga: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda | 23:06 |
| zyga | w...t...f.. | 23:06 |
| zyga | how does it work? | 23:06 |
| Chipaca | IKR | 23:06 |
| zyga | hollly | 23:07 |
| Chipaca | zyga: escape sequences, of course | 23:07 |
| Chipaca | and a particularly gnarly one to parse | 23:07 |
| Chipaca | if I were one to be writing a de-ansifier, that is | 23:07 |
| zyga | it also works in F27 | 23:07 |
| zyga | so you bumped into this because it broke something | 23:08 |
| Chipaca | heh, everything I've found so far has broken with a lot less | 23:08 |
| Chipaca | but yes, this broke my thing | 23:08 |
| zyga | man, thank you for sharing this | 23:08 |
| zyga | this is pretty cool actually | 23:08 |
| Chipaca | zyga: most de-ansifiers broke with just | 23:09 |
| zyga | but man | 23:09 |
| Chipaca | printf '\033(0lqwqk\nx x x\ntqnqu\nx x x\nmqvqj\n\033(B') | 23:09 |
| zyga | this will be exploited | 23:09 |
| Chipaca | uh, remove the trailing ) | 23:09 |
| zyga | snaps can even abuse this | 23:09 |
| zyga | someone who did this will add a "preload" feature next | 23:10 |
| nacc | ok so they removed the ability to title the terminal, but added this!? ) | 23:10 |
| nacc | :) | 23:10 |
| Chipaca | nacc: they whaaaa | 23:10 |
| nacc | Chipaca: it's been gone for a few releases now | 23:11 |
| Chipaca | nacc: you mean, in the ui? or with escapes? | 23:11 |
| nacc | Chipaca: in the UI | 23:11 |
| Chipaca | ah! psh | 23:11 |
| nacc | Chipaca: i can try with escapes, do you have an example? | 23:11 |
| Chipaca | that was just confusing because your escapes would override it | 23:11 |
| Chipaca | nacc: you have an example in your .bashrc :-) | 23:11 |
| Chipaca | it's in the skeleton bashrc | 23:11 |
| Chipaca | your PS1 is probably doing it | 23:11 |
| nacc | Chipaca: oh sure, I know that part | 23:11 |
| nacc | it's a hassle to write a per-terminal instance PS1 though :) | 23:12 |
| Chipaca | nacc: yup | 23:14 |
| Chipaca | nacc: my favourite complaint is that they add or remove features and there's no way to detect them | 23:15 |
| nacc | that's a fact :) | 23:15 |
| Chipaca | like, how would an implementer know whether the terminal has hyperlinks? 24-bit rgb? properly wide emojis? | 23:15 |
| nacc | right | 23:15 |
| nacc | and then wait til someone puts it in backports :) | 23:15 |
| Chipaca | and, and, it sets TERM to xterm-256color | 23:16 |
| Chipaca | and xterms do _so much more_! | 23:16 |
| nacc | heh | 23:16 |
| Chipaca | and faster, also | 23:16 |
| Chipaca | I can measure the width taken by every unicode character on an xterm in under five minutes, wheras I need 10 instances running gnome terminal for an hour | 23:17 |
| Chipaca | anyhow. silly rant over. | 23:17 |
| zyga | echo -e '\e#8' | 23:19 |
| zyga | this is fun :) | 23:19 |
| Chipaca | 'alignment test'? | 23:19 |
| zyga | indeed | 23:19 |
| Chipaca | man | 23:19 |
| Chipaca | heh, you want to hear a funny one | 23:19 |
| Chipaca | microsoft added support for DEC graphics charset to their terminal recently | 23:20 |
| zyga | good | 23:20 |
| zyga | at least microsoft documents stuff now :) | 23:20 |
| Chipaca | but in the dec character chart | 23:20 |
| Chipaca | they have some codepoints with things like | 23:21 |
| Chipaca | ␍ | 23:21 |
| Chipaca | microsoft thought they were carriage returns :-D | 23:21 |
| Chipaca | https://vt100.net/docs/vt220-rm/table2-4.html for reference | 23:22 |
| Chipaca | so on windows if you do printf '\033(0c\033(B\n' | 23:23 |
| Chipaca | it throws an actual form feed at you | 23:23 |
| Chipaca | (compare with https://vt100.net/docs/vt220-rm/table2-1.html) | 23:24 |
| * Chipaca shuts up about obscure silliness and gets back to fixing snapcraft | 23:24 | |
| gsilvapt | Hello all. Need some help as I never done this kind of work. I contributed to snapcraft a few months ago and haven't update my remotes for a while | 23:28 |
| gsilvapt | So if I checkout to master, do git pull upstream (upstream...) master and git push origin (my fork) master should update my fork as well? | 23:28 |
| Chipaca | gsilvapt: hmm... that's not how I do it | 23:36 |
| mup | PR snapcraft#1956 opened: snap: actually plug the completer in <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1956> | 23:36 |
| Chipaca | gsilvapt: I do: git checkout master, then git fetch upstream, then git merge upstream/master, then git push origin | 23:37 |
| Chipaca | gsilvapt: but git is hairy enough that these two might be equivalent | 23:38 |
| Chipaca | ¯\_(ツ)_/¯ | 23:38 |
| gsilvapt | Chipaca, uhh, I'm noob in open source projects. I'm only used to work in a single remote :P | 23:38 |
| gsilvapt | That makes sense too | 23:38 |
| Chipaca | fwiw I've stashed it all into a single command 'git sync', https://github.com/chipaca/bin/blob/master/git-sync | 23:38 |
| Chipaca | gsilvapt: a neat trick of git is that any command that you call git-foo in your path, git'll happily use as 'git foo' | 23:39 |
| Chipaca | so if aliases aren't enough you can do that | 23:39 |
| gsilvapt | Chipaca, thanks! | 23:40 |
| gsilvapt | Chipaca, I was checking the commit logs in my remote and they seem right in comparison to the upstream's: https://github.com/gsilvapt/snapcraft/commits/master | 23:40 |
| gsilvapt | Guess we both learned something, haha :D | 23:41 |
| Chipaca | gsilvapt: :-) | 23:41 |
| Chipaca | gsilvapt: good thing is, if they're the same, it'll tell you | 23:41 |
| Chipaca | so you can push/pull again if in doubt | 23:42 |
| gsilvapt | Chipaca, you mean using the aliases? Hum, never did that before. Interesting! | 23:42 |
| Chipaca | gsilvapt: no i mean, git push origin; git push origin -> second one says "meh" | 23:42 |
| gsilvapt | Chipaca, ahh! I see | 23:46 |
| gsilvapt | elopio, you around? | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
