| teej | How does Snappy differ from Flatpak? | 02:08 |
|---|---|---|
| mup | PR snapd#4134 closed: interfaces/uhid: unconditionally add existing uhid device to the device cgroup (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4134> | 05:46 |
| mup | PR snapd#4137 closed: cmd/snap-update-ns: fix mount rules for font sharing (2.29) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4137> | 05:46 |
| mup | PR snapd#4127 closed: interfaces/uhid: unconditionally add existing uhid device to the device cgroup <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4127> | 05:47 |
| mup | PR snapd#4132 closed: interfaces/serial-port: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4132> | 05:47 |
| mup | PR snapd#4133 closed: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4133> | 05:47 |
| mup | PR snapd#4116 closed: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4116> | 05:48 |
| mup | PR snapd#4114 closed: interfaces: don't udev tag devmode or classic snaps <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4114> | 05:49 |
| mup | PR snapd#4123 closed: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4123> | 05:50 |
| mborzecki | morning | 06:07 |
| mvo | hey mborzecki, good morning | 06:25 |
| mup | PR snapd#4064 closed: tests: new test for hardware-random-control interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4064> | 06:41 |
| zyga-solus | hey | 06:43 |
| zyga-solus | mvo: goodmorning | 06:43 |
| zyga-solus | mvo: man, you're up early | 06:43 |
| zyga-solus | mvo: btw, about tests being slow: http://autopkgtest.ubuntu.com/running | 06:44 |
| mvo | zyga-solus: yeah, well, travis is the main issue | 06:45 |
| mborzecki | zyga-solus: morning | 06:51 |
| zyga-solus | hey mborzecki | 06:51 |
| mborzecki | is there a checker in gocheck lib that can verify if something is in a list? something similar to this: https://godoc.org/github.com/stretchr/testify/assert#Assertions.Contains | 06:52 |
| mborzecki | (disclaimer, i've quite heavily used testify/assert and testify/mock packages before) | 06:53 |
| zyga-solus | mborzecki: I wrote one | 06:54 |
| zyga-solus | mborzecki: in testutils/ | 06:54 |
| mborzecki | thx | 06:54 |
| zyga-solus | mborzecki: ironically this was one of my first patches to snapd :D | 06:55 |
| zyga-solus | and my first go code | 06:55 |
| zyga-solus | "where is contains in this language" | 06:55 |
| mborzecki | zyga-solus: you mentioned that account-control is feeding bad information on arch | 06:56 |
| mborzecki | i'm fixing this right now (or at least that's what i think i'm doing) | 06:57 |
| mup | PR snapd#4115 closed: interfaces/serial-port: udev tag plugged slots that have just 'path' via KERNEL <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4115> | 06:59 |
| zyga-solus | mborzecki: excellent, thank you! | 07:00 |
| mvo | zyga-solus: 4136 is failing for real it seems | 07:00 |
| mvo | zyga-solus: the /run/snapd/ns/snapd.test-snapd-desktop.fstab just contains fontconfig three times ?! | 07:01 |
| zyga-solus | looking | 07:02 |
| zyga-solus | I wrote that one "dry", without running it | 07:02 |
| zyga-solus | autopkgtest.ubuntu.com is very slow for me | 07:03 |
| mvo | zyga-solus: this is available in travis (which is also slow) and I have a local shell in qemu open right now, but it looks strange, almost as if we just mount systemfontconfigcachedir three times instead of systemfontsdir, systemlocalfontsdir | 07:04 |
| mvo | zyga-solus: aha, no, the fstab file is correct in /var/lib/snapd/mount | 07:05 |
| zyga-solus | mvo: can you paste both fstab files please | 07:06 |
| zyga-solus | the one in /var/lib/snapd/mount/ and in /run/snapd/ns | 07:06 |
| zyga-solus | I'll try localy but it will take some time | 07:06 |
| mvo | zyga-solus: http://paste.ubuntu.com/25877947/ | 07:07 |
| zyga-solus | ha | 07:07 |
| zyga-solus | that's very werid | 07:07 |
| zyga-solus | thanks, I'll dig | 07:07 |
| zyga-solus | mvo: if you still have the shell | 07:08 |
| zyga-solus | before I get there | 07:08 |
| zyga-solus | can you please nsenter and look at mountinfo | 07:08 |
| mvo | zyga-solus: http://paste.ubuntu.com/25877952/ | 07:09 |
| zyga-solus | thank you | 07:09 |
| zyga-solus | mounts doesn't show the source correctly | 07:10 |
| zyga-solus | I'll run locally and debug, no worries | 07:10 |
| mvo | zyga-solus: mountinfo looks correct, no? so its just the outside that looks fishy? | 07:10 |
| mborzecki | do you amend/fixup/rebase/reshuffle commits in a PR or just add new ones on top? | 07:10 |
| zyga-solus | no, mounts doesn't show this at all | 07:10 |
| zyga-solus | mborzecki: we usually add and squash | 07:11 |
| zyga-solus | (when merging) | 07:11 |
| mborzecki | working around github's mess? :) | 07:11 |
| zyga-solus | mborzecki: optimizing for review flow | 07:11 |
| zyga-solus | mvo: if you hold the release for 30 minutes until we get a better picture I can help analyze this | 07:12 |
| mup | PR snapd#4138 opened: release: 2.29.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4138> | 07:14 |
| mvo | zyga-solus: too late for 2.29.1, if its something grave we need a 2.29.2 | 07:14 |
| zyga-solus | k | 07:14 |
| mvo | zyga-solus: inside the ns I have /usr/share/fonts from the outside afaict ? | 07:15 |
| zyga-solus | mvo: yes, | 07:15 |
| mvo | zyga-solus: so what is missing :) ? | 07:16 |
| zyga-solus | mvo: but please tail mountinfo (not mounts) | 07:16 |
| zyga-solus | mvo: because the earlier pastebin was inconclusive | 07:16 |
| zyga-solus | (mounts doesn't show the relevant stuff) | 07:16 |
| zyga-solus | I worry about why that thing was listed three times, that's very fishy | 07:16 |
| mvo | zyga-solus: http://paste.ubuntu.com/25877985/ | 07:17 |
| zyga-solus | this is correct | 07:17 |
| zyga-solus | so | 07:17 |
| zyga-solus | if this is correct, why was the other file wrong :D ? | 07:17 |
| zyga-solus | did you just ran the test? | 07:18 |
| zyga-solus | or experiment in some other way? | 07:18 |
| mvo | zyga-solus: I did nothing to the system, just ran the spread test in qemu. the output looks consistent with what linode outputs | 07:18 |
| mborzecki | i probably don't know what i'm doing, but I've updated https://github.com/snapcore/snapd/pull/4135 | 07:18 |
| mup | PR #4135: Workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135> | 07:18 |
| zyga-solus | thank you, I'll look now | 07:19 |
| zyga-solus | mborzecki: that looks very good to me | 07:21 |
| mborzecki | btw. has anyne seen something like https://paste.ubuntu.com/25878010/ ? | 07:23 |
| mborzecki | snapSeccompSuite.TestRestrictionsWorkingArgsUidGid failing with 'setuid u:daemon' | 07:24 |
| zyga-solus | mvo: reproduced now | 07:25 |
| mvo | mborzecki: not this particular error, this is the seccomp confinement test, it runs on the real (running) kernel | 07:25 |
| zyga-solus | mborzecki: hmmm | 07:25 |
| zyga-solus | mborzecki: just checking, you do have an user called daemon on your system, right? | 07:25 |
| mvo | mborzecki: I assume this is the arch kernel? | 07:25 |
| mborzecki | suprisingly, i did not see this yday, then ran pacman -Syu in the evening, and rebooted to a new kernel today :) | 07:25 |
| mborzecki | mvo: yes, it's an arch kernel | 07:26 |
| mvo | mborzecki: what version is that? | 07:26 |
| mborzecki | 4.13.10-1-ARCH | 07:26 |
| zyga-solus | it's curious btw, it seccomp is so well established that this should not fail | 07:26 |
| mvo | mborzecki, zyga-solus maybe its argument filtering and something with daemon is different on arch? | 07:27 |
| mborzecki | i'll poke around | 07:27 |
| zyga-solus | mvo: perhaps | 07:27 |
| mvo | mborzecki: whats the uid of your daemon user? | 07:29 |
| mborzecki | daemon:x:2:2:daemon:/:/usr/bin/nologin | 07:29 |
| mvo | mborzecki: there you go :/ the test assumes "1" | 07:29 |
| mvo | mborzecki: {"setuid u:daemon", "setuid;native;1", main.SeccompRetAllow}, | 07:29 |
| mvo | mborzecki: i.e. it sends the setuid (native arch) syscall with arg 1 which does not work on arch. silly test ! | 07:30 |
| mborzecki | heh, i can fix that | 07:30 |
| mvo | mborzecki: thanks | 07:30 |
| mborzecki | btw. uid 1 is 'bin', interesting | 07:31 |
| zyga-solus | mborzecki: it's all broken | 07:31 |
| zyga-solus | distros don't agree on any uid other than root | 07:32 |
| mborzecki | trying to remember what it was in yocto | 07:32 |
| zyga-ubuntu | mvo: http://pastebin.ubuntu.com/25878071/ | 07:41 |
| zyga-ubuntu | this is the failure | 07:41 |
| zyga-ubuntu | something is clearly wrong | 07:42 |
| zyga-ubuntu | man :/ | 07:42 |
| zyga-solus | mvo: I _think_ I know | 07:43 |
| mvo | zyga-solus: what are the implications of this bug? | 07:43 |
| zyga-solus | bad stuff is in the current profile | 07:43 |
| zyga-solus | but namespace is correct | 07:43 |
| zyga-solus | it shows up when > 1 entry is present | 07:43 |
| zyga-solus | but I'm a bit DOH | 07:43 |
| mvo | zyga-solus: what is the implication of bad stuff in the current profile? | 07:44 |
| zyga-solus | golang feature | 07:44 |
| zyga-solus | mvo: we'll undo stuff that's not done | 07:44 |
| zyga-solus | mvo: it will all fall apart as we try to "mend" it | 07:44 |
| mvo | zyga-solus: when do we do that? on refresh? | 07:44 |
| zyga-solus | when we setup security | 07:44 |
| mvo | zyga-solus: so things will explode when snapd is restarted? | 07:45 |
| zyga-solus | not really explode | 07:45 |
| zyga-solus | it will not return a failure code | 07:45 |
| zyga-solus | mvo: testing a small fix | 07:47 |
| mvo | zyga-solus: hm, maybe I need to ask differently. this freeze/thaw is something new added, its not in 2.29 iirc. so does this affect 2.29 and if so what are the implications for the users, i.e. is it just internal or are there visialbe regressions? | 07:47 |
| zyga-solus | mvo: unless I'm mistaken golang does something I didn't expect | 07:47 |
| mvo | zyga-solus: looking forward to see the diff :) | 07:48 |
| zyga-solus | mvo: this should not affect freeze/thaw | 07:48 |
| mvo | zyga-solus: so this affects 2.29? | 07:48 |
| zyga-solus | mvo: taking the address of a variable on iteration seems to return the same thing over and over | 07:48 |
| zyga-solus | mvo: as if this was a loop local temporary | 07:48 |
| zyga-solus | mvo: so :/ | 07:48 |
| zyga-solus | mvo: it's scaryt | 07:49 |
| zyga-solus | we had this since forever | 07:49 |
| mvo | zyga-solus: could you paste the diff? just so that I can get an idea | 07:49 |
| zyga-solus | yes | 07:49 |
| mvo | zyga-solus: thanks | 07:49 |
| zyga-ubuntu | http://paste.ubuntu.com/25878114/ | 07:50 |
| zyga-ubuntu | where else are we doing something like this? | 07:50 |
| mborzecki | zyga-solus: can you point me to the code with this iteration? | 07:50 |
| zyga-ubuntu | why doesn't golang warn / error on this | 07:50 |
| zyga-ubuntu | mborzecki: please look at main.go in cmd/snap-update-ns | 07:50 |
| zyga-ubuntu | changesMade = append(changesMade, change) | 07:51 |
| zyga-ubuntu | a variant of this line | 07:51 |
| zyga-ubuntu | near line 164 | 07:51 |
| zyga-ubuntu | (I applied a helper patch so there may be an offset) | 07:51 |
| mvo | zyga-ubuntu: if we had this forever and nothing bad happens, is it critical for 2.29.1? | 07:52 |
| zyga-solus | mvo: nobody noticed / tested >1 mount entry | 07:52 |
| zyga-solus | mvo: I think .2 is in order now that we know really | 07:52 |
| mborzecki | zyga-solus: it's always taking the same &change? | 07:52 |
| zyga-solus | mvo: especially since this will really mess up all the desktop interface snaps over time | 07:52 |
| zyga-solus | yes | 07:53 |
| zyga-solus | mborzecki: that's what it looks like | 07:53 |
| zyga-solus | testing a fix now | 07:53 |
| mvo | zyga-solus: well, maybe. I want to understand what happens if we don't fix it | 07:53 |
| zyga-solus | mvo: I can tell you in 20 minutes after another test where I undo this | 07:53 |
| mborzecki | can you drop _, change := range ... and use for i := range changesNeeded ... { change := changesNeeded[i] .. } ? | 07:53 |
| zyga-solus | mvo: ok, with the patch it works | 07:53 |
| zyga-solus | mborzecki: right, I understand that now, I just found it unexpected | 07:54 |
| mborzecki | hit this myself a couple of times, enough to make me doubt range | 07:54 |
| mborzecki | typical scenarios is the code inside is calling goroutines or doing syscalls (which are rescheduling points) | 07:56 |
| zyga-solus | mvo: patch pushed | 07:57 |
| mvo | zyga-solus: I think I would slightly prefer the minmal diff that mborzecki suggests (using an for i := ... loop). anyway, sorry for being difficult | 07:57 |
| zyga-solus | mvo: no, please look at the patch | 07:57 |
| zyga-solus | mvo: the patch is minimal and simpler semantically | 07:58 |
| mvo | zyga-solus: just trying to understand the implications of this | 07:58 |
| mvo | zyga-solus: ok, checking | 07:58 |
| zyga-solus | mvo: 14 lines changed | 07:58 |
| zyga-solus | one character each | 07:58 |
| mborzecki | lgtm | 07:59 |
| zyga-solus | and thank $DIETY for spread tests! | 07:59 |
| mborzecki | pushed another patch to https://github.com/snapcore/snapd/pull/4135 cmd/snap-seccomp tests are all passing now | 08:01 |
| mup | PR #4135: Workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135> | 08:01 |
| zyga-solus | mvo: will you take that patch? | 08:04 |
| mvo | zyga-solus: tbh, I'm still on the fence, if its not a regression and it has not yet caused problems yet I'm not sure. but lets prepare a 2.29 PR so that we have it | 08:08 |
| zyga-solus | mvo: ok | 08:09 |
| zyga-solus | mvo: if you can take it I'd suggest so | 08:09 |
| zyga-solus | mvo: it's a clear bug | 08:09 |
| zyga-solus | mvo: and the more we use content interface the more harm it will cause | 08:09 |
| zyga-solus | mvo: I'll make a 2.29 PR for you | 08:09 |
| mvo | zyga-solus: thank you | 08:10 |
| zyga-solus | done, 4139 | 08:11 |
| mup | PR snapd#4139 opened: cmd/snap-update-ns: fix collection of changes made <Created by zyga> <https://github.com/snapcore/snapd/pull/4139> | 08:11 |
| mvo | zyga-solus: thank you | 08:21 |
| mborzecki | FYI 'nogroup' is replaced with 'nobody' in arch | 08:35 |
| zyga-solus | mborzecki: yeah, I'm afraid some of those tests will look like Swiss cheese | 08:35 |
| mborzecki | zyga-solus: is 'nogroup' used in other placed in the code? | 08:36 |
| zyga-solus | mborzecki: I don't think so, we only used it for tests | 08:37 |
| zyga-solus | (AFAIK I made that change) | 08:37 |
| zyga-solus | mborzecki: to work around other things that weren't common between ubuntu and solus | 08:37 |
| mborzecki | good, this is the last unit test that fails here | 08:37 |
| mborzecki | btw. is there a not-empty checker? | 08:37 |
| zyga-solus | HasLen, 0 is useful | 08:38 |
| kalikiana | good morning, snappy | 08:38 |
| mvo | mborzecki: depends on what you need, there is "HasLen" | 08:38 |
| zyga-solus | hey kalikiana :) | 08:38 |
| mborzecki | Not(HasLen), 0 ? | 08:38 |
| mup | PR snapd#4140 opened: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140> | 08:39 |
| zyga-solus | mborzecki: yes | 08:44 |
| zyga-solus | mborzecki: note that we can add IsEmpty or similar | 08:45 |
| zyga-solus | mborzecki: it's not hard to add a new checker | 08:45 |
| zyga-solus | mborzecki: and especially when the error messages are nicer, this could be useful | 08:45 |
| pedronis | pstolowski: hi, looking at #4108 again, do we need Hooks/Apps on ConnectedSlot ? you didn't implement Hooks | 08:56 |
| mup | PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108> | 08:56 |
| pstolowski | pedronis, hi, we don't have Hooks on slots, per comment and implementation in snap/info.go in the existing code | 08:59 |
| pedronis | pstolowski: but we have apps? do we use them? | 09:01 |
| pstolowski | pedronis, we do, they affect SecurityTags() | 09:03 |
| mborzecki | can this https://github.com/snapcore/snapd/pull/4119 be merged, or should i rebase on top of master? | 09:05 |
| mup | PR #4119: tests/test-snapd-service: fix shellcheck issues <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4119> | 09:05 |
| zyga-solus | looking | 09:06 |
| === slvn is now known as slvn_ | ||
| zyga-solus | mborzecki: yeah, or merge master | 09:07 |
| mup | PR snapd#4141 opened: snap-update-ns: add missing unit test for desired/current profile handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/4141> | 09:08 |
| zyga-solus | nice! | 09:08 |
| mborzecki | rebased and pushed | 09:09 |
| pedronis | pstolowski: thanks | 09:14 |
| pedronis | pstolowski: zyga-solus: shouldn't places in interaces doing range plug.Apps ? also consider plug.Hooks ? | 09:16 |
| pedronis | *interfaces | 09:16 |
| zyga-solus | pedronis: yes, do you know of one that does not? | 09:16 |
| pedronis | they all don't | 09:17 |
| pedronis | afact | 09:17 |
| pedronis | I'm not even sure the interface is the best given the issue | 09:17 |
| zyga-solus | pedronis: hmm | 09:17 |
| pedronis | zyga-solus: there's a bunch of plug.Apps in interfaces/builtin but not plug.Hooks | 09:17 |
| pedronis | afaict | 09:18 |
| pedronis | I suppose we didn't notice because the interfaces that need that are not typical hook plugs | 09:18 |
| pedronis | but I suppose there is an issue | 09:18 |
| zyga-solus | indeed | 09:18 |
| zyga-solus | I see this in common | 09:18 |
| zyga-solus | and in other places | 09:18 |
| pstolowski | info.go // NOTE: hooks cannot have slots | 09:18 |
| pstolowski | ah, sorry, you're asking about plugs | 09:19 |
| zyga-solus | yes | 09:20 |
| zyga-solus | pedronis: it's isolated to udev handling, it seems | 09:20 |
| zyga-solus | pstolowski: do you want to fix it or shall I? | 09:20 |
| zyga-solus | pedronis: thank you for spotting! | 09:20 |
| pstolowski | zyga-solus, i'm currently working on cookies issue from yesterday | 09:21 |
| zyga-solus | ok | 09:21 |
| zyga-solus | I'll do it | 09:21 |
| pedronis | pstolowski: also related, I notice that plugJSON has no hooks either | 09:25 |
| pstolowski | pedronis, thanks, will fix | 09:25 |
| pedronis | I don't know if it's important, are we still using plugJSON ? | 09:26 |
| mvo | zyga-solus: 4139 has unit tests failures, fix is trivial http://paste.ubuntu.com/25878484/ - could you please update? | 09:27 |
| zyga-solus | sure | 09:28 |
| * zyga-solus wonders how that happened, I go tested this | 09:28 | |
| === __chip__ is now known as Chipaca | ||
| zyga-solus | done | 09:30 |
| zyga-solus | mvo: ah, the backport, I must have not tested that one | 09:31 |
| Chipaca | aw, you can't make an alias into a namespace :-( | 09:40 |
| Chipaca | - Setup manual alias "xbill-xaw.xbill-xaw" => "xbill-xaw" for snap "xbill-xaw" (cannot enable alias "xbill-xaw.run" for "xbill-xaw", it conflicts with the command namespace of installed snap "xbill-xaw") | 09:41 |
| Chipaca | gah, mis-paste | 09:41 |
| Chipaca | - Setup manual alias "xbill-xaw.run" => "xbill-xaw" for snap "xbill-xaw" (cannot enable alias "xbill-xaw.run" for "xbill-xaw", it conflicts with the command namespace of installed snap "xbill-xaw") | 09:41 |
| Chipaca | (yes that is kinda backwards) | 09:41 |
| mup | PR snapd#4138 closed: release: 2.29.1 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4138> | 09:50 |
| Chipaca | how're you doing, mborzecki ? | 09:52 |
| mvo | oSoMoN: fwiw, I can reproduce the chromium nvidia black screen issue here | 09:52 |
| mvo | oSoMoN: I get mknod denials for seccomp | 09:53 |
| mborzecki | Chipaca: good, fixed all unit tests that were failing on arch, lookign into updating arch package now | 09:55 |
| mvo | oSoMoN: and manually adding "mknod" to the seccomp profile works | 09:55 |
| Chipaca | mborzecki: neat | 09:55 |
| mvo | oSoMoN: well, works in the sense that when i do that, recompile the profile and start chromium it works | 09:55 |
| mborzecki | Chipaca: there's a PR open https://github.com/snapcore/snapd/pull/4135 in case you want to sake a second look | 09:56 |
| mup | PR #4135: Workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135> | 09:56 |
| oSoMoN | mvo, thanks for the feedback! do the denials indicate which node chromium is trying (and failing) to create? | 10:02 |
| mvo | oSoMoN: I try to figure this out right now, it does not give me this data currently | 10:06 |
| oSoMoN | mvo, you'll probably need to strace it to get that info | 10:06 |
| mvo | oSoMoN: yes | 10:06 |
| zyga-solus | or run it and look at /tmp | 10:06 |
| mvo | zyga-solus: /tmp ? | 10:06 |
| zyga-solus | well, it has to keep the node somewhere | 10:06 |
| zyga-solus | so /tmp or /run | 10:07 |
| zyga-solus | or $HOME | 10:07 |
| pedronis | mborzecki: we tend to title our PRs with: comma-separated relevant packages or dirs or "many" ":" lowercase summary | 10:15 |
| mborzecki | pedronis: noted, thanks | 10:16 |
| pedronis | mborzecki: like "cmd/snap,client,daemon: show ignore-validation if set in snap info" | 10:16 |
| mborzecki | pedronis: I can rename it now, but I'm afraid it might restart the builds | 10:19 |
| zyga-solus | mborzecki: no need | 10:19 |
| zyga-solus | mborzecki: just hit edit on GH | 10:19 |
| mborzecki | updated | 10:21 |
| pedronis | yes, this is about the PR title and the merge commit, not the commits inside | 10:21 |
| pedronis | we are not very strict, but this is the idea | 10:21 |
| mborzecki | ok | 10:22 |
| Chipaca | mborzecki: git log --oneline --no-merges <- we try to make this readable (it's a struggle) | 10:23 |
| Chipaca | zyga has a link with more rationale | 10:23 |
| zyga-solus | me? I don't recall | 10:23 |
| Chipaca | yus | 10:23 |
| zyga-solus | now that you said that I do recall | 10:23 |
| zyga-solus | but I don't recall what it was :) | 10:23 |
| zyga-solus | I recall _something_ :D | 10:24 |
| mborzecki | aah, yeah, i'm used to rebasing a lot :) this usually kept the history linear | 10:24 |
| pedronis | it's a struggle because we aren't as rebase happy as other projects, | 10:24 |
| pedronis | mborzecki: yea, general rule we don't rebase after a PR got some comments, we tend not to squash commit either unless the PR is messy, then we do | 10:25 |
| pedronis | the results are mixed | 10:25 |
| pedronis | also we have rules how the merge commit should look like but it's a struggle to remember to apply them when clicking in GH | 10:25 |
| mborzecki | noted :) sorry cause i've rebased both PRs already | 10:26 |
| mborzecki | some project do merges outside of github just to keep the history linear, iirc zephyr does that | 10:27 |
| Chipaca | that's ok, we won't burn you alive for the first one | 10:27 |
| Chipaca | :-) | 10:27 |
| zyga-solus | mborzecki: github has an option to rebase nowadays | 10:27 |
| Chipaca | (but really, these are our intentions; then things are on fire and it all goes out the window) | 10:28 |
| mborzecki | though it's still not particularly review friendly with rebase/fixup workflow :( | 10:28 |
| mborzecki | small things like ordering commits chronologically rather than using the order from git | 10:28 |
| pedronis | mmh, I don't this stuff in written in the form or the readmes ? | 10:42 |
| pedronis | s/form/forum/ | 10:42 |
| mborzecki | any idea why libseccomp is linked statically into snap-seccomp? | 10:44 |
| zyga-solus | mborzecki: because of re-exec woes | 10:44 |
| zyga-solus | mborzecki: snapd needs to operate on systems where libseccomp is old/unpatched | 10:44 |
| pedronis | Chipaca: are you working on aliases? or the private refresh bug? | 10:45 |
| Chipaca | pedronis: aliases; AIUI refresh needs gustavo (and it's just one more day) | 10:50 |
| Chipaca | pedronis: if you want to start in it feel free :-) my plate has plenty on it | 10:51 |
| pedronis | no, mostly asking if you had time for some reviews | 10:52 |
| Chipaca | always¹ | 10:53 |
| Chipaca | 1. not always | 10:54 |
| zyga-solus | LOL | 10:54 |
| zyga-solus | 1. conditions apply | 10:54 |
| Chipaca | ;) | 10:54 |
| pedronis | Chipaca: interested in your feedback on #4112 | 10:56 |
| mup | PR #4112: cmd/snap,client,daemon: show ignore-validation if set in snap info <Created by pedronis> <https://github.com/snapcore/snapd/pull/4112> | 10:56 |
| Chipaca | pedronis: https://github.com/snapcore/snapd/pull/4112/files?w=1 | 10:57 |
| Chipaca | (ignore whitespace for the github diff) | 10:58 |
| Chipaca | pedronis: hm, i would've put it in notes | 10:58 |
| Chipaca | pedronis: then you also get it (for free) in snap list | 10:58 |
| pedronis | well I asked for feedback, | 10:59 |
| pedronis | otoh you get notes only with --verbose | 10:59 |
| Chipaca | pedronis: no, you get the expanded notes with --verbose | 10:59 |
| Chipaca | pedronis: without it you get them a la list | 10:59 |
| pedronis | ah, so seems the right thing to do | 11:00 |
| pedronis | let me close this | 11:01 |
| * Chipaca will allow it | 11:01 | |
| Chipaca | :-D | 11:01 |
| mup | PR snapd#4112 closed: cmd/snap,client,daemon: show ignore-validation if set in snap info <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4112> | 11:01 |
| pedronis | Chipaca: ah, it's a cmd/snap concept, not a rest api concept | 11:03 |
| Chipaca | yes, the client side is fine | 11:03 |
| pedronis | good(tm) | 11:04 |
| pedronis | Chipaca: is ignore-validation too long for notes? | 11:05 |
| Chipaca | pedronis: do you have something better? | 11:08 |
| pedronis | no | 11:08 |
| mup | PR snapcraft#1652 closed: tests: fork skip into snaps_tests <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1652> | 11:08 |
| Chipaca | pedronis: 's fine | 11:08 |
| pedronis | ah, I still need my code for the verbose case | 11:10 |
| pedronis | that's a little odd | 11:10 |
| sergiusens | snappy-m-o autopkgtest 1650 xenial:amd64 xenial:armhf xenial:arm64 zesty:amd64 zesty:armhf zesty:arm64 artful:amd64 artful:armhf artful:arm64 bionic:amd64 bionic:armhf bionic:arm64 | 11:12 |
| snappy-m-o | sergiusens: I've just triggered your test. | 11:12 |
| zyga-solus | tests are not with me today | 11:20 |
| mup | PR snapd#4142 opened: cmd/snapd,client,daemon: display ignore-validation flag through the notes mechanism <Created by pedronis> <https://github.com/snapcore/snapd/pull/4142> | 11:24 |
| pedronis | Chipaca: ^ | 11:25 |
| Chipaca | pedronis: lovely | 11:32 |
| mborzecki | zyga-solus: you introduce packaging for arch, can you take a look at this patch: https://github.com/bboozzoo/snapd/commit/1ac38e2614cef8e30d17b8800bc18c1abeac9409 | 11:36 |
| zyga-solus | looking | 11:37 |
| mborzecki | once arch related PRs get merged, i'd like to publish this to AUR as snapd-git | 11:38 |
| zyga-solus | mborzecki: I merged snap-confine into one package now | 11:38 |
| zyga-solus | mborzecki: btw, did you see the packaging that was added to 2.27.x releases? | 11:38 |
| zyga-solus | (on GH release pages) | 11:39 |
| zyga-solus | ah, I was confused by depends on snap-confine | 11:39 |
| mborzecki | yes, but the community package is still split into snapd and snap-confine, unless it's listed in conflicts pacman will not try to remove it | 11:39 |
| zyga-solus | hmm | 11:39 |
| zyga-solus | mborzecki: I see | 11:39 |
| zyga-solus | that's unfortunate | 11:39 |
| zyga-solus | can we do anything about that? | 11:40 |
| mborzecki | zyga-solus: it's there, snap-confine is listed in conflicts in my patch, this should do the trick | 11:41 |
| zyga-solus | ah, I see | 11:41 |
| zyga-solus | +1 then | 11:41 |
| zyga-solus | not sure if other things are done | 11:42 |
| * zyga-solus looks | 11:42 | |
| zyga-solus | nope | 11:42 |
| zyga-solus | look at 2.27.x releases for updated packaging | 11:42 |
| zyga-solus | things like snap-exec etc are missing | 11:42 |
| mvo | oSoMoN: I added some info into the forum post, chromium acts a bit strange, maybe its something specific to their code but it tries to create /dev/nvidiactl which is already avialable in the namespace and which the same pid stat()s successfully a couple of times before | 11:45 |
| oSoMoN | mvo, thanks, that's very useful, I'll dig in chromium code to try and understand why they would do that | 11:48 |
| mborzecki | zyga-solus: hmm looks like arch packaging was never updated to include snap-exec :/ | 11:49 |
| zyga-solus | mborzecki: not the one in the repo (as it was never upstreamed) | 11:49 |
| mvo | oSoMoN: thanks, might be an issue on our side too, but from the strace it looks like something strange is happening in the code | 11:49 |
| zyga-solus | mborzecki: sorry about that, arch situation is a bit unoptimal | 11:49 |
| mborzecki | can you point me to the code? | 11:51 |
| zyga-solus | sure | 11:51 |
| zyga-solus | https://github.com/snapcore/snapd/releases/tag/2.27.5 | 11:51 |
| zyga-solus | there's a source package for arch attached | 11:51 |
| zyga-solus | https://github.com/snapcore/snapd/releases/download/2.27.5/snapd-2.27.5-1-arch-srcpkg.tar.gz | 11:51 |
| zyga-solus | a bit crude but :/ | 11:51 |
| pedronis | mvo: did you see my question about default tests for the configure-snapd code? | 11:51 |
| mvo | pedronis: yes thank you! I started to write one and then $stuff happend :/ (the mount profile chnage bug that zyga-ubuntu found/fixed and an nvidia error) | 11:54 |
| pedronis | it's ok, just wondered because there was no answer in the PR | 11:55 |
| pedronis | mvo: on my side a 2nd review of #4106 would be appreciated, and thansk for reviewing the snap info/list change | 11:56 |
| mup | PR #4106: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106> | 11:56 |
| mvo | pedronis: ok, I do that next (probably after lunch though) | 11:57 |
| mborzecki | zyga-solus: got it, by the looks of it, it's a bit outdated and the build process is so-so (CGO_*FLAGS are not set properly) | 11:58 |
| zyga-solus | mborzecki: that's the most recent we have, we didn't do arch releases since | 11:58 |
| mborzecki | what's the plan then? so far there's an outdated version in snapd tree, another one on gh release page (outdated as well) and one in community repo (more outdated than both previous) | 11:58 |
| zyga-solus | mborzecki: if you merge it with your improvements and merge back to master it should be fairly ok | 11:58 |
| zyga-solus | ideally, update the community repo but ENOLUCK | 11:59 |
| zyga-solus | mborzecki: we can update the packaging in master for reference | 11:59 |
| zyga-solus | mborzecki: but we still don't have arch tests that run on PRs so it's likely to go out of date eventually | 11:59 |
| zyga-solus | mborzecki: little by little, since you run arch daily it will help a lot in making the package healthy | 12:00 |
| mborzecki | ok, hmm let's do this, first merge and update all pkgbuilds into master tree, make it a -git package (this should make it easy to test it directly from git) | 12:01 |
| zyga-solus | +1 | 12:01 |
| mborzecki | then maybe add snapd-git to aur, so that the users are not blocked and update archwiki page (if there's one) | 12:01 |
| mborzecki | guess the last step would be getting an image for spread and adding arch to the test suite | 12:01 |
| oSoMoN | mvo, it might be https://cs.chromium.org/chromium/src/content/gpu/gpu_sandbox_hook_linux.cc?type=cs&sq=package:chromium&l=223 , but I'm still trying to figure out where that call to mknod is issued | 12:02 |
| mborzecki | zyga-solus: first 2 i can take care of, will need help with the last one :), how does that sound? | 12:02 |
| zyga-solus | mborzecki: arch is supported on linode already | 12:03 |
| zyga-solus | mborzecki: but it all sounds like a good plan | 12:03 |
| * kalikiana coffee vreak | 12:07 | |
| mup | PR snapcraft#1655 opened: lxd: distinguish argless clean from clean -s pull <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1655> | 12:08 |
| zyga-solus | mvo: can you do a 2nd review of 4136 | 12:08 |
| zyga-solus | this will let us merge 4141 next | 12:10 |
| mup | PR snapd#4119 closed: tests/test-snapd-service: fix shellcheck issues <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4119> | 12:22 |
| mup | PR snapcraft#1646 closed: sources: enforce default language in subversion info <Created by clobrano> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1646> | 12:29 |
| pedronis | seen this: + tar czf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz /var/lib/snapd /snap /etc/systemd/system/snap-core-3386.mount /etc/environment /etc/systemd/system/snapd.service.d /etc/systemd/system/snapd.socket.d | 12:30 |
| pedronis | tar: Removing leading `/' from member names | 12:30 |
| pedronis | tar: /var/lib/snapd: file changed as we read it | 12:30 |
| pedronis | are we not stopping enough stuff? | 12:30 |
| pedronis | was on 14.04 | 12:30 |
| zyga-solus | maybe refresh timer (unlikely but maybe?) | 12:30 |
| zyga-solus | the udev tagging situation is more complex than other backends but I think I have something that will allow us to fix it in a generic way | 12:39 |
| zyga-solus | hey cachio, how are you feeling? | 12:41 |
| cachio | zyga-solus, I am in a 35% | 12:41 |
| zyga-solus | cachio: go away and recharge then | 12:42 |
| zyga-solus | cachio: take a break, rest, it's friday | 12:42 |
| cachio | zyga-solus, it is ok, if I feel bad I'll go to bed | 12:42 |
| cachio | zyga-solus, mvo, the #3378 is the one to validate? | 12:44 |
| mup | PR #3378: tests: fixes for executions using the staging store <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3378> | 12:44 |
| cachio | core snap rev 3378 | 12:44 |
| * Chipaca looks at cachio | 12:45 | |
| Chipaca | cachio: this is not how you get better | 12:45 |
| Chipaca | mvo: i need to go to the school it seems; i'll be missing the standup | 12:46 |
| Chipaca | mvo: report from me would be: still hating aliases (but still hopeful to finish before eow), and, need to look at how to handle refresh of private (and bought) snaps next week with niemeyer | 12:47 |
| Chipaca | (via people having trouble with this in the forum) | 12:48 |
| mvo | Chipaca: thank you | 12:57 |
| mvo | oSoMoN: indeed, this looks like the right track | 12:58 |
| mvo | zyga-solus: looking at 4136 in a wee bit, last I looked tests were still running but looks like that is finished now | 12:59 |
| zyga-solus | thank you | 12:59 |
| * sergiusens starts making his way to the bank | 13:00 | |
| sergiusens | bbiab | 13:00 |
| === JoshStrobl is now known as JoshStrobl|Store | ||
| zyga-solus | mvo: I'll push my PR in a moment | 13:28 |
| mvo | zyga-solus: ta | 13:31 |
| mup | PR snapd#4136 closed: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4136> | 13:32 |
| pedronis | pstolowski: for the 2nd part of the issue, I think will need something like Change.LaneTasks(lanes []int) []*Tasks that gives all the tasks in the change in the given lanes, or all of the them if one of the lanes is 0 (the default lane) | 13:34 |
| pedronis | heh, sorry, the last bit is wrong | 13:35 |
| pedronis | about 0 | 13:35 |
| pstolowski | pedronis, will look at snapctl issue next. thanks | 13:38 |
| pedronis | pstolowski: np | 13:38 |
| pstolowski | what's the quickest/recommended way of disabling a spread test entirely? | 13:39 |
| pstolowski | via systems: ? | 13:39 |
| mvo | pstolowski: manual: true is one way and a comment | 13:39 |
| pstolowski | mvo, great, thanks | 13:40 |
| mvo | pstolowski: or exit 0 in execute with an echo with the details why its disabled | 13:40 |
| pstolowski | mvo, i'm going to propose this only against 2.29, since MR will receive a fix in next few days; makes sense? | 13:43 |
| pstolowski | s/MR/master/ | 13:43 |
| mvo | pstolowski: yes | 13:43 |
| mvo | pstolowski: we will still pull it into master to minimize the delta but if you target 2.29 thats great that means we can move faster | 13:44 |
| mup | PR snapcraft#1412 opened: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412> | 13:44 |
| zyga-solus | offtopic, HasLen checker is particularly unhelpful about saying what the real length was | 13:46 |
| mup | PR snapd#4106 closed: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4106> | 13:48 |
| mup | PR snapd#4110 closed: many: have a timestamp on store assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4110> | 13:51 |
| mup | PR snapd#4139 closed: cmd/snap-update-ns: fix collection of changes made <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4139> | 13:51 |
| === mborzeck1 is now known as mborzecki | ||
| mup | PR snapd#4143 opened: snapctl: Disable stop/start/restart (2.29) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4143> | 13:58 |
| pstolowski | mvo, ^ this should do it | 13:59 |
| pstolowski | kyrofa, ^ bad news :( | 14:00 |
| zyga-solus | mvo: now doing common | 14:03 |
| zyga-solus | mvo: behind one innocent line in common.go there are lots of interfaces that need small tweaks to consts | 14:05 |
| mborzecki | zyga-solus: there was a template based refactoring tool for go | 14:08 |
| zyga-ubuntu | mborzecki: uh, not worth it in this case | 14:08 |
| mborzecki | eg? | 14:08 |
| zyga-ubuntu | I need to tweak a few constants | 14:08 |
| zyga-ubuntu | and change type | 14:08 |
| mborzecki | hm change type can be done with gorename | 14:09 |
| mborzecki | it'll update all packages that use that type | 14:09 |
| zyga-ubuntu | mborzecki: I need to do that to about a dozen variables spread around dozen files | 14:09 |
| zyga-ubuntu | mborzecki: I'll show you the patch and I can learn abou the tool when you see it | 14:10 |
| mvo | pstolowski: thank you | 14:10 |
| mvo | mborzecki: anything that needs to go to 2.29? | 14:11 |
| mborzecki | mvo: don't think that arch fixes are a priority, so nothing from my side | 14:12 |
| mvo | mborzecki: ta | 14:12 |
| mvo | zyga-ubuntu: your renames are master, right? or also 2.29? | 14:12 |
| zyga-solus | mvo: master unless you think it's 2.29 material | 14:13 |
| zyga-solus | mvo: "renames" are not real renames, just a mental shortcut | 14:13 |
| mvo | zyga-solus: I will wait for the PR but probably not 2.29 then | 14:18 |
| mvo | zyga-solus: just trying to avoid a .3 by gathering all potential further changes | 14:18 |
| zyga-solus | k | 14:19 |
| zyga-solus | mvo: ok ready | 14:23 |
| zyga-solus | pushing | 14:23 |
| zyga-solus | mvo: 4144 | 14:27 |
| zyga-solus | I'll self-review for typos now | 14:27 |
| mup | PR snapd#4144 opened: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144> | 14:28 |
| roadmr | jdstrand: hi! hey question. You approved classic confinement for goby yesterday. Did you by chance also trigger an automated review after doing that? | 14:31 |
| zyga-solus | mvo: read it, pushed and squashed one trivial unused variable removal | 14:32 |
| zyga-solus | mvo: I'll check if this applies to 2.29 | 14:32 |
| zyga-solus | mvo: yep, I can propose a 2.29 variant too | 14:33 |
| zyga-solus | close it if you don't want to take that risk | 14:33 |
| mvo | zyga-solus: I ponder over it | 14:34 |
| mvo | roadmr: jdstrand is not around today | 14:34 |
| mup | PR snapd#4145 opened: Backport/udev hooks 2.29 <Created by zyga> <https://github.com/snapcore/snapd/pull/4145> | 14:35 |
| roadmr | mvo: darn! mystery will need to wait to be solved :) | 14:35 |
| zyga-solus | pedronis: can you have a look at 4144 | 14:35 |
| zyga-solus | pedronis: that should fix the issue you found today | 14:35 |
| mvo | roadmr: yeah :) | 14:36 |
| roadmr | thanks though mvo | 14:36 |
| mup | PR snapd#4145 closed: interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4145> | 14:37 |
| mup | PR snapd#4146 opened: interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4146> | 14:38 |
| mborzecki | zyga-solus: you're right, does not look like this could be done with go's refactoring tools | 14:42 |
| zyga-solus | mvo: I'll make some tea, let me know if I can help you somehow | 14:44 |
| * sergiusens is back | 14:59 | |
| sergiusens | kyrofa might want to start looking into this https://pastebin.ubuntu.com/25880037/ | 15:00 |
| sergiusens | that is all I have from the error as the log has not been generated/exposed yet | 15:00 |
| sergiusens | that extract is from running on bionic, which I thought would be a skip for these | 15:01 |
| mvo | zyga-solus: quick brainstorm, can you check https://github.com/snapcore/snapd/compare/master...mvo5:refactor-ifstate?expand=1 and tell me what names you prefer? do you think overlord/ifacestate/repo is a good name for the package? | 15:03 |
| mvo | zyga-solus: fwiw, tests for 4143 have not started yet :( so no 2.29.2 until those have run | 15:03 |
| mborzecki | i'm done for today, gotta go pick up my kids, have a nice weekend guys | 15:05 |
| elopio | Good morning! | 15:06 |
| kalikiana | sergiusens: You might like to have a look at snapcraft#1655 this is to avoid `snapcraft -s pull` killing your container | 15:07 |
| mup | PR snapcraft#1655: lxd: distinguish argless clean from clean -s pull <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1655> | 15:07 |
| diddledan | build.snapcraft.io isn't letting me sign-into launchpad oauth: Invalid association handle | 15:07 |
| * kalikiana waves at elopio | 15:07 | |
| diddledan | or rather it redirects back to build.snapcraft.io but reports error | 15:08 |
| kyrofa | pstolowski, uh oh | 15:09 |
| kyrofa | pstolowski, what's the background there? | 15:09 |
| pstolowski | kyrofa, it breaks with an error if run from configure hook as part of snap install/refresh. will also error out in install/refresh hooks. | 15:11 |
| pstolowski | kyrofa, my spread test was only testing one case | 15:12 |
| kyrofa | pstolowski, is this a case of the fix being known, just more work than can be done right before a release | 15:12 |
| kyrofa | ? | 15:12 |
| pstolowski | kyrofa, more work, but not on time for this .point release | 15:13 |
| zyga-solus | re | 15:13 |
| kyrofa | pstolowski, that's fair, I appreciate the heads up. Something you anticipate happening soon, though? | 15:13 |
| zyga-solus | mvo: sorry, had IRL interrupt | 15:13 |
| zyga-solus | mvo: checking your branch | 15:13 |
| pstolowski | kyrofa, yeah, should be fixed soon and in the 2.30 release | 15:14 |
| kyrofa | pstolowski, alright, thank you :) | 15:15 |
| om26er | Who is responsible for transfer of snap ownership ? | 15:15 |
| zyga-solus | mvo: hmm | 15:16 |
| zyga-solus | mvo: please add repo.go :) | 15:16 |
| zyga-solus | mvo: and push :) | 15:16 |
| zyga-solus | mvo: I'll check after I really make that tea | 15:16 |
| noise][ | om26er: there are a few of us here that can do it | 15:16 |
| kyrofa | sergiusens, huh, that one's not skipped. Maybe it's something we lost as part of the migration into snapd tests, or maybe it's something that used to work, but I'm adding a skip now | 15:16 |
| noise][ | and i'm aware we are a bit behind on the forum requests this week | 15:16 |
| om26er | noise][: kindly transfer android-studio and sublime-text-3 from my name(om26er) to snapcrafters | 15:16 |
| kyrofa | Oh, that's not part of the snapd suite, haha | 15:17 |
| * zyga-solus cannot wait to snap install sublime-text-3 | 15:17 | |
| om26er | The packaging was already moved under snapcrafters but the ownership didn't. | 15:17 |
| ogra_ | pfft ... vim rules ... | 15:17 |
| zyga-solus | ogra_: yeah, but fira code font is amazing | 15:18 |
| zyga-solus | ogra_: do you know that font? | 15:18 |
| noise][ | om26er: ok, we can get to those today, sorry for the delay | 15:18 |
| zyga-solus | mvo: travis is starving us so badly I wonder why this is so | 15:18 |
| mvo | zyga-solus: autsch, sorry, added repo.go now | 15:19 |
| kyrofa | It must have passed at some point, that test has been there for a while | 15:19 |
| ogra_ | zyga-solus, is that the one with weird arrows and such ? | 15:19 |
| zyga-solus | ogra_: yes | 15:20 |
| zyga-solus | well, "weird" | 15:20 |
| zyga-solus | normal actually | 15:20 |
| om26er | noise][: thanks :) | 15:20 |
| zyga-solus | mvo: so, first of repo is not a great name since it clashes with interfaces/repo.go and that Repository, something non-clashing would be better | 15:21 |
| zyga-solus | mvo: what is the cycle this breaks? | 15:21 |
| zyga-solus | mvo: I expected that we'd have something outside of ifacestate, not a nested package actually | 15:21 |
| mvo | zyga-solus: see explaination in the preview, it allows creating a "interfaces.Repository" based on the current state from snapstate | 15:23 |
| mvo | zyga-solus: which allows to e.g. answer the question if a content interface is already connected | 15:23 |
| mvo | zyga-solus: that is important to know if the default-provider needs to be downloaded or not | 15:23 |
| zyga-solus | right | 15:23 |
| zyga-solus | hmm | 15:23 |
| kyrofa | sergiusens, wait... that's a duplicate test! | 15:23 |
| mup | PR snapcraft#1656 opened: integration tests: skip shared ROS test on non-xenial <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1656> | 15:23 |
| zyga-solus | I'm a little lsot about how this makes it work (I totally believe it does, just not grok it yet) | 15:24 |
| kyrofa | Ignore that PR for a sec, it looks like that test became a snapd test, but then was never removed | 15:24 |
| mvo | zyga-solus: I'm open for other ideas, I'm not super happy about "repo" | 15:24 |
| zyga-solus | snapstate->ifacestate->snapstate is the cycle that we are breaking? | 15:24 |
| kyrofa | Man, that's gonna speed travis up so much | 15:24 |
| zyga-solus | mvo: let me branch and see | 15:24 |
| zyga-solus | mvo: +1 on the idea, this is just nitpick territory now | 15:24 |
| mvo | zyga-solus: yes, snapstate imports ifacestate/repo and ifacestate imports ifacestate/repo too | 15:25 |
| mvo | zyga-solus: we do something similar in configstate/config | 15:25 |
| kyrofa | sergiusens, wait I lied. It's not, it's closely related | 15:25 |
| mvo | zyga-solus: yeah, no worries, happy to bikesheed about the name, naming is hard | 15:25 |
| mvo | zyga-solus: the three most difficult problems in cs: naming and off-by-one errors | 15:26 |
| kyrofa | And it's a faster one anyway | 15:27 |
| zyga-solus | mvo: iterating | 15:28 |
| === JoshStrobl|Store is now known as JoshStrobl | ||
| kyrofa | mvo, very clever :P | 15:30 |
| zyga-solus | mvo: and indentation | 15:30 |
| mvo | zyga-solus: so once we have a name i can add some tests and cleanup around this and then use it in the default provider PR | 15:32 |
| zyga-solus | I'm tweaking locally, one more moment please | 15:32 |
| mvo | sure | 15:33 |
| pedronis | my internet connection is flaky | 15:35 |
| zyga-solus | ok | 15:38 |
| kyrofa | sergiusens, shall I queue up a non-xenial run on snapcraft#1656 ? Perhaps not bionic though as it seems the biggest queue | 15:41 |
| mup | PR snapcraft#1656: integration tests: skip shared ROS test on non-xenial <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1656> | 15:41 |
| zyga-solus | mvo: pushed to my branch of the same name | 15:41 |
| kyrofa | Oh bionic is looking pretty decent for upstream actually | 15:42 |
| zyga-solus | kyrofa: forever people googling for "bionic libc ..." will curse ubuntu | 15:42 |
| kyrofa | zyga-solus, I've never once googled "xenial libc" :P | 15:43 |
| zyga-solus | kyrofa: bionic as the android libc | 15:43 |
| kyrofa | Oh, the other way around-- I thought you meant they would find android results when they were looking for ubuntu. Gotcha | 15:43 |
| kyrofa | Yeah they probably will! | 15:43 |
| zyga-solus | yeah, I think >> android than ubuntu | 15:43 |
| mvo | zyga-solus: thank you! Not sure I like "Restore", maybe "Load"? | 15:44 |
| zyga-solus | mvo: sure | 15:44 |
| zyga-solus | mvo: I was thinking that it should live in overlord | 15:44 |
| zyga-solus | but that is somewhat black-hole logic | 15:44 |
| zyga-solus | eventually everything will be in overlord | 15:45 |
| zyga-solus | so instead I think it makes sense to speak of interfaces and state as interfaces/ifstate | 15:45 |
| sergiusens | kyrofa just do zesty; bionic and artful will fail adt anyways | 15:45 |
| mvo | zyga-solus: re overlord> I kept it there mostly because we have all state related things there. beside daemon/ itself all the things that are importing/manipulating state are under overlord afaict | 15:46 |
| sergiusens | elopio kyrofa can we do that meeting one hour later? This is the time I try to avoid meetings | 15:47 |
| mvo | zyga-solus: maybe it is one of those - we need gustavo PRs :) - but happy to use your PR as the starting point (except for "Restore" which feels a bit off to me) | 15:48 |
| kyrofa | sergiusens, yep | 15:48 |
| zyga-solus | mvo: sure | 15:48 |
| elopio | sergiusens: no problem. | 15:48 |
| zyga-solus | mvo: Load is fine, please use that | 15:48 |
| mvo | zyga-solus: thanks | 15:48 |
| zyga-solus | mvo: look at the package imports in ifstate.go, we can . import interfaces to almost unify this with the rest of the cod there | 15:48 |
| kyrofa | snappy-m-o, autopkgtest 1656 zesty:i386 | 15:48 |
| snappy-m-o | kyrofa: I've just triggered your test. | 15:49 |
| kyrofa | That queue is non-existent | 15:49 |
| zyga-solus | mvo: some things could move sideways to utils.go (AddImplicitSlot, etc) | 15:49 |
| zyga-solus | mvo: or elsewhere, as appropriate | 15:50 |
| zyga-solus | mvo: it would also help to, at least in my eyes, to connect the interfaces.Repository to state handling, at least it would be "close" | 15:50 |
| mvo | zyga-solus: not sure I understand what you have in mind. " . import interfaces" - what does ". import" mean? | 15:52 |
| zyga-solus | import ( . "github.com/snapcore/snapd/interfaces" ) | 15:52 |
| zyga-solus | then you can say Load(...) (*Repository, error) | 15:52 |
| zyga-solus | without having to preprend "interfaces." to most types | 15:53 |
| mvo | hm, not sure I like that, maybe just because its unfamiliar (and its friday :) | 15:55 |
| zyga-solus | mvo: we use it to import check.v1 (almost) everywhere | 15:55 |
| zyga-solus | mvo: anyway, just an idea, since this code mostly deals with interface types | 15:55 |
| zyga-solus | mvo: what do you think about 4144 | 15:56 |
| mup | PR snapd#4147 opened: ifacestate: refactor and extract ifacestate/repo <Created by mvo5> <https://github.com/snapcore/snapd/pull/4147> | 15:57 |
| mvo | zyga-solus: ups, sorry, reading now | 15:57 |
| roadmr | diddledan: hey you requested a bunch of snap transfers from you to snapcrafters. Did snapcrafters agree to this? :) | 15:58 |
| pedronis | mvo: why is New is in that package, btw having a New for a type not defined there is strange | 16:03 |
| kalikiana | brb | 16:03 |
| zyga-solus | pedronis: look at my proposal in the same branch under my account | 16:03 |
| mvo | pedronis: yeah, zyga-solus was suggesting "Restore" we also discussed "Load" | 16:06 |
| zyga-solus | pedronis: I also moved it to interfaces/ifstate since it's closely coupled to types there | 16:06 |
| zyga-solus | pedronis: but just more ideas | 16:06 |
| pedronis | ifstate is a weird name | 16:07 |
| roadmr | diddledan: also - is build.snapcraft.io still misbehaving? I just registered and built a snap without any issues | 16:08 |
| zyga-solus | pedronis: I also tried interface/state but then I imported it as ifstate in overlord | 16:09 |
| pedronis | it's doing very different things | 16:12 |
| pedronis | I fear we need to think a bit more | 16:12 |
| pedronis | there's not a stronge relation between repo stuff and conns stuff for example | 16:12 |
| mup | PR snapd#4143 closed: snapctl: disable stop/start/restart (2.29) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4143> | 16:12 |
| zyga-solus | no? I think repo is mostly about storing what is connected | 16:14 |
| mvo | pedronis: yeah, it seems a bit loose right now, the PR is the first discussion point (the most minimal thing I could do to de-couple it) | 16:14 |
| pedronis | mvo: I really need to understand what you need, because the decoupling as such doesn't make sense to me | 16:15 |
| pedronis | it feels very arbitrary | 16:15 |
| mvo | pedronis: my use case is that I want to answer the question "is this content interface connected" in snapstate when I decide if I need to download the default-provider | 16:16 |
| mvo | pedronis: there is another use case in another branch but that is for later (but also 2.30) | 16:16 |
| pedronis | I don't see how moving ReloadConnections relates to that | 16:17 |
| zyga-solus | pedronis: ReloadConnections is really Repository.Import(state) | 16:18 |
| pedronis | sorry, I don't understand | 16:18 |
| pedronis | how do you get to repo? | 16:19 |
| pedronis | do you build a different one in snapstate? | 16:19 |
| pedronis | I'm probably super confused | 16:19 |
| zyga-solus | no, sorry | 16:19 |
| zyga-solus | overlord keeps one repository instance around | 16:19 |
| pedronis | ? | 16:19 |
| pedronis | and passes it to snapstate? | 16:20 |
| zyga-solus | exposes certain functionality, I didn't look exactly if that passes the whole repo or just one method from it | 16:20 |
| zyga-solus | my desire to keep the ifstate module closer to interfaces/ was because it's really about how the interface repository is serialized | 16:20 |
| zyga-solus | and "deserialized" from the state | 16:21 |
| pedronis | this branch doesn't change overload or snapstate | 16:21 |
| pedronis | afaict | 16:21 |
| mvo | pedronis: the new code loads a repo from state | 16:21 |
| pedronis | ? | 16:21 |
| mvo | pedronis: so it gets a snapshot of the current connection from the state to answer this question (what is connected right now) | 16:21 |
| zyga-solus | I mean there's nothing new in this, just a way to untangle some cyclic imports | 16:21 |
| pedronis | mvo: we create repos on teh fly all the time? | 16:21 |
| pedronis | where? | 16:22 |
| pedronis | I know how repo is used | 16:22 |
| pedronis | there was one repo | 16:22 |
| pedronis | inside ifacemanager | 16:22 |
| zyga-solus | pedronis: we don't create repos on the fly (fortunately!) :) | 16:22 |
| mvo | pedronis: we don't do that, my idea was to have code in snapstate that creates a repo on the fly in the future. but happy about alternative ideas | 16:22 |
| pedronis | mvo: what? | 16:23 |
| pedronis | that's kind of expensive | 16:23 |
| pedronis | also remember we are moving to have singletons for connections | 16:23 |
| pedronis | that's pawel work | 16:23 |
| pedronis | so that will not work | 16:23 |
| mvo | pedronis: meh, I was not following that new work, which PR should I look at? | 16:24 |
| pedronis | mvo: is not done yet | 16:24 |
| pedronis | mvo: anyway creating repos on the fly is a bad idea | 16:24 |
| zyga-solus | I agree with pedronis | 16:24 |
| zyga-solus | I wasn't expecting on-the-fly repos | 16:24 |
| mvo | pedronis: fair enough. what options do we have? | 16:24 |
| pedronis | mvo: have you looked at how assertstate deals with the assertions db ? | 16:24 |
| pedronis | we stick it in the cache | 16:25 |
| pedronis | and then can accessors that do state -> cache -> db -> answer questions | 16:25 |
| mup | PR snapd#4147 closed: ifacestate: refactor and extract ifacestate/repo <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4147> | 16:25 |
| mvo | pedronis: ok, I check that out, this looks good | 16:25 |
| mvo | pedronis: I close the PR and look at the alternative approach later (or Monday). thanks for your input! | 16:26 |
| zyga-solus | I think it's a good idea | 16:26 |
| pedronis | mvo: sorry if I was bit harsh, but refactoring without intended uses are hard to parse | 16:27 |
| pedronis | it's not about the code as such, it's more how it's going to be used | 16:27 |
| mvo | pedronis: no worries, I got the input that I needed :) i.e. the important part to me is how snapstate can get data from the repo and I think you pointed to a good solution which is great | 16:28 |
| pedronis | mvo: you'll probably need anyway a subpackage of ifacestate because of circularity but it can be focused on querying | 16:28 |
| === anewman is now known as anewman|away | ||
| mvo | pedronis: yeah, I think so too | 16:29 |
| pedronis | spread tests are very flaky again :/ | 16:44 |
| zyga-solus | what failed? | 16:46 |
| pedronis | lots of different things | 16:46 |
| pedronis | all a bit random | 16:46 |
| zyga-solus | worst kind :/ | 16:48 |
| === anewman|away is now known as anewman | ||
| * kalikiana going to wrap up for the day | 17:04 | |
| mthaddon | hi folks, I've been able to install this (classic) snap locally. Any idea why the snapstore doesn't like it? https://pastebin.ubuntu.com/25880784/ | 17:07 |
| zyga-solus | mthaddon: no idea, how did you make it? | 17:08 |
| roadmr | mthaddon: can you put that somewhere I can get to it? I'll run the review tools on it and see what the boggle is | 17:09 |
| mthaddon | zyga-solus: I'm not quite sure how to answer that question. Do you want to see the snapcraft.yaml file? | 17:09 |
| mthaddon | roadmr: will do | 17:09 |
| roadmr | mthaddon: that message can appear if you try to upload a random file, which does not appear to be your case | 17:09 |
| zyga-solus | mthaddon: no, just curious if it is hand made | 17:09 |
| mthaddon | I just ran "snapcraft" in a directory containing lp:codetree, fwiw | 17:10 |
| ogra_ | mthaddon, file codetree_0.1.6_amd64.snap | 17:19 |
| ogra_ | does it talk about being a squashfs file ? | 17:20 |
| mthaddon | yep, there now (retried at roadmr's request) | 17:20 |
| cachio | zyga-solus, I am getting this error: cannot snap-exec: cannot read info for "test-snapd-check-fs-access": stat /var/lib/snapd/snaps/test-snapd-check-fs-access_x2.snap: no such file or directory | 17:24 |
| cachio | zyga-solus, the file snap exists | 17:24 |
| cachio | any idea why it could happening? | 17:24 |
| zyga-solus | cachio: hmmm | 17:24 |
| zyga-solus | cachio: is the snap file mounted? | 17:25 |
| zyga-solus | any denials | 17:25 |
| zyga-solus | how did you experience this? | 17:25 |
| cachio | no denials | 17:26 |
| cachio | I am testing a new test | 17:26 |
| cachio | inlinode | 17:26 |
| cachio | do you want access? | 17:26 |
| zyga-solus | no, too tired today | 17:26 |
| zyga-solus | I can look on monday | 17:27 |
| cachio | zyga-solus, sure | 17:31 |
| cachio | zyga-solus, enjoy your weekend | 17:31 |
| zyga-solus | thank you, likewise | 17:31 |
| kyrofa | snappy-m-o, github subscribe 1656 | 17:52 |
| snappy-m-o | kyrofa: I'll send you a message if a test fails in the pull request #1656 (integration tests: skip shared ROS test on non-xenial). | 17:52 |
| mup | PR #1656: snap: do not sort the result of `snap find` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1656> | 17:52 |
| kyrofa | snappy-m-o, github subscribe 165 | 17:52 |
| snappy-m-o | kyrofa: I'll send you a message if a test fails in the pull request #165 (Enabling testing with new cli). | 17:52 |
| mup | PR #165: forgot to git add the tests <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/165> | 17:52 |
| kyrofa | snappy-m-o, github subscribe 1650 | 17:52 |
| snappy-m-o | kyrofa: I'll send you a message if a test fails in the pull request #1650 (Release changelog for 2.35). | 17:52 |
| mup | PR #1650: Merge master onto #1623 to check tests <Created by niemeyer> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1650> | 17:52 |
| kyrofa | That's gonna get old | 17:53 |
| elopio | sergiusens: kyrofa the other error on zesty was the git snap taking too long. | 17:56 |
| diddledan | roadmr: does this not count? https://github.com/orgs/snapcrafters/teams/snapcrafters/members | 17:57 |
| elopio | that's another one to simplify and demote to integration suite. | 17:57 |
| sergiusens | elopio we could probably just remove that test, does it give us anything? Mind double checking? | 17:57 |
| kyrofa | elopio, how do timeouts work on the autopkgtests? Is it like Travis, where it watches stdout? | 17:57 |
| sergiusens | If it is for classic, then I think we already have that in the integration suite | 17:57 |
| roadmr | diddledan: I saw that... well if you as a member of snapcrafters tell me you're happy with it, then I'll go ahead with the transfers | 17:57 |
| === jkridner|pd is now known as jkridner | ||
| Chipaca | niemeyer: can we make mup ignore snappy-m-o? | 17:57 |
| diddledan | I'll move the repos across, too | 17:57 |
| roadmr | diddledan: I just didn't want to assume, you know what they say about that. As long as you're explicitly OK with it that's fine. | 17:58 |
| diddledan | I just hadn't got that far :-) | 17:58 |
| sergiusens | Chipaca or better yet, ignore random numbers like 1111 | 17:58 |
| sergiusens | or #1111 | 17:58 |
| mup | PR #1111: timeout,snap: add YAML unmarshal function for timeout.Timeout <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/1111> | 17:58 |
| roadmr | diddledan: right, I do consider a repo under snapcrafters as explicit agrement :) which is why I transferred irccloud | 17:58 |
| Chipaca | #1111 is not a random number though | 17:58 |
| elopio | kyrofa: it depends. One part is a counter, from the start of the test. The other is what we added on pexpect, to fail earlier adjusting the expected timeout of a command ourselves | 17:59 |
| kyrofa | elopio, ah ha. Did pexpect timeout, then? | 17:59 |
| sergiusens | Chipaca no I thought about it twice in a row :-) | 17:59 |
| sergiusens | is #1234 random? | 17:59 |
| mup | PR #1234: debian: make snapd get its environ from /etc/environment <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1234> | 17:59 |
| diddledan | roadmr: thanks for the prudence :-) | 17:59 |
| diddledan | roadmr: inadyn now in snapcrafters: https://github.com/snapcrafters/inadyn | 18:00 |
| elopio | sergiusens: that's the one that tests classic confinement. We can replace it with a more simple one that reads /tmp, or something. | 18:00 |
| elopio | kyrofa: yes: Expected output 'Snapped .*\\.snap' not found. | 18:01 |
| roadmr | diddledan: thanks! let me wrap up a call and I'll get on the transfers. Will be done today (EDT) for sure | 18:01 |
| diddledan | I'll note on each topic the new repo location | 18:01 |
| roadmr | diddledan: much appreciated, that'll help with the bureaucratic side of things. | 18:02 |
| mvo | cachio: 2.29.2 is available in beta for everything except amd64, that got corrupted and I'm rebuilding it | 18:05 |
| * Chipaca vanishes into the night | 18:06 | |
| zyga-solus | mvo: corrupted? | 18:16 |
| mup | PR snapd#4148 opened: Release 2.29.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4148> | 18:20 |
| cachio | mvo, great | 18:23 |
| cachio | mvo, starting ... | 18:23 |
| mvo | cachio: \o/ | 18:28 |
| === anewman is now known as anewman|away | ||
| kyrofa | sergiusens, the deprecation notice for `snapcraft pack` is not in place, FYI | 19:12 |
| === anewman|away is now known as anewman | ||
| === anewman is now known as anewman|away | ||
| === anewman|away is now known as anewman | ||
| sergiusens | kyrofa would be good to get one I'd say. | 19:22 |
| * sergiusens crafts one up | 19:22 | |
| sergiusens | which other one is missing? | 19:22 |
| kyrofa | sergiusens, that's it | 19:23 |
| kyrofa | (just dn6) | 19:23 |
| sergiusens | kyrofa oh, so the others just didn't make it to the website | 19:28 |
| kyrofa | sergiusens, yeah deployment is a different issue | 19:28 |
| sergiusens | kyrofa and I seem to know what it is ;-) | 19:30 |
| kyrofa | Hmm. noise][ nessita the store is rejecting all my daily uploads with "__all__: The upload does not appear to be a valid package." | 19:33 |
| === anewman is now known as anewman|away | ||
| zyga-solus | kyrofa: upload valid packages then | 19:34 |
| zyga-solus | what is this >> thing you are uploading | 19:34 |
| kyrofa | zyga-solus, yeah either the store is borked or LP is messing up every single build :P | 19:35 |
| zyga-solus | kyrofa: __all__ your base are belong to us | 19:36 |
| noise][ | kyrofa: weird, can you grab the snap and try to install it locally? | 19:37 |
| === anewman|away is now known as anewman | ||
| zyga-solus | kyrofa: but one thing is good | 19:38 |
| zyga-solus | kyrofa: at least the store is not implemented in perl | 19:38 |
| kyrofa | noise][, yeah, works fine. https://launchpad.net/~nextcloud-snappy-dev/+snap/nextcloud-daily-master/+build/101331 | 19:39 |
| noise][ | weird | 19:42 |
| noise][ | can you file a bug and we can get someone to take a look on monday? | 19:42 |
| sergiusens | kyrofa read this one please https://github.com/canonical-docs/snappy-docs/pull/145 | 19:44 |
| mup | PR canonical-docs/snappy-docs#145: deprecation notice number 6 <Created by sergiusens> <https://github.com/canonical-docs/snappy-docs/pull/145> | 19:44 |
| sergiusens | kyrofa refresh if you've opened it, I forgot to `git add` my mods to `index.md` | 19:47 |
| kyrofa | sergiusens, oh good catch on the index | 19:48 |
| === Trevinho is now known as Trevinho|holiday | ||
| === Trevinho|holiday is now known as Trevinho|off | ||
| === anewman is now known as anewman|away | ||
| === anewman|away is now known as anewman | ||
| sergiusens | kyrofa ok, I have satisfied your demands! | 20:07 |
| sergiusens | if you +1 I'll merge | 20:07 |
| sergiusens | kyrofa oh, my write access has been revoked | 20:10 |
| kyrofa | Haha, bam! | 20:10 |
| === anewman is now known as anewman|away | ||
| sergiusens | davidcalle ^ | 20:10 |
| davidcalle | kyrofa: did it? I'm reading the PR | 20:11 |
| davidcalle | kyrofa: sergiusens: has it been revoked for both of you? | 20:12 |
| === JanC is now known as Guest57563 | ||
| === JanC_ is now known as JanC | ||
| kyrofa | davidcalle, I was never cool enough to have it in the first place | 20:12 |
| davidcalle | kyrofa: let's fix this | 20:12 |
| kyrofa | davidcalle, well hey! Thanks! | 20:14 |
| davidcalle | kyrofa: speaking of PR, how do you feel about these link changes: https://github.com/canonical-docs/snappy-docs/pull/136/files (in language guides: "https://forum.snapcraft.io" -> "https://forum.snapcraft.io/t/process-for-reviewing-aliases-auto-connections-and-track-requests/455 " | 20:15 |
| mup | PR canonical-docs/snappy-docs#136: Point forum links in guides at requests guidelines topic <Created by caldav> <https://github.com/canonical-docs/snappy-docs/pull/136> | 20:15 |
| === anewman|away is now known as anewman | ||
| kyrofa | davidcalle, yeah, +1 from me | 20:18 |
| davidcalle | ty | 20:19 |
| === anewman is now known as anewman|away | ||
| kyrofa | Oh my gosh the store is so slow today... I'm getting 80k | 20:27 |
| noise][ | kyrofa - API, download from CDN, ?? | 20:29 |
| noise][ | "store" is a pretty broad term | 20:29 |
| kyrofa | noise][, `snap download` whatever that is | 20:29 |
| noise][ | kyrofa: host 068ed04f23.site.internapcdn.net, and then check traceroutes to the IPs | 20:32 |
| mup | PR snapd#4104 closed: cmd/snap-update-ns: add logging to snap-update-ns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4104> | 20:51 |
| mup | PR snapcraft#1656 closed: integration tests: skip shared ROS test on non-xenial <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1656> | 22:34 |
| sergiusens | snappy-m-o autopkgtest 1650 xenial:amd64 xenial:armhf xenial:arm64 zesty:amd64 zesty:armhf zesty:arm64 artful:amd64 artful:armhf artful:arm64 bionic:amd64 bionic:armhf bionic:arm64 | 22:35 |
| snappy-m-o | sergiusens: I've just triggered your test. | 22:35 |
| mup | PR snapd#4149 opened: tests: new tests for network setup control and observe interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4149> | 22:51 |
| kyrofa | Huh, the bot didn't tell me that the test failed | 23:31 |
| kyrofa | snappy-m-o, github subscribe 1650 | 23:31 |
| snappy-m-o | kyrofa: I'll send you a message if a test fails in the pull request #1650 (Release changelog for 2.35). | 23:32 |
| mup | PR #1650: Merge master onto #1623 to check tests <Created by niemeyer> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1650> | 23:32 |
| kyrofa | Oh man, totally missed that circle CI can do periodic jobs, now! | 23:38 |
| kyrofa | elopio, FYI ^^ | 23:38 |
| kyrofa | elopio, did you also know you could run a job with SSH enabled for debugging? | 23:39 |
| elopio | I didn't know. | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!