[05:41] Good morning [06:31] morning [06:39] Hey mborzecki :-) [06:45] zyga: hey [06:46] zyga: simple review ? https://github.com/snapcore/snapd/pull/6596 [06:46] PR #6596: spread: restore SELinux context when we mess with system files [06:50] On it [06:52] Done [06:52] zyga: thanks [07:15] Hello mvo [07:19] hey zyga [07:24] mvo: hey [07:25] じゃあまた [07:25] That was what you asked about last time [07:26] hey mborzecki [07:26] zyga: !!! [07:26] zyga: amazing [07:26] zyga: looking forward for you teaching me some more [07:29] I’ll be around shortly [07:43] hey sil2100 ! quick question - can we get https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd into core18 via your foundations ppa maybe? this way we can run our regression test (and full suite) with the fix just like we did with xenial === pstolowski|afk is now known as pstolowski [08:04] morning [08:04] hey pstolowski [08:14] Hey Pawel [08:22] mvo: https://www.viva64.com/en/b/0600/ [08:22] zyga: ^^ [08:22] pstolowski: hey [08:23] mborzecki: looks good, we should try it [08:27] Applied [08:27] Thank you === chihchun_afk is now known as chihchun [08:37] mvo: couple of Q/comments on 6401 , I didn't notice but we are trying not to add anymore to api.go, see recent work by Chipaca and me [08:39] pedronis: oh, ok. I have a look, I missed that. thank you [08:42] mvo: i'd gladly pick that up if you're otherwise busy [08:42] * Chipaca dreading the merge-the-health-checks work [08:42] :-) [08:42] Chipaca: yeah, that is welcome [08:42] ok [08:42] Chipaca: \o/ [08:43] * mvo tries to tame wait-chains right now [08:44] Chipaca: did you update the Reason: scheduled one? [08:44] and morning [08:44] first i'll address pedronis's comment on #6598 [08:44] PR #6598: overlord/snapstate, store: set a header when auto-refreshing [08:44] pedronis: morning [08:44] pedronis: i'd written up to # and went looking for the number :-) [08:45] pedronis: it's just the flag -> opt thing, right? [08:45] Chipaca: there's a suggested if reorg as well [08:45] pedronis: or do you want me to also do the cleanups of things that were already there? [08:45] Chipaca: ideally also the cleanups, yes [08:46] (that'll make the diff bigger, meaning less chance convincing pedronis it's minimal and can go in 2.38 :-p) [08:46] Chipaca: you can do a follow up instead [08:47] but it would be good to address them [08:47] pedronis: your call, I don't mind if this doesn't make 2.38 :-) [08:50] Chipaca: either maybe the if, but the rename should be rather innocuous [08:50] Chipaca: I mean, I don't think the diff will be that much bigger [08:50] the biggest addition are the tests in fact [08:50] i wonder why we decided rate limit would be an int64 (and not a uint64) [08:51] Chipaca: no clue, I don't think I reviewed that code [08:52] Chipaca: it starts with ParseByteSize returning int64 [08:52] (but that doesn't support -5b) [08:53] Chipaca: anyway that is a bigger change [08:53] not for this one [08:53] Chipaca: but yes, it makes one wonder if rateLimit can be -128 [08:53] totally [08:54] I'll change things around a little, hopefully for the better, and push a change to make the rate thing not be negative separately [08:54] ParseByteSize doesn't support negative numbers more by accident than by design i fear [08:54] Chipaca: do negative sizes make sense though? [08:54] no [08:55] I mean, they might be used in the kernel or something to indicate errors [08:55] but for our use, no [08:55] (and our use of ParseByteSize is purely about rate limiting) [09:04] * dot-tobias waves hello [09:10] pedronis: reqOptions() -> downloadReqOpts() ok with you? [09:11] Chipaca: yes, it is used in download and connectivity check, right? [09:13] pedronis: yes, and in conn check it's used for the download endpoint [09:13] yup [09:17] hey Chipaca :) [09:17] * zyga is happy despite the rainy day [09:18] zyga: morning sah :-) [09:23] Chipaca: brexit makes my sleeping pattern erratic [09:23] zyga: welcome to my world [09:23] Chipaca: on the up side, the current state, as chaotic as it is, feels like an improvement over last few weeks [09:24] Chipaca: at least from far away here, I don't know how it feels to be directly affected [09:24] zyga: I'm refusing to get my hopes up, but my favourite outcome is still in the race [09:24] Chipaca: I did an unrelated change (unrelated to the api layout we discussed) you may need to git pull for 6401 [09:24] mvo: will do [09:33] mvo: thank you for adding that check [09:34] my pleasure [09:44] pedronis, mvo, pushed to 6401 [09:44] maybe i should've pushed two commits [09:44] Chipaca: thank you! [09:44] instead of one with two changes [09:44] hm [09:45] pedronis: again not daemon_test package because apiBaseSuite is a beast [09:45] Chipaca: that's ok, we can look into that at some point [09:45] but at least the beasts are not growing [09:45] y [09:45] yes [10:07] ogra: you around? [10:07] #6596 is one unlucky PR [10:07] PR #6596: spread: restore SELinux context when we mess with system files [10:08] the travis job just keeps on failing and failing, either github, or store timeout, or some from-repo package installation taking too long [10:08] Chipaca, in a meeting, so half way ... === chihchun is now known as chihchun_afk [10:15] hi, I'm trying to build a core18 snap with multipass, but it seems to just hang there after starting the vm. if I "multipass shell" in it, I don't see anything running. how can I debug this? [10:15] pedronis: quick question (if you have a moment) - in doUpdate we merge a bunch of taskSets and the "edge" information (DownloadAndChecksDoneEdge) gets lot - one approach would be to transfer edges in ts.AddAll(anotherTs), I drafted this in http://paste.ubuntu.com/p/tDJf9XbTGg/ would love to hear your thoughts http://paste.ubuntu.com/p/tDJf9XbTGg/ [10:16] (ups, sorry for the same url twice) === chihchun_afk is now known as chihchun [10:23] guys, so how about we land https://github.com/snapcore/snapd/pull/6270 ? [10:23] PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests [10:24] mvo: Chipaca: I made a help suggestion in 6401 [10:24] mvo: it's a bit problematic because some edges might not make sense in the larger task set [10:24] pedronis: I can also just transfer the edge over in doUpdate explicitely [10:25] pedronis: thats the simplest one [10:25] pedronis: its slightly annoying that this area of code has to have knowledge about this though [10:25] pedronis: or I can try to rework the way doUpdate is using []*TaskSet but that seems to be hard [10:26] pedronis: anyway, would love some ideas :) [10:26] mvo: let me look at the code [10:26] pedronis: updated #6593 [10:26] PR #6593: sandbox/seccomp: a helper package wrapping calls to snap-seccomp [10:32] mvo: I think it would be fine to have separate AddAllWithEdges (my point is mostly tha whether to copy them over, rename them around etc needs to be conscious decision) [10:35] pedronis: ok - with the same error handling as is in there already? i.e. error on dupes? [10:35] mvo: yes [10:35] pedronis: great, thank you! I make this happen [10:35] pedronis: a problem with that help message is that AIUI it breaks https://forum.snapcraft.io/t/convention-for-command-help-text/1856 [10:36] Chipaca: fix it [10:36] :-) [10:36] pedronis: the docs, or the help message :-D [10:36] Chipaca: I mean the original was saying too little [10:36] a'ight [10:36] we need something that respect the style guide [10:37] but also tells more [10:38] mborzecki: what's the difference between InternalToolPath and the helper? I'm obtuse [10:39] pedronis: in that PR none, in the final one InternalToolPath won't work because it assumes it's either distro libexecdir or a path under snap-mount-dir [10:39] pedronis: and in bootstrap the mount path is none of the 2 locations [10:41] mborzecki: does it mean InternalToolPath is broken? [10:41] I mean are we sure it doesn't it this issue in some cases [10:43] pedronis: i wouldn't say it's broken, it's more like there is an assumption that snapd is installed in the system in some way, which is true in general, but not true during bootstrap [10:44] huh, Nonce is missing or invalid [10:44] does snapcraft keep any state other than the usual (parts/ stage/ prime/) dirs when run in --destructive-mode ? [10:46] mborzecki: are we failing generate key during bootstrap, I see similar code [10:46] there [10:47] mborzecki: findSnapdPath [10:48] pedronis: that code is correct [10:49] pedronis: it does not fall back to filepath.Join(dirs.DistroLibexecDir,...) [10:49] pedronis: perhaps an update to InternalToolPath would make sense [10:50] pedronis: after all if the tool is 'internal' it's supposed to be where snapd binary is [10:50] afaict it does fallback [10:50] maybe I'm reading it wrong [10:50] anyway I'm a bit worried about all this places doing slightly different with self/exe [10:53] pedronis: I just split it :-) [10:54] * Chipaca context-switches pedronis for fun & profit [10:54] haha [10:54] mborzecki: if I read correctly we do a full seeding with snapd running from the tmp dir [10:54] pedronis: yes [10:54] so any place is potentially buggy [10:54] yup, fortunately it's only system key and seccomp at this point [10:54] well, no [10:55] there's a place using InternalToolPath [10:55] maybe it's buggy [10:55] or not [10:55] Can I somehow check how snapd reads my gadget.yaml by invoking some CLI command? I have a default configuration that has to be fed to the configure hook as a string, but it really is a YAML file thus should preserve line breaks. [10:56] pedronis: haha :P [10:56] dot-tobias: have you looked at what the online yaml parser makes of it? [10:56] (was it you i showed that one to yesterday?) [10:57] pedronis: i'd say that in the general case we should just do filepath.Dir(Readlink("/proc/self/exe")) and use that [10:57] mborzecki: interfaces/mount/ns.go [10:57] pedronis: unless realdink fails, in which case fallback to distro libexecdir may be ok [10:58] mborzecki: the code is not like that though, in most of these places [10:58] they all check mount dir [10:59] Chipaca: Yes, I was the one from yesterday 😊 I checked and it preserves line breaks as \n, but feeding this to mir-kiosk (display-config can be set as a string) results in an erroneous miral-kiosk.display file with newline printed as literal \n [10:59] dot-tobias: can you show me? [11:00] pedronis: at least for the seccomp tool, I updated this here https://github.com/snapcore/snapd/pull/6485/files#diff-a5ed6485262fae2e80ad61a8b843504eR68 [11:00] dot-tobias: to answer your question directly, there isn't a way to do that right now [11:00] PR #6485: interfaces/seccomp: regenerate changed profiles only <⛔ Blocked> [11:01] mborzecki: I have a bit lost track of why the check [11:01] Chipaca: Sure, here's the current gadget.yaml: https://gitlab.com/glancr/gadget-snap-pi-kiosk/blob/master/gadget.yaml#L12 [11:01] we probably need to talk with mvo [11:01] pedronis: a chat then? [11:01] yes [11:01] mvo: ^^ [11:02] pedronis: mvo: HO? [11:02] mborzecki: in a meeting right now [11:02] mvo: ok, once you're finished then? [11:02] Chipaca: If I run "snap set mir-kiosk display-config="$(cat a config file with the exact same contents)", everything works fine. But I suspect the multiline string from gadget.yaml is mangled somewhere. [11:05] Chipaca: I can't really check what the actual result is from the device intialization as snapd errors (mir-kiosk configure hook can't parse the mess it gets from the yaml default) and rolls back. I occasionally check on-device but I'm always either too early or too late to see the actual file created 😞 [11:06] dot-tobias: which 'actual file created'? [11:06] dot-tobias: (i'm not super familiar with this part of the code :) ) === chihchun is now known as chihchun_afk [11:08] Chipaca: mir-kiosk's configure hook saves display-config to a file in $SNAP_DATA/miral_kiosk.display (cf. https://github.com/MirServer/mir-kiosk/blob/ad041e6b19205acacaf9881568061d8fd5a5742e/snap/hooks/configure#L29). [11:08] right, but the first boot config isn't done from the file [11:08] it's done from reading the snap.yaml [11:09] dot-tobias: let me load and dump that yaml file and see what snapd makes of it [11:12] Chipaca: That would be great, thank you. Correct me if wrong, but I thought that the gadget setup was roughly this: boot > mir-kiosk snap is installed from prefetched .snap, including any default config > gadget.yaml is read for default settings > snapd basically runs “snap set snap-name some-setting=specified-value-from-gadget.yaml – if that's the case, I don't quite follow your statement about first boot config [11:12] dot-tobias: snapd does basically run snap set … [11:13] dot-tobias: but the file comes after 'snap set', not before [11:13] dot-tobias: so if the file has mangled \n's, it's because whatever called the equivalent of 'snap set' did it wrong [11:14] dot-tobias: and the codepath is simple enough that it's _probably_ reading it wrong in the first place but idunno [11:14] getting there [11:14] dot-tobias: the problematic config is display-config, yes? [11:14] Chipaca: I guess we're talking about the same thing, but not sure 😄 [11:15] Chipaca: yes, display-config is the one I'm trying to set. [11:16] the config is loaded jus' fine [11:16] so the problem is in the setting of it [11:16] hmm [11:17] oh wait what is this normalize code [11:18] Chipaca: Yes, I suspect that the gadget.yaml multiline string is parsed somewhere and passed to “snap set” with literal \n newlines, which mir-kiosk's configure hook does not further parse or validate (just echoes the passed string to miral-kiosk.display) – thus resulting in one long string with literal \n instead of a valid YAML dict [11:19] indeed [11:22] Chipaca: And that's the part where I don't know if “I'm holding it wrong” or if preserving a config file with implicit newlines (dunno if that's the correct term) through this whole YAML parsing is currently just not possible. 😊 [11:23] dot-tobias: so, there's a bug, this should work [11:23] dot-tobias: we should fix it [11:23] dot-tobias: but that doesn't unblock you [11:23] dot-tobias: however, there's a way out for you [11:23] i hope [11:23] dot-tobias: but it's a bit nasty [11:24] Chipaca: I'm all for nasty workarounds if they do the job until the elegant way is possible 😊 [11:26] dot-tobias: rewrite the config file yaml using the json-like syntax [11:26] dot-tobias: gimme a sec i'll do it for you [11:26] PR snapd#6596 closed: spread: restore SELinux context when we mess with system files [11:29] dot-tobias: layouts: {normal: {cards: [{card-id: 0, HDMI-A-1: null}]}, right: {cards: [{card-id: 0, HDMI-A-1: {orientation: right}}]}, left: {cards: [{card-id: 0, HDMI-A-1: {orientation: left}}]}, inverted: {cards: [{card-id: 0, HDMI-A-1: {orientation: inverted}}]}} [11:29] dot-tobias: no comments in this format :-/ [11:30] pedronis: pstolowski: we have some issue with spurious escaping of config values coming from gadget.yaml [11:30] Chipaca: Can live without comments for now. Thank you very much! So I put that into gadget.yaml > defaults > display.config as a string? [11:30] dot-tobias: yes [11:31] dot-tobias: let me know if it actually works of course :-) [11:31] pedronis: pstolowski: meaning the snaps get \\n instead of \n for ex [11:32] Chipaca: Will do, thank you! [11:32] Chipaca: escaping where? [11:33] pedronis: mvo: can we land #6270? [11:33] PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests [11:33] pedronis: the Configure hook that's run using the values from the gadget.yaml [11:34] Chipaca: yes [11:34] Chipaca: where is the escaping, snapctl get? or before? [11:35] or it's misunderstanding about what the result is [11:35] pedronis: the loading seems to be fine, no spurious escaping [11:35] pedronis: I don't know where it's happening, don't have an easy way to repro [11:36] we do need a repro [11:36] * pedronis lunch [11:36] pedronis: I mean, dot-tobias was hitting this IRL [11:37] pedronis: I mean I don't have a _minimal_ way to reproduce it that doesn't involve a gadget and a device and first-booting it [11:37] fortunately there's a workaround for them, as it's yaml so you can just scrunch it up (ewww), but if it'd been an .ini file we would've been SOL [11:37] Chipaca: we do have spread test like that [11:38] I mean we should be able to write a spread test [11:38] I know :-) i'm saying I haven't -- I was trying to make it SEP [11:42] Chipaca: did we learn anything more about the 19.40 seeeding woes? [11:42] 19.04 [11:42] * pedronis really lunch [11:43] pedronis: I'm trying to reproduce them locally [11:43] s/them/it/ [11:43] them == the woes, clearly [11:45] right now I'm struggling to get a new disco install to _boot_, let alone be snappy [11:46] two different icons for installation, with arrows pointing different ways [11:49] Chipaca, so what was that ping about ? [11:53] ogra: who knows :-) [11:53] heh [11:55] hrm, hrm, whats up with tests [11:55] ogra: while you are here - you probably like https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd [11:56] ogra: we just need to convince someone from the sru team to actually approve :) [11:56] YAY !!! [11:56] mborzecki: you wanted to talk about something earlire? sorry was in a meeting and then forgot [11:57] mvo: yes, we need pedronis too [11:57] hey sil2100 ! quick question - can we get https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd into core18 via your foundations ppa maybe? this way we can run our regression test (and full suite) with the fix just like we did with xenia [11:57] mborzecki: probably after lunch, what was the question? [11:57] and why are tests unhappy currently :( ? [11:58] mvo: some concerns about finding internal tools [11:59] mborzecki: ok, so - for snapd its easy, just os.dirname(os.link("/proc/self/exe")) [12:00] mborzecki: but for the "snap" binary its not [12:00] mborzecki: I think we need to lookup something (snap-exec?) there [12:01] mborzecki: maybe the answer is that the toolpath is also just relative for the snap binary "../lib/snapd" [12:01] mborzecki: am I actually speaking about the right question or am I lost in something else :) ? [12:01] mvo: ../lib{exec}/snapd [12:02] mvo: right, we were discussing the case of 'snapd' and cmd.InternalToolPath which does not work for boostrap environment [12:02] mborzecki: yeah, for snapd my suggestion is to always look into the same dir [12:03] mborzecki: and maybe (to support running from a git tree) to fallback to /usr/lib{,exec}/snapd [12:03] mborzecki: but for snap its slightly more complicated [12:04] mvo: hey! Let me take a look [12:05] PR snapd#6599 opened: snapstate,state: add TaskSet.AddAllWithEdges() and use in doUpdate [12:05] mvo: hm, I can review it today for -proposed and then copy it over to the PPA for testing (with a lower version) [12:06] sil2100: cool, let me know if I can help in any way (but I probably don't have the right permissions) === chihchun_afk is now known as chihchun [12:10] mvo: i can try and open a PR cleaning up cmd.InternalToolPath/findSnapdPath/seccompToBpfPath to be consistent [12:12] Chipaca: do we understand enough from dot-tobias situation to make a LP bug? [12:12] mborzecki: I think that would be good [12:12] mborzecki: maybe a separate PR? [12:12] pedronis: I think so yes [12:12] mvo: right [12:12] dot-tobias: could you do that? file an lp bug about this [12:12] Chipaca: could you make one? [12:12] or dot-tobias [12:12] pedronis: trying to punt it :-) [12:12] mborzecki: yes, simplifiying would be good [12:13] mborzecki: mvo: do we compute system key from snap ? or only from snapd? [12:13] pedronis: only snapd apparently [12:13] ok [12:15] mborzecki: no, both, snap run uses SystemKeyMismatch [12:15] so findSnapdPath is abit more delicate [12:15] afaict [12:16] pedronis: right, but only snapd build-id is used in the system key data [12:16] mborzecki: well and snap-seccomp output in your PRs? no? [12:16] yes [12:24] * pstolowski lunch [12:25] mvo: ok, bionic looks good, accepted for bionic-proposed [12:25] Chipaca, where do you see those inconsistant arrows for installation? [12:26] heh [12:26] I will copy it to the PPA but please please please shepherd the bionic-proposed systemd upload [12:26] seb128: https://snapforum.s3.amazonaws.com/original/2X/6/6db33b0da7456be46210985f939a0e2040284e6b.jpg [12:26] Chipaca, did you sort out your non booting image? maybe worth mentioning on #ubuntu-desktop [12:26] if you need help figuring it out [12:26] mvo: systemd uploads trigger a lot of tests and a lot of failures and the uploader needs to make sure they pass and/or are identified as flaky [12:26] seb128: it was booting, just not doing anything graphic [12:26] pedronis: can you advise on what to do about https://travis-ci.org/snapcore/snapd/jobs/505983378? [12:26] Wouldn't want this upload to be stuck in bionic forever [12:26] Chipaca, ah, thx [12:26] seb128: -vga qxl fixed that [12:27] Chipaca, ah, good [12:27] seb128: https://forum.snapcraft.io/t/no-more-preinstalled-snap-on-ubuntu-19-04/10339/49?u=chipaca [12:27] pedronis: hello btw :) [12:27] (just writing random stuff there as i try to repro the issue at hand) [12:28] pedronis: sergiusens said something about a rebase, but I thought that would confuse github [12:28] jdstrand: did you see my comment on why it's blocked? (it was about the tests, I think we talked about it but I forgot to write the reason in the PR) [12:28] Chipaca, ah, tb didn't charge the image from the email for some reason, I see it now, the 'other arrow' on the desktop is because it's a symlink, it's a bit unfortunate how it 'conflicts' with the icon own arrows placed in the same corner [12:29] * jdstrand doesn't have 'zyga@xenial' anywhere in the tree [12:29] seb128: if it didn't, then it'd have two opposite arrows :-) [12:29] Chipaca, Ken didn't get the issue every time, might be racy, so I guess "how you reproduce' is by trying a new install again [12:29] jdstrand: does git log do? [12:29] jdstrand: it's the history [12:29] seb128: yep [12:29] pedronis: I thought you said it could go in so long as tests came later. you want the tests now? [12:29] Chipaca, right :) [12:29] jdstrand: sorry, it was not about the tests [12:29] jdstrand: please read the comment in the PR [12:30] zyga: 'does git log do'? can you rephrase? [12:30] and answer there [12:30] jdstrand: run git log | grep zyga@xenial [12:30] pedronis: "I agree though with niemeyer comments regarding the summaries, we probably want to change those before merging." I did that [12:31] zyga: yes, I have that: [12:31] Author: zyga [12:31] Signed-off-by: zyga [12:31] the author needs to be changed [12:31] every time I try gnome shell i miss the keyboard-friendliness of unity :-( === ricab is now known as ricab|lunch [12:31] * Chipaca hugs his 16.04 to his chest [12:32] jdstrand: this comment: https://github.com/snapcore/snapd/pull/5644#issuecomment-472723883 [12:32] PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <⛔ Blocked> [12:32] from this morning [12:32] zyga: uhh, everyone has to do this? [12:32] jdstrand: perhaps I misunderstand but this is in an incoming PR? [12:32] jdstrand: if so, just that needs to change [12:33] Chipaca / pedronis : I'll open a LP bug (for snapd?) and try to describe the problem as detailed as possible; Chipaca feel free to make amends if I misunderstood the actual issue (but at least I can describe what the outcome is) [12:33] jdstrand: we can work on landing it on our side [12:33] dot-tobias: thanks! [12:33] jdstrand: I'm still interested if what I described is a blocker or not [12:36] pedronis: I answered in the PR. I don't consider it a blocker since at worst I will see things come into the queue and manually approve them/grant the snap decl while I'm working through all the grants [12:37] pedronis: but if you do, then I can try to get to it. it's several hundred so it will take me a while [12:37] jdstrand: what I'm worried is if somebody installs with snapd beta one of the affected snaps before the declaration is changed [12:38] zyga: it isn't a new PR, it is an ancient PR at this point that all of a sudden started failing that cause I did a git fetch/merge [12:38] will not the install fail? [12:38] well, not fail [12:38] but not work until it connects things manually [12:38] which is not expected [12:39] yes, that would happen [12:39] that is a fair point [12:41] * jdstrand doesn't understand how all of a sudden 92a096278e040b452125260b00742ae6e62caf2c from October is now causing me problems [12:41] Saviq, hi, how can I debug what snapcraft is doing inside a multipass vm? [12:42] Saviq, I'm trying to figure out why a snapcraft build seems to hang after having launched the vm [12:42] zyga: ^ why am I seeing this now and why doesn't master change it so that no one else will be affected? [12:43] jdstrand: I don't understand, can you tell me where exactly are you seeing it? [12:43] zyga: https://travis-ci.org/snapcore/snapd/jobs/505983378 [12:43] jdstrand: I see your ping now, sorry for the interrupt [12:45] jdstrand: wow, no idea now [12:45] perhaps tests/lib/cla_check.py should ignore that email if people don't want to rewrite history. how is this passing for anyone? [12:45] no idea, it's odd [12:46] pedronis: oh, this is all set for 2.39 anyway. that's right. I was thinking as soon as it was committed, I'd get started, do 50 a day or something [12:47] Chipaca: hey, you seem to have written ./tests/lib/cla_check.py [12:48] jdstrand: sorry I was not of much help [12:48] Chipaca: after a recent fetch/merge with master for an existing PR, I started seeing https://travis-ci.org/snapcore/snapd/jobs/505983378 [12:48] jdstrand: perhaps do a test: rebase and open a new PR [12:48] jdstrand: if that passes it's a data point [12:48] jdstrand: huh [12:49] Chipaca: the email address that is failing is from 92a096278e040b452125260b00742ae6e62caf2c october [12:49] jdstrand: should be easy to fix [12:49] jdstrand: somehow :-| [12:50] jdstrand: I mean, should be easy to fix the script to catch that exception [12:50] Chipaca: I mean, I can adjust the author with a git rebase, but is that the right thing to do? why aren't others seeing this? (granted, my pr started before october, so maybe the check was added after that and I'm only seeing this cause I'm the only one with commits that stretch that far back?) [12:50] jdstrand: I don't know why it's trying to verify an email already on master though [12:50] hmm [12:51]