| Chipaca | mwhudson: https://github.com/golang/go/commit/91139b87f776a553524b022753981e7909386777 | 00:00 |
|---|---|---|
| Chipaca | and good night | 00:00 |
| yo_ | shouldn't the "requires classic or confinement override | 01:37 |
| yo_ | " error be a "do you want to install classic mode which is blah blah Yes/No" ? | 01:37 |
| === JanC_ is now known as JanC | ||
| mup | PR snapcraft#1371 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1371> | 03:44 |
| icey | is it possible to get builds.snapcraft.io to build a package for which you are not a maintainer? the project has a snapcraft.yaml | 06:36 |
| icey | I've just invited the owner of the repository to collaborate on the snap, but wondering what I can do to help move things forward | 06:37 |
| mpt | icey, GitHub requires someone to be a repo admin (or an organization owner) to set up “webhooks”, which is how build.snapcraft.io detects commits. So you’ll need to persuade a maintainer. | 07:12 |
| mpt | (Details here: <https://help.github.com/articles/about-webhooks/>) | 07:13 |
| icey | lett about persuading mpt, more about coordinating; I think he's in Pacific time, I'm Central European | 07:13 |
| mpt | icey, in the meantime, maybe you could build the snap on your own machine, to make sure it will work when it is set up. :-) | 07:14 |
| icey | mpt I've been building it, I just invited the maintainer to collaborate on it :) `snap install --edge --classic alacritty` ;-) | 07:15 |
| mpt | Ah, good stuff | 07:15 |
| mup | PR snapd#3502 opened: snap-seccomp: add more tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502> | 07:22 |
| Chipaca | moin | 07:34 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#3503 opened: tests: add browser-support interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3503> | 09:11 |
| mvo | fgimenez: hey, quick question - do you have a suggestion how we could test the seccomp-bpf branch against the nested revert test that uncovered the network-manager and bluez issues? its not merged yet but before we merge it it would be great to verify that the bug is actually fixes | 09:53 |
| mvo | fixed | 09:53 |
| fgimenez | hey mvo, sure, the changes in the test for covering the bluez issue are already on master, just merging it in your branch (maybe the changes are already in your branch and this step is not needed) and running after setting the env vars should be enough, i can give it a try | 09:55 |
| fgimenez | wait, we need a core with your changes.. | 09:56 |
| mvo | fgimenez: yeah, thats the issue, could we simply revert to a saved copy of the self-build core or something? | 09:58 |
| mvo | fgimenez: or maybe we need to do it manually, but it would be great to get confirmation | 09:58 |
| fgimenez | mvo: yep after your changes are in master and an edge core is built from it it should be easy but before... we could build a core changing the ppa from wich it picks the debs and uploading there the debs built from your branch (maybe we could do this in the edge branch too?) | 10:01 |
| fgimenez | mvo: once we have a core with the changes from your branch i can change the test to sideload it, should that work (instead of refreshing)? | 10:02 |
| mvo | fgimenez: hm, it all sounds brittle, maybe the best is to do some basic testing manually and then once it is merged to the proper nested run, we want this merged anyway so it should be fine | 10:03 |
| fgimenez | mvo: ok sgtm, how can we test this manually? | 10:03 |
| fgimenez | instead of sideloading we could also upload the core built from your branch to staging and do a proper refresh | 10:07 |
| jacekn | hello! Quick question - I can "snap set <snap> key=val". How do I remove certain config option? There is no "unset" | 10:37 |
| ogra_ | you set it to nothing | 10:41 |
| bloodearnest | so, when installing a snap, systemd units start up before the initial configure hook is run, correct? | 10:48 |
| bloodearnest | is there an install hook or similar thing that runs first, before systemd units are set up? | 10:48 |
| jacekn | ogra_: so that does not seem to work for the kube-apiserver (I used snap set kube-apiserver runtime-config="") | 10:50 |
| jacekn | ogra_: I end up with something like this: --min-request-timeout 300 --runtime-config --service-account-key-file | 10:50 |
| === bloodearnest_ is now known as bloodearnest | ||
| bloodearnest | am I right in thinking that snapctl only works in the configure hook, currently? It seems to fail in any other context anyway | 11:10 |
| mup | PR snapd#3504 opened: interfaces: bring back seccomp argument filtering <Created by mvo5> <https://github.com/snapcore/snapd/pull/3504> | 11:14 |
| mvo | jdstrand: you will like this one -^ :) | 11:15 |
| Chipaca | pstolowski: i think you're the one for answering bloodearnest's question there | 11:15 |
| pstolowski | bloodearnest, hey. correct, services are started before configure hook. install hook that runs before services are started is being reviewed currently - https://github.com/snapcore/snapd/pull/3498 | 11:21 |
| mup | PR snapd#3498: hooks: support for install and remove hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3498> | 11:21 |
| bloodearnest | pstolowski, great, thanks. Any rough idea of when that might be in a release? | 11:22 |
| pstolowski | bloodearnest, also, last week support for using snapctl also from other contexts (from apps in your snap) landed into master | 11:23 |
| === trijntje_ is now known as trijntje | ||
| bloodearnest | pstolowski, awesome | 11:24 |
| pstolowski | bloodearnest, not sure when the next release is, probably 2-3 weeks from now if it lands soon; mvo? | 11:24 |
| mup | PR snapd#3505 opened: PLEASE IGNORE: Enable more tests for suse and fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3505> | 11:35 |
| Facu | Chipaca, et al, I'm running snapd like this: sudo SNAP_TESTING=1 SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 SNAPPY_USE_STAGING_STORE=1 /usr/lib/snapd/snapd | 11:39 |
| Chipaca | Facu: using it to install things, or just to query? | 11:40 |
| Facu | however, I'm not seeing the body responses in the logs, shouldn't I? this is an excerpt of the response: http://linkode.org/#IiLRuuty0L54FkOAgtvKb7 | 11:40 |
| Facu | Chipaca, it's inside a VM, it works! but I lack logging | 11:40 |
| Chipaca | ah | 11:40 |
| Chipaca | Facu: not related: it's SNAPPY_TESTING, not SNAP_TESTING | 11:41 |
| Chipaca | that _should_ work | 11:41 |
| * Chipaca tries it | 11:42 | |
| Facu | Chipaca, but no body logged :/ | 11:42 |
| Chipaca | Facu: can you show me? | 11:42 |
| Chipaca | Facu: i mean, show me the logs you can see | 11:43 |
| Facu | Chipaca, note that I'd want also body in the requests, not only in the responses | 11:43 |
| Facu | Chipaca, yes! | 11:43 |
| Chipaca | Facu: you're not expecting to see the body of a snap download in the logs, are you? | 11:43 |
| Facu | Chipaca, http://linkode.org/#LhT7ABi0DterA4v7hEpZT4 , the activity triggered by a "snap refresh foobar40" | 11:43 |
| Facu | Chipaca, nah, just jsons | 11:44 |
| Chipaca | Facu: I'm seeing the response bodies in the logs, running it the same way you are | 11:45 |
| Facu | :o | 11:45 |
| Chipaca | and 2.22.2 is old, but not _that_ old | 11:45 |
| Chipaca | Facu: in particular: 2017/06/21 12:44:41.973596 logger.go:75: DEBUG: < "HTTP/1.1 404 Not Found\r\nContent-Length: 380\r\nCache-Control: private, max-age=0, no-cache\r\nContent-Type: application/problem+json\r\nDate: Wed, 21 Jun 2017 11:44:42 GMT\r\nServer: Apache/2.4.7 (Ubuntu)\r\nStrict-Transport-Security: max-age=15768000; includeSubDomains; preload\r\nX-Bzr-Revision-Number: 138\r\nX-Vcs-Revision: 138\r\n\r\n{\"detail\":\"no assertion with type | 11:45 |
| Chipaca | \\\"snap-declaration\\\" and key {\\\"series\\\":\\\"16\\\",\\\"snap-id\\\":\\\"99T7MUlRhtI3U0QFgl5mXXESAiSwt776\\\"}\",\"error_list\":[{\"code\":\"not-found\",\"message\":\"not found: no assertion with type \\\"snap-declaration\\\" and key {\\\"series\\\":\\\"16\\\",\\\"snap-id\\\":\\\"99T7MUlRhtI3U0QFgl5mXXESAiSwt776\\\"}\"}],\"status\":404,\"title\":\"not found\",\"type\":\"assertions:v1:not-found\"}\n" | 11:45 |
| Facu | logger.go in DEBUG, I have those | 11:46 |
| Chipaca | yes | 11:46 |
| Chipaca | i can clearly see your log truncated at the \r\n | 11:46 |
| Chipaca | which is strange | 11:46 |
| Chipaca | ie just before the body | 11:47 |
| Chipaca | Facu: what happens if you run the snapd from core directly? | 11:47 |
| Chipaca | iei instead of /usr/lib/snapd/snapd, /snap/core/current/usr/lib/snapd/snapd | 11:47 |
| Facu | Chipaca, let me check; also, for considering... I'm in the VM after doing "lxc exec snapd-staging bash", may it be that my terminal is weird, and the golang library behaves differently? | 11:48 |
| Chipaca | what "golang library" dude | 11:48 |
| Chipaca | :-) | 11:48 |
| Chipaca | all the go bits are static i mean | 11:49 |
| Chipaca | … | 11:49 |
| Chipaca | oh, i got what you meant | 11:49 |
| Facu | Chipaca, logger.go, don't know | 11:49 |
| Chipaca | Facu: try sending it to a file to check that | 11:49 |
| Chipaca | but i seriously doubt it | 11:49 |
| Facu | it logs to stderr | 11:50 |
| Chipaca | yes | 11:50 |
| Facu | Chipaca, no luck (running core and/or into a file) | 11:50 |
| Chipaca | grmbl | 11:51 |
| Facu | this are the situations where I value a lot editing some /usr/lib/whatever system file and putting a print() there :p | 11:52 |
| Chipaca | Facu: this should be just as easy once you've got it set up to build | 11:53 |
| Chipaca | ie something like 'go build -o /tmp/srv ./cmd/snapd && SNAPPY_yadda … /tmp/srv' | 11:54 |
| Chipaca | but, yes, not python | 11:54 |
| Facu | Chipaca, yes, but in that case I'm not using *what is installed* | 11:54 |
| Chipaca | well... you're using 2.26.3+git410.g6e6bfcc which is pretty funky | 11:55 |
| Chipaca | :-) | 11:55 |
| Chipaca | Facu: what happens if you force it to use the one in /usr/lib? | 11:55 |
| Facu | Chipaca, isn't that what I'm doing when running /usr/lib/snapd/snapd ? | 11:56 |
| Chipaca | Facu: sudo SNAP_REEXEC=0 SNAPPY_TESTING=1 SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 SNAPPY_USE_STAGING_STORE=1 /usr/lib/snapd/snapd | 11:56 |
| Facu | still no luch | 11:57 |
| Facu | *luck | 11:57 |
| Chipaca | phew | 11:57 |
| Chipaca | Facu: can you check whether this works outside of the vm (but not pointing to staging)? | 11:57 |
| Facu | Chipaca, it works fine in my host machine | 11:57 |
| Chipaca | o...k | 11:57 |
| Facu | Chipaca, maybe updating snapd? | 11:58 |
| Chipaca | Facu: updating to what? | 11:58 |
| Facu | Chipaca, latest version? no idea | 11:58 |
| Chipaca | Facu: you ran the one from core already | 11:58 |
| Chipaca | that's the latest | 11:58 |
| Chipaca | Facu: and i have never seen this behaviour since I added support for the 3rd bit | 11:59 |
| Chipaca | give me a bit though | 11:59 |
| mup | PR snapcraft#1372 opened: cli: Containerbuild clean <bug> <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1372> | 12:00 |
| Chipaca | Facu: what distro is snapd-staging? | 12:00 |
| Facu | Chipaca, I'm not *blocked* for this right now (may really needed it later) but I'm happy to help you testing and trying stuff | 12:00 |
| Facu | Chipaca, xenial, 16.04.2 | 12:00 |
| Chipaca | Facu: no idea then | 12:01 |
| Chipaca | Facu: if you can give me steps to reproduce this i'll give it a poke this afternoon | 12:01 |
| Facu | Chipaca, created an lxc as specified in https://docs.google.com/document/d/1MSThKrO762SgeY2lw74R5lcA7oQjTtq1ifYNut18bho/edit#heading=h.7f3zvinx0gcg under "snapd" and entered into it with "lxc exec snapd-staging bash" | 12:06 |
| Facu | Chipaca, and thanks | 12:08 |
| === Tryum_ is now known as Tryum | ||
| Chipaca | Facu: the github gist that doc points to is 404 for me | 12:24 |
| Facu | Chipaca, why people uses gist and not linkode!? | 12:25 |
| Chipaca | Facu: access control? revision history? group and team membership? Faster page loads? https by default? | 12:26 |
| Facu | Chipaca, oh, I wonder why linkode does not redirects to 443 | 12:27 |
| mvo | bloodearnest: we are currently working on an important fix in snapd, once that lands (the goal is this week), then normal 2 week schedule for snapd releases resumes | 12:28 |
| bloodearnest | mvo, ack, tx | 12:28 |
| ogra_ | ppisati, when i patch a dts in the tree and re-build the package, is anything in the build env reverting my change ? i dont get the new devices in the dtb | 12:29 |
| ogra_ | (i didnt run "fdr clean" to save time, would that be needed ?) | 12:30 |
| === chihchun is now known as chihchun_afk | ||
| ppisati | ogra_: nothing reverts stuff in the tree, and it should call 'make dtb' at the end, so you should get the 'new' dtb | 13:12 |
| ppisati | unless there's a bug, of course | 13:12 |
| ppisati | ogra_: which tree? | 13:12 |
| ogra_ | master-next ... i'm trying to add a sun8i-emac driver http://paste.ubuntu.com/24916775/ | 13:13 |
| ppisati | ogra_: artul? | 13:13 |
| ppisati | *artful? | 13:13 |
| ogra_ | yep | 13:13 |
| ppisati | ogra_: let me try that | 13:14 |
| ogra_ | ppisati, well, fdr clean seems to have helped, now i see ethernet0 | 13:15 |
| * ogra_ checks if he also sees it after u-boot :P | 13:16 | |
| ogra_ | [ 12.387103] sun8i-emac 1c30000.ethernet (unnamed net_device) (uninitialized): No associated PHY | 13:16 |
| ogra_ | aha | 13:16 |
| ogra_ | seems i'm close :) | 13:16 |
| mup | Bug #1699504 opened: "network" plug does not allow outbound ping <Snappy:New> <https://launchpad.net/bugs/1699504> | 13:20 |
| ogra_ | hmm,, thats a bit annoying that it makes everything so time consuming | 13:21 |
| abeato | ppisati, ogra_ is it possible to force building with a given gcc version a kernel snap? | 13:31 |
| ogra_ | abeato, i guess you can force one in build-packages | 13:32 |
| ogra_ | but indeed only the ones available in xenial | 13:32 |
| mup | PR snapcraft#1373 opened: Add support in snapcraft yaml for reload-command directive <Created by bloodearnest> <https://github.com/snapcore/snapcraft/pull/1373> | 13:33 |
| abeato | ogra_, ok, will give a try, thanks | 13:33 |
| mup | PR snapd#3490 closed: client, daemon: using oddjobstate, implement service operations <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3490> | 13:33 |
| ppisati | abeato: uhm, not that i'm aware | 13:35 |
| abeato | ppisati, ok, nw | 13:35 |
| davidcalle | Chipaca: hey, I've just noticed a store snap with an empty publisher field in snap info, is that supposed to happen in some edge cases? | 13:40 |
| Chipaca | davidcalle: what snap? | 13:41 |
| davidcalle | snap info peek | 13:41 |
| fgimenez | mvo: quick question, is SNAPPY_USE_STAGING_STORE enough for ubuntu-image to use staging? the underlying prepare-image is going to honor it, right? | 13:49 |
| jdstrand | mvo: hey, so I'm going to flesh out the password-manager-service policy next. you have a PR already that I figured I'd build on. how do you want to coordinate that work? | 13:53 |
| pedronis | fgimenez: it needs snap built for staging | 13:54 |
| pedronis | because of keys for checking assertions | 13:55 |
| fgimenez | pedronis: aha, great thx, i'll change the test to have that into account to (and eventually build snap if needed) | 13:58 |
| mvo | fgimenez: I think so, yes | 14:01 |
| mvo | jdstrand: you can have the password-manager-service, either branch from it and push a new PR and I close mine - or just push to my PR. but if its a lot of churn I think branch, new PR is better | 14:01 |
| Chipaca | niemeyer: taking this logs things to its natural conclusion, i think i'll make systemd.Logs (which nobody else uses) return an io.Reader | 14:04 |
| jdstrand | mvo: ack, thanks. I'll do a new PR I think | 14:04 |
| Chipaca | davidcalle: I don't see it having an empty publisher here | 14:04 |
| Chipaca | davidcalle: what are you seeing? | 14:04 |
| niemeyer | Chipaca: Yeah, that seems reasonable | 14:06 |
| niemeyer | Chipaca: The other option would be to pass in a writer, but that's perhaps less natural | 14:07 |
| davidcalle | Chipaca: I think I figured out what happened. I had a homemade snap of the same name locally installed, which gave me: | 14:09 |
| davidcalle | https://usercontent.irccloud-cdn.com/file/ZZJolLOW/Screenshot%20from%202017-06-21%2016-09-10.png | 14:09 |
| Chipaca | davidcalle: yep, x revisions don't have a publisher | 14:10 |
| Chipaca | because they're not published :-) | 14:10 |
| davidcalle | Chipaca: yeah, but snap info picked up channel data from the store snap :) | 14:10 |
| Chipaca | yeah | 14:10 |
| davidcalle | Hence, the confusion | 14:10 |
| Chipaca | davidcalle: suggestions for making this difference clearer very much accepted | 14:10 |
| davidcalle | Chipaca: what about "tracking: local" when there is no tracking info available, hence not in the store ? | 14:14 |
| Chipaca | that kinda makes sense :-) | 14:14 |
| Chipaca | niemeyer: what do you think? | 14:14 |
| niemeyer | It's not actually tracking local.. it's not really tracking anything since it won't ever update without manual action | 14:16 |
| niemeyer | Chipaca: Given the above picture, the magic dash seems fitting | 14:16 |
| niemeyer | As in, it's what we used to mean "there's nothing there" in the channels | 14:17 |
| davidcalle | +1 | 14:17 |
| Chipaca | niemeyer: consider it done | 14:18 |
| Chipaca | and by "it" I obviously mean using “ヽ( ͡͡ ° ͜ ʖ ͡ °)⊃━☆ﾟ. * ･ ｡ﾟ” to signify the above | 14:18 |
| mup | PR snapd#3472 closed: interfaces, tests: add mising dbus abstraction to system-observe and extend spread test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3472> | 14:18 |
| Chipaca | niemeyer: hopping subjects again, what needs to happen so shellcheck is available on the linode that runs the static tests? (that's a ubuntu-16.04-64) | 14:22 |
| niemeyer | Chipaca: Is that a deb package in the archive? | 14:23 |
| Chipaca | niemeyer: yes but not in xenial (we'd need the one from yakkety at least) | 14:23 |
| Chipaca | niemeyer: (it's usable directly, if you install the deb in the image directly for example) | 14:24 |
| Chipaca | niemeyer: http://mirrors.kernel.org/ubuntu/pool/universe/s/shellcheck/shellcheck_0.4.4-2_amd64.deb | 14:24 |
| niemeyer | Chipaca: Okay, so best route is likely to wait for cachio's PR to go in, so he doesn't need to fix that again (it's centralizing all package installs), and then it'll get included in the big image rebundling that I'll need to do for moving those installs out of the suite altogether | 14:26 |
| Chipaca | niemeyer: neat | 14:27 |
| Chipaca | niemeyer: this will make master fail right now | 14:27 |
| Chipaca | because a number of things have crept in | 14:27 |
| Chipaca | still, easy to fix once we're there | 14:27 |
| Chipaca | some are actual bugs :-/ | 14:27 |
| === chihchun_afk is now known as chihchun | ||
| === mup_ is now known as mup | ||
| mup | PR snapd#3506 opened: asserts: introduce NewDecoderWithTypeMaxBodySize <Created by pedronis> <https://github.com/snapcore/snapd/pull/3506> | 14:51 |
| mvo | Chipaca: hey, zyga pointed me to you for this issue https://forum.snapcraft.io/t/edge-beta-revert-fails/1072 - he said you know more about this | 14:51 |
| mvo | Chipaca: this will be a blocker for 2.27 | 14:53 |
| * Chipaca looks | 14:53 | |
| Chipaca | mvo: I think he confuses "it happened to me a lot and drove me bonkers" with "knows more" | 14:54 |
| mvo | Chipaca: lol | 14:54 |
| ogra_ | ogra@orangepi-zero:~$ snap list | 14:54 |
| ogra_ | Name Version Rev Developer Notes | 14:54 |
| ogra_ | core 16-2.26.4+git245.a96842e 2212 canonical - | 14:54 |
| ogra_ | linux-generic-allwinner 4.11.0-7.12 x1 - | 14:54 |
| ogra_ | orangepi-zero 16-0.1 x1 - | 14:54 |
| ogra_ | \o/ | 14:54 |
| Chipaca | mvo: but i thought he'd fixed this? | 14:54 |
| pedronis | I thought it was fixed as well | 14:54 |
| mvo | Chipaca: well, he said he did but then he said he did not | 14:54 |
| * Chipaca looks at his prs | 14:54 | |
| Chipaca | mvo: ah | 14:55 |
| mvo | Chipaca: he said the wrong snap-update-ns is used, but I'm not fully understanding why, at this point current should still point to the "good" snap-update-ns from edge with his fix | 14:56 |
| Chipaca | mvo: in what scenario is "current" the wrong one to use? | 14:56 |
| mvo | Chipaca: in my failure scenario I go from edge to beta and edge is supposed to have the latest code but maybe something else is going on, I stumbled over this by accident I really want to test my seccomp-bpf work | 14:57 |
| mvo | Chipaca: i.e. the latest code that contains the fix | 14:58 |
| mup | PR snapcraft#1316 closed: Run unit tests on Travis with mock armhf <Created by kalikiana> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1316> | 15:27 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#3507 opened: many: backport of seccomp-bpf branch (#3431) to the 2.26 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3507> | 16:14 |
| morphis | mvo, pedronis, niemeyer: where does snapd take the CA certificates from? Is it tied with openssl and the ca-certificates database for HTTPS access? | 16:22 |
| morphis | and I guess you don't use certificate pinning yet, right? | 16:22 |
| === cachio is now known as cachio_afk | ||
| ogra_ | ogra@localhost:~$ snap list | 16:40 |
| ogra_ | Name Version Rev Developer Notes | 16:40 |
| ogra_ | core 16-2.26.4+git245.a96842e 2212 canonical - | 16:40 |
| ogra_ | linux-generic-allwinner 4.11.0-7.12 x1 - | 16:40 |
| ogra_ | nanopi-neo 16-0.1 x1 - | 16:40 |
| ogra_ | and the next one :) | 16:40 |
| === wililupy_ is now known as wililupy | ||
| niemeyer | morphis: I recall a recent change that moved CA lookup into the core snap | 17:01 |
| morphis | ah! | 17:01 |
| niemeyer | morphis: It's been such a long time since we managed to get a release all the way into stable due to the revert issues being worked on that I don't know if that's there or not | 17:02 |
| morphis | niemeyer: I just have somebody who does certificate substituion on a proxy and wonders why things aren't working :-) | 17:02 |
| morphis | he claimed to have extended ca-certificates but if it's in the core snap that does help | 17:02 |
| niemeyer | morphis: Wait.. certificate substitution on a proxy? | 17:02 |
| morphis | don't ask me, a bad idea | 17:03 |
| morphis | which will break anyway once we pin the certificates | 17:03 |
| niemeyer | Yeah, we should probably do that sooner now that you mention it :) | 17:03 |
| morphis | niemeyer: hehe | 17:05 |
| Chipaca | pedronis: if you're still there, what content type do you use for "a series of json documents"? | 17:14 |
| Chipaca | application/json-seq | 17:16 |
| pedronis | Chipaca: we don't anywhere | 17:19 |
| pedronis | atm, afaik | 17:20 |
| niemeyer | Yeah, that sounds suspect | 17:20 |
| pedronis | we return objects with arrays inside | 17:20 |
| pedronis | Chipaca: what had you in mind? | 17:21 |
| Chipaca | pedronis: streaming journalctl output | 17:22 |
| pedronis | we don't stream json anywhere | 17:22 |
| pedronis | atm | 17:22 |
| Chipaca | right | 17:22 |
| Chipaca | i think we'd looked into this a bit, but probably for long poll or whatever it's called | 17:23 |
| === jaggz- is now known as jaggz | ||
| Chipaca | niemeyer: suspect how? | 17:25 |
| pedronis | Chipaca: ah, we might have done something for u1db but it was fully adhoc I think | 17:27 |
| pedronis | with our own mimetype | 17:27 |
| === cachio_afk is now known as cachio | ||
| mvo | morphis: there is a PR that needs to be resurrected for cert pinning https://github.com/snapcore/snapd/pull/2316 - its mostly about how we distribute the cert updates at this point, probably via assertions but we need to flesh out details | 17:46 |
| mup | PR snapd#2316: store: add basic certificate pinning <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2316> | 17:46 |
| ogra_ | erm | 17:53 |
| ogra_ | ogra@nanopi-neo:~$ ps ax|grep user | 17:53 |
| ogra_ | 1742 ? Ss 0:00 /lib/systemd/systemd --user | 17:53 |
| ogra_ | we do spawn a --user session on core ? | 17:53 |
| * ogra_ wonders why | 17:53 | |
| mup | PR snapd#3508 opened: tests: shellcheck improvementes for lib scripts <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3508> | 18:20 |
| * ogra_ glares at https://forum.snapcraft.io/t/certificate-substitution-and-snaps/1077 ... | 18:50 | |
| ogra_ | i suspect we'd need the ability to add certificates to the core snap dynamically | 18:51 |
| === wxl_ is now known as wxl | ||
| pedronis | mvo: also wgrant had a counter proposal on that | 19:02 |
| pedronis | at the last sprint | 19:02 |
| niemeyer | pedronis: mvo isn't here | 19:25 |
| niemeyer | Chipaca: It was just a dumb gut feeling which I shouldn't have mentioned.. it probably makes sense to do that if you want to stream logs | 19:26 |
| Chipaca | niemeyer: i agree it's weird and strange and i'm not super enamoured with it | 19:27 |
| Chipaca | niemeyer: but streaming json leaves few options | 19:27 |
| Chipaca | so, yeah | 19:27 |
| mup | PR snapcraft#1374 opened: tests: set up the spread execution in linode <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1374> | 19:27 |
| niemeyer | Chipaca: Yeah, I think it's nice.. it means we can have more interesting semantics through that pipeline | 19:27 |
| niemeyer | Chipaca: We just need to be a bit careful to establish a nice pattern that can be reused for other cases soon | 19:28 |
| niemeyer | But it's worth going over it | 19:28 |
| Chipaca | semantics, schmemantics, i want icecream | 19:28 |
| Chipaca | :-) | 19:28 |
| Chipaca | but, yes. consciously not working on it now though (hadn't realised my irc was still connected) | 19:29 |
| niemeyer | Chipaca: It wasn't until recently :) | 19:29 |
| mup | PR snapd#3435 closed: interfaces: add password-manager-service implicit interface <Created by mvo5> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3435> | 20:27 |
| cachio | Chipaca, are you able to rerun the failed autopkgtest on there? https://github.com/snapcore/snapd/pull/3494 | 20:32 |
| mup | PR snapd#3494: tests: restart rng-tools services after few seconds <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3494> | 20:32 |
| mup | PR snapd#3494 closed: tests: restart rng-tools services after few seconds <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3494> | 21:07 |
| mup | PR snapd#3509 opened: tests: shellcheck improvements for tests/nested tasks <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3509> | 21:32 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#3510 opened: tests: shellcheck improvements for nightly upgrade and regressions tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3510> | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
