| kyrofa | That makes the snapd suite far more than just hello-type snaps | 00:00 |
|---|---|---|
| kyrofa | But I'm fine with it as long as running the snaps doesn't add a lot of time | 00:01 |
| elopio | kyrofa: some of them should be in the plugins integration suite, right? | 00:01 |
| elopio | the ones that don't require execution. | 00:01 |
| kyrofa | Yeah that would be better... but then we have problems :P | 00:02 |
| kyrofa | Just trying to figure out what we want to do about snapcraft#1717 | 00:02 |
| mup | PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717> | 00:02 |
| elopio | kyrofa: I haven't seen that plainbox error before, but permission denied in tmp isn't it the same we get in ruby? | 00:04 |
| kyrofa | elopio, I've never seen that for ruby, I just saw an inability to find rbconfig.rb | 00:04 |
| elopio | kyrofa: http://paste.ubuntu.com/25954649/ line #4 | 00:06 |
| kyrofa | elopio, that's probably shebang rewriting etc. Yeah, not sure why permission would be denied there | 00:06 |
| kyrofa | But it's a separate issue from the breakage a few lines below | 00:07 |
| kyrofa | (which I've fixed) | 00:07 |
| kyrofa | elopio, note that I see those warnings as well | 00:08 |
| kyrofa | (just checked) | 00:08 |
| kyrofa | elopio, looks like ruby sets gems to 444 (read-only) | 00:09 |
| kyrofa | So, non-fatal indeed | 00:09 |
| kyrofa | We can ignore those | 00:09 |
| === mwhudson_ is now known as mwhudson | ||
| elopio | kyrofa: ahh, I was looking at the wrong place then. Where are you getting those plainbox errors? to try to reproduce | 00:13 |
| kyrofa | elopio, on xenial, adt running in xenial lxc | 00:13 |
| kyrofa | I'll be running another one in a minute, see if it happens again or if it was a fluke of some kind | 00:13 |
| elopio | kyrofa: amd64? | 00:14 |
| kyrofa | elopio, yes indeed, sorry | 00:14 |
| elopio | yeah, I haven't seen that one. | 00:14 |
| kyrofa | sergiusens, elopio, both of those PRs depend on making a call on where we want that test to be | 00:16 |
| kyrofa | I vote for leaving it alone until we can split the plugins suite | 00:17 |
| elopio | kyrofa: +1. Make the move after we have the reorg branch, probably to snapcraft/integration/plugins/catkin | 00:21 |
| elopio | the hard part is to define where to put all the ones that are not catkin, naming those directories "general" is kind of sad. | 00:22 |
| elopio | maybe, we can make a filter, and run everything except catkin. | 00:22 |
| kyrofa | elopio, hmm, aren't the filters regex though? | 00:23 |
| elopio | kyrofa: they could be. | 00:23 |
| kyrofa | Negative regex gets gross | 00:24 |
| elopio | yes. I don't have a solution for this, but I'm happy to push it for later. | 00:25 |
| sergiusens | reorgs later | 00:25 |
| kyrofa | Good | 00:26 |
| kyrofa | I'll run a zesty test on 1717 | 00:26 |
| kyrofa | elopio, thanks for the --setup-commands hint, by the way. I'll propose that for our testing doc once this release is out the door | 00:31 |
| kyrofa | Running 1719 zesty:amd64 on my server as well | 00:41 |
| kyrofa | elopio, how do you feel about upping the ROS timeouts for arm adt? | 00:41 |
| elopio | kyrofa: I'm ok with that | 00:44 |
| kyrofa | Every time it happens they're priming or snapping, so we're so close | 00:44 |
| kyrofa | It also means it's not a legit hang, it's just taking a little longer | 00:44 |
| elopio | kyrofa: also, they can be moved to integration tests, right? | 00:44 |
| kyrofa | elopio, oh, are we talking about the demos? | 00:45 |
| kyrofa | elopio, yes they can, but then we run into the same question of where to put them | 00:45 |
| kyrofa | Seems pointless to move them until we have a place they can stay | 00:46 |
| elopio | kyrofa: they will be slow snapd integration tests, so they will only run on adt | 00:47 |
| kyrofa | Oh riiight | 00:47 |
| elopio | we haven't set a timeout for those, but we probably should. | 00:47 |
| kyrofa | I'd still rather just tweak the timeouts here so I don't need to retest them | 00:48 |
| kyrofa | (for release I mean) | 00:48 |
| elopio | kyrofa: ah, yes, for now, just bump that. | 00:51 |
| elopio | I would hate to cause a timeout in a different place, again. | 00:51 |
| kyrofa | No kidding | 00:51 |
| kyrofa | I just wanna get this thing out the door | 00:51 |
| mup | PR snapcraft#1731 opened: demo tests: bump catkin timeout by ten minutes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1731> | 00:58 |
| kyrofa | elopio, ^ | 00:58 |
| sergiusens | kyrofa elopio fwiw I am not fond of timeouts | 01:42 |
| * sergiusens looks for a clever blog post with why | 01:42 | |
| sergiusens | meh, I cannot find any. I wouldn't use timeouts on test hardware that is shared or out of our control | 01:44 |
| sergiusens | there are so many things that can go wrong | 01:44 |
| mup | PR snapd#4211 opened: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4211> | 02:22 |
| kyrofa | sergiusens, fine by me, they do cause issues | 02:28 |
| kyrofa | sergiusens, we can remove them after this release, when we slurp them into the snapd suite | 02:29 |
| kyrofa | (which doesn't have timeouts) | 02:29 |
| kyrofa | (at least, I don't think they do. Maybe they have shorter timeouts though, we'll have to check) | 02:29 |
| sergiusens | kyrofa \o/ | 02:38 |
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| kyrofa | sergiusens, bug #1732065 is probably for you | 03:32 |
| mup | Bug #1732065: dotnetplugin: use of xenial-only stage-packages <Snapcraft:New> <https://launchpad.net/bugs/1732065> | 03:32 |
| sergiusens | kyrofa heh, the dotnet plugin will not work on anything but xenial | 03:33 |
| kyrofa | sergiusens, alrighty, more skips! | 03:33 |
| sergiusens | kyrofa seems the tests for snapcraft#1730 went rather well | 03:35 |
| mup | PR snapcraft#1730: ruby plugin: be smarter about arch-specific paths <bug> <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1730> | 03:35 |
| kyrofa | snappy-m-o, autopkgtest 1731 xenial:armhf | 03:35 |
| snappy-m-o | kyrofa: I've just triggered your test. | 03:36 |
| kyrofa | sergiusens, armhf is red, let me see... | 03:36 |
| kyrofa | Ugh. Network problems | 03:37 |
| sergiusens | kyrofa ros test and python, network related and unrelated to this, but please double check | 03:37 |
| kyrofa | sergiusens, indeed, both network related | 03:37 |
| sergiusens | kyrofa is snapcraft#1717 good when looking at the errors? | 03:38 |
| mup | PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717> | 03:38 |
| kyrofa | sergiusens, for zesty anyway, yeah. But that skips some tests... would sure like xenial armhf to run | 03:39 |
| kyrofa | But then we hit the timeout issue | 03:39 |
| sergiusens | kyrofa is that the 10 thing? | 03:40 |
| kyrofa | sergiusens, yep | 03:40 |
| kyrofa | armhf is running there now | 03:40 |
| kyrofa | Or queued at least | 03:40 |
| sergiusens | kyrofa be more ambitious, triple it | 03:40 |
| kyrofa | Hahaha | 03:40 |
| kyrofa | You got it | 03:40 |
| sergiusens | as if there were no timeout | 03:40 |
| sergiusens | really | 03:40 |
| sergiusens | I asked elopio a year ago to remove these timeouts | 03:40 |
| sergiusens | the only thing we do when we reach them is increase it | 03:40 |
| mup | PR snapcraft#1730 closed: ruby plugin: be smarter about arch-specific paths <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1730> | 03:40 |
| sergiusens | and we already have the timeouts imposed by the machinery running the tests anyways | 03:41 |
| kyrofa | snappy-m-o, autopkgtest 1731 xenial:armhf | 03:43 |
| snappy-m-o | kyrofa: I've just triggered your test. | 03:43 |
| kyrofa | sergiusens, done | 03:43 |
| sergiusens | great | 03:44 |
| kyrofa | sergiusens, my adt run on snapcraft#1719 blew up, unfortunately, it seems like it doesn't like running in nested containers. I'm starting it again here, but it takes about two hours | 03:47 |
| mup | PR snapcraft#1719: many: account for python shebang args in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719> | 03:47 |
| kyrofa | (zesty:amd64) | 03:47 |
| kyrofa | Would be nice to see xenial:armhf there as well but there seems little point in queuing that up until the timeout fix lands | 03:48 |
| kyrofa | I'll check back in a bit | 03:49 |
| sergiusens | kyrofa one sec | 03:49 |
| sergiusens | can you review something real quick? | 03:49 |
| kyrofa | Sure | 03:49 |
| sergiusens | kyrofa #1732 | 03:50 |
| mup | PR #1732: many: respect dirs.SnapSnapsDir in tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1732> | 03:50 |
| sergiusens | kyrofa hmph, snapcraft#1732 | 03:50 |
| mup | PR snapcraft#1732: tests: dotnet only works on 16.04 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1732> | 03:50 |
| kyrofa | sergiusens, haha, I got it. Always gets ya, though! | 03:51 |
| sergiusens | kyrofa I am doing it on purpose sometimes, maybe enough "incorrect" people get pinged that it gets removed as the implicit default :-P | 03:51 |
| kyrofa | Hahahahaha | 03:51 |
| kyrofa | sergiusens, +1 | 03:52 |
| kyrofa | Alright, back soon | 03:52 |
| mup | PR snapcraft#1732 opened: tests: dotnet only works on 16.04 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1732> | 03:52 |
| HazWard | Is there a guide to package Wine programs into snaps? I want to try out some windows programs but I don't want to have all those dependencies | 03:57 |
| mup | Issue snapcraft#1492 closed: Support for advanced filtering for build-packages <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1492> | 04:38 |
| sergiusens | snappy-m-o autopkgtest 1732 artful:amd64 | 04:40 |
| snappy-m-o | sergiusens: I've just triggered your test. | 04:40 |
| ikey | had to push a fix to the full-nvidia-support PR | 04:43 |
| ikey | turns out Ubuntu uses a slightly different filename convention for vulkan ICDs (it doens't start with 10_ so i glob without the 10 now..) | 04:43 |
| kyrofa | Tests still running... | 05:38 |
| kyrofa | The timeout-increasing PR has its armhf run going though, looks like | 05:41 |
| kyrofa | I suspect things will come together tomorrow | 05:41 |
| mup | PR core#64 opened: 30-fix-timedatectl.chroot: fix quoting issues <Created by mvo5> <https://github.com/snapcore/core/pull/64> | 06:50 |
| * zyga-ubuntu is doing some tax work in the morning, sorry about that | 07:45 | |
| mup | PR snapd#4212 opened: tests/interfaces-network-control-tuntap: disable on debian-unstable for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/4212> | 08:21 |
| zyga-ubuntu | mvo: hint: all of debian unstable is broken | 08:23 |
| zyga-ubuntu | mvo: because of https://forum.snapcraft.io/t/snapd-2-27-6-2-in-debian-sid-blocked-on-apparmor-in-kernel-4-13-0-1/2813/12 | 08:24 |
| zyga-ubuntu | mvo: so perhaps we need to refresh the debian image and fix this for real, disabling all of debian while this happens | 08:24 |
| mvo | zyga-ubuntu: I see only the failures in tun/tap so far | 08:25 |
| mvo | zyga-ubuntu: but those are quite consitent | 08:25 |
| zyga-ubuntu | mvo: what is the error there? | 08:26 |
| mvo | zyga-ubuntu: permission denied | 08:26 |
| mvo | zyga-ubuntu: I have not checked (yet) for the details, just want to unblock master for now | 08:27 |
| mvo | zyga-ubuntu: there are some PRs ready otherwise | 08:27 |
| pedronis | pstolowski: hi, I re-reviewed #4158 | 08:55 |
| mup | PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158> | 08:55 |
| pstolowski | pedronis, ty | 08:57 |
| mvo | pedronis: hey, good morning. can I run an idea by you? I have created https://github.com/snapcore/snapd/compare/master...mvo5:refresh-candidates-managed?expand=1 as a starting point for the work for the refresh.schedule=managed PR. my idea was that if the refresh schedule is managed there is code that calls store.ListRefresh() with the RefreshControlManaged flag. do you think this makes sense or would you suggest a different approach? | 09:06 |
| mvo | also 4212 would unblock master | 09:07 |
| mvo | if it gets reviews | 09:07 |
| mup | PR snapd#4212 closed: tests/interfaces-network-control-tuntap: disable on debian-unstable for now <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4212> | 09:07 |
| * mvo hugs zyga | 09:07 | |
| mvo | zyga-ubuntu: lets try to merge in a controlled way so that we don't cause a travis congestion | 09:08 |
| zyga-ubuntu | mvo: ok, let's coordinate here | 09:08 |
| mvo | zyga-ubuntu: I will push 4204 as this should be ready now | 09:09 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/4207 can land | 09:09 |
| mup | PR #4207: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207> | 09:09 |
| mvo | zyga-ubuntu: also 4202 | 09:09 |
| zyga-ubuntu | 4202 has some comments | 09:09 |
| zyga-ubuntu | if you add those that's fine | 09:09 |
| mvo | zyga-ubuntu: I think he addressed them, no? | 09:10 |
| pedronis | mvo: we are trying not do add new headers | 09:10 |
| pedronis | because we are redesigning all of them | 09:10 |
| mvo | pedronis: aha, happy to use json then, any suggestions for a straw-man? | 09:10 |
| pedronis | mvo: I mean it's ok if first iteration doesn't flag this anyway | 09:11 |
| pedronis | it's really a question for cprov tbh | 09:11 |
| mvo | pedronis: what the json should look like | 09:11 |
| mvo | pedronis: oh, you mean in the first iteration we don't need this flag send? fair enough, I can hold back then if it does not make sense to add it at this point (because of the store API work) | 09:12 |
| pedronis | mvo: I don't know, the issue is also that if we send something like this probably we need to send it with all calls | 09:12 |
| pedronis | not just the extra calls | 09:12 |
| mvo | pstolowski, zyga-ubuntu: is there anything controversial in 4120? it looks quite mechanical, if this is the agreed interface it seems we want to merge it. or does it need a gustavo +1? | 09:12 |
| pedronis | mvo: I don't think it make sense to add a flag without discussing how it will be used | 09:13 |
| pedronis | for that we probably need cprov | 09:13 |
| mvo | pedronis: all refresh calls or all all calls, i.e. install etc as ewll? | 09:13 |
| pedronis | all refresh calls at least | 09:13 |
| pedronis | but see general point | 09:13 |
| zyga-ubuntu | mvo: I'll look in a sec | 09:13 |
| mvo | pedronis: adding it to all refresh calls was my plan, but happy to hold off for now and discuss wider first. sorry for the rush, was mostly because we want the managed mode in 2.30 but if we can life without the flag for v1 all is well | 09:14 |
| mvo | pedronis: I followup in the forum | 09:14 |
| pstolowski | mvo, i hope there is nothing controversial | 09:17 |
| pedronis | that was the agreed direction, Permanent takes Info sanitized at read time | 09:18 |
| Chipaca | mo'in | 09:19 |
| mvo | pedronis: great, then its just a second review and it can go in. thanks for your feedback | 09:19 |
| mvo | hey Chipaca | 09:19 |
| pedronis | mvo: yes, please write something in the topic | 09:19 |
| ackk | Chipaca, hi, could you please have another look at https://github.com/snapcore/snapd/pull/3916 ? I think I addressed the remaining comments | 09:20 |
| mup | PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916> | 09:20 |
| Chipaca | sure | 09:21 |
| ackk | thanks | 09:21 |
| cprov | mvo, pedronis: Hi! how can I help ? | 09:25 |
| mvo | cprov: hey, good morning | 09:25 |
| cprov | mvo: morning | 09:26 |
| mvo | zyga-ubuntu: you did say that you want to have a look at 4207, right? | 09:28 |
| mvo | zyga-ubuntu: it has two +1 already but you are the expert in this area so your review will certainly not hurt :) | 09:28 |
| zyga-ubuntu | mvo: I will look again and merge it | 09:30 |
| zyga-ubuntu | thank you :) | 09:30 |
| * zyga-ubuntu is almost done with taxes | 09:31 | |
| zyga-ubuntu | mvo: +1 to land https://github.com/snapcore/snapd/pull/4120 | 09:40 |
| mup | PR #4120: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120> | 09:40 |
| pstolowski | thanks1 | 09:42 |
| mup | PR snapcraft#1731 closed: demo tests: bump catkin timeout by a lot <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1731> | 09:45 |
| mup | PR snapd#4120 closed: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4120> | 09:46 |
| mup | PR core#64 closed: 30-fix-timedatectl.chroot: fix quoting issues <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/64> | 09:52 |
| sergiusens | snappy-m-o autopkgtest 1717 xenial:armhf | 10:01 |
| snappy-m-o | sergiusens: I've just triggered your test. | 10:01 |
| * zyga-ubuntu goes to the doctor with his son | 10:09 | |
| Chipaca | ackk: +1; merged | 10:11 |
| Chipaca | ackk: thank you! | 10:11 |
| mup | PR snapd#3916 closed: snap,wrappers: add support for socket activation <Created by albertodonato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3916> | 10:11 |
| ackk | Chipaca, \o/ thanks :) | 10:11 |
| ackk | Chipaca, are the blockers for the snapcraft PR to alow that syntax? | 10:12 |
| Chipaca | ackk: je ne sais pas | 10:16 |
| Chipaca | ackk: that's a snapcrafter question :-) | 10:16 |
| Chipaca | (i haven't been following that particular thing) | 10:16 |
| Chipaca | ackk: have you checked with review tools also? | 10:16 |
| ackk | Chipaca, wdym? | 10:20 |
| ackk | yeah I should probably ask kyrofa about that one | 10:21 |
| ackk | (https://github.com/snapcore/snapcraft/pull/1617 FTR) | 10:21 |
| mup | PR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617> | 10:21 |
| Chipaca | ackk: there's a sanity checker / enforcer that's run as part of a store upload that might block this (i don't know, but somebody should check) | 10:23 |
| Chipaca | ackk: it used to be called click-review-tools (it might still be called that) | 10:23 |
| ackk | I see | 10:23 |
| Chipaca | rabble rabble proud heritage rah rah | 10:24 |
| cjwatson | Chipaca: hey, so man pages :-) I've been putting some weekend/evening time into getting man-db set up with apparmor and seccomp | 10:45 |
| cjwatson | Chipaca: at the moment the state of play is that I've got committed-but-not-uploaded changes to add an apparmor profile to /usr/bin/man that confines various groff-related processes that it starts, plus decompressors and other misc filters | 10:46 |
| cjwatson | Chipaca: I've also got work in progress to do seccomp confinement in other simpler cases - groff can't really be seccomp-confined because we need to be able to do path filtering (to let it open temp files but not other things) | 10:47 |
| cjwatson | Chipaca: how widely deployed would we want all this to be before we could be comfortable turning it on in snaps, though? | 10:48 |
| cjwatson | Chipaca: the main issue here is that seccomp confinement requires some new API in libpipeline, so it'd be difficult to SRU. the apparmor confinement on its own would probably be quite easy to SRU. might we be comfortable if we just had apparmor for groff-related processes called by man, which it seemed to me before was the main concern? | 10:49 |
| Chipaca | cjwatson: wrt whether apparmor would be enough for us to be happy, that's a question for jdstrand | 10:49 |
| cjwatson | OK, hopefully he'll see that. I did run the profile past him | 10:50 |
| Chipaca | cjwatson: wrt SRU, i'll check what mvo thinks; worst case we might look at rolling it into 18 | 10:50 |
| cjwatson | AIUI from Gustavo at the rally, 18 is more of a future escape hatch than a concrete plan | 10:50 |
| cjwatson | so yeah, that's a worst case, seems like quite a bad one though :) | 10:50 |
| Chipaca | cjwatson: wrt how widely deployed, i'm ok with letting the packager decide whether their target distribution supports it or not | 10:50 |
| Chipaca | cjwatson: 18 is many things :-) but we'll be switching to an 18.04-based default at _some_ point | 10:51 |
| Chipaca | as opposed to our current 16.04-based default | 10:51 |
| Chipaca | and that's what i meant | 10:51 |
| cjwatson | right, if you mean 18.04 base snaps rather than series 18 assertions or whatever, then sure | 10:51 |
| Chipaca | series:18 is the thing that's an escape hatch | 10:51 |
| cjwatson | hopefully should be able to get the apparmor profile SRUed to xenial after some bake time, though | 10:52 |
| Chipaca | yes (for moost non-devs, a 18.04 base snap defaut is as 18 as it gets) | 10:52 |
| Chipaca | that would be ideal, agreed | 10:52 |
| Chipaca | cjwatson: the change in libpipeline, it's a new API, not a changed one? | 10:54 |
| cjwatson | the main hole this leaves would be man-db's own scanning of manual pages to figure out what their NAME headers are. there's literally never been a vulnerability in that, though, so I'm not too worried | 10:54 |
| Chipaca | so it can be made ABI-compatible? | 10:54 |
| cjwatson | it's a new API, yes, but it'd effectively be a new upstream version | 10:54 |
| cjwatson | also new ABI, so not quite sure what you mean by ABI-compatibile | 10:54 |
| cjwatson | *compatible | 10:54 |
| Chipaca | maybe i misunderstood -- i thought if you just added new symbols you didn't need to bump the abi | 10:55 |
| Chipaca | but my knowledge of that part of the stack is very hazy :-) | 10:55 |
| Chipaca | (i've never had to learn it) | 10:56 |
| cjwatson | Chipaca: well, it's not a new SONAME so doesn't require a library transition or anything, sure | 10:56 |
| Chipaca | right, that's what i meant, thank you | 10:56 |
| Chipaca | cjwatson: taking a step back, that's great news, and thank you for your work on this! I'll try not to get too excited until more bits get put in place, but it's hard :-) | 10:59 |
| cjwatson | right, it'll take a week or two more until everything lands in bionic, probably, since the seccomp stuff requires some care about portability. Just mainly wanted to check whether I was missing anything important | 11:01 |
| Chipaca | Son_Goku: o/ | 11:10 |
| Son_Goku | hey | 11:10 |
| Chipaca | Son_Goku: question for you: if you set MANPATH to include, say, /var/lib/snapd/snap/man, and that directory contained manpages, would your man pick it up, or would its confinement block that? | 11:12 |
| Son_Goku | it'd probably get blocked | 11:13 |
| niemeyer | o/ | 11:13 |
| Son_Goku | niemeyer: hi | 11:13 |
| Son_Goku | man can only access files labeled as "man_t" | 11:13 |
| Son_Goku | I'd probably have to fiddle with the SELinux policy to make sure any files in /var/lib/snapd/snap/man were marked as man pages | 11:14 |
| Son_Goku | or at least could transition from type snappy_var_t to man_t | 11:14 |
| Chipaca | Son_Goku: could snapd do that labeling? | 11:14 |
| Son_Goku | it *should* | 11:15 |
| mvo | pedronis: I think I'm at the point now where I would like to use the fakestore with a fake snapDeclaration for my snapd refresh managed PR, maybe we can have a quick chat after the standup? happy to work on it just want to make sure things are aligned | 11:15 |
| Son_Goku | the fact it doesn't is super annoying | 11:15 |
| Chipaca | Son_Goku: ok, i'll keep it in mind | 11:15 |
| Son_Goku | it should be generating all of these policy things | 11:15 |
| Chipaca | Son_Goku: tell me more | 11:15 |
| Chipaca | about "all of these policy things"? | 11:15 |
| Chipaca | i mean, i have no idea how to label something, but i presume it's something that could in worst case be done via a command | 11:16 |
| Chipaca | so snapd could do it as part of install | 11:16 |
| Son_Goku | sure | 11:16 |
| Son_Goku | there are a few ways to do it | 11:16 |
| Chipaca | so my question is more what needs labeling | 11:16 |
| Son_Goku | libselinux provides a programmatic way to do it, but you can also use chcon to do it | 11:16 |
| Son_Goku | it does run the risk of being reset unless a policy is generated and loaded | 11:17 |
| Son_Goku | so snaps need to be labeled correctly on install and mount | 11:17 |
| Son_Goku | matching the label in the snapd policy profile for them | 11:17 |
| Son_Goku | assuming man is confined, man pages on install need to be labeled correctly, too | 11:18 |
| Chipaca | Son_Goku: what would do that resetting? and how does a policy loading stop the reset? | 11:18 |
| pedronis | mvo: yes, it's almost lunch here, we can chat after the standup, this morning I looked around about what is the current situation about that | 11:18 |
| Son_Goku | and snapd should be generating policies to enforce these so that when the user runs restorecon, it doesn't get reset by policy | 11:18 |
| Son_Goku | the restorecon command can be used to reset all filesystem labels to match what's in the loaded SELinux policy | 11:19 |
| Chipaca | Son_Goku: is the policy something like "everything under /foo/bar has label baz"? | 11:19 |
| Son_Goku | yes, it can be | 11:19 |
| Chipaca | Son_Goku: so we could instead have that and do restorecon? | 11:20 |
| Son_Goku | yes | 11:20 |
| Chipaca | or would that be frowned on | 11:20 |
| Son_Goku | no, that's fine | 11:20 |
| Son_Goku | you can tell restorecon to restore only within a set of paths | 11:20 |
| Son_Goku | rather than the whole filesystem | 11:20 |
| Chipaca | Son_Goku: and how does restorecon affect running processes? | 11:20 |
| Son_Goku | it doesn't | 11:21 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | ok | 11:21 |
| Son_Goku | processes get their SELinux context from when they're initialized | 11:21 |
| Son_Goku | that comes from the label they were on disk | 11:21 |
| Chipaca | Son_Goku: thanks (i'll ask and dig more when i'm closer to the feature) | 11:21 |
| Son_Goku | :) | 11:21 |
| Chipaca | this gives me a general feel of what needs to happen :-) | 11:21 |
| Son_Goku | for SELinux, there are two "languages" for them: a high level language (you can see that here: https://github.com/snapcore/snapd/tree/master/data/selinux), and an intermediate language that you can use to build another language to compile to: https://github.com/SELinuxProject/cil/wiki | 11:23 |
| Chipaca | cjwatson: is the libpipeline work being done upstream? would fedora be picking that up as well? | 11:23 |
| cjwatson | Chipaca: I am upstream for libpipeline | 11:24 |
| cjwatson | so yes | 11:24 |
| mvo | pedronis: same here, lunch and meetings, looking forward for your ideas :) enjoy lunch | 11:24 |
| Chipaca | cjwatson: thank you | 11:24 |
| Son_Goku | Chipaca, since snapd has its own high level language for security constructs, any programmatic SELinux enablement would probably be done by leveraging the CIL | 11:24 |
| Son_Goku | CIL constructs can be directly loaded into the kernel | 11:25 |
| Chipaca | Son_Goku: I know some of those words! I'll see how much I need to learn down the road (not now though) | 11:26 |
| Son_Goku | :D | 11:27 |
| Chipaca | Son_Goku: the context is that we'll be adding manpage support at some point, and want man to be able to load manpages from snaps while minimising risk | 11:28 |
| Son_Goku | right | 11:28 |
| Son_Goku | the CIL structure more closely resembles how AppArmor profiles are written, so that might be helpful for you ;) | 11:29 |
| * Chipaca goes back to reviewing stuff | 11:30 | |
| Son_Goku | also... restorecon: https://www.mankier.com/8/restorecon | 11:30 |
| * kalikiana tea break | 11:36 | |
| cjwatson | the in-progress apparmor profile is https://anonscm.debian.org/cgit/pkg-man-db/man-db.git/tree/debian/apparmor/usr.bin.man FWIW | 11:38 |
| cjwatson | definitely not perfect but it protects the bits that deal with untrusted data most directly | 11:39 |
| andyrock | ogra_: regarding the problem of snaps mounts appearing in gdu | 11:48 |
| andyrock | the mount options 'x-gdu.whatdever' cannot be used because it requires that to be in fstab | 11:48 |
| andyrock | an enviroment variable cannot be used because cannot be get using udisk2 | 11:49 |
| zyga-ubuntu | re | 11:50 |
| zyga-ubuntu | JamieBennett: I'm home now | 11:50 |
| andyrock | zyga-ubuntu: http://paste.ubuntu.com/25960186/ | 11:51 |
| andyrock | I asked upstream if we can just mark them as udisk2 ignored | 11:52 |
| andyrock | and maybe gdu can avoid displaying an ignored loop device | 11:52 |
| andyrock | and show all the other devices (even if ignored) | 11:53 |
| zyga-ubuntu | andyrock: looking | 11:53 |
| zyga-ubuntu | andyrock: I don't understand why x-gdu.whatever cannot be used | 11:54 |
| andyrock | because it's not passed around | 11:54 |
| zyga-ubuntu | andyrock: is it because the custom mount unit data is lost and cannot be accessed? | 11:54 |
| andyrock | not written in mtab | 11:54 |
| andyrock | nowhere | 11:54 |
| zyga-ubuntu | I see | 11:55 |
| andyrock | it can be that i'm doing something wrong | 11:56 |
| andyrock | but I don't think so :D | 11:56 |
| andyrock | https://www.irccloud.com/pastebin/qWM7FlOw/ | 11:57 |
| andyrock | it can be that I'm using an old version of util-linux | 11:59 |
| andyrock | let me check on bionic | 11:59 |
| zyga-ubuntu | andyrock: I think you are right | 12:01 |
| andyrock | https://www.irccloud.com/pastebin/8i62fxih/ | 12:01 |
| andyrock | zenial has 2.27 | 12:02 |
| andyrock | *xenial | 12:02 |
| andyrock | bionic should be fine | 12:02 |
| andyrock | and it's ok to not target X | 12:02 |
| JamieBennett | zyga-ubuntu: OK, see you at the stand-up | 12:03 |
| zyga-ubuntu | mvo: hello, did you consider increasing the number of workers? | 12:06 |
| zyga-ubuntu | ok | 12:08 |
| zyga-ubuntu | mvo: I just +1d https://github.com/snapcore/snapd/pull/4207 | 12:19 |
| mup | PR #4207: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4207> | 12:19 |
| zyga-ubuntu | not sure if you think jamie should see it as well | 12:19 |
| zyga-ubuntu | Chipaca: hey | 12:20 |
| zyga-ubuntu | Chipaca: FYI, there's a C rewrite of c-n-f | 12:20 |
| Son_Goku | zyga-ubuntu: eh? | 12:20 |
| zyga-ubuntu | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881692 | 12:21 |
| zyga-ubuntu | hey Son_Goku | 12:21 |
| Son_Goku | yet another c-n-f thing? | 12:22 |
| Son_Goku | jeez | 12:22 |
| Son_Goku | why | 12:22 |
| zyga-ubuntu | Son_Goku: I'd love one upstream cnf that's not tied to gnome-software/packagekit | 12:23 |
| zyga-ubuntu | Son_Goku: that can work anywhere | 12:23 |
| Son_Goku | and of course, it's debian specific, though I shouldn't be surprised since it's a rewrite of the debian c-n-f tool | 12:23 |
| zyga-ubuntu | but it's world vs reality | 12:23 |
| Son_Goku | zyga-ubuntu: suse's scout uses libsolv | 12:23 |
| zyga-ubuntu | Son_Goku: why debian specific? | 12:23 |
| Son_Goku | which can parse literally anything | 12:23 |
| zyga-ubuntu | Son_Goku: I don't want to use libsolve | 12:23 |
| zyga-ubuntu | Son_Goku: this is not a merit | 12:23 |
| Son_Goku | why is that not a merit? | 12:23 |
| zyga-ubuntu | Son_Goku: cnf has a very simple goal: deliver useful hint quickly | 12:24 |
| Son_Goku | yes | 12:24 |
| zyga-ubuntu | Son_Goku: it has a very simple data format | 12:24 |
| zyga-ubuntu | Son_Goku: that can be fed by anything | 12:24 |
| Son_Goku | you want a cnf framework? | 12:24 |
| Son_Goku | then make one | 12:24 |
| zyga-ubuntu | Son_Goku: no, I don't want a framework, we have one already, it just needed a C rewrite for speed | 12:24 |
| zyga-ubuntu | Son_Goku: app name -> list of info about hints | 12:25 |
| zyga-ubuntu | that's literally the whole thing | 12:25 |
| zyga-ubuntu | Son_Goku: I'm sure each distribution had a reason to come up with something similar but I was trying to make a point about simplicity and speed | 12:26 |
| zyga-ubuntu | Son_Goku: using complex libraries for complex tasks is not improving the situation | 12:26 |
| zyga-ubuntu | Son_Goku: there's nothing to solve for | 12:26 |
| Son_Goku | the debian c-n-f calls apt directly | 12:26 |
| Son_Goku | that's basically the same problem then | 12:26 |
| zyga-ubuntu | Son_Goku: ? | 12:26 |
| zyga-ubuntu | Son_Goku: is the debian cnf the same as ubuntu's cnf? | 12:27 |
| * Son_Goku shrugs | 12:27 | |
| zyga-ubuntu | Son_Goku: note that "calling $packaging tool" directly is a simple build thing that can be tweaked form same source | 12:27 |
| zyga-ubuntu | Son_Goku: in fact the code I wrote a decade ago did that | 12:27 |
| zyga-ubuntu | Son_Goku: (though it was my very early python so it's pretty terrible) | 12:27 |
| Son_Goku | zyga-ubuntu: it looks like it reads apt metadata | 12:29 |
| Son_Goku | Contents and Packages, specifically | 12:29 |
| zyga-ubuntu | Son_Goku: the debian one? that's too bad, sorry about that (I didn't write that) | 12:30 |
| zyga-ubuntu | Son_Goku: my implementation was always about data, any package can add additional data files that contain hints | 12:30 |
| zyga-ubuntu | Son_Goku: and with minimal dependencies it is sane for servers and desktops and embedded alike | 12:30 |
| Son_Goku | the goal of most c-n-f tools is to identify what you need to install to make the missing command available | 12:30 |
| zyga-ubuntu | Son_Goku: and the data can come from whatever format, can be packagekit, gnome-software, apt, dnf, whatever | 12:31 |
| Son_Goku | that's what PK-cnf, scout, etc. all do | 12:31 |
| Son_Goku | the problem in your case is you want to inject foreign applications into the cnf | 12:31 |
| zyga-ubuntu | ? | 12:31 |
| zyga-ubuntu | no, there's no problem here | 12:31 |
| zyga-ubuntu | anyway, not sure what we are arguing about | 12:32 |
| zyga-ubuntu | the many implementations | 12:32 |
| zyga-ubuntu | the design of a particular one | 12:32 |
| zyga-ubuntu | or something else | 12:32 |
| Son_Goku | we're not arguing | 12:32 |
| Son_Goku | I'm just telling you what the stuff has been forever | 12:32 |
| Son_Goku | and your problem space (adding snaps to cnf) is not easy because most don't have a way to do it | 12:32 |
| zyga-ubuntu | Son_Goku: well, I know there were, I tried to unifiy it after writing the first one | 12:32 |
| zyga-ubuntu | Son_Goku: that's fine, we'll go little by little | 12:33 |
| zyga-ubuntu | Son_Goku: (actually not sure if I wrote the first one or just the one that got used in ubuntu) | 12:33 |
| Son_Goku | I think you just wrote the one that went into ubuntu | 12:33 |
| zyga-ubuntu | Son_Goku: but my point is that it's hard to unify everyone now as they all have their own quirky versions | 12:34 |
| zyga-ubuntu | Son_Goku: but was it also the first one? | 12:34 |
| Son_Goku | I recall cnf systems existing since before Ubuntu's existence | 12:34 |
| Son_Goku | Mandrake had one, iirc | 12:34 |
| zyga-ubuntu | aha, I didn't know that | 12:34 |
| zyga-ubuntu | Son_Goku: in my problem the actually interesting/hard part was data collection | 12:34 |
| Son_Goku | my memories of Mandrake are super-foggy though, it was 15 years ago | 12:35 |
| zyga-ubuntu | the display part was really not that hard | 12:35 |
| Son_Goku | sure | 12:35 |
| zyga-ubuntu | nowadays it's (maybe) better with better repo-side meta-data | 12:35 |
| Son_Goku | yeah | 12:35 |
| zyga-ubuntu | but when you cannot get "vim" (because it's vim.real) or gcc (because $REASONS) I had to do some very ugly things to collect better source data | 12:35 |
| Son_Goku | well, Mandrake's urpmi was one of the first easily searchable metadata formats | 12:36 |
| Son_Goku | it had a binary index called synthesis | 12:36 |
| Son_Goku | that made things super-fast for queries | 12:36 |
| Son_Goku | right | 12:36 |
| zyga-ubuntu | Son_Goku: the index is not a problem, I built one too, the problem were postinst scripts | 12:36 |
| Son_Goku | this wasn't a problem in RPM land, because we had %ghost | 12:36 |
| Son_Goku | we can just say a file *will exist* and it would show up in the file lists anyway | 12:36 |
| zyga-ubuntu | Son_Goku: dpkg-divert and dpkg-alternatives | 12:36 |
| Son_Goku | I don't know how debian solved that problem | 12:36 |
| Son_Goku | alternatives has and will remain, garbage fire | 12:37 |
| zyga-ubuntu | Son_Goku: I think they now describe command line applications explicitly | 12:37 |
| zyga-ubuntu | Chipaca: hey, about the README file, I'm thinking if it should be a standalone file && symlink | 12:40 |
| zyga-ubuntu | Chipaca: and about the complexity tradeoff | 12:41 |
| zyga-ubuntu | not sure | 12:41 |
| zyga-ubuntu | Son_Goku: have you seen that PR? | 12:41 |
| Son_Goku | which one? | 12:41 |
| Son_Goku | I follow lots of PRs for lots of projects... | 12:41 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/4210 | 12:41 |
| mup | PR #4210: many: add magic /snap/README file <Created by zyga> <https://github.com/snapcore/snapd/pull/4210> | 12:41 |
| zyga-ubuntu | yesterday's experiment to help users | 12:41 |
| zyga-ubuntu | this was caused by https://forum.snapcraft.io/t/a-more-graceful-way-for-snapd-to-fail-when-snap-is-missing/2712/31 (which is very eye-opening) | 12:42 |
| Chipaca | zyga-ubuntu: question is, where do you symlink it to / copy it from | 12:43 |
| zyga-ubuntu | Chipaca: yeah, complexity | 12:43 |
| zyga-ubuntu | Chipaca: this is blissfully simple | 12:43 |
| Chipaca | zyga-ubuntu: make it readonly i'm +1 on it :-) | 12:44 |
| Chipaca | zyga-ubuntu: the others are wishful dreaming | 12:44 |
| zyga-ubuntu | Chipaca: could be i18n if we had core locale handling :D | 12:44 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| zyga-ubuntu | Chipaca: ok, I'll check if that doens't upset the ensure code and do it | 12:44 |
| zyga-ubuntu | *doesn't | 12:44 |
| Son_Goku | zyga-ubuntu: umm wtf? | 12:46 |
| Son_Goku | you're dynamically generating a readme? | 12:46 |
| zyga-ubuntu | Son_Goku: yes, like everything else there | 12:47 |
| Son_Goku | alright then | 12:49 |
| Son_Goku | man page like readmes should be treated like man pages :) | 12:49 |
| zyga-ubuntu | Son_Goku: I mean it's a bit of a stretch | 12:49 |
| zyga-ubuntu | Son_Goku: but it has some advantages | 12:49 |
| Son_Goku | I'm not saying it's bad | 12:49 |
| Son_Goku | it's just out of left field | 12:49 |
| zyga-ubuntu | Son_Goku: yeah but this is for users who don't really read man pages | 12:49 |
| Son_Goku | yes, yes | 12:49 |
| zyga-ubuntu | out of left field? | 12:49 |
| Son_Goku | something I didn't expect anyone would do | 12:50 |
| zyga-ubuntu | aha :) | 12:50 |
| Chipaca | Son_Goku: this is to address a problem we saw in the forum | 12:50 |
| Son_Goku | "out of left field" is an English idiomatic phrase coming from baseball | 12:50 |
| Chipaca | Son_Goku: somebody rsync'ed /snap and then mounted that and wondered why everything was terrible | 12:50 |
| zyga-ubuntu | I almost think we could have WHAT-IS-THIS.desktop that runs browser and goes to the forum | 12:50 |
| Son_Goku | zyga-ubuntu: https://en.wikipedia.org/wiki/Out_of_left_field | 12:50 |
| zyga-ubuntu | with gustavo movie explaining things | 12:50 |
| * zyga-ubuntu reads | 12:50 | |
| Son_Goku | the forum is a bad reference for these things | 12:50 |
| Son_Goku | it's too dynamic and people are allowed to freely edit and delete things | 12:51 |
| Son_Goku | as the information is relatively static, it makes little sense to not incorporate it into the README file if that's its purpose | 12:51 |
| zyga-ubuntu | Son_Goku: that topic is in the "doc" section | 12:52 |
| zyga-ubuntu | Son_Goku: so it should be curated | 12:52 |
| Son_Goku | it can just as easily not be | 12:52 |
| Son_Goku | that is *not* a good enough indicator in my mind | 12:52 |
| zyga-ubuntu | Son_Goku: what would you add to the file that is not there already/ | 12:52 |
| Son_Goku | actually, I think the readme itself is fine | 12:53 |
| Son_Goku | but if there's supposed to be more information, don't cop-out to link to the forum | 12:53 |
| Son_Goku | it's a bad habit | 12:53 |
| Son_Goku | it already happens too much when it really shouldn't | 12:53 |
| Son_Goku | documentation topics should probably be regularly exported from the forum into something that can be bundled and shipped as a static site | 12:54 |
| zyga-ubuntu | Son_Goku: maybe, I think it could be done if the forum has an API | 12:54 |
| zyga-ubuntu | Son_Goku: I like the appeal of offline, curated docs | 12:54 |
| zyga-ubuntu | Son_Goku: but nowadays people mostly just google stuff | 12:55 |
| Son_Goku | I'm more concerned that the docs aren't really forkable | 12:55 |
| zyga-ubuntu | aha | 12:55 |
| Son_Goku | they *were* when they were managed in a github wiki | 12:55 |
| Son_Goku | but they're not anymore | 12:55 |
| Son_Goku | and we have problems from time to time with people being unable to edit their own topics/posts | 12:55 |
| mvo | zyga-ubuntu: I don't think I can do that myself, I can do a PR though, but I have no analyized why things are slow currently | 12:59 |
| zyga-ubuntu | mvo: I mean, we can just do a PR with some extra nodes in it to see how timing works | 13:00 |
| === dontbeadick is now known as CoderEurope | ||
| niemeyer | Son_Goku: Don't overthink it too much.. it's a link to a place which can be publicly edited and maintained. The link can change, the content in the forum can change, everything can change if it has to. For now this approach is good enough, and it's visible both to the community and to people maintaining it. | 13:15 |
| zyga-ubuntu | Son_Goku: I addressed your comments now, thank you! | 13:16 |
| jdstrand | zyga-ubuntu: hey, so 4163 was committed before I looked at it, but I looked at it yesterday. while the code appears to have the end result we want, I felt that it was a bit confusing as an api and hard to read. it's approved and it works so not a blocker, but 2 cents | 13:25 |
| zyga-ubuntu | jdstrand: hey thank you for reviewing that | 13:30 |
| zyga-ubuntu | jdstrand: yes, it got merged by accident really | 13:30 |
| jdstrand | ok | 13:30 |
| zyga-ubuntu | jdstrand: I did that to reuse code / testing for similar features, if you think it'd be better to just get it in one function like before that's useful data for me | 13:30 |
| jdstrand | zyga-ubuntu: if you agree and wanted to do a followup PR, I'm happy to review it | 13:31 |
| zyga-ubuntu | jdstrand: did you add the feedback on github? | 13:31 |
| zyga-ubuntu | or is that just the remark here about the api complexity | 13:31 |
| jdstrand | zyga-ubuntu: it isn't so much about reuse (which is fine). my comments are in the PR, yes | 13:31 |
| zyga-ubuntu | ok, i'll have a look; thank you! | 13:32 |
| jdstrand | surprised you didn't get an email... | 13:32 |
| jdstrand | wonder if github is 'smart' and doesn't send reviews after it is merged... | 13:32 |
| jdstrand | in that light... | 13:34 |
| ogra_ | yeah, GH mail handling for PRs sucks | 13:34 |
| ogra_ | they should implement the launchpad one ;) | 13:34 |
| jdstrand | ackk: hi! not sure if you noticed, but I added a few comments to https://github.com/snapcore/snapd/pull/3916#pullrequestreview-76430191 | 13:34 |
| mup | PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3916> | 13:34 |
| jdstrand | ackk: summary: I thought input validation was good but requested a few extra tests | 13:35 |
| zyga-ubuntu | jdstrand: I think it didn't email me, I'll have to check the branch directly | 13:36 |
| jdstrand | zyga-ubuntu: https://github.com/snapcore/snapd/pull/4163#pullrequestreview-76253522 | 13:36 |
| mup | PR #4163: cmd/snap-update-ns: re-factor secureMkdirAll into secureMk{Prefix,Dir} <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4163> | 13:36 |
| jdstrand | zyga-ubuntu: (and the inline comments below that ^) | 13:37 |
| zyga-ubuntu | ah, I see your notification now | 13:37 |
| zyga-ubuntu | thanks! | 13:37 |
| jdstrand | np | 13:37 |
| jdstrand | zyga-ubuntu: again, if you disagree, and feel it is fine, that is 3 against 1, so it is for your consideration | 13:38 |
| zyga-ubuntu | jdstrand: I'll take it into account and integrate parts into other RPs, the rest will be in a separate PR most likely, I need to read this carefully first | 13:38 |
| zyga-ubuntu | jdstrand: I think partially it is just naming as I was trying to have code that I can reuse for <prefix>/<leaf> where there are N leaf functions and one function for prefix | 13:39 |
| zyga-ubuntu | mvo: I'm looking at the tuntap test failure now | 13:53 |
| zyga-ubuntu | cachio: hey | 13:54 |
| cachio | zyga-ubuntu, hi | 13:54 |
| zyga-ubuntu | cachio: how can we refresh the debian sid image we have in linode | 13:54 |
| zyga-ubuntu | cachio: and ideally unbreak the sid vs debian 9 issue | 13:54 |
| zyga-ubuntu | cachio: so we have the same distro in qemu and in linode | 13:55 |
| cachio | we need to use spread-images for that | 13:55 |
| zyga-ubuntu | do I have permissions for that? i can have a look at fixing htis if I do | 13:56 |
| cachio | zyga-ubuntu, which kind of refresh should we do? | 13:56 |
| zyga-ubuntu | cachio: we need to dist-upgtrade, including the new kernel, essentially | 13:56 |
| cachio | you need to download the spread-images | 13:57 |
| cachio | then execute with spread tasks/update | 13:57 |
| zyga-ubuntu | aha | 13:57 |
| zyga-ubuntu | https://github.com/snapcore/spread-images I assume | 13:57 |
| cachio | with the image you want to update | 13:57 |
| cachio | then you can manually install want yuou need | 13:58 |
| cachio | and then gustavo will replace that image that you created | 13:58 |
| cachio | I can start the image and give you the credentials | 13:58 |
| cachio | so then I make the tear down lo clean up the image | 13:58 |
| cachio | zyga-ubuntu, just giveme 5 minutes to start the machine | 13:59 |
| zyga-ubuntu | ok | 13:59 |
| zyga-ubuntu | cachio: I forked the repo | 13:59 |
| zyga-ubuntu | er | 13:59 |
| zyga-ubuntu | cloned it | 13:59 |
| cachio | I am running the test | 14:00 |
| cachio | I'll have that machine in few minutes | 14:00 |
| ogra_ | pedronis, did the behaviour of the "snap download... ; snap ack ... ; snap install ..." triplet change recently ? i was just told by someone that he didnt need to ack but could just do download and install | 14:07 |
| mvo | zyga-ubuntu: \o/ | 14:08 |
| Chipaca | ogra_: if they've previously acked they don't need to re-ack | 14:08 |
| zyga-ubuntu | mvo: ha, the test just passed?!? | 14:08 |
| pedronis | ogra_: no, didn't change, I had some discussion that we might ack for you but it didn't happen | 14:08 |
| pedronis | so far | 14:09 |
| ogra_ | well, Chipaca's answer might explain it | 14:09 |
| mvo | zyga-ubuntu: race? | 14:09 |
| mvo | zyga-ubuntu: did you ran it on linode? | 14:09 |
| zyga-ubuntu | yes | 14:11 |
| zyga-ubuntu | inside linode | 14:11 |
| zyga-ubuntu | I doubt it is racing | 14:11 |
| zyga-ubuntu | I'll retry | 14:11 |
| zyga-ubuntu | Son_Goku: Fedora 27 is now released :) | 14:19 |
| Son_Goku | yes | 14:19 |
| Son_Goku | the fedora 27 VM needs to be distro-sync'd to GA package set | 14:20 |
| zyga-ubuntu | mvo: it passed again, I'll send a PR re-enabling that | 14:26 |
| mup | PR snapd#4213 opened: tests: re-enable tun/tap test on Debian <Created by zyga> <https://github.com/snapcore/snapd/pull/4213> | 14:28 |
| roadmr | jdstrand: good morning! tools r939 is in prod as of 2 hours ago \o/ | 14:39 |
| zyga-ubuntu | mvo: I worked with cachio on an updated pair of debian images, a proper debian-9 image (new) and separately from that debian-unstable (as today) that represents a current snapshot of sid | 14:51 |
| mvo | zyga-ubuntu: nice | 14:51 |
| zyga-ubuntu | mvo: the stretch/9 image will be a good baseline for testing snapd in stable | 14:52 |
| mvo | zyga-ubuntu: yeah, debian-9 will be less volatile | 14:53 |
| zyga-ubuntu | mvo: and the refreshed image will show us the issues with mainline kernel apparmor | 14:53 |
| zyga-ubuntu | mvo: I'll focus on resolving those with jjohansen and jdstrand | 14:53 |
| mvo | thanks zyga-ubuntu | 14:53 |
| cachio | zyga-ubuntu, machines are clean, now we need to wait until those are updated in linode | 14:54 |
| jdstrand | roadmr: thanks! | 14:56 |
| zyga-ubuntu | mvo: can you please merge https://github.com/snapcore/snapd/pull/4213 | 15:08 |
| mup | PR #4213: tests: re-enable tun/tap test on Debian <Created by zyga> <https://github.com/snapcore/snapd/pull/4213> | 15:08 |
| * Chipaca goes to have lunch before it's tea | 15:10 | |
| elopio | nessita: I need help sending an oauth request to an SSO authenticated URL. Can you help me? | 15:10 |
| roadmr | oauth? | 15:10 |
| roadmr | elopio: does "surl" help here? it takes care of authentication | 15:10 |
| ogra_ | only if you dont use 2fa though | 15:12 |
| sergiusens | kalikiana hey, how's that container work going? | 15:12 |
| sergiusens | elopio notice a problem here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-snapcraft-daily/artful/amd64/s/snapcraft/20171114_144114_e9c38@/log.gz ? | 15:15 |
| sergiusens | :-) | 15:15 |
| === cachio is now known as cachio_lunch | ||
| elopio | sergiusens: ugh, I will fix it. | 15:18 |
| mup | PR snapd#4213 closed: tests: re-enable tun/tap test on Debian <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4213> | 15:18 |
| sergiusens | elopio thanks | 15:18 |
| sergiusens | elopio would be good to not check the output of commands we do not control; imagine people using ours as a result of test if you cannot see my point :-) | 15:19 |
| sergiusens | unless it is supposed to be machine readable output | 15:20 |
| elopio | roadmr: I didn't know about surl, I will check that. I was trying with the ssoclient and requests_oauth: http://paste.ubuntu.com/25961322/ | 15:23 |
| elopio | but last time I did this was years ago, I'm not sure if I'm doing it wrong. | 15:24 |
| roadmr | elopio: that's probably rotten :( surl does the macaroon dance, not really oauth, so depending on what you want it for, it may or may not work | 15:24 |
| kalikiana | sergiusens: anything specific? I've got a branch for the matter of injecting the core snap but didn't propose it as to avoid taking resources off Travis | 15:24 |
| nessita | elopio, i think so! | 15:25 |
| nessita | elopio, tell me more | 15:25 |
| elopio | nessita: I've just sent my script to roadmr: http://paste.ubuntu.com/25961322/ | 15:26 |
| elopio | oh, there's a bad import there, but well, that's the idea. | 15:26 |
| nessita | elopio, what's the goal of the script? I don't think https://autopkgtest.ubuntu.com/request.cgi supports oauth authorization? | 15:28 |
| nessita | elopio, ie SSO is not an oauth provider, is an openid provider | 15:28 |
| nessita | elopio, the OAuth that SSO supports is not rfc compliant and works with sso APIs (its own) | 15:28 |
| sergiusens | kalikiana have you seen your email inbox as of late? | 15:29 |
| elopio | nessita: so, more context. I copied some bash from pitti that triggers the autopkgtests in a PPA. It uses a cookie for the request: | 15:31 |
| elopio | https://github.com/elopio/snapcraft/blob/ppa-autopkgtest/tools/run_ppa_autopkgtests.py | 15:31 |
| kalikiana | sergiusens: oh, were you asking about the release stuffs I guess. "that container work" sounded like some PR you were looking for. My bad. | 15:31 |
| kalikiana | sergiusens: I'm getting myself acquainted with asciinema | 15:32 |
| elopio | nessita: Instead of the cookie, I thought it might be better to use oauth. But, it didn't work, so I started asking and they haven't tried that. Maybe, you are right and it's not supported. | 15:32 |
| nessita | elopio, SSO has not API for other sites to do OAuth validation | 15:33 |
| nessita | has no* API | 15:33 |
| elopio | nessita: so, do you know of a way to do this user/password instead of thte cookie? | 15:33 |
| CoderEurope | http://www.rightrelevance.com/search/articles/hero?article=8461f06abc90aa4816d85711cc78e4f09d2a5bb0&query=ubuntu&emaildigest=true | 15:34 |
| nessita | elopio, I don't think there is a way, SSO supported openid dance only which is browser/cookie based | 15:35 |
| CoderEurope | nessita: https://help.launchpad.net/API | 15:37 |
| CoderEurope | last edited 20-11 | 15:38 |
| elopio | nessita: well, thanks for the info. I will stop trying :) | 15:39 |
| elopio | nessita: the script mentioned that the cookie is valid for a month. Is that a month without use? Or will I always have to refresh the cookie manually? | 15:41 |
| elopio | omw to the meeting | 15:45 |
| Chipaca | CoderEurope: ? | 15:46 |
| cjwatson | CoderEurope: that's not super-relevant to autopkgtest or SSO APIs. Launchpad uses SSO, yes, but its APIs won't help in this case. | 15:58 |
| === cachio_lunch is now known as cachio | ||
| mup | PR snapcraft#1597 closed: pluginhandler: warn about migrated system libraries <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1597> | 16:04 |
| mup | Issue snapcraft#1733 opened: Apply guidelines from design to error messages with commands that fix <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1733> | 16:07 |
| zyga-ubu1tu | ok, now debian tests will probably all fail, I'll work on a PR to update them | 16:15 |
| * zyga-ubu1tu tries | 16:15 | |
| pedronis | mvo: we haven't released 2.29 to stable right? | 16:19 |
| cachio | pedronis, no yet | 16:23 |
| mvo | pedronis: no, still waiting for CE for the final test-ok | 16:23 |
| mvo | pedronis: why? any last minute issues? | 16:23 |
| pedronis | mvo: there are store issues | 16:23 |
| mvo | pedronis: store issues because of overload? | 16:26 |
| mvo | pedronis: that is a good point actually, I need to tell the store about the immanent release. but if you say there are issues we should hold back with the release (cc cachio ) | 16:26 |
| pedronis | https://forum.snapcraft.io/t/snap-store-apis-outage/2832 | 16:27 |
| cachio | mvo, pedronis sure | 16:27 |
| cachio | pedronis, is there any test that we can do | 16:28 |
| pedronis | no, but yes, don't think it makes or is sensible to release until the store is back to normal | 16:28 |
| cachio | pedronis, ok | 16:29 |
| zyga-ubu1tu | yeah, store is down for me too :? | 16:30 |
| zyga-ubu1tu | I guess time to focus on something else | 16:30 |
| zyga-ubu1tu | some new code :) | 16:30 |
| mvo | heh, and I was thinking my fakestore refactor was broken | 16:33 |
| ppisati | https://travis-ci.org/snapcore/snapcraft/jobs/301966989 | 16:34 |
| zyga-ubu1tu | mvo: I guess someone's feet are burning today | 16:34 |
| zyga-ubu1tu | mvo: but not ours (this time) | 16:34 |
| ppisati | this unit test fails when checking CLA check | 16:35 |
| ppisati | do anyone know why? | 16:35 |
| mvo | zyga-ubu1tu: maybe ours, if our client code goes crazy | 16:35 |
| zyga-ubu1tu | mvo: interesting, yes, let's see what happens | 16:35 |
| mup | PR snapd#4214 opened: fakestore: add go-flags to prepare for `new-snap-declaration` cmd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4214> | 16:38 |
| ppisati | kalikiana: ^ | 16:40 |
| ppisati | kyrofa: ^ | 16:40 |
| ppisati | not sure who is the most appropiate guy fo this kind of stuff | 16:40 |
| ogra_ | ppisati, i'd interpret that as 'marius@ubports.com' has not signed the CLA (though it is weird that it doesnt say that and just dies quietly) | 16:44 |
| ogra_ | i'm pretty sure he has signed (he contributed a lot to phone code before he started ubports) it but most likely not under this email address | 16:46 |
| ppisati | ogra_: yep, but why it's failing in my test? if he didn't sign the CLA, his commits shouldn't be part of snapcraft at all - my branch is based off origin/master + my own commits | 16:46 |
| ogra_ | yeah | 16:46 |
| ogra_ | elopio, ^^^ any idea ? | 16:46 |
| * ogra_ wonders if the snapcraft team is on a team excursion today :P | 16:47 | |
| ogra_ | hiking and picnic ... | 16:48 |
| sergiusens | ogra_ what's up? just got out of our team meeting | 16:48 |
| ppisati | sergiusens: this failure - https://travis-ci.org/snapcore/snapcraft/jobs/301966989 | 16:48 |
| ogra_ | :) | 16:48 |
| sergiusens | ogra_ ppisati that happens on merge instead of rebase with our CLA checker tool, as the "squash and merge" functionality sets the email to the one set on github | 16:49 |
| ppisati | sergiusens: ok, how do i fix it? | 16:50 |
| ogra_ | ppisati, obviously with a lot of patience :) | 16:54 |
| zyga-ubu1tu | my tweet was liked/retweeted by @systemdsucks and I have lots of notifications all the time | 16:57 |
| === zyga-ubu1tu is now known as zyga | ||
| kyrofa | ogra_, team meeting this morning, took a little while. So you're not far off! Hahaha | 17:01 |
| ogra_ | haha | 17:01 |
| kalikiana | :-D | 17:02 |
| davidcalle | elopio: kyrofa: hola, I'm looking for fresh pair of eyes on a new snap tutorial, are you interested? hhttps://github.com/canonical-websites/tutorials.ubuntu.com/pull/412 | 17:04 |
| kyrofa | sergiusens, is this the only store API doc we have? http://search.apps.ubuntu.com/docs/ | 17:04 |
| kyrofa | It doesn't seem to cover snap uploads, for example | 17:04 |
| kyrofa | davidcalle, sure! | 17:04 |
| kyrofa | Let me get a few reviews out of the way here, first | 17:05 |
| mup | PR snapd#4215 opened: Fix path in snap install <Created by asalminen> <https://github.com/snapcore/snapd/pull/4215> | 17:12 |
| CoderEurope | davidcalle: wat am I looking at ? | 17:12 |
| CoderEurope | davidcalle: Iam here - http://tutorials.ubuntu.com-pr-412.run.demo.haus Wat tutorial is it ? | 17:13 |
| pedronis | kyrofa: there is this https://dashboard.snapcraft.io/docs/api/snap.html | 17:14 |
| mup | PR snapcraft#1734 opened: recording: don't log the command when image info fails <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1734> | 17:14 |
| kyrofa | Thanks pedronis! | 17:14 |
| pedronis | I'm not sure how up to date it is though | 17:15 |
| davidcalle | CoderEurope: it's in the PR description: http://tutorials.ubuntu.com-pr-412.run.demo.haus/tutorial/snap-a-website | 17:15 |
| mup | PR snapd#4154 closed: overlord/snapstate: support completion for command aliases <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4154> | 17:15 |
| davidcalle | CoderEurope: thanks for having a look! | 17:16 |
| CoderEurope | davidcalle: its says some basic command line know-how --- do you want me to PM you about sugestions ? | 17:17 |
| davidcalle | CoderEurope: feel free to leave feedback directly on the PR | 17:18 |
| CoderEurope | davidcalle: I have never done that before - is the PR just meanings That I need a github account ? | 17:19 |
| CoderEurope | & whois caldav ? | 17:19 |
| davidcalle | CoderEurope: yes, once you have an account, you can leave comments there: hhttps://github.com/canonical-websites/tutorials.ubuntu.com/pull/412 | 17:19 |
| davidcalle | That's me | 17:20 |
| CoderEurope | k | 17:20 |
| CoderEurope | it just says I cannot comment at this time. | 17:28 |
| kyrofa | snappy-m-o, autopkgtest 1717 xenial:armhf | 17:29 |
| snappy-m-o | kyrofa: I've just triggered your test. | 17:29 |
| sergiusens | kyrofa why again? | 17:34 |
| kyrofa | sergiusens, it hasn't run without them timing out yet | 17:34 |
| kyrofa | sergiusens, it's not enough now that you reminded me that it doesn't actually run the snaps, so I'm also running xenial:amd64 locally | 17:35 |
| kyrofa | sergiusens, the next one doesn't need arm, though | 17:36 |
| sergiusens | kyrofa but you retriggered an armhf test | 17:40 |
| sergiusens | should be arm64 | 17:40 |
| CoderEurope | davidcalle: ^ | 17:42 |
| CoderEurope | nothing, http://paste.ubuntu.com/25962234/ | 17:43 |
| kyrofa | sergiusens, does arm64 run snaps? | 17:56 |
| sergiusens | kyrofa yes | 18:00 |
| kyrofa | Darn, I misunderstood | 18:01 |
| kyrofa | snappy-m-o, autopkgtest 1717 xenial:arm64 | 18:01 |
| snappy-m-o | kyrofa: I've just triggered your test. | 18:01 |
| sergiusens | kyrofa btw, what you just did was cancel the armhf test I had triggered around 6am my time as armhf is what I had triggered | 18:01 |
| sergiusens | kyrofa did you check why it failed? | 18:02 |
| kyrofa | sergiusens, oh! No, I just assumed it was failed from the previous run, ugh | 18:02 |
| kyrofa | sergiusens, elopio this is the regression to which you were referring this morning, I assume? https://pastebin.ubuntu.com/25962350/ | 18:07 |
| zyga | re | 18:17 |
| zyga | (dinner done) | 18:17 |
| kalikiana | kyrofa: there's an extra "." there it seems | 18:22 |
| kyrofa | kalikiana, right | 18:23 |
| kyrofa | Or not enough, depending on your frame of reference | 18:23 |
| kyrofa | Just wondering if I should fix it or if that's what's elopio is working on | 18:24 |
| * kalikiana wondering to have dinner now, it's been a long day | 18:25 | |
| elopio | davidcalle: great! I'm adding it to my todo. | 18:30 |
| elopio | davidcalle: great! I'm adding it to my todo. | 18:31 |
| elopio | davidcalle: great! I'm adding it to my todo. | 18:31 |
| elopio | davidcalle: great! I'm adding it to my todo. | 18:31 |
| elopio | davidcalle: great! I'm adding it to my todo. | 18:31 |
| elopio | upps, sorry David! | 18:31 |
| elopio | kyrofa: yes, there's already a pr ready for review. | 18:31 |
| kyrofa | elopio, ah ha! Okay very good, I see it now | 18:32 |
| sergiusens | elopio do not take it out on the wrong person 😂 | 18:34 |
| sergiusens | kyrofa, yeah, I had rebased your branch as it was conflicting with the timeout one | 18:35 |
| sergiusens | kyrofa ask elopio I'd there is a way to retrieve the previous run. Should be confidence enough | 18:36 |
| kyrofa | elopio, yeah, do you know if it's possible to see the previous adt run of a PR? | 18:37 |
| elopio | kyrofa: Not really. Sometimes you can click the red/green button in github, and the link will be there. But not always, not sure why. The index has all the results, but it's hard to tell which corresponds to the PR. My script in progress might help. | 18:42 |
| elopio | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-snapcraft-daily | 18:42 |
| kyrofa | Hey zyga you mentioned that you might have more lxd info today? | 18:43 |
| elopio | the index ^ | 18:43 |
| kyrofa | Haha, that is hilariously unparsable | 18:48 |
| zyga | kyrofa: yes, good progress just stalled with some random (other) issues | 18:49 |
| kyrofa | zyga, so the new solution is looking promising? | 18:49 |
| zyga | kyrofa: yeah, it's just *annoying* | 18:49 |
| zyga | kyrofa: the hardest one I thought of | 18:50 |
| zyga | kyrofa: but doable | 18:50 |
| zyga | kyrofa: so +1 :) | 18:50 |
| kyrofa | Haha, isn't that always the case | 18:50 |
| zyga | kyrofa: I need to unbreak debian first and then I can try to wrap that up | 18:50 |
| kyrofa | Good deal, thanks | 18:50 |
| zyga | kyrofa: yes, reality is fantastic at correcting assumptions | 18:50 |
| === dontbeadick is now known as CoderEurope | ||
| sergiusens | elopio snapcraft#1734 failed | 19:43 |
| mup | PR snapcraft#1734: recording: don't log the command when image info fails <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1734> | 19:43 |
| ikey | should i wait for new snapd to be released with my changes before uploading my snaps to store? | 19:45 |
| sergiusens | elopio retriggered the one failing test | 19:45 |
| * ikey wonders if the snap yaml supports: assumes [works-for-me] | 19:45 | |
| sergiusens | ikey are you using assumes? If so I'd guess not... or maybe leave them on edge | 19:45 |
| sergiusens | lol | 19:45 |
| ikey | oh id only have them in edge | 19:46 |
| ikey | and atm i have assumes on 2.29.2 | 19:46 |
| sergiusens | ikey then it probably is fine | 19:46 |
| ikey | the problem im having is testing | 19:46 |
| ikey | each time i have to remove the snap and reinstalla | 19:46 |
| ikey | and it nukes my data | 19:46 |
| ikey | i did also figure out that i shouldnt be using SNAP_USER_DATA | 19:46 |
| ikey | and switched to SNAP_USER_COMMON | 19:46 |
| ikey | dont really want gigabytes of data being transferred on update | 19:47 |
| sergiusens | good call | 19:47 |
| ikey | it still has nasty $SNAP_USER_COMMON/.local/share but meh | 19:47 |
| ikey | the LSI snap exists only to support steam | 19:47 |
| ikey | and steam.sh looks for XDG_CONFIG_HOME/XDG_DATA_HOME/etc | 19:48 |
| sergiusens | is that because that is the default path to install steam games? | 19:51 |
| ikey | yeah | 19:51 |
| ikey | ~/.local/share/Steam | 19:51 |
| ikey | or $XDG_DATA_HOME/.local/share/Steam | 19:51 |
| elopio | sergiusens: thanks | 19:51 |
| ikey | so im overriding the environment to suit | 19:51 |
| ikey | shim has a magical shim_init_user function: https://github.com/solus-project/linux-steam-integration/blob/master/src/shim/shim.c#L114 | 19:52 |
| ikey | we call it further down in shim_export_extra | 19:52 |
| ikey | passing it the value of SNAP_USER_COMMON | 19:52 |
| ikey | its uh, pretty comprehensive. | 19:53 |
| ikey | also meant i was able to "avoid" having a shell script entry point | 19:53 |
| kyrofa | sergiusens, elopio what on earth is this? Failure on arm64: https://pastebin.ubuntu.com/25962979/ | 20:17 |
| kyrofa | Oh, looks like a warning is leaking | 20:17 |
| kyrofa | That weird ResourceWarning | 20:17 |
| elopio | kyrofa: I couldn't understand that open socket, so reported this https://github.com/msabramo/requests-unixsocket/issues/36 | 20:19 |
| elopio | but no reply :( | 20:19 |
| kyrofa | elopio, yeah I've tried looking into the code as well, which seems just fine. I never see that warning in prod, so something is weird in adt | 20:19 |
| kyrofa | elopio, oh dang, you can reproduce?! Nice | 20:20 |
| elopio | I learned that the tests set that default warning filter. We could remove that as an ugly workaround | 20:20 |
| kyrofa | elopio, do we need to dig into the unixsocket code? Although even if we propose a PR I don't have confidence it'll be noticed at this point | 20:22 |
| kyrofa | This thing looks pretty much orphaned | 20:22 |
| kyrofa | elopio, think that will go away if I re-run? | 20:23 |
| elopio | kyrofa: yes, most certainly. And maybe it will also go away with your pr to reset the log. | 20:24 |
| kyrofa | Okay, I'll re-run, and also propose that PR | 20:24 |
| elopio | I'm fine ignoring it for 2.35. | 20:24 |
| kyrofa | Alright | 20:24 |
| kyrofa | snappy-m-o, autopkgtest 1717 xenial:arm64 | 20:25 |
| snappy-m-o | kyrofa: I've just triggered your test. | 20:25 |
| mup | PR snapd#4216 opened: interfaces/time*_control: explicitly deny noisy read on /proc/1/environ <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4216> | 20:32 |
| sergiusens | kyrofa why? | 20:35 |
| kyrofa | sergiusens, it failed with a log leak error before it could even build the deb | 20:38 |
| kyrofa | sergiusens, I'm rerunning since those are typically flaky, and also testing the PR I'm about to propose to fix | 20:39 |
| sergiusens | kyrofa so it looks like a release is not happening today either... | 20:40 |
| kyrofa | sergiusens, I'm still hoping, but given how long these tests take... | 20:41 |
| kyrofa | sergiusens, for what it's worth, I got a successful xenial:amd64 run locally on that one | 20:43 |
| kyrofa | And that PR doesn't _explicitly_ touch multi-arch bits | 20:44 |
| kyrofa | Depends on how risk-adverse you're feeling | 20:44 |
| kyrofa | How odd. sergiusens setting the log level at the beginning of the test instead of resetting it in cleanup actually doubles up the prints when it comes to tests/test_log.py | 20:45 |
| kyrofa | It seems doing it in cleanup is the only thing that works consistently | 20:47 |
| sergiusens | kyrofa something like snapcraft/internal/remote_parts.py:logging.getLogger("urllib3").setLevel(logging.CRITICAL) (which is manifestation of what we discussed yesterday) | 20:55 |
| kyrofa | sergiusens, oh interesting. We should be going that in the log module alongside requests | 20:57 |
| sergiusens | kyrofa this is only needed because we are doing things wrong | 20:59 |
| elopio | snappy-m-o github subscribe 1734 | 20:59 |
| snappy-m-o | elopio: I'll send you a message if a test fails in the pull request #1734 (recording: don't log the command when image info fails). | 20:59 |
| mup | PR #1734: boot: add missing udevadm mock to fix FTBFS <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1734> | 20:59 |
| kyrofa | Yeah we need to fix | 21:00 |
| ikey | can someone help me review my yamls before i get them ready for store upload pls? :3 | 21:00 |
| ikey | pure meta, no build instructions | 21:01 |
| mup | PR snapd#4217 opened: interfaces/browser-support: add shm path for nwjs <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4217> | 21:03 |
| kyrofa | sergiusens, do you want me to propose this cleanup log reset thing? | 21:20 |
| kyrofa | I'd rather not see more test failures because of this | 21:21 |
| sergiusens | kyrofa if you have the time, yes | 21:21 |
| sergiusens | ikey review in what sense? | 21:22 |
| ikey | check for jankiness | 21:22 |
| sergiusens | jdstrand is crt available as a snap so that ikey could validate his snaps? | 21:23 |
| mup | PR snapcraft#1735 opened: unit tests: reset log level after test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1735> | 21:24 |
| kyrofa | sergiusens, sure, it was already done ^ . Running adt xenial:amd64 locally on it now | 21:27 |
| elopio | sergiusens: all green. | 21:28 |
| kyrofa | Though I'm not sure I even need to do the whole thing given that it's only units | 21:28 |
| kyrofa | (units have already passed) | 21:28 |
| kyrofa | snappy-m-o, subscribe github 1717 | 21:29 |
| snappy-m-o | Command "," / ", subscribe" not found. | 21:29 |
| snappy-m-o | Did you mean "/snappy-m-o github subscribe" ? | 21:29 |
| kyrofa | snappy-m-o, well look at you being so helpful! | 21:29 |
| snappy-m-o | Command "," / ", well" not found. | 21:29 |
| kyrofa | snappy-m-o, github subscribe 1717 | 21:29 |
| snappy-m-o | kyrofa: I'll send you a message if a test fails in the pull request #1717 (catkin plugin: check for pip packages in part only). | 21:29 |
| mup | PR #1717: daemon,overlord: add subcommand handling to snapctl <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1717> | 21:29 |
| kyrofa | Wow, what's the changes both PRs would be by me | 21:29 |
| kyrofa | Uh. Chances | 21:30 |
| kyrofa | sergiusens, uh oh. Ever tried the asciinema snap on trusty? | 21:35 |
| kyrofa | I can't upload :P | 21:35 |
| kyrofa | Thankfully it captured. Guess I'll just scp it over | 21:35 |
| === dontbeadick is now known as CoderEurope | ||
| sergiusens | kyrofa from the snap? you need my version which has the compiled python | 21:42 |
| kyrofa | sergiusens, I don't see one from you in snap find. Is it stable? | 21:43 |
| sergiusens | kyrofa oh, I don't have it pushed even | 21:43 |
| kyrofa | Hahaha | 21:43 |
| kyrofa | You should make a PR for sabdfl | 21:44 |
| sergiusens | I don't know where that code is, and I'd rather have it as the experiment snap to test out the classic stuff | 21:44 |
| mup | PR snapd#4211 closed: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4211> | 21:54 |
| mup | PR snapd#4218 opened: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4218> | 21:54 |
| sergiusens | elopio I have a question on your PR | 21:56 |
| === jero is now known as Guest21343 | ||
| sergiusens | kyrofa do you think my question on snapcraft#1734 is a concern? | 22:20 |
| mup | PR snapcraft#1734: recording: don't log the command when image info fails <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1734> | 22:20 |
| kyrofa | sergiusens, it's a good question, but I feel like elopio answered it, no? | 22:22 |
| sergiusens | kyrofa ah, I hadn't seen the reply; still would like to see some corroborration | 22:23 |
| kyrofa | Gah, thunderbird sucks. It doesn't upload my folders | 22:24 |
| kyrofa | I didn't see that he answered my question either | 22:24 |
| kyrofa | s/upload/update/ | 22:24 |
| * ikey adds handy debug tools to lsi.. | 22:28 | |
| ikey | https://ibin.co/3hJKqbCtvh86.png ^^ | 22:28 |
| mup | PR snapcraft#1736 opened: recording: pass the build info flag to the container <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1736> | 22:30 |
| elopio | sergiusens: kyrofa: I found a recording bug ^ | 22:31 |
| kyrofa | elopio, ah, good catch | 22:32 |
| kyrofa | elopio, is that required for this release, though? | 22:32 |
| kyrofa | Seems like an issue we've probably had for a while | 22:32 |
| mup | PR snapcraft#1734 closed: recording: don't log the command when image info fails <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1734> | 22:33 |
| sergiusens | snappy-m-o autopkgtest 1732 artful:amd64 | 22:34 |
| snappy-m-o | sergiusens: I've just triggered your test. | 22:34 |
| sergiusens | elopio kyrofa I am fine with snapcraft#1736 | 22:36 |
| mup | PR snapcraft#1736: recording: pass the build info flag to the container <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1736> | 22:36 |
| sergiusens | sort of needed to show off the feature neatly | 22:36 |
| kyrofa | Alright | 22:37 |
| sergiusens | kyrofa stop living in the past, go in all webapps 💩 | 22:38 |
| kyrofa | sergiusens, hahaha | 22:38 |
| elopio | kyrofa: sergiusens: the past is the new future! Use mutt | 22:40 |
| sergiusens | elopio can you open calendar invites there? | 22:41 |
| sergiusens | everything is so embedded with "the web" these days that it is hard to use something that doesn't support it | 22:41 |
| kyrofa | Apparently it's just too much to ask for decent system integration | 22:41 |
| elopio | I would love to use a text browser. But I always give up too soon. | 22:43 |
| elopio | sergiusens: I copy the calendar link from mutt to firefox | 22:44 |
| elopio | but I haven't been able to configure gmail there. I need to get back to bother m vo. | 22:45 |
| elopio | ok, I will have lunch while my new branch is green, then come back to continue recording with asciinema | 22:47 |
| sergiusens | elopio cannot do much in text browsers theses days | 22:47 |
| ikey | how do i go about signing a snap? | 22:48 |
| sergiusens | ikey https://forum.snapcraft.io/t/isv-questions-about-signing-a-snap/2546 | 22:54 |
| ikey | sign-build doesn't work | 22:56 |
| ikey | does it? | 22:56 |
| ikey | Native builds aren't supported on Solus. You can however use 'snapcraft cleanbuild' with a container. | 22:56 |
| ikey | nay | 22:56 |
| sergiusens | ikey once you have the snap, you should be able to `snapcraft sign-build`, it should work and if it doesn't we can make it work | 22:57 |
| sergiusens | btw, you read fast | 22:57 |
| ikey | lol | 22:57 |
| ikey | yeah i mean the main thing is i just wanna sign the snaps but i have my whole ugly manual build process | 22:57 |
| sergiusens | snapcraft sign-build <snap-file> given all the keys are in place should be doable | 22:57 |
| ikey | (its hella inefficient and i need to fix that) | 22:57 |
| ikey | yea | 22:57 |
| ikey | so i assume i have to create keys via the API only | 22:57 |
| ikey | not my own local keys | 22:58 |
| ikey | so they're registered in some fashion | 22:58 |
| sergiusens | ikey internally they are just gpg keys, but I think the system is very strict on poor keys (not saying yours are); you might get away with using your current keys by means of symlinking the directory the snap command looks for | 22:58 |
| ikey | ah ok | 22:59 |
| sergiusens | ikey yes, snapcraft register-key pushes it to some vault on the store for corroboration | 22:59 |
| sergiusens | ikey I am being vague on the store side, and keys for that matter, as this is not my best area of expertise | 22:59 |
| ikey | sub rsa4096 2016-02-22 [E] [expires: 2018-02-21] | 22:59 |
| ikey | lol | 22:59 |
| sergiusens | also, once you sign snaps, I don't think you can go back to unsigned ones | 23:00 |
| sergiusens | cprov care to expand on my ignorant comments? ^ | 23:01 |
| ikey | gotcha | 23:01 |
| ikey | fwiw in the initial stages we've no need to sign them | 23:01 |
| ikey | as they'll be in the store on --edge only | 23:01 |
| sergiusens | ikey fwiw, help for snapcraft says: `Usage: snapcraft sign-build [OPTIONS] <snap-file>` | 23:01 |
| ikey | oh do i need to explicitly set grade/confinement to edge/devmode for now? | 23:01 |
| ikey | gotcha | 23:02 |
| ikey | er grade devel | 23:02 |
| ikey | even | 23:02 |
| cprov | sergiusens: what you say is true, once signed there is no reason to pull it back | 23:02 |
| sergiusens | ikey no, no need; but if it requires devmode I would and if you do not want to accidentally have that same snap build make it to candidate or stable then set grade to devel | 23:02 |
| ikey | yea | 23:03 |
| ikey | ty | 23:03 |
| * ikey was worried about that | 23:03 | |
| ikey | do base snaps have confinement..? | 23:03 |
| cprov | the key might be revoked or expired and the signature won't be valid anymore | 23:03 |
| ikey | ack | 23:04 |
| * ikey is muchly looking forward to having snap updates instead of doing the whole reinstall doflicky | 23:05 | |
| cprov | sergiusens: "once you sign snaps, I don't think you can go back to unsigned ones", not true thou, there is nothing enforcing snaps to continue to be signed. 'snap-build' is per-snap-revision | 23:05 |
| sergiusens | cprov wait I am confused, it seems you said the opposite just above :-P | 23:06 |
| cprov | sergiusens: the scope is the snap revision, once signed it cannot be unsigned (mainly because a snap revision is immutable) | 23:07 |
| cprov | sergiusens: in terms of workflow, subsequent revisions can be either signed or unsigned, there is nothing enforcing "signed from now on" (or anything similar) | 23:08 |
| cprov | there are proposals like https://forum.snapcraft.io/t/isv-questions-about-signing-a-snap/2546 | 23:08 |
| cprov | sergiusens: un-confused ? | 23:08 |
| cprov | sergiusens: and yes, I've misinterpreted your comment at first, sorry. | 23:10 |
| sergiusens | no worries | 23:10 |
| sergiusens | all good | 23:10 |
| sergiusens | ikey wrt base snaps, if they have no apps entries in snap.yaml there is no reason for them to be confined, essentially what ends up being confined is what is under `apps`, so the "users" of the base snap will drive the confinement | 23:11 |
| cprov | sergiusens: 👍 | 23:11 |
| sergiusens | that said, I am not authoritative on this matter either, just using my spider senses | 23:12 |
| ikey | sergiusens, ack :] | 23:12 |
| sergiusens | elopio please make sure snapcraft#1736 is bullet proof | 23:12 |
| mup | PR snapcraft#1736: recording: pass the build info flag to the container <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1736> | 23:12 |
| sergiusens | it looks like it is, but we have been fooled before | 23:13 |
| elopio | I tested it to confirm the fix. It's no different than the existing var, so I see no room for failure. | 23:14 |
| elopio | But, I appreciate thorough reviews. | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
