| zyga | Good morning | 05:41 |
|---|---|---|
| mborzecki | morning | 06:31 |
| zyga | Hey mborzecki :-) | 06:39 |
| mborzecki | zyga: hey | 06:45 |
| mborzecki | zyga: simple review ? https://github.com/snapcore/snapd/pull/6596 | 06:46 |
| mup | PR #6596: spread: restore SELinux context when we mess with system files <SELinux> <Simple π> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6596> | 06:46 |
| zyga | On it | 06:50 |
| zyga | Done | 06:52 |
| mborzecki | zyga: thanks | 06:52 |
| zyga | Hello mvo | 07:15 |
| mvo | hey zyga | 07:19 |
| mborzecki | mvo: hey | 07:24 |
| zyga | γγγγΎγ | 07:25 |
| zyga | That was what you asked about last time | 07:25 |
| mvo | hey mborzecki | 07:26 |
| mvo | zyga: !!! | 07:26 |
| mvo | zyga: amazing | 07:26 |
| mvo | zyga: looking forward for you teaching me some more | 07:26 |
| zyga | Iβll be around shortly | 07:29 |
| mvo | 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 | 07:43 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 08:04 |
| mvo | hey pstolowski | 08:04 |
| zyga | Hey Pawel | 08:14 |
| mborzecki | mvo: https://www.viva64.com/en/b/0600/ | 08:22 |
| mborzecki | zyga: ^^ | 08:22 |
| mborzecki | pstolowski: hey | 08:22 |
| mvo | mborzecki: looks good, we should try it | 08:23 |
| zyga | Applied | 08:27 |
| zyga | Thank you | 08:27 |
| === chihchun_afk is now known as chihchun | ||
| pedronis | 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:37 |
| mvo | pedronis: oh, ok. I have a look, I missed that. thank you | 08:39 |
| Chipaca | mvo: i'd gladly pick that up if you're otherwise busy | 08:42 |
| * Chipaca dreading the merge-the-health-checks work | 08:42 | |
| Chipaca | :-) | 08:42 |
| mvo | Chipaca: yeah, that is welcome | 08:42 |
| Chipaca | ok | 08:42 |
| mvo | Chipaca: \o/ | 08:42 |
| * mvo tries to tame wait-chains right now | 08:43 | |
| pedronis | Chipaca: did you update the Reason: scheduled one? | 08:44 |
| pedronis | and morning | 08:44 |
| Chipaca | first i'll address pedronis's comment on #6598 | 08:44 |
| mup | PR #6598: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6598> | 08:44 |
| Chipaca | pedronis: morning | 08:44 |
| Chipaca | pedronis: i'd written up to # and went looking for the number :-) | 08:44 |
| Chipaca | pedronis: it's just the flag -> opt thing, right? | 08:45 |
| pedronis | Chipaca: there's a suggested if reorg as well | 08:45 |
| Chipaca | pedronis: or do you want me to also do the cleanups of things that were already there? | 08:45 |
| pedronis | Chipaca: ideally also the cleanups, yes | 08:45 |
| Chipaca | (that'll make the diff bigger, meaning less chance convincing pedronis it's minimal and can go in 2.38 :-p) | 08:46 |
| pedronis | Chipaca: you can do a follow up instead | 08:46 |
| pedronis | but it would be good to address them | 08:47 |
| Chipaca | pedronis: your call, I don't mind if this doesn't make 2.38 :-) | 08:47 |
| pedronis | Chipaca: either maybe the if, but the rename should be rather innocuous | 08:50 |
| pedronis | Chipaca: I mean, I don't think the diff will be that much bigger | 08:50 |
| pedronis | the biggest addition are the tests in fact | 08:50 |
| Chipaca | i wonder why we decided rate limit would be an int64 (and not a uint64) | 08:50 |
| pedronis | Chipaca: no clue, I don't think I reviewed that code | 08:51 |
| pedronis | Chipaca: it starts with ParseByteSize returning int64 | 08:52 |
| pedronis | (but that doesn't support -5b) | 08:52 |
| pedronis | Chipaca: anyway that is a bigger change | 08:53 |
| pedronis | not for this one | 08:53 |
| pedronis | Chipaca: but yes, it makes one wonder if rateLimit can be -128 | 08:53 |
| Chipaca | totally | 08:53 |
| Chipaca | 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 |
| Chipaca | ParseByteSize doesn't support negative numbers more by accident than by design i fear | 08:54 |
| pedronis | Chipaca: do negative sizes make sense though? | 08:54 |
| Chipaca | no | 08:54 |
| Chipaca | I mean, they might be used in the kernel or something to indicate errors | 08:55 |
| Chipaca | but for our use, no | 08:55 |
| Chipaca | (and our use of ParseByteSize is purely about rate limiting) | 08:55 |
| * dot-tobias waves hello | 09:04 | |
| Chipaca | pedronis: reqOptions() -> downloadReqOpts() ok with you? | 09:10 |
| pedronis | Chipaca: yes, it is used in download and connectivity check, right? | 09:11 |
| Chipaca | pedronis: yes, and in conn check it's used for the download endpoint | 09:13 |
| pedronis | yup | 09:13 |
| zyga | hey Chipaca :) | 09:17 |
| * zyga is happy despite the rainy day | 09:17 | |
| Chipaca | zyga: morning sah :-) | 09:18 |
| zyga | Chipaca: brexit makes my sleeping pattern erratic | 09:23 |
| Chipaca | zyga: welcome to my world | 09:23 |
| zyga | Chipaca: on the up side, the current state, as chaotic as it is, feels like an improvement over last few weeks | 09:23 |
| zyga | Chipaca: at least from far away here, I don't know how it feels to be directly affected | 09:24 |
| Chipaca | zyga: I'm refusing to get my hopes up, but my favourite outcome is still in the race | 09:24 |
| mvo | Chipaca: I did an unrelated change (unrelated to the api layout we discussed) you may need to git pull for 6401 | 09:24 |
| Chipaca | mvo: will do | 09:24 |
| pedronis | mvo: thank you for adding that check | 09:33 |
| mvo | my pleasure | 09:34 |
| Chipaca | pedronis, mvo, pushed to 6401 | 09:44 |
| Chipaca | maybe i should've pushed two commits | 09:44 |
| mvo | Chipaca: thank you! | 09:44 |
| Chipaca | instead of one with two changes | 09:44 |
| Chipaca | hm | 09:44 |
| Chipaca | pedronis: again not daemon_test package because apiBaseSuite is a beast | 09:45 |
| pedronis | Chipaca: that's ok, we can look into that at some point | 09:45 |
| pedronis | but at least the beasts are not growing | 09:45 |
| Chipaca | y | 09:45 |
| Chipaca | yes | 09:45 |
| Chipaca | ogra: you around? | 10:07 |
| mborzecki | #6596 is one unlucky PR | 10:07 |
| mup | PR #6596: spread: restore SELinux context when we mess with system files <SELinux> <Simple π> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6596> | 10:07 |
| mborzecki | 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 |
| ogra | Chipaca, in a meeting, so half way ... | 10:08 |
| === chihchun is now known as chihchun_afk | ||
| ackk | 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 |
| mvo | 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:15 |
| mvo | (ups, sorry for the same url twice) | 10:16 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | guys, so how about we land https://github.com/snapcore/snapd/pull/6270 ? | 10:23 |
| mup | PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270> | 10:23 |
| pedronis | mvo: Chipaca: I made a help suggestion in 6401 | 10:24 |
| pedronis | mvo: it's a bit problematic because some edges might not make sense in the larger task set | 10:24 |
| mvo | pedronis: I can also just transfer the edge over in doUpdate explicitely | 10:24 |
| mvo | pedronis: thats the simplest one | 10:25 |
| mvo | pedronis: its slightly annoying that this area of code has to have knowledge about this though | 10:25 |
| mvo | pedronis: or I can try to rework the way doUpdate is using []*TaskSet but that seems to be hard | 10:25 |
| mvo | pedronis: anyway, would love some ideas :) | 10:26 |
| pedronis | mvo: let me look at the code | 10:26 |
| mborzecki | pedronis: updated #6593 | 10:26 |
| mup | PR #6593: sandbox/seccomp: a helper package wrapping calls to snap-seccomp <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6593> | 10:26 |
| pedronis | 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:32 |
| mvo | pedronis: ok - with the same error handling as is in there already? i.e. error on dupes? | 10:35 |
| pedronis | mvo: yes | 10:35 |
| mvo | pedronis: great, thank you! I make this happen | 10:35 |
| Chipaca | pedronis: a problem with that help message is that AIUI it breaks https://forum.snapcraft.io/t/convention-for-command-help-text/1856 | 10:35 |
| pedronis | Chipaca: fix it | 10:36 |
| Chipaca | :-) | 10:36 |
| Chipaca | pedronis: the docs, or the help message :-D | 10:36 |
| pedronis | Chipaca: I mean the original was saying too little | 10:36 |
| Chipaca | a'ight | 10:36 |
| pedronis | we need something that respect the style guide | 10:36 |
| pedronis | but also tells more | 10:37 |
| pedronis | mborzecki: what's the difference between InternalToolPath and the helper? I'm obtuse | 10:38 |
| mborzecki | 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 |
| mborzecki | pedronis: and in bootstrap the mount path is none of the 2 locations | 10:39 |
| pedronis | mborzecki: does it mean InternalToolPath is broken? | 10:41 |
| pedronis | I mean are we sure it doesn't it this issue in some cases | 10:41 |
| mborzecki | 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:43 |
| Chipaca | huh, Nonce is missing or invalid | 10:44 |
| ackk | does snapcraft keep any state other than the usual (parts/ stage/ prime/) dirs when run in --destructive-mode ? | 10:44 |
| pedronis | mborzecki: are we failing generate key during bootstrap, I see similar code | 10:46 |
| pedronis | there | 10:46 |
| pedronis | mborzecki: findSnapdPath | 10:47 |
| mborzecki | pedronis: that code is correct | 10:48 |
| mborzecki | pedronis: it does not fall back to filepath.Join(dirs.DistroLibexecDir,...) | 10:49 |
| mborzecki | pedronis: perhaps an update to InternalToolPath would make sense | 10:49 |
| mborzecki | pedronis: after all if the tool is 'internal' it's supposed to be where snapd binary is | 10:50 |
| pedronis | afaict it does fallback | 10:50 |
| pedronis | maybe I'm reading it wrong | 10:50 |
| pedronis | anyway I'm a bit worried about all this places doing slightly different with self/exe | 10:50 |
| Chipaca | pedronis: I just split it :-) | 10:53 |
| * Chipaca context-switches pedronis for fun & profit | 10:54 | |
| mborzecki | haha | 10:54 |
| pedronis | mborzecki: if I read correctly we do a full seeding with snapd running from the tmp dir | 10:54 |
| mborzecki | pedronis: yes | 10:54 |
| pedronis | so any place is potentially buggy | 10:54 |
| mborzecki | yup, fortunately it's only system key and seccomp at this point | 10:54 |
| pedronis | well, no | 10:54 |
| pedronis | there's a place using InternalToolPath | 10:55 |
| pedronis | maybe it's buggy | 10:55 |
| pedronis | or not | 10:55 |
| dot-tobias | 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:55 |
| mborzecki | pedronis: haha :P | 10:56 |
| Chipaca | dot-tobias: have you looked at what the online yaml parser makes of it? | 10:56 |
| Chipaca | (was it you i showed that one to yesterday?) | 10:56 |
| mborzecki | pedronis: i'd say that in the general case we should just do filepath.Dir(Readlink("/proc/self/exe")) and use that | 10:57 |
| pedronis | mborzecki: interfaces/mount/ns.go | 10:57 |
| mborzecki | pedronis: unless realdink fails, in which case fallback to distro libexecdir may be ok | 10:57 |
| pedronis | mborzecki: the code is not like that though, in most of these places | 10:58 |
| pedronis | they all check mount dir | 10:58 |
| dot-tobias | 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 |
| Chipaca | dot-tobias: can you show me? | 10:59 |
| mborzecki | pedronis: at least for the seccomp tool, I updated this here https://github.com/snapcore/snapd/pull/6485/files#diff-a5ed6485262fae2e80ad61a8b843504eR68 | 11:00 |
| Chipaca | dot-tobias: to answer your question directly, there isn't a way to do that right now | 11:00 |
| mup | PR #6485: interfaces/seccomp: regenerate changed profiles only <β Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485> | 11:00 |
| pedronis | mborzecki: I have a bit lost track of why the check | 11:01 |
| dot-tobias | Chipaca: Sure, here's the current gadget.yaml: https://gitlab.com/glancr/gadget-snap-pi-kiosk/blob/master/gadget.yaml#L12 | 11:01 |
| pedronis | we probably need to talk with mvo | 11:01 |
| mborzecki | pedronis: a chat then? | 11:01 |
| pedronis | yes | 11:01 |
| mborzecki | mvo: ^^ | 11:01 |
| mborzecki | pedronis: mvo: HO? | 11:02 |
| mvo | mborzecki: in a meeting right now | 11:02 |
| mborzecki | mvo: ok, once you're finished then? | 11:02 |
| dot-tobias | 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:02 |
| dot-tobias | 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:05 |
| Chipaca | dot-tobias: which 'actual file created'? | 11:06 |
| Chipaca | dot-tobias: (i'm not super familiar with this part of the code :) ) | 11:06 |
| === chihchun is now known as chihchun_afk | ||
| dot-tobias | 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 |
| Chipaca | right, but the first boot config isn't done from the file | 11:08 |
| Chipaca | it's done from reading the snap.yaml | 11:08 |
| Chipaca | dot-tobias: let me load and dump that yaml file and see what snapd makes of it | 11:09 |
| dot-tobias | 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 |
| Chipaca | dot-tobias: snapd does basically run snap set β¦ | 11:12 |
| Chipaca | dot-tobias: but the file comes after 'snap set', not before | 11:13 |
| Chipaca | dot-tobias: so if the file has mangled \n's, it's because whatever called the equivalent of 'snap set' did it wrong | 11:13 |
| Chipaca | dot-tobias: and the codepath is simple enough that it's _probably_ reading it wrong in the first place but idunno | 11:14 |
| Chipaca | getting there | 11:14 |
| Chipaca | dot-tobias: the problematic config is display-config, yes? | 11:14 |
| dot-tobias | Chipaca: I guess we're talking about the same thing, but not sure π | 11:14 |
| dot-tobias | Chipaca: yes, display-config is the one I'm trying to set. | 11:15 |
| Chipaca | the config is loaded jus' fine | 11:16 |
| Chipaca | so the problem is in the setting of it | 11:16 |
| Chipaca | hmm | 11:16 |
| Chipaca | oh wait what is this normalize code | 11:17 |
| dot-tobias | 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:18 |
| Chipaca | indeed | 11:19 |
| dot-tobias | 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:22 |
| Chipaca | dot-tobias: so, there's a bug, this should work | 11:23 |
| Chipaca | dot-tobias: we should fix it | 11:23 |
| Chipaca | dot-tobias: but that doesn't unblock you | 11:23 |
| Chipaca | dot-tobias: however, there's a way out for you | 11:23 |
| Chipaca | i hope | 11:23 |
| Chipaca | dot-tobias: but it's a bit nasty | 11:23 |
| dot-tobias | Chipaca: I'm all for nasty workarounds if they do the job until the elegant way is possible π | 11:24 |
| Chipaca | dot-tobias: rewrite the config file yaml using the json-like syntax | 11:26 |
| Chipaca | dot-tobias: gimme a sec i'll do it for you | 11:26 |
| mup | PR snapd#6596 closed: spread: restore SELinux context when we mess with system files <SELinux> <Simple π> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6596> | 11:26 |
| Chipaca | 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 |
| Chipaca | dot-tobias: no comments in this format :-/ | 11:29 |
| Chipaca | pedronis: pstolowski: we have some issue with spurious escaping of config values coming from gadget.yaml | 11:30 |
| dot-tobias | 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 |
| Chipaca | dot-tobias: yes | 11:30 |
| Chipaca | dot-tobias: let me know if it actually works of course :-) | 11:31 |
| Chipaca | pedronis: pstolowski: meaning the snaps get \\n instead of \n for ex | 11:31 |
| dot-tobias | Chipaca: Will do, thank you! | 11:32 |
| pedronis | Chipaca: escaping where? | 11:32 |
| mborzecki | pedronis: mvo: can we land #6270? | 11:33 |
| mup | PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270> | 11:33 |
| Chipaca | pedronis: the Configure hook that's run using the values from the gadget.yaml | 11:33 |
| pedronis | Chipaca: yes | 11:34 |
| pedronis | Chipaca: where is the escaping, snapctl get? or before? | 11:34 |
| pedronis | or it's misunderstanding about what the result is | 11:35 |
| Chipaca | pedronis: the loading seems to be fine, no spurious escaping | 11:35 |
| Chipaca | pedronis: I don't know where it's happening, don't have an easy way to repro | 11:35 |
| pedronis | we do need a repro | 11:36 |
| * pedronis lunch | 11:36 | |
| Chipaca | pedronis: I mean, dot-tobias was hitting this IRL | 11:36 |
| Chipaca | 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 |
| Chipaca | 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 |
| pedronis | Chipaca: we do have spread test like that | 11:37 |
| pedronis | I mean we should be able to write a spread test | 11:38 |
| Chipaca | I know :-) i'm saying I haven't -- I was trying to make it SEP | 11:38 |
| pedronis | Chipaca: did we learn anything more about the 19.40 seeeding woes? | 11:42 |
| pedronis | 19.04 | 11:42 |
| * pedronis really lunch | 11:42 | |
| Chipaca | pedronis: I'm trying to reproduce them locally | 11:43 |
| Chipaca | s/them/it/ | 11:43 |
| Chipaca | them == the woes, clearly | 11:43 |
| Chipaca | right now I'm struggling to get a new disco install to _boot_, let alone be snappy | 11:45 |
| Chipaca | two different icons for installation, with arrows pointing different ways | 11:46 |
| ogra | Chipaca, so what was that ping about ? | 11:49 |
| Chipaca | ogra: who knows :-) | 11:53 |
| ogra | heh | 11:53 |
| mvo | hrm, hrm, whats up with tests | 11:55 |
| mvo | ogra: while you are here - you probably like https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd | 11:55 |
| mvo | ogra: we just need to convince someone from the sru team to actually approve :) | 11:56 |
| ogra | YAY !!! | 11:56 |
| mvo | mborzecki: you wanted to talk about something earlire? sorry was in a meeting and then forgot | 11:56 |
| mborzecki | mvo: yes, we need pedronis too | 11:57 |
| mvo | 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 |
| mvo | mborzecki: probably after lunch, what was the question? | 11:57 |
| mvo | and why are tests unhappy currently :( ? | 11:57 |
| mborzecki | mvo: some concerns about finding internal tools | 11:58 |
| mvo | mborzecki: ok, so - for snapd its easy, just os.dirname(os.link("/proc/self/exe")) | 11:59 |
| mvo | mborzecki: but for the "snap" binary its not | 12:00 |
| mvo | mborzecki: I think we need to lookup something (snap-exec?) there | 12:00 |
| mvo | mborzecki: maybe the answer is that the toolpath is also just relative for the snap binary "../lib/snapd" | 12:01 |
| mvo | mborzecki: am I actually speaking about the right question or am I lost in something else :) ? | 12:01 |
| mborzecki | mvo: ../lib{exec}/snapd | 12:01 |
| mborzecki | mvo: right, we were discussing the case of 'snapd' and cmd.InternalToolPath which does not work for boostrap environment | 12:02 |
| mvo | mborzecki: yeah, for snapd my suggestion is to always look into the same dir | 12:02 |
| mvo | mborzecki: and maybe (to support running from a git tree) to fallback to /usr/lib{,exec}/snapd | 12:03 |
| mvo | mborzecki: but for snap its slightly more complicated | 12:03 |
| sil2100 | mvo: hey! Let me take a look | 12:04 |
| mup | PR snapd#6599 opened: snapstate,state: add TaskSet.AddAllWithEdges() and use in doUpdate <Created by mvo5> <https://github.com/snapcore/snapd/pull/6599> | 12:05 |
| sil2100 | mvo: hm, I can review it today for -proposed and then copy it over to the PPA for testing (with a lower version) | 12:05 |
| mvo | sil2100: cool, let me know if I can help in any way (but I probably don't have the right permissions) | 12:06 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | mvo: i can try and open a PR cleaning up cmd.InternalToolPath/findSnapdPath/seccompToBpfPath to be consistent | 12:10 |
| pedronis | Chipaca: do we understand enough from dot-tobias situation to make a LP bug? | 12:12 |
| mvo | mborzecki: I think that would be good | 12:12 |
| mvo | mborzecki: maybe a separate PR? | 12:12 |
| Chipaca | pedronis: I think so yes | 12:12 |
| mborzecki | mvo: right | 12:12 |
| Chipaca | dot-tobias: could you do that? file an lp bug about this | 12:12 |
| pedronis | Chipaca: could you make one? | 12:12 |
| pedronis | or dot-tobias | 12:12 |
| Chipaca | pedronis: trying to punt it :-) | 12:12 |
| pedronis | mborzecki: yes, simplifiying would be good | 12:12 |
| pedronis | mborzecki: mvo: do we compute system key from snap ? or only from snapd? | 12:13 |
| mborzecki | pedronis: only snapd apparently | 12:13 |
| pedronis | ok | 12:13 |
| pedronis | mborzecki: no, both, snap run uses SystemKeyMismatch | 12:15 |
| pedronis | so findSnapdPath is abit more delicate | 12:15 |
| pedronis | afaict | 12:15 |
| mborzecki | pedronis: right, but only snapd build-id is used in the system key data | 12:16 |
| pedronis | mborzecki: well and snap-seccomp output in your PRs? no? | 12:16 |
| mborzecki | yes | 12:16 |
| * pstolowski lunch | 12:24 | |
| sil2100 | mvo: ok, bionic looks good, accepted for bionic-proposed | 12:25 |
| seb128 | Chipaca, where do you see those inconsistant arrows for installation? | 12:25 |
| Chipaca | heh | 12:26 |
| sil2100 | I will copy it to the PPA but please please please shepherd the bionic-proposed systemd upload | 12:26 |
| Chipaca | seb128: https://snapforum.s3.amazonaws.com/original/2X/6/6db33b0da7456be46210985f939a0e2040284e6b.jpg | 12:26 |
| seb128 | Chipaca, did you sort out your non booting image? maybe worth mentioning on #ubuntu-desktop | 12:26 |
| seb128 | if you need help figuring it out | 12:26 |
| sil2100 | 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 |
| Chipaca | seb128: it was booting, just not doing anything graphic | 12:26 |
| jdstrand | pedronis: can you advise on what to do about https://travis-ci.org/snapcore/snapd/jobs/505983378? | 12:26 |
| sil2100 | Wouldn't want this upload to be stuck in bionic forever | 12:26 |
| seb128 | Chipaca, ah, thx | 12:26 |
| Chipaca | seb128: -vga qxl fixed that | 12:26 |
| seb128 | Chipaca, ah, good | 12:27 |
| Chipaca | seb128: https://forum.snapcraft.io/t/no-more-preinstalled-snap-on-ubuntu-19-04/10339/49?u=chipaca | 12:27 |
| jdstrand | pedronis: hello btw :) | 12:27 |
| Chipaca | (just writing random stuff there as i try to repro the issue at hand) | 12:27 |
| jdstrand | pedronis: sergiusens said something about a rebase, but I thought that would confuse github | 12:28 |
| pedronis | 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 |
| seb128 | 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:28 |
| * jdstrand doesn't have 'zyga@xenial' anywhere in the tree | 12:29 | |
| Chipaca | seb128: if it didn't, then it'd have two opposite arrows :-) | 12:29 |
| seb128 | 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 |
| zyga | jdstrand: does git log do? | 12:29 |
| zyga | jdstrand: it's the history | 12:29 |
| Chipaca | seb128: yep | 12:29 |
| jdstrand | pedronis: I thought you said it could go in so long as tests came later. you want the tests now? | 12:29 |
| seb128 | Chipaca, right :) | 12:29 |
| pedronis | jdstrand: sorry, it was not about the tests | 12:29 |
| pedronis | jdstrand: please read the comment in the PR | 12:29 |
| jdstrand | zyga: 'does git log do'? can you rephrase? | 12:30 |
| pedronis | and answer there | 12:30 |
| zyga | jdstrand: run git log | grep zyga@xenial | 12:30 |
| jdstrand | pedronis: "I agree though with niemeyer comments regarding the summaries, we probably want to change those before merging." I did that | 12:30 |
| jdstrand | zyga: yes, I have that: | 12:31 |
| jdstrand | Author: zyga <zyga@xenial-server> | 12:31 |
| jdstrand | Signed-off-by: zyga <zyga@xenial-server> | 12:31 |
| zyga | the author needs to be changed | 12:31 |
| Chipaca | every time I try gnome shell i miss the keyboard-friendliness of unity :-( | 12:31 |
| === ricab is now known as ricab|lunch | ||
| * Chipaca hugs his 16.04 to his chest | 12:31 | |
| pedronis | jdstrand: this comment: https://github.com/snapcore/snapd/pull/5644#issuecomment-472723883 | 12:32 |
| mup | PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <β Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644> | 12:32 |
| pedronis | from this morning | 12:32 |
| jdstrand | zyga: uhh, everyone has to do this? | 12:32 |
| zyga | jdstrand: perhaps I misunderstand but this is in an incoming PR? | 12:32 |
| zyga | jdstrand: if so, just that needs to change | 12:32 |
| dot-tobias | 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 |
| pedronis | jdstrand: we can work on landing it on our side | 12:33 |
| Chipaca | dot-tobias: thanks! | 12:33 |
| pedronis | jdstrand: I'm still interested if what I described is a blocker or not | 12:33 |
| jdstrand | 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:36 |
| jdstrand | 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 |
| pedronis | jdstrand: what I'm worried is if somebody installs with snapd beta one of the affected snaps before the declaration is changed | 12:37 |
| jdstrand | 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 |
| pedronis | will not the install fail? | 12:38 |
| pedronis | well, not fail | 12:38 |
| pedronis | but not work until it connects things manually | 12:38 |
| pedronis | which is not expected | 12:38 |
| jdstrand | yes, that would happen | 12:39 |
| jdstrand | that is a fair point | 12:39 |
| * jdstrand doesn't understand how all of a sudden 92a096278e040b452125260b00742ae6e62caf2c from October is now causing me problems | 12:41 | |
| ackk | Saviq, hi, how can I debug what snapcraft is doing inside a multipass vm? | 12:41 |
| ackk | Saviq, I'm trying to figure out why a snapcraft build seems to hang after having launched the vm | 12:42 |
| jdstrand | zyga: ^ why am I seeing this now and why doesn't master change it so that no one else will be affected? | 12:42 |
| zyga | jdstrand: I don't understand, can you tell me where exactly are you seeing it? | 12:43 |
| jdstrand | zyga: https://travis-ci.org/snapcore/snapd/jobs/505983378 | 12:43 |
| zyga | jdstrand: I see your ping now, sorry for the interrupt | 12:43 |
| zyga | jdstrand: wow, no idea now | 12:45 |
| jdstrand | 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 |
| zyga | no idea, it's odd | 12:45 |
| jdstrand | 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:46 |
| jdstrand | Chipaca: hey, you seem to have written ./tests/lib/cla_check.py | 12:47 |
| zyga | jdstrand: sorry I was not of much help | 12:48 |
| jdstrand | 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 |
| zyga | jdstrand: perhaps do a test: rebase and open a new PR | 12:48 |
| zyga | jdstrand: if that passes it's a data point | 12:48 |
| Chipaca | jdstrand: huh | 12:48 |
| jdstrand | Chipaca: the email address that is failing is from 92a096278e040b452125260b00742ae6e62caf2c october | 12:49 |
| Chipaca | jdstrand: should be easy to fix | 12:49 |
| Chipaca | jdstrand: somehow :-| | 12:49 |
| Chipaca | jdstrand: I mean, should be easy to fix the script to catch that exception | 12:50 |
| jdstrand | 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 |
| Chipaca | jdstrand: I don't know why it's trying to verify an email already on master though | 12:50 |
| Chipaca | hmm | 12:50 |
| Chipaca | oh | 12:51 |
| zyga | this branch predates october | 12:51 |
| zyga | is that the reason? | 12:51 |
| Chipaca | jdstrand: there's been a change in travis.yaml that might be relevant | 12:51 |
| Chipaca | or was that in snapcraft | 12:51 |
| Chipaca | looks like it was just in snapcraft | 12:51 |
| jdstrand | Chipaca: at this point I'm happen to be told what to do and I'll mash buttons like a monkey :) | 12:52 |
| jdstrand | happy* | 12:52 |
| Chipaca | jdstrand: http://paste.ubuntu.com/p/QdXzftpW3b/ | 12:53 |
| Chipaca | jdstrand: that might help | 12:53 |
| jdstrand | pedronis: please advise since this is for 2.39 if I need to slog though all of them or can go at my own pace | 12:53 |
| * Chipaca β lunch | 12:54 | |
| pedronis | jdstrand: I would recommend to start | 12:54 |
| jdstrand | pedronis: well there is starting and there is slogging so the PR is unblocked. it sounds like you mean the latter | 12:55 |
| sergiusens | jdstrand: we rebase all the time in snapcraft, github is really saavy, it even mentions you rebased in the PR... the only drawback is when you amend new code from the PR (problem for the reviewer, not github), but stuff that is in master is usually fine | 12:56 |
| jdstrand | Chipaca: that shange seems unrelated to my PR and should be in a separate PR. I don't know why that is fixing things or what side effects it may have so am uncomfortable proposing it | 12:56 |
| jdstrand | sergiusens: when you say rebase, what are you saying, change the order so the merges happen before my stuff? | 12:57 |
| jdstrand | sergiusens: or are you saying change the author | 12:58 |
| jdstrand | ? | 12:58 |
| sergiusens | git rebase origin/master (it will even remove the merge commit) | 12:58 |
| pedronis | jdstrand: sorry, I would prefer not to buy a conscious regression, we already have our fair share of unconscious ones | 12:58 |
| jdstrand | pedronis: well, since it is for 2.39, I don't need to drop everything, so I'll go at whatever pace works for me and that makes it commitable for 2.39 | 12:59 |
| sergiusens | jdstrand: here's an example of a rebase https://github.com/snapcore/snapcraft/pull/2479 (search for force-pushed) | 12:59 |
| mup | PR snapcraft#2479: store: support registering to a specific store <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2479> | 13:00 |
| pedronis | jdstrand: that sounds good | 13:00 |
| pedronis | mborzecki: btw to be clear I don't thik that cleanup should block 6593 but is good to have a plan forward for that area | 13:07 |
| mborzecki | off to pick up the kids | 13:09 |
| jdstrand | sergiusens: that's fine, and I use rebase all the time. I was wondering what you were specifically suggesting since I have gotten several suggestions. I think I know what to try | 13:10 |
| dot-tobias | Chipaca / pedronis: Filed https://bugs.launchpad.net/snapd/+bug/1820060 β let me know if it's clear enough | 13:17 |
| mup | Bug #1820060: multiline strings in gadget.yaml defaults are mangled <snapd:New> <https://launchpad.net/bugs/1820060> | 13:18 |
| ackk | sergiusens, hi, I have a snapcraft build that's been stuck for ages at "Launched: <vm>", it seems nothing is happening in the VM itself, how can I debug that? | 13:19 |
| mup | PR snapd#6600 opened: timings: add new helpers, Measurer interface and DurationThreshold <Created by stolowski> <https://github.com/snapcore/snapd/pull/6600> | 13:19 |
| dot-tobias | Is there a command I can run to retry a failed change? My system init change (gadget snap) is failing and I want to retry so that I can inspect some files which are deleted as soon as it err's | 13:25 |
| jdstrand | pedronis, Chipaca, zyga, sergiusens: ok, just a simple rebase was enough to put the PRs changes on top (and after the problematic commit) and make cla check happy | 13:29 |
| zyga | woot :) | 13:35 |
| Chipaca | zyga: just seen news that A50 is blocked | 13:42 |
| Chipaca | zyga: thought you might like to hear that | 13:42 |
| kenvandine | Chipaca: well... today's iso seems fixed! | 13:43 |
| willcooke | Chipaca, using the great troubleshooting method of "maybe it will just fix itself" kenvandine and I have tested with today's ISO and everything is back to normal. | 13:43 |
| kenvandine | no idea what the hell was up with the past few days | 13:43 |
| willcooke | II'll keep testing and make sure it's reliable | 13:43 |
| willcooke | Sorry for the wild goose chase | 13:43 |
| kenvandine | i noticed the iso size is a little different | 13:43 |
| Chipaca | kenvandine: willcooke: from the description it was a race, so i'd expect it to come back in the same way | 13:43 |
| mvo | sil2100: thanks for accepting | 13:44 |
| mvo | sil2100: I will watch out for it | 13:44 |
| Chipaca | kenvandine: willcooke: I have been trying to reproduce it, and only saw it happen once in ~20 installs so far | 13:44 |
| willcooke | using todays iso? | 13:44 |
| Chipaca | kenvandine: willcooke: of course that was before i had debug logs so i leraned nothing :-( | 13:44 |
| kenvandine | Chipaca: oh... so you have reproduced it? | 13:44 |
| === ricab|lunch is now known as ricab | ||
| Chipaca | kenvandine: or something very much like it | 13:45 |
| Chipaca | willcooke: yes | 13:45 |
| willcooke | nod | 13:45 |
| Chipaca | willcooke: it _might_ have been something different, but it looked the same :-) | 13:46 |
| willcooke | :) | 13:46 |
| Chipaca | this was before I got systematic about it, after which nothing | 13:46 |
| willcooke | Heisenbug | 13:46 |
| Chipaca | do we still have the iso that _did_ have the issue? maybe i should use that one | 13:46 |
| * willcooke checks his trash | 13:47 | |
| kenvandine | so... can we increase the log verbosity in the devel images? | 13:47 |
| Chipaca | kenvandine: yes, easily | 13:47 |
| kenvandine | Chipaca: yes | 13:47 |
| willcooke | I have it | 13:47 |
| willcooke | the ISO that is | 13:47 |
| kenvandine | it's still up on cdimage | 13:47 |
| willcooke | oh, even better | 13:47 |
| kenvandine | grab 20190313 | 13:47 |
| Chipaca | kenvandine: When installing, once it prompts you to restart, before clicking restart edit /target/etc/environment and add SNAPD_DEBUG=1 | 13:48 |
| Chipaca | kenvandine: that will give you debug logs in the install | 13:48 |
| willcooke | I did that yesterday on the broken image and it didnt seem to work | 13:48 |
| Chipaca | willcooke: disco seems to rotate journal a lot more aggressively | 13:48 |
| Chipaca | willcooke: so you need to look in /var/log/syslog | 13:48 |
| willcooke | ooooooooh | 13:49 |
| willcooke | thanks | 13:49 |
| kenvandine | Chipaca: i meant in the future, during the devel cycle we should just turn up the verbosity in the images | 13:49 |
| Chipaca | (which is a pain btw) | 13:49 |
| kenvandine | maybe up until RC or something | 13:49 |
| Chipaca | kenvandine: i'd like that :-) | 13:49 |
| kenvandine | just so when things like this happen we have a means to debug it | 13:49 |
| Chipaca | <3 | 13:49 |
| kenvandine | ok, i've done 2 installs of today's image and both worked fine | 13:50 |
| kenvandine | and booted the live session 3 times | 13:50 |
| kenvandine | all good | 13:50 |
| kenvandine | :/ | 13:50 |
| Chipaca | kenvandine: did you ever get this in the live session itself? | 13:50 |
| kenvandine | yes | 13:51 |
| Chipaca | nice | 13:51 |
| Chipaca | (for negative values of nice) | 13:51 |
| Chipaca | kenvandine: dropping "[Service]\nEnvironment=SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7\n" into /etc/systemd/system/snapd.service.d/debug.conf would do that fwiw | 13:52 |
| mup | PR snapd#6601 opened: errortracker: fix panic in Report if db cannot be opened <β Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6601> | 13:53 |
| zyga | joinign | 14:01 |
| dot-tobias | Chipaca: re: Workaround for mir-kiosk config: While JSON-like syntax seems to make it through snapd, mir-kiosk's configure hook expects exactly two spaces (== yaml indentation) and fails otherwise: https://github.com/MirServer/mir-kiosk/blob/ad041e6b19205acacaf9881568061d8fd5a5742e/snap/hooks/configure#L62 | 14:05 |
| dot-tobias | Chipaca: So I'm running from one issue into the next π Will now try if creating the whole file via clout-init happens at the right time (i.e. after the snap has been installed) | 14:06 |
| Chipaca | dot-tobias: maybe that one can be fixed from mir-kiosk | 14:06 |
| dot-tobias | Chipaca: I'll open a PR there once I figure out how to check for JSON-like syntax without breaking their (surely sensible) strict grep line in the YAML case. Thanks again so far! | 14:10 |
| seb128 | kenvandine, willcooke, I would strongly recommend against thinking around the line of 'oh, we did nothing, it's fixed in today's daily, let's move on', that's going to bite us back in release week | 14:16 |
| kenvandine | seb128: i agree | 14:16 |
| mup | PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, | 14:17 |
| mup | snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601 | 14:17 |
| kenvandine | i'm trying to see what's different in the isos | 14:17 |
| seb128 | it doesn't matter, does it? | 14:17 |
| seb128 | if it's timing and something changed it's not going to tell us anything on fixing | 14:17 |
| seb128 | imho someone from the snappy team needs to do an install which has the issue and debug snapd | 14:17 |
| seb128 | anything else is a waste of effort | 14:17 |
| mup | PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, | 14:18 |
| mup | snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601 | 14:18 |
| kenvandine | seb128: you're probably right | 14:18 |
| kenvandine | Chipaca: are you trying the 20190313 iso? | 14:18 |
| Chipaca | kenvandine: y | 14:18 |
| Chipaca | kenvandine: yes | 14:18 |
| kenvandine | great | 14:18 |
| diddledan | does the desktop team have a channel I can discuss desktop non-snap issues? | 14:36 |
| mup | PR snapd#6270 closed: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6270> | 14:39 |
| mborzecki | btw. if you want to see the tests break and get weird errors like "Settle is not converging" you need to build an image with yocto | 14:45 |
| mup | PR pc-i386-gadget#8 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/8> | 15:17 |
| mup | PR pc-i386-gadget#9 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/9> | 15:17 |
| mup | PR snapd#6602 opened: [RFC] cmd, interfaces: replace local helpers with cmd.InternalToolPath() <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6602> | 15:17 |
| Chipaca | kenvandine: willcooke: walk with me please | 15:17 |
| Chipaca | kenvandine: willcooke: remember when I asked you if any of the seeded snaps were 'base: core18', and you assured me they weren't? | 15:18 |
| * willcooke puts his shoes obn | 15:18 | |
| mup | PR pc-i386-gadget#8 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/8> | 15:18 |
| mup | PR pc-i386-gadget#9 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/9> | 15:18 |
| Chipaca | kenvandine: willcooke: this is true of today's image: snap info --verbose /var/lib/snapd/seed/snaps/* shows no base: core18 | 15:18 |
| Chipaca | kenvandine: willcooke: this is, however, _not_ true of the 20190313 image | 15:18 |
| Chipaca | kenvandine: willcooke: gnome-system-monitor and gnome-calculator in yesterday's image use core18 | 15:19 |
| Chipaca | so you need to seed core18 as well, or, well, not :-) | 15:19 |
| mvo | 6401 needs a second review | 15:20 |
| kenvandine | Chipaca: oh... but the revisions of those that were on the iso did not use core18 | 15:21 |
| mup | PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, snapd#6541, | 15:21 |
| mup | snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601, snapd#6602 | 15:21 |
| kenvandine | i confirmed that, they were the old revision | 15:22 |
| mup | PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, snapd#6541, | 15:22 |
| mup | snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601, snapd#6602 | 15:22 |
| Chipaca | kenvandine: as I say, in yesterday's iso, the snaps in seed are base:core18 | 15:22 |
| Chipaca | kenvandine: 'snap info --verbose' on the file says as much | 15:23 |
| pedronis | some of them at least | 15:23 |
| Chipaca | two of 'em | 15:23 |
| pedronis | yup | 15:23 |
| Chipaca | gnome-calculator and gnome-system-monitor | 15:23 |
| kenvandine | Chipaca: what revision of gnome-calculator was it? | 15:23 |
| Chipaca | kenvandine: the file says 335 | 15:24 |
| kenvandine | that was core18 | 15:24 |
| kenvandine | sigh... | 15:24 |
| pedronis | 335 | 15:24 |
| kenvandine | i was checking those revisions... but that might have been when i was using the iso from 20190309 | 15:24 |
| kenvandine | which was the iso the original reported used | 15:24 |
| kenvandine | but... i could never reproduce this problem on that iso | 15:24 |
| kenvandine | :/ | 15:25 |
| mup | PR snapd#6603 opened: snapstate: add new NoReRefresh flag and use in Remodel() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6603> | 15:25 |
| Chipaca | kenvandine: I'll comment on the forum, see if it's just been that they downloaded a different one or something | 15:25 |
| Chipaca | kenvandine: does an iso 'know' when it was made, anywhere? | 15:26 |
| kenvandine | i think that original report for 20190309 had some other issue... | 15:26 |
| kenvandine | and started misleading us | 15:26 |
| kenvandine | probably | 15:26 |
| Chipaca | kenvandine: perhaps, although by comment #3 it looks a lot like this one | 15:26 |
| Chipaca | kenvandine: I'm going to explain what we know so far, and see if that explains the whole thing | 15:28 |
| kenvandine | Chipaca: we are going to be publishing the seeded snaps based on core18 to stable in the next couple days :) | 15:30 |
| kenvandine | so we'll need to update the seed | 15:30 |
| pedronis | kenvandine: have you tested the upgrade from old base to new base, somebody reported issues with that (changing the base of a snap over refresh), zyga can tell more | 15:31 |
| kenvandine | i actually just tested that on xenial | 15:32 |
| * cachio lunch | 15:32 | |
| kenvandine | refreshed from stable to candidate | 15:32 |
| kenvandine | candidate now has base: core18 | 15:32 |
| kenvandine | worked fine | 15:32 |
| Chipaca | kenvandine: did you have core18 before refreshing | 15:33 |
| zyga | kenvandine: there's a bug where changing bases runs the new revision on the old base | 15:33 |
| kenvandine | i probably did have the old base | 15:34 |
| kenvandine | but i can test right now | 15:34 |
| kenvandine | Chipaca zyga: started out with no core18, refreshed candidate which did pull down core18 | 15:38 |
| kenvandine | still installing :) | 15:39 |
| === chihchun is now known as chihchun_afk | ||
| kenvandine | Chipaca zyga: works fine! | 15:39 |
| kenvandine | on disco, installed from today's iso | 15:40 |
| Chipaca | GREAT SUCCESS | 15:40 |
| kenvandine | :) | 15:40 |
| Chipaca | pedronis: mvo: should I squash-merge #6598 then? | 15:42 |
| mup | PR #6598: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6598> | 15:42 |
| mvo | Chipaca: last I looked it was two commits, I can cherry pick two :) | 15:43 |
| mvo | Chipaca: so either way is fine | 15:43 |
| Chipaca | just regular merge, then | 15:43 |
| Chipaca | :-) | 15:43 |
| mup | PR snapd#6598 closed: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6598> | 15:43 |
| mvo | 6401 needs a second review | 15:51 |
| Chipaca | jdstrand: when you have a sec, could you tell me if I did something wrong wrt icdiff such that I can't install the version from candidate? | 15:56 |
| Chipaca | mvo: would it be very cheeky if I reviewed that myself? | 15:56 |
| mvo | Chipaca: its fine, I can review your bits | 15:57 |
| Chipaca | mvo: ok, i +1'ed your bits :-p | 15:57 |
| mvo | Chipaca: thank you! | 16:07 |
| mvo | Chipaca: I did the same | 16:08 |
| Chipaca | mvo: also i restarted spread because it hates you | 16:08 |
| * mvo nods | 16:08 | |
| mvo | I wonder if I need to merge master | 16:08 |
| mvo | or if it just hates me regardless | 16:08 |
| pedronis | mvo: Chipaca: seems we have forgotten about ForSnapSetup (noticed when looking at the NoReRefresh PR) | 16:12 |
| Chipaca | pedronis: ? | 16:12 |
| Chipaca | pedronis: in what sense? | 16:12 |
| mvo | what is ForSnapSetup? | 16:13 |
| pedronis | Chipaca: we have added flags that are not used in handlers, and we are not clearing them | 16:13 |
| pedronis | in it | 16:13 |
| Chipaca | mvo: a method on flags that drops things in flags that are for snapstate and not snapsetup | 16:13 |
| Chipaca | pedronis: ah, in that sense | 16:13 |
| Chipaca | pedronis: maybe we should turn it around | 16:13 |
| Chipaca | pedronis: less likely to forget to add things to it that are needed | 16:14 |
| pedronis | Chipaca: maybe | 16:14 |
| pedronis | Chipaca: mvo: anyway afaict only Amend has this problem | 16:14 |
| pedronis | but the new flag would as well | 16:14 |
| pedronis | (not deep consequences just a bit more unused data in the state) | 16:15 |
| * mvo nods | 16:15 | |
| pstolowski | mvo, cachio can https://github.com/snapcore/snapd/pull/6553 land? | 16:17 |
| mup | PR #6553: tests: enable opensuse tumbleweed back <Created by stolowski> <https://github.com/snapcore/snapd/pull/6553> | 16:17 |
| cachio | pstolowski, checking | 16:28 |
| cachio | pstolowski, done | 16:30 |
| cachio | pstolowski, thanks!! | 16:30 |
| mup | PR snapd#6553 closed: tests: enable opensuse tumbleweed back <Created by stolowski> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6553> | 16:31 |
| cachio | mvo, ./run-checks --static | 16:38 |
| jdstrand | pedronis: there is something not right with icdiff. I thought I got the declaration right: https://paste.ubuntu.com/p/sBYQd2PWCB/ based on your comment in https://bugs.launchpad.net/snapstore/+bug/1814592/comments/6 | 16:41 |
| mup | Bug #1814592: cannot compile personal-files/system-files snap declaration constraints <Snap Store:Invalid> <https://launchpad.net/bugs/1814592> | 16:42 |
| pedronis | jdstrand: no, you really need to squash them into one regexp with | | 16:43 |
| pedronis | jdstrand: otherwise one of the two entries will fail | 16:43 |
| pedronis | for one of the side of your ORed plug-attributes | 16:44 |
| pedronis | jdstrand: I said as much: For the multiple entries in read/write so you need to use a regexp with | and quoting/() as needed | 16:44 |
| jdstrand | pedronis: well, that is what I thought until I read your "For the multiple entries in read/write so you need to use a regexp with | and quoting/() as needed." comment | 16:44 |
| jdstrand | what did you mean by multiple entries there? | 16:45 |
| jdstrand | for say, different snap ids? | 16:45 |
| pedronis | jdstrand: the multiple entries in the attribute in the snap.yam plug | 16:45 |
| pedronis | the rule matches for a list if each entry in the list matches the regexp | 16:45 |
| pedronis | for a list in the attribute in the plug/slot | 16:46 |
| jdstrand | you mean that read and write need the | cause they are different | 16:46 |
| pedronis | jdstrand: there's no write here? | 16:46 |
| jdstrand | no | 16:46 |
| jdstrand | but I'm trying to parse "the multiple entries in the attribute in the snap.yam plug" | 16:47 |
| pedronis | I mean you need "read": "\\$HOME/\\.gitconfig|\\$HOME/\\.config/git/config" in the rule | 16:47 |
| jdstrand | I get the bit about all the entries in the list need to match the regex | 16:47 |
| jdstrand | pedronis: sure, I get that. I need to fix that | 16:47 |
| pedronis | jdstrand: ok | 16:48 |
| jdstrand | pedronis: but I want to understand when I am supposed to use | | 16:48 |
| jdstrand | oh duh | 16:48 |
| jdstrand | I got a wire crossed. this whole time I was interpreting '|' as a shorthand for alternate constraints. jeez | 16:49 |
| pedronis | np | 16:49 |
| jdstrand | you meant in the regex of course | 16:49 |
| pedronis | yes | 16:49 |
| * jdstrand shakes head | 16:49 | |
| pedronis | and the entries refered to the entries in the list value of the plug attribute | 16:50 |
| pedronis | not rule side entries | 16:50 |
| jdstrand | yes | 16:50 |
| cachio | mvo | 16:50 |
| jdstrand | Chipaca: ok, it installs and it should continue to pass automated review | 16:56 |
| jdstrand | pedronis: thank you again. I need to make a small tweak for the alternate constraints bit in the review-tools cause of my misinterpretation of the LP comment, but that's fine | 16:57 |
| * jdstrand continues to shake head | 16:57 | |
| jdstrand | it shouldn't be this hard :) | 16:57 |
| Chipaca | jdstrand: huh, it installs here too, now | 17:01 |
| Chipaca | i wonder what i'd broken before | 17:01 |
| Chipaca | jdstrand: anyway i'm blaming you for it working: thanks! | 17:02 |
| sil2100 | mvo: hey! So apparently I don't have the permissions to push to the snapcore/pi-gadget branch still | 17:03 |
| sil2100 | mvo: can you add foundations to it? | 17:03 |
| sil2100 | mvo: since I'm in the middle of changing the branch ownership back from CanonicalLtd to snapcore | 17:04 |
| mvo | sil2100: let me try | 17:05 |
| mvo | sil2100: I think I added you now, please check | 17:06 |
| jdstrand | Chipaca: what broke was it had the wrond snap decl (see conversation with pedro nis ^) | 17:06 |
| * Chipaca reads up | 17:06 | |
| jdstrand | Chipaca: well, you should blame me for it not working and then fixing it with pedro nis help | 17:06 |
| Chipaca | jdstrand: tomahto/tomeito | 17:08 |
| Chipaca | it works now \o/ | 17:08 |
| Chipaca | now i need to figure out why it doesn't build on ppc64el | 17:08 |
| Chipaca | :-P | 17:08 |
| jdstrand | Chipaca: heh, well, it is hard for me to accept the gratitue since this is like the 3rd time I got this bit wrong. 4th times the charm? | 17:09 |
| jdstrand | pedronis may have a higher tally. we will be there today, finally! :) | 17:09 |
| sil2100 | mvo: yay, works! Thanks! Did you add the foundations group (or whatever that is) or just me? | 17:10 |
| sil2100 | Since I guess the more the merrier :) | 17:10 |
| sil2100 | mvo: hm, I still don't seem to have full github powers on the branch like on the others | 17:11 |
| sil2100 | (like settings etc.) | 17:12 |
| mvo | sil2100: the foundations group | 17:13 |
| mvo | sil2100: aha, let me see | 17:13 |
| sil2100 | (git push worked though) | 17:13 |
| mvo | sil2100: try now | 17:13 |
| mvo | sil2100: this failure on trusty is mysterious, even the LP generated debdiff shows no packaging changes | 17:14 |
| sil2100 | mvo: works now, thanks! | 17:17 |
| sil2100 | hmmm | 17:17 |
| sil2100 | mvo: let me take a look at trusty as well | 17:17 |
| * sil2100 checks his trusty schroot | 17:21 | |
| sil2100 | oh, components mismatch maybe? However, this built fine before | 17:22 |
| sil2100 | mvo: so golang-1.6 is in universe while snapd is in main, but the previous version didn't have a problem with that | 17:23 |
| Chipaca | sil2100: snapd uses -1.10 | 17:24 |
| mvo | Chipaca: that 2.38 | 17:24 |
| Chipaca | ah | 17:24 |
| Chipaca | oh | 17:24 |
| Chipaca | uh | 17:24 |
| Chipaca | eh | 17:24 |
| mvo | Chipaca: in 2.37.4 we should still be fine .) | 17:24 |
| mvo | sil2100: yeah, what can we do? demote snapd to universe? | 17:24 |
| mup | PR pc-amd64-gadget#12 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-amd64-gadget/pull/12> | 17:27 |
| mup | PR pc-amd64-gadget#13 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-amd64-gadget/pull/13> | 17:27 |
| mvo | sil2100: I need to run for lunch | 17:28 |
| * zyga waves from school meeting | 17:28 | |
| mup | PR pc-i386-gadget#8 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-i386-gadget/pull/8> | 17:30 |
| mup | PR pc-i386-gadget#9 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-i386-gadget/pull/9> | 17:30 |
| sil2100 | mvo: can we actually demote snapd to universe? | 17:32 |
| sil2100 | mvo: anyway, first I'd like someone else confirm that's the problem, let me poke someone | 17:32 |
| sil2100 | vorlon: maybe you have an idea? Is this the problem? ^ | 17:32 |
| sil2100 | vorlon: context: snapd in trusty doesn't build at all, dep-waits on packages even though no new dependencies have been added | 17:33 |
| sil2100 | vorlon: I was suspecting a component-mismatch here as golang-1.6 is in universe in trusty, but it was building fine in the past | 17:34 |
| * sil2100 AFK for a bit | 17:34 | |
| Chipaca | pedronis: I marked #1819427 as invalid, and also marked the forum topic as solved | 18:03 |
| mup | Bug #1819427: Disco daily install doens't include the snaps <ubiquity (Ubuntu):Invalid by chipaca> <ubiquity (Ubuntu Disco):Invalid by chipaca> <https://launchpad.net/bugs/1819427> | 18:03 |
| pedronis | thx | 18:03 |
| vorlon | sil2100: demote snapd to universe> ... no? | 18:07 |
| cachio | niemeyer, hey, I have created a small PR on spread https://github.com/snapcore/spread/pull/74 to enable travis | 18:15 |
| mup | PR spread#74: Add .travis.yaml file <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/74> | 18:16 |
| cachio | it is the initial step | 18:16 |
| cachio | niemeyer, could you please take a look | 18:16 |
| cachio | ? | 18:16 |
| niemeyer | cachio: That doesn't look very useful :) | 18:18 |
| cachio | niemeyer, I know, it is just to have a .tavis.yaml file | 18:18 |
| niemeyer | cachio: Right, that's what I'm talking about | 18:19 |
| cachio | I already have a set of changes to run the tests | 18:19 |
| kenvandine | zyga: i'm having a layouts problem | 18:19 |
| cachio | niemeyer, but I need to start running the builds on travis | 18:19 |
| niemeyer | cachio: Sorry, I really don't get it | 18:19 |
| kenvandine | zyga: specifically refreshing from a snap without the layout to a snap using layouts | 18:19 |
| kenvandine | https://paste.ubuntu.com/p/fVp6Tjd5vb/ | 18:19 |
| niemeyer | cachio: Running "echo" on Travis is not very useful | 18:19 |
| niemeyer | cachio: What am I missing? | 18:20 |
| kenvandine | zyga: it seems to only happen if i run the non-layouts revision first | 18:20 |
| cachio | niemeyer, I need a way to see in github the execution of the change | 18:20 |
| cachio | niemeyer, currently it is not running nothing | 18:20 |
| niemeyer | cachio: I consider not running nothing a good thing | 18:21 |
| cachio | niemeyer, I already created a change #73 on spread and it didnt trigger the tests | 18:21 |
| mup | PR #73: fix a bug in lightweights that set the wrong type for frameworks found by AllPartBags that were lexicographically greater than the oem part <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/73> | 18:21 |
| cachio | niemeyer, https://github.com/snapcore/spread/pull/73/files | 18:21 |
| mup | PR spread#73: Run tests on travis <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/73> | 18:22 |
| cachio | niemeyer, how should I do to start running on travis? | 18:22 |
| cachio | do you need to configure that? | 18:22 |
| niemeyer | cachio: Michael's point in that PR is that your change is huge | 18:23 |
| cachio | or I could add the unit tests execution as part of the change https://github.com/snapcore/spread/pull/74 if you think it is good idea | 18:23 |
| mup | PR spread#74: Add .travis.yaml file <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/74> | 18:23 |
| niemeyer | cachio: We don't want to review that | 18:23 |
| niemeyer | cachio: Instead, the PR should introduce testing with less boilerplate | 18:23 |
| niemeyer | cachio: We already have tests in spread | 18:23 |
| niemeyer | cachio: Running those in Travis would be nice, and hopefully not as complex | 18:24 |
| niemeyer | cachio: What's the minimum we can do for that? | 18:24 |
| cachio | niemeyer, ok, I can make a PR to run unit tests | 18:25 |
| cachio | then another to run spread tests | 18:25 |
| niemeyer | cachio: We already have tests in there | 18:25 |
| niemeyer | cachio: And they are not unittests | 18:25 |
| niemeyer | cachio: They are functional tests | 18:25 |
| kenvandine | zyga: i've reproduced that with both stable and edge channels of the core snap | 18:26 |
| cachio | niemeyer, I know, in that case the PR should include to run the spread tests | 18:26 |
| cachio | niemeyer, just that | 18:26 |
| cachio | niemeyer, does it make sense? | 18:26 |
| niemeyer | cachio: Yeah, even just one of those would be enough of a PR | 18:27 |
| cachio | niemeyer, great | 18:27 |
| cachio | I'll make that | 18:27 |
| niemeyer | Thanks! | 18:27 |
| cachio | yaw | 18:27 |
| cachio | niemeyer, we are going to need a new key to run the tests on google for the travis spread project | 18:32 |
| niemeyer | cachio: That's okay.. perhaps first get it working for you, which should work with your key, and once that's happy we can setup something more permanent | 18:33 |
| cachio | niemeyer, I already have that working | 18:35 |
| cachio | because I did it as part of the PR 73 | 18:35 |
| mup | PR #73: fix a bug in lightweights that set the wrong type for frameworks found by AllPartBags that were lexicographically greater than the oem part <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/73> | 18:35 |
| cachio | I need just to get that part and create a new PR | 18:36 |
| niemeyer | cachio: Okay, so submit that alone so we can integrate first, and then submit the PR that enables that to run on Travis | 18:36 |
| niemeyer | cachio: and by "that alone" I mean just the changes necessary to make spread tests run on GCE | 18:36 |
| niemeyer | cachio: So anyone can fire those in their own environment | 18:36 |
| cachio | niemeyer, great, thanks | 18:36 |
| cachio | sure | 18:37 |
| mup | PR snapcraft#2479 closed: store: support registering to a specific store <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2479> | 18:46 |
| zyga | kenvandine: reproduced which issue sir? The one about base snap? | 19:00 |
| kenvandine | no | 19:00 |
| kenvandine | the layouts issue | 19:00 |
| kenvandine | zyga: https://paste.ubuntu.com/p/fVp6Tjd5vb/ | 19:01 |
| kenvandine | gnome-characters in stable doesn't use layouts and in candidate it does | 19:01 |
| kenvandine | if i run gnome-characters from stable once | 19:01 |
| zyga | Let me look | 19:01 |
| kenvandine | then refresh candidate | 19:01 |
| kenvandine | it blows up on refresh | 19:01 |
| kenvandine | but it doesn't blow up if i never run it | 19:02 |
| zyga | Ahhh | 19:02 |
| zyga | Can you report that please | 19:02 |
| kenvandine | all the steps to reproduce it is in the pastebin :) | 19:02 |
| kenvandine | sure | 19:02 |
| zyga | And assign it to me | 19:02 |
| zyga | I will otherwise not track it very well | 19:02 |
| zyga | Thank you | 19:02 |
| zyga | I think I know why | 19:02 |
| kenvandine | zyga: what's your LP id? | 19:09 |
| kenvandine | LP search is failing me :) | 19:10 |
| roadmr | kenvandine: https://launchpad.net/~zyga ? | 19:12 |
| cachio | niemeyer, PR ready https://github.com/snapcore/spread/pull/75 | 19:12 |
| mup | PR spread#75: Make spread tests run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75> | 19:12 |
| kenvandine | No items matched "zyga". | 19:12 |
| kenvandine | but you are right | 19:12 |
| kenvandine | i can't assign a bug to that though | 19:12 |
| kenvandine | zyga: bug 1820109 | 19:13 |
| mup | Bug #1820109: refresh fails with layouts <snapd:New> <https://launchpad.net/bugs/1820109> | 19:13 |
| kenvandine | zyga: it won't let me assign it to you | 19:13 |
| roadmr | hn the snapd project must have funky bug assignment policies | 19:15 |
| kenvandine | yeah | 19:15 |
| kenvandine | zyga: i'd mark it as critical if i was allowed... we need to update all the seeded snaps to core18 based so we can seed the new content package at the same time we unseed the old one | 19:16 |
| kenvandine | so this is going to block that :/ | 19:16 |
| roadmr | kenvandine: apparently it only allows assigning bugs to teams, not specific people | 19:16 |
| kenvandine | i see other bugs assigned to individuals though | 19:16 |
| roadmr | kenvandine: it won't let me select individuals (even me), but see at the top of the assignment window, it says "select a team of which you're a member" or somesuch | 19:18 |
| kenvandine | yeah | 19:18 |
| kenvandine | saw that | 19:18 |
| kenvandine | so i can't even assign it to the snappy team :/ | 19:18 |
| roadmr | :( | 19:19 |
| mup | PR snapd#6401 closed: many: add /v2/model API, `snap remodel` CLI and spread test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6401> | 20:05 |
| pedronis | kenvandine: I assigned, I don't know if it has a quick/non risky fix, we'll need to see what zyga says | 20:06 |
| mup | PR snapcraft#2502 opened: meta: fix management of snap/local <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2502> | 20:08 |
| ogra | hmm, ouch ... core18 misses snapfuse ... so you cant run lxd on top of Ubuntu Core 18 images | 20:13 |
| ogra | (well, you can, but not install snaps in the container) | 20:14 |
| ogra | stgraber, pedronis ^^^ is that known ? | 20:14 |
| jdstrand | roadmr: hi! can you add a pull of r1208 to your queue? | 20:49 |
| jdstrand | roadmr: it isn't urgent | 20:49 |
| roadmr | jdstrand: pullity pull coming right up | 20:50 |
| jdstrand | thank you :) | 20:50 |
| roadmr | jdstrand: yep, I don't think we can deploy that before next week but it'll get queued | 20:50 |
| jdstrand | pedronis: fyi, that ^ has the small fix I referred to | 20:50 |
| Saviq | ackk: hey, sorry for the very late reply... I saw your ping but missed which channel it was on... | 21:21 |
| Saviq | ackk: that would be https://github.com/CanonicalLtd/multipass/issues/678 - it's fixed now in our master, but we've another issue we're fighting with on edge (https://github.com/CanonicalLtd/multipass/issues/677) so it's best to stick with --beta for a bit | 21:22 |
| stgraber | go get github.com/snapcore/snapd/i18n/xgettext-go: unzip /lxc-ci/build/tmp.GQSoN0Ki3g/go/pkg/mod/cache/download/github.com/snapcore/snapd/@v/v0.0.0-20190314200526-9cca2d5a116a.zip: malformed file path "cmd/snap-confine/spread-tests/distros/debian.": trailing dot in path element | 21:23 |
| stgraber | ^ that's go tip failing to "go get" the snapd repo due to something funky going on with unzip | 21:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
