| mup | PR snapcraft#1958 opened: Migrating to more granular store permission <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1958> | 03:18 |
|---|---|---|
| mborzecki | morning | 06:10 |
| mup | PR snapd#4733 closed: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4733> | 06:38 |
| mup | PR snapd#4732 closed: [2.31] timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4732> | 06:42 |
| mup | PR snapd#4734 closed: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.31 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4734> | 06:42 |
| mup | PR snapd#4736 closed: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.32 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4736> | 06:42 |
| mup | PR snapd#4713 closed: cmd/snap: add self-strace to `snap run` <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4713> | 06:50 |
| mvo | hey mborzecki ! good morning | 06:50 |
| mborzecki | mvo: hey, morning | 06:51 |
| mborzecki | mvo: is it also that cold where you live? | 06:51 |
| mvo | mborzecki: yeah, unusually cold. up to minus 10 or so in the nights | 06:51 |
| mvo | mborzecki: very clear skys all the time, sunny but bitter cold :) | 06:52 |
| mborzecki | mvo: my outside thermometer is showing -14 atm | 06:52 |
| mborzecki | mvo: yeah, it's clear and sunny.. and cold :P | 06:52 |
| mvo | mborzecki: woah, -14 even | 06:53 |
| mvo | impressive! | 06:53 |
| mborzecki | my dogs were unimpressed this morning :) | 06:53 |
| mvo | heh | 06:53 |
| * mvo checks his outside thermometer | 06:54 | |
| mup | PR snapd#4739 opened: many: remove snapd.refresh.{timer,service} <Created by mvo5> <https://github.com/snapcore/snapd/pull/4739> | 07:08 |
| zyga | good morning | 07:15 |
| mvo | hey zyga ! good morning | 07:15 |
| zyga | hey | 07:16 |
| zyga | mvo I experienced something very odd last nigth | 07:16 |
| zyga | 54 Do 2018-02-24T10:49:28Z - Auto-refresh snap "core" | 07:16 |
| zyga | my snapd is stuck updating | 07:16 |
| zyga | I sent a pastebin as well, still valid: https://pastebin.ubuntu.com/p/sj6s9qNzFQ/ | 07:17 |
| zyga | and I had one denial | 07:17 |
| zyga | lut 25 22:08:15 fyke kernel: audit: type=1400 audit(1519592895.774:1751): apparmor="DENIED" operation="exec" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-device-helper" pid=39793 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 | 07:17 |
| zyga | I'm currently on core 16-2.29.4.2 4144 canonical core | 07:17 |
| zyga | I wonder if this is some bad revision that didn't have the symlink to make it work | 07:18 |
| zyga | or if we missed something bigger | 07:18 |
| zyga | and release will break | 07:18 |
| zyga | oh, and none of the snaps work now | 07:18 |
| zyga | they fail with that same denial | 07:19 |
| mup | PR snapd#4737 closed: cmd/snap: tweaks to 'snap info' (feat. installed->current rename) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4737> | 07:19 |
| zyga | looking at snapd.service logs I see one more error: | 07:20 |
| zyga | lut 24 11:49:38 fyke snapd[35097]: 2018/02/24 11:49:38.755234 backend.go:91: cannot create host `snap userd` dbus service file: failed to copy all: "cp: nie | 07:20 |
| zyga | and that's all | 07:21 |
| zyga | ideas welcome, I'm not sure what's failed | 07:21 |
| zyga | for instance, I don't understand why the change is stuck | 07:22 |
| zyga | why is it not auto-connecting things | 07:22 |
| zyga | deadlock? | 07:22 |
| mvo | zyga: uh, thats serious if that is stable to stable | 07:35 |
| mvo | zyga: yeah, its very strange. 2.29 you say? its double strange as it should also have tried to go to 2.30 before already | 07:36 |
| zyga | I think something odd has happened | 07:37 |
| zyga | it is on distro package now | 07:37 |
| zyga | I didn't set any reexec flags | 07:38 |
| zyga | nothing in /etc/environment | 07:38 |
| zyga | any ideas on what to check for next? | 07:38 |
| zyga | note: I installed a snap on Friday evening | 07:38 |
| zyga | mvo how can I be on 4144 which is more recent than beta but less recent than core | 07:43 |
| zyga | and still be on 2.29.4.2?!? | 07:43 |
| zyga | is. that some build that was made to make an out-of-bounds release | 07:43 |
| zyga | this makes no sense to me | 07:43 |
| mvo | zyga: what channel are you tracking? | 07:53 |
| zyga | edge | 07:54 |
| mvo | zyga: and what does "apt list --all snapd" show? | 07:54 |
| mvo | zyga: edge, huh | 07:54 |
| zyga | Name Version Rev Developer Notes | 07:54 |
| zyga | core 16-2.31+git583.0e8bcef 4104 canonical core,disabled | 07:54 |
| zyga | core 16-2.31+git586.d89ba3c 4117 canonical core,disabled | 07:54 |
| zyga | core 16-2.31.1+git587.d3e52a0 4133 canonical core,disabled | 07:54 |
| zyga | core 16-2.29.4.2 4144 canonical core | 07:54 |
| mvo | zyga: apt :) | 07:55 |
| zyga | given this revision progression | 07:55 |
| zyga | haha | 07:55 |
| mvo | zyga: you mentioned your packaged version is run | 07:55 |
| zyga | I didn't see apt | 07:55 |
| zyga | I replaced "snapd" with core without thinking though | 07:55 |
| zyga | yeah | 07:55 |
| zyga | because of the +17.10 version | 07:55 |
| zyga | zyga@fyke:~/go/src/github.com/snapcore/snapd$ snap version | 07:55 |
| zyga | snap 2.29.4.2+17.10 | 07:55 |
| zyga | snapd 2.29.4.2+17.10 | 07:55 |
| zyga | mvo is it sane that 4144 has version 16-2.29.4.2? | 07:56 |
| mvo | zyga: no, that does not sound sensible | 07:57 |
| zyga | can you pull that revision and check? | 07:57 |
| mvo | zyga: what does snap changes show? is it maybe trying to refresh for some time wihtout success? | 07:57 |
| zyga | ID Status Spawn Ready Summary | 07:57 |
| zyga | 54 Do 2018-02-24T10:49:28Z - Auto-refresh snap "core" | 07:57 |
| zyga | 55 Done 2018-02-26T00:51:39Z 2018-02-26T00:51:39Z Refresh all snaps: no updates | 07:57 |
| zyga | I pastebinned snap change 54 earlier | 07:57 |
| mvo | zyga: and before that? when was the last successful core update? | 07:58 |
| zyga | that 55 is "fun" because there *are* updates but core has changes in progress | 07:58 |
| zyga | there's nothing more, is there a switch for earlier history? | 07:58 |
| mvo | zyga: uh, you are right: 4144 2018-02-24T04:25:30Z amd64 16-2.29.4.2 edge | 07:58 |
| mvo | zyga: so it looks like on sat we had 2.29.4.2 in edge for a brief time before a new build kicked in | 08:00 |
| mvo | zyga: and we got the git version again | 08:00 |
| zyga | store bug? | 08:00 |
| mvo | zyga: so you went from master (from friday) to 2.29.4.2 and then back to git and that seems to be not working | 08:00 |
| mvo | zyga: I think more a problem with the snap-cron publish to edge thing | 08:01 |
| mvo | zyga: what does `snap version` give you? | 08:03 |
| mvo | zyga: i.e. which version is active right now? | 08:03 |
| mvo | zyga: (sorry if you said this already) | 08:03 |
| zyga | 2.29.4.2 | 08:03 |
| zyga | since all other versions are deactivated | 08:03 |
| pstolowski | good morning! | 08:03 |
| zyga | well | 08:04 |
| zyga | 2.29.4.2+17.10 | 08:04 |
| zyga | so that is the vanilla packaged version | 08:04 |
| mvo | zyga: so here is my theory: you started with 2.32~git, that generated a new auto-connect tasks, then it installed core 2.29.4.2 because of silliness, then that rebooted and tried to do the tasks that are in the state | 08:04 |
| mvo | zyga: however 2.29.4.2 does not know about auto-conneect so its stuck in doing | 08:04 |
| zyga | didn't we have an unknown task handler now? | 08:05 |
| zyga | maybe not in 2.29 | 08:05 |
| mvo | zyga: exactly, not in 2.29 | 08:05 |
| mvo | zyga: fortunately its only people tracking edge that are affected and the change will be auto-abort after 7(?) days | 08:05 |
| mvo | zyga: still not great | 08:05 |
| zyga | do we keep track of the edge publishing cron job | 08:06 |
| zyga | to ensure this was really it? | 08:06 |
| mvo | zyga: I think so, we have the spread-cron logs for vendor-sync and the ppa upload history and the core build logs | 08:07 |
| zyga | btw, off-topic: I will have some fixes to layouts | 08:09 |
| zyga | can we do another RC? | 08:09 |
| mvo | zyga: yes | 08:09 |
| zyga | this will make them work on core | 08:09 |
| zyga | excellent | 08:09 |
| zyga | I will have two or three patches | 08:09 |
| zyga | just running spread to make sure it's green before I start chopping | 08:09 |
| zyga | wow | 08:10 |
| zyga | mvo I aborted change 54 and instantly I got a change 66 that refreshed core correctly | 08:10 |
| zyga | I'm tracking edge again now | 08:10 |
| mvo | zyga: sounds good, either a 2.32 targeted PR or make the PR with as little commits as possible so that we/i/you can cherry-pick | 08:10 |
| mvo | zyga: thanks for confirming, so it will auto-heal | 08:11 |
| zyga | those will be separate for review and because they are not related; each one should be ok to cherry-pick | 08:11 |
| kalikiana | moin moin | 08:12 |
| zyga | hey kalikiana | 08:12 |
| zyga | woot :) | 08:19 |
| zyga | it passed :) | 08:19 |
| === Tenente is now known as LtWorf | ||
| mup | PR snapd#4740 opened: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink <Created by zyga> <https://github.com/snapcore/snapd/pull/4740> | 08:35 |
| zyga | mvo 1st PR: https://github.com/snapcore/snapd/pull/4740/files | 08:35 |
| mup | PR #4740: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink <Created by zyga> <https://github.com/snapcore/snapd/pull/4740> | 08:35 |
| zyga | mvo 2nd PR: https://github.com/snapcore/snapd/pull/4741/files | 08:38 |
| mup | PR #4741: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4741> | 08:38 |
| zyga | once those land the spread test should pass | 08:38 |
| mup | PR snapd#4741 opened: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4741> | 08:39 |
| * zyga -> breakfast | 08:54 | |
| Chipaca | morning! | 08:59 |
| zyga | hey | 09:00 |
| zyga | I saw your PR last night | 09:00 |
| Chipaca | zyga: which of 'em? | 09:01 |
| Chipaca | it's been a fun weekend :-) | 09:01 |
| zyga | the one on sunday night | 09:02 |
| zyga | anyway, I will go over PRs soon | 09:02 |
| zyga | but some 2.32 things first | 09:02 |
| pedronis | mvo: hi, thinking a bit, in 2.32 we should probably not ask for snap_yaml_raw on snap find/store.Find | 09:10 |
| mvo | pedronis: ok, what is the alternative we should use? | 09:11 |
| pedronis | mvo: ? | 09:11 |
| mvo | pedronis: we need the plugs to get the default provider | 09:11 |
| mvo | pedronis: we use snap_yaml_raw to get that data | 09:11 |
| pedronis | mvo: I'm saying we should ask for details | 09:11 |
| pedronis | but not find | 09:11 |
| mvo | pedronis: oh, on find? yes | 09:12 |
| mvo | pedronis: that sounds sensible | 09:12 |
| pedronis | mvo: we don't use it | 09:12 |
| pedronis | afaict | 09:12 |
| pedronis | on find | 09:12 |
| Chipaca | oooh, oohh | 09:12 |
| Chipaca | can i work on that? | 09:12 |
| pedronis | is just that fields is the same for all | 09:12 |
| Chipaca | :-) | 09:12 |
| pedronis | atm | 09:12 |
| Chipaca | i've been wanting to make fields per request | 09:12 |
| pedronis | Chipaca: yes, please, as I said, something we can still add to 2.32 though | 09:13 |
| Chipaca | 2.32 is _right now_, no? | 09:13 |
| pedronis | yes | 09:13 |
| Chipaca | ok | 09:13 |
| pedronis | but I suspect we neeld .x | 09:13 |
| Chipaca | (btw, if you guys haven't tried the Go (mono) font, you should) | 09:14 |
| mvo | Chipaca: yeah, please do! we are at 2.32~pre1 so as long as it can be cherry picked all is well | 09:14 |
| palasso | Hello, I'm a bit confused about something. Are the channel risks 4 (stable, candidate, beta, edge) or can there be more? | 09:14 |
| Chipaca | palasso: the risks are those four | 09:14 |
| palasso | https://forum.snapcraft.io/t/channels-2-0-implementation/156 | 09:15 |
| palasso | "This allow publishers to go beyond the current 4 channels we offer and provide custom channels." | 09:16 |
| Chipaca | palasso: risks != channels | 09:16 |
| Chipaca | palasso: a channel is track/risk[/branch] | 09:16 |
| palasso | So the channels go beyond in the sense of having tracks and branches? | 09:16 |
| Chipaca | palasso: with a default track of 'latest' | 09:16 |
| Chipaca | palasso: I think I've been in the 'new' channels world for too long and I don't remember well being where you are, but I'll try | 09:17 |
| Chipaca | palasso: we used to have just four channels, representing risk levels | 09:17 |
| Chipaca | palasso: what used to be just 'stable', is now fully called latest/stable | 09:18 |
| Chipaca | palasso: (although we'll still call it just stable, because the latest/ is implied) | 09:18 |
| Chipaca | palasso: and, devs can ask for more "tracks", which is the 'latest' bit | 09:18 |
| palasso | Ahh I see | 09:18 |
| Chipaca | palasso: if you do «snap info go» you'll see a good example | 09:18 |
| palasso | Chipaca: If an app were to have an "LTS" stable release (e.g. firefox has ESR) how would they do it under the current 4 risks model? they'd introduce an ESR/stable? | 09:19 |
| Chipaca | palasso: yes, or if there are going to be multiple ESRs (like Ubuntu has multiple supported LTSs), they could call it something more specific | 09:20 |
| Chipaca | palasso: or have both, a generic ESR that tracks the latest ESR, and a more specific ESR-x-y-z | 09:20 |
| palasso | I see, thank you :) | 09:21 |
| Chipaca | palasso: the mysql snap also makes good use of tracks | 09:21 |
| pedronis | that's why tracks were introduced, to support parallel streams of maintained releases | 09:21 |
| palasso | Okay I'll check out go and mysql. Thank you for providing me examples as well | 09:21 |
| Chipaca | palasso: a bad example of a snap is if you have a commercial and a free version, you shouldn't really use tracks for one and t'other | 09:22 |
| Chipaca | s/bad example of a snap/bad example of a use of tracks for a snap/ | 09:22 |
| palasso | Yeah I've noticed for example how JetBrains does it | 09:22 |
| Chipaca | k | 09:23 |
| * Chipaca gets back to codin' | 09:23 | |
| Chipaca | mvo: I was meant to write a forum topic before that current pr got merged | 09:24 |
| Chipaca | :-) | 09:24 |
| * Chipaca writes | 09:24 | |
| Chipaca | also! mvo, pedronis, zyga, (mborzecki, pstolowski?), niemeyer, feedback appreciated on the 'debugging tab completion' tutorialish thing | 09:25 |
| zyga | Chipaca where can we read it? | 09:25 |
| Chipaca | https://forum.snapcraft.io/t/debugging-tab-completion/4198 | 09:25 |
| mup | PR snapd#4730 closed: userd/tests: Test kdialog calls and mock kdialog too to make tests work in KDE <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4730> | 09:33 |
| Chipaca | mvo: #4737 isn't going to sneak into 2.32, right? | 09:39 |
| mup | PR #4737: cmd/snap: tweaks to 'snap info' (feat. installed->current rename) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4737> | 09:39 |
| Chipaca | ie it's 2.33 material, which is not for another month/ | 09:39 |
| Chipaca | ? | 09:39 |
| mvo | Chipaca: if there is a compelling reason we can cherry pick it | 09:41 |
| mvo | Chipaca: its still early in 2.32 | 09:41 |
| Chipaca | mvo: on the contrary, I want it _not_ in 2.32 | 09:44 |
| Chipaca | mvo: to give people more forewarning of the change | 09:44 |
| Chipaca | mvo: am I right in guesstimating 2.33 is a month away? | 09:44 |
| Chipaca | from hitting stable | 09:44 |
| Chipaca | or is it a month from release, and another month to stable? | 09:45 |
| mborzecki | zyga: pstolowski: can give #4695 another pass? | 09:47 |
| mup | PR #4695: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695> | 09:47 |
| zyga | yes, in a moment | 09:48 |
| mborzecki | great, thanks | 09:48 |
| pedronis | Chipaca: it should go to beta around when 2.32 goes to stable (roadmap says mar 12), but we still have things for 18.04 that are not in 2.32, not sure how that will play on 2.33 timing | 09:49 |
| Chipaca | pedronis: mar12 is right after the sprint | 09:50 |
| Chipaca | that seems to be setting us up for insanity | 09:50 |
| Chipaca | let's not do that :-) | 09:50 |
| pedronis | do what? | 09:50 |
| Chipaca | pedronis: set ourselves up for insanity | 09:50 |
| * pedronis expects Mar to be insane | 09:50 | |
| pstolowski | mborzecki, sure, sorry i didn't do that last Fri, will do | 09:55 |
| zyga | I need two reviews for critical PRs | 09:57 |
| Chipaca | zyga: shout | 10:00 |
| zyga | last two open PRs | 10:00 |
| zyga | one trivial | 10:00 |
| zyga | one more complex | 10:00 |
| zyga | 4740 is trivial | 10:00 |
| mup | PR snapd#4728 closed: store: move infoFromRemote into details.go close to snapDetails <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4728> | 10:00 |
| Chipaca | zyga: you're going to need el jay-dee to look at 4741 i think | 10:08 |
| Chipaca | zyga: am I reading it right that with this change we _always_ use detach? | 10:10 |
| zyga | for directories, yes | 10:10 |
| zyga | for files we keep the regular thing | 10:10 |
| Chipaca | zyga: is that reasonable? | 10:10 |
| zyga | yes, as the commit message explains we have no other choice | 10:11 |
| Chipaca | i guess we don't record when we recursed? | 10:11 |
| zyga | no no, we always pair recurse with detach | 10:11 |
| zyga | we don't always detach | 10:11 |
| Chipaca | ah ok | 10:11 |
| zyga | or am I missing something | 10:11 |
| mvo | Chipaca: yeah, 2.33 is about a month away | 10:11 |
| zyga | I mean, that is the intent | 10:11 |
| Chipaca | zyga: https://github.com/snapcore/snapd/pull/4741/files#diff-4480ffd44957efa3395867c929f88014L377 | 10:13 |
| mup | PR #4741: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4741> | 10:13 |
| Chipaca | zyga: that's the bit that looked very unconditional | 10:13 |
| Chipaca | but i might be missing part of the logic | 10:13 |
| zyga | that's the safe keeping directory | 10:13 |
| zyga | it is originally rbind'ed | 10:13 |
| zyga | each rbind should be paired with MNT_DETACH | 10:14 |
| Chipaca | k | 10:14 |
| zyga | https://github.com/snapcore/snapd/pull/4741/files#diff-4480ffd44957efa3395867c929f88014L331 | 10:14 |
| Chipaca | heh, and pedronis agrees from backstage | 10:15 |
| mborzecki | 'backstage' ;) | 10:15 |
| Chipaca | 'bambalinas' translates as that, but it doesn't feel the same | 10:15 |
| Chipaca | ¯\_(ツ)_/¯ | 10:15 |
| zyga | hmm? | 10:15 |
| Chipaca | it's used as 'behind the scene' more than 'backstage', i guess, although those two are the same (but different) | 10:16 |
| Chipaca | zyga: he quietly added jdstrand as reviewer of the PR | 10:16 |
| zyga | oh I would definitely have jamie review it | 10:16 |
| pedronis | stage are scenes but not all scenes are stages | 10:16 |
| zyga | I said so last week | 10:16 |
| Chipaca | zyga: but who listens to you | 10:17 |
| Chipaca | pedronis: translating is hard | 10:17 |
| mup | PR snapd#4740 closed: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4740> | 10:22 |
| zyga | mvo any idea why snapd-control-with-manage consistently failed in your PR? | 10:27 |
| zyga | https://api.travis-ci.org/v3/job/346163312/log.txt | 10:27 |
| zyga | this is inside 4739 | 10:27 |
| mvo | zyga: let me check | 10:28 |
| mvo | zyga: yes, let me fix it | 10:29 |
| zyga | do you know what happened there? | 10:29 |
| mvo | zyga: yes, a leftover that checked for snapd.refresh in a test | 10:30 |
| mvo | zyga: I killed that and force pushed (for cherry-picking) | 10:31 |
| zyga | cool, thanks! | 10:31 |
| mborzecki | mvo: https://paste.ubuntu.com/p/4y6jghpWQz/ maybe you're missing this | 10:31 |
| mborzecki | mvo: I did those changes on Friday but didn't open a PR yet :) | 10:32 |
| mvo | mborzecki: yes, except for the first bit :) - echo 'from the store start/enable the snapd.service' is still needed, right? or will it be enabled (snapd.service) on arch on install? | 10:32 |
| mvo | mborzecki: if so I can kill it | 10:32 |
| mvo | mborzecki: that line | 10:32 |
| mborzecki | mvo: you can kill it to | 10:33 |
| mvo | mborzecki: cool | 10:33 |
| mborzecki | mvo: there's one peculiar scenario with the timers that I mentioned here https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/20 | 10:33 |
| mborzecki | not sure if anyone uses it like this, but if you only have snapd.socket enabled, then snapd will not run unless something activates it, and if so, no refreshes will be applied | 10:34 |
| mvo | mborzecki: are you sure it can be removed? the current install says "to use snapd start/enable the snapd.socket" but that means that on the next reboot snapd will only come up after "snap list" (or similar). so to get refreshes the user still has to enable the snapd.service so that it runs persistently? or am I missing something | 10:34 |
| mborzecki | mvo: yes, that PKGBUILD is not used and i'll be syncing it with the one that's in the AUR repo | 10:35 |
| * Chipaca -> break (physio) | 10:35 | |
| mborzecki | mvo: that echo was removed there as well | 10:35 |
| mvo | mborzecki: aha, I think we are on the same page. so we should keep the message about "systemctl start/enable snapd.service" ? | 10:36 |
| mborzecki | mvo: you can keep it for now | 10:36 |
| mvo | mborzecki: I mean, we should contribute that back to upstream (this echo?) | 10:36 |
| mvo | mborzecki: ok | 10:36 |
| mborzecki | zyga: pushed an update to 4695 | 10:38 |
| zyga | ack | 10:38 |
| mborzecki | mvo: what do you think about the case when only socket activation is enabled? | 10:39 |
| mvo | mborzecki: a good question, I think its an unsupported mode of operation, we should advice our packagers to recommend to enable the service. and if its not done, well | 10:40 |
| mvo | not much we can do - we could warn of course | 10:40 |
| mup | PR snapd#4727 closed: many: simplify mocking of home-on-NFS <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4727> | 10:42 |
| mborzecki | a bit crazy, but i thought we could do something like the timer services, autogenerate snapd.refresh.timer and have `snap refresh --timer='...'` | 10:42 |
| pedronis | we have a bunch of extra logic around refreshes | 10:49 |
| pedronis | we retry to some extent if they fail (but waiting at least some time) | 10:50 |
| mborzecki | pedronis: right, but it only works as long as snapd is running, whereas if you do socket activation only then it may not be running at all | 10:55 |
| pedronis | mborzecki: my point is more that implementing that way add different complexity to support an unsupported mode | 10:56 |
| mborzecki | pedronis: aah, you're right, maybe it's not worth doing this at all | 10:56 |
| pstolowski | mborzecki, my comment re systemd-analyze was about making sure we run this check on predefined systems (similiar to what we do in some spread tests) and not just rely on path lookup | 11:00 |
| pstolowski | mborzecki, but I'm not sure how to do that nicely and if it's worth it. just 'nice to have' | 11:00 |
| pstolowski | otherwise we have no guarantee we run this validation at all | 11:01 |
| mborzecki | pstolowski: we could fail the test if systemd-analyze is not found, but that seems a bit overager | 11:01 |
| mborzecki | s/overager/overeager/ | 11:01 |
| pstolowski | mborzecki, maybe just a warning that the check was disabled? | 11:01 |
| mup | PR snapcraft#1949 closed: repo: silence deb caching when fetching packages <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1949> | 11:05 |
| mborzecki | pstolowski: yeah, warning will probably do | 11:07 |
| mup | PR snapd#4742 opened: overlord/snapstate: verify that default schedule is randomized and is not a single time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4742> | 11:08 |
| mborzecki | so that we don't accidentally break the store again ^^ | 11:09 |
| * cachio afk | 11:12 | |
| zyga | jdstrand hey, please have a look at 4714 | 11:14 |
| zyga | jdstrand I think it can land for 2.32 cherry-pick then | 11:14 |
| zyga | (though it might be a bigger pick) | 11:14 |
| zyga | jdstrand please also look at a layout bugfix in 4741 | 11:15 |
| zyga | jdstrand with that in the spread test in 4644 passes | 11:15 |
| zyga | ok, now for a tiny break and then back to mount validation | 11:19 |
| * zyga FAIL: store_asserts_test.go:161: storeSuite.TestCheckAuthority | 11:31 | |
| * zyga store_asserts_test.go:180: | 11:31 | |
| * zyga c.Assert(err, ErrorMatches, `store assertion "store1" is not signed by a directly trusted authority: other`) | 11:31 | |
| * zyga ... error string = "store assertion timestamp outside of signing key validity (key valid since \"2018-02-26 10:45:06 +0000 UTC\")" | 11:31 | |
| * zyga ... regex string = "store assertion \"store1\" is not signed by a directly trusted authority: other" | 11:31 | |
| zyga | this popped up on an unrelated PR | 11:32 |
| zyga | pedronis ^ | 11:32 |
| zyga | the PR is 4739 | 11:32 |
| mborzecki | zyga: seen it a couple of times already | 11:32 |
| mborzecki | hmm the tst suite setup is using time.Now().Truncate(time.Second), while respective tests just do time.Now().Format(...) | 11:36 |
| mborzecki | zyga: are you updating those tests? | 11:37 |
| zyga | nope, go ahead please | 11:37 |
| zyga | I'm still trying to finish the race detector | 11:37 |
| mup | PR snapd#4742 closed: overlord/snapstate: verify that default schedule is randomized and is not a single time <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4742> | 11:47 |
| mborzecki | mvo: can you publish 2.31.1 release files on github? | 12:03 |
| mvo | mborzecki: sure, done | 12:11 |
| mup | PR snapcraft#1955 closed: meta: make sure adapter does not propagate <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1955> | 12:11 |
| mborzecki | mvo: thanks | 12:11 |
| mup | PR snapcraft#1844 closed: Included fix for error messages <codein> <Created by Tanesh1701> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1844> | 12:17 |
| zyga | mborzecki having read https://www.freedesktop.org/software/systemd/man/systemd.time.html I really think syntax is hard | 12:27 |
| mborzecki | zyga: ours or theirs? | 12:27 |
| zyga | theirs | 12:28 |
| mborzecki | zyga: yeah agreed, feels slightly awkward, on top of this, the entries OnCalendar, OnFoo.. are cumulative | 12:29 |
| mborzecki | don't recall if that's mentioned int he manuals or not | 12:29 |
| pedronis | zyga: might be related to the test renames, some tests that worked because of order, I will look | 12:38 |
| mup | PR snapd#4743 opened: packaging/arch: sync with snapd/snapd-git from AUR <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4743> | 12:39 |
| mup | PR snapd#4744 opened: testutil: allow mocking syscall.Fstat <Created by zyga> <https://github.com/snapcore/snapd/pull/4744> | 12:51 |
| === pbek_ is now known as pbek | ||
| mup | PR snapd#4745 opened: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <https://github.com/snapcore/snapd/pull/4745> | 13:06 |
| mup | PR snapd#4746 opened: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink <Created by zyga> <https://github.com/snapcore/snapd/pull/4746> | 13:24 |
| mup | PR snapd#4747 opened: cmd/snap-update-ns: use recursive bind mounts for writable mimic (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4747> | 13:28 |
| zyga_ | mvo I opened two PRs for 2.32 backport for overlay fixes | 13:30 |
| === zyga_ is now known as zyga | ||
| zyga | er, not overlay, layout | 13:32 |
| === chihchun_afk is now known as chihchun | ||
| mvo | zyga: ta | 13:38 |
| * pstolowski lunch | 13:57 | |
| * zyga needs to go out to do some errands, I'll be back later | 14:00 | |
| mup | PR snapcraft#1959 opened: elf: only patch elf files that aren't referenced by DT_NEEDED <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/1959> | 14:48 |
| cachio | mvo, already running beta validation | 14:59 |
| cachio | hello | 14:59 |
| mvo | cachio: good morning | 14:59 |
| mvo | cachio: thank you | 14:59 |
| mvo | cachio: how are things looking so far? | 15:00 |
| * kalikiana food | 15:03 | |
| cachio | mvo, about sru, is it ready to run the validation? | 16:18 |
| mvo | cachio: yes | 16:19 |
| cachio | ok, I'll start it | 16:19 |
| zyga | re :) | 16:35 |
| zyga | man it is *cold* outside | 16:35 |
| zyga | like really cold | 16:35 |
| zyga | I need warmer pants | 16:35 |
| zyga | jdstrand so looking at your response | 16:36 |
| zyga | apart from updating comments, do you want to see any other changes? | 16:36 |
| zyga | my main motivation for that is not having to chagne a lot of the algorithms behind the current process | 16:36 |
| mup | PR snapcraft#1746 closed: cli: add version command <bug> <Created by gsilvapt> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1746> | 16:36 |
| Chipaca | zyga: I've got something to warm the cockles of your heart | 16:36 |
| zyga | as we don't have to know what is currently mounted (via mountinfo) to get things correct | 16:37 |
| zyga | we only act on fstab delta | 16:37 |
| Chipaca | zyga: not as good as warm trousers, but https://pastebin.ubuntu.com/p/nd67wh7p3x/ | 16:37 |
| jdstrand | zyga: just the comment change, but that was based on your answer | 16:37 |
| zyga | Chipaca ohh | 16:38 |
| zyga | I like the raw sys call thing | 16:38 |
| zyga | I need to do that anyway | 16:38 |
| zyga | cool, let me update the comment then | 16:38 |
| Chipaca | pedronis: can you think of other fields that'd only be used for details? | 16:39 |
| pedronis | Chipaca: not without being backward incompatible | 16:40 |
| pedronis | Chipaca: we return most feilds through the rest api, no? | 16:40 |
| pedronis | I mean snap list doesn't use all them | 16:40 |
| pedronis | but in the api they are there | 16:40 |
| Chipaca | pedronis: well, I'll stop asking for the channel map (but we weren't getting it anyway) | 16:40 |
| jdstrand | zyga: can you re-review PR 4714 when you get a chance? the test failure was unrelated. I restarted travis | 16:41 |
| mup | PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714> | 16:41 |
| pedronis | Chipaca: in search | 16:41 |
| zyga | jdstrand yes, sure | 16:41 |
| zyga | jdstrand btw, I merged master into it today | 16:41 |
| zyga | did you see that? | 16:41 |
| pedronis | Chipaca: that's ok | 16:41 |
| Chipaca | pedronis: yep | 16:41 |
| zyga | ah, you did | 16:41 |
| Chipaca | bah, maybe i'm going too meta | 16:41 |
| zyga | cool, lookin g | 16:41 |
| Chipaca | and i should make it simpler | 16:41 |
| Chipaca | hmmm | 16:41 |
| Chipaca | especially if we're going to throw this away for v++ | 16:41 |
| Chipaca | yeah, screw it | 16:42 |
| pedronis | Chipaca: the old code is complicated mostly for tests | 16:42 |
| * Chipaca git revert's | 16:42 | |
| zyga | oh | 16:42 |
| zyga | so I learned something today :) | 16:42 |
| Chipaca | zyga: ? | 16:42 |
| pedronis | Chipaca: new api is diferent, also I'm also testing it differently | 16:42 |
| Chipaca | pedronis: good :-) | 16:42 |
| pedronis | Chipaca: I'm testing the equivalent of infoFromRemote which we didn't | 16:42 |
| Chipaca | pedronis: if it were the same i'd start asking if we learned nothing :-) | 16:42 |
| pedronis | and makes for verbose tests | 16:42 |
| pedronis | for everything | 16:42 |
| zyga | jdstrand so to understand this correctly, if the upperdir has space we need quoting to make that work? | 16:43 |
| Chipaca | pedronis: are you using detailFields for anything? | 16:43 |
| zyga | and with that, brb, I'll make some tea, it's sooo cold today | 16:43 |
| jdstrand | zyga: yes, the parser will not like it | 16:43 |
| pedronis | Chipaca: no, a have a different list | 16:43 |
| pedronis | s/a have/I have/ | 16:43 |
| pedronis | that is a global | 16:43 |
| pedronis | not coming from config | 16:43 |
| pedronis | and many fields have new names or are grouped in the new api | 16:44 |
| pedronis | Chipaca: you can hardcode stuff, if you can keep the tests happy | 16:45 |
| Chipaca | pedronis: yup | 16:49 |
| Chipaca | pedronis: resisting the temptation of kaizen | 16:49 |
| Chipaca | for this one | 16:49 |
| Chipaca | must . resist . | 16:49 |
| jdstrand | roadmr: hey, fyi, the store is occasionally oopsing when adding feedback | 16:54 |
| pedronis | mvo: I'm getting this: overlord/ifacestate/handlers.go:580: github.com/snapcore/snapd/overlord/state.Retry composite literal uses unkeyed fields from go vet here | 16:54 |
| roadmr | jdstrand: got an oops id for me? | 16:54 |
| jdstrand | OOPS ID: OOPS-612e03a3abfe4e63b67bd58b51731171 | 16:54 |
| roadmr | thanks! | 16:55 |
| zyga | jdstrand (re, suspended) - does our live media use whitespace in upperdir? | 16:55 |
| jdstrand | roadmr: that was putting in the text and doing 'Ask for information' | 16:55 |
| jdstrand | roadmr: there was another when I went to the feedback url that oops. I lost that oppsid | 16:55 |
| jdstrand | zyga: no | 16:55 |
| roadmr | jdstrand: oh I see. It's trouble contacting rabbitmq (the thing you're doing presumably uses a celery task) | 16:56 |
| zyga | jdstrand so what triggered the use of " ", the fact that it is possible? | 16:56 |
| jdstrand | zyga: the idea is simple-- we are getting something from outside of snappy and injecting it into policy | 16:56 |
| zyga | right | 16:56 |
| roadmr | jdstrand: and this is in turn because at least one of our rabbitmq units was rebooted for upgrade purposes | 16:56 |
| zyga | just wanted to understand that bit | 16:56 |
| jdstrand | zyga: so yes, being cautious. we didn't need it when the policy was hard-coded before, but now we are detecting, so I am being defensive | 16:56 |
| jdstrand | roadmr: does that mean it is temporary? | 16:57 |
| roadmr | jdstrand: yes, checking current status of rabbit | 17:00 |
| nathancahill | Have some odd behavior with Ubuntu Core (on Docker) vs Ubuntu Desktop | 17:01 |
| nathancahill | Fonts aren't being loaded from the file:// protocol in Firefox on Ubuntu Core | 17:01 |
| nathancahill | Works fine on Ubuntu Desktop though. Also works fine if they are served via http | 17:01 |
| Chipaca | nathancahill: so you've got Firefox, on X? mir? wayland?, on ubuntu core, on docker, and it's not loading fonts from file:/// | 17:04 |
| Chipaca | nathancahill: ? | 17:04 |
| nathancahill | firefox headless (latest build supports running headless with no display server) | 17:05 |
| Chipaca | nice | 17:06 |
| nathancahill | yeah, it's really slick | 17:07 |
| roadmr | jdstrand: things look healthy here, can you retry those things you were doing? | 17:08 |
| zyga | jdstrand does https://github.com/snapcore/snapd/pull/4741/commits/8169900842c19cb09cb9510bdbafb4e8ca61554e look all right now? | 17:09 |
| mup | PR #4741: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4741> | 17:09 |
| nathancahill | can't figure out the exact different between the ubuntu snap build and ubuntu desktop that's causing the issue though | 17:10 |
| nathancahill | i installed ubuntu-server and ubuntu-desktop on top of ubuntu:latest and the issue persists | 17:10 |
| zyga | Chipaca as to your pastebin | 17:11 |
| zyga | Chipaca is that string zero terminated? | 17:11 |
| zyga | I don't think it is in that way you wrote it | 17:11 |
| zyga | Pharaoh_Atem hey, what do I need to reproduce the problem | 17:12 |
| zyga | is F27 sufficient or do I need F28? | 17:12 |
| Pharaoh_Atem | zyga: you need F28 | 17:12 |
| zyga | ah, thanks, I will update then | 17:12 |
| zyga | jdstrand if you ack that patch I will also push it into the 2.31 PR | 17:13 |
| zyga | er | 17:13 |
| zyga | 2.32 | 17:13 |
| Chipaca | zyga: yes | 17:15 |
| Chipaca | #fingerscrossed | 17:15 |
| Chipaca | :-) | 17:15 |
| Chipaca | zyga: I haven't checked why, but it works like that, so yeah | 17:15 |
| zyga | you need something ... | 17:15 |
| zyga | like... | 17:15 |
| Chipaca | zyga: to actually do that kind of thing, I'd suggest checking (or enforcing) :-) | 17:16 |
| jdstrand | roadmr: I tried a couple more, it seems fine now | 17:16 |
| roadmr | jdstrand: yay thanks! | 17:16 |
| zyga | https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/bootstrap.go#L96 | 17:17 |
| jdstrand | zyga: approved, thanks | 17:18 |
| zyga | woot, thank you | 17:18 |
| * Chipaca looks around for mvo | 17:21 | |
| zyga | Chipaca he went for hockey | 17:21 |
| mup | PR snapd#4744 closed: testutil: allow mocking syscall.Fstat <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4744> | 17:21 |
| mup | PR snapd#4748 opened: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/4748> | 17:21 |
| Chipaca | smart | 17:21 |
| Chipaca | pedronis: ^ | 17:21 |
| pedronis | thx, will look in a bit | 17:22 |
| * zyga installs more ram | 17:22 | |
| pedronis | Chipaca: one comment | 17:29 |
| Chipaca | pedronis: I could rename the function to `getStructFieldsExceptSnapYAML` | 17:31 |
| pedronis | Chipaca: still strange | 17:31 |
| Chipaca | pedronis: what I'd been doing before reverting everything was having another tag | 17:32 |
| pedronis | that is overkill | 17:32 |
| Chipaca | e.g. only:"SnapInfo" | 17:32 |
| pedronis | though | 17:32 |
| Chipaca | pedronis: getStructFields(theStruct, anException) and it skips just that tag? | 17:33 |
| Chipaca | even a list there feels silly :-) | 17:34 |
| pedronis | it can be a list, no? | 17:34 |
| Chipaca | I mean, it can, but we're only going to use it for one | 17:34 |
| pedronis | we have strings.ListContains | 17:34 |
| Chipaca | and we're calling this thing for every request (which is stoopid) | 17:34 |
| Chipaca | ah wait | 17:34 |
| pedronis | are we? | 17:34 |
| Chipaca | no | 17:34 |
| Chipaca | no ,not the getStructFields | 17:34 |
| pedronis | I hope not | 17:34 |
| Chipaca | ok, fair | 17:34 |
| Chipaca | doing the change | 17:34 |
| pedronis | Chipaca: in case this is annoying, I'm using getStructFields in the new code | 17:35 |
| Chipaca | pedronis: ah, then it's fine | 17:35 |
| pedronis | that's why the hard coded old style field is a bit strange | 17:35 |
| Chipaca | yeah, i thought getStructField was done for | 17:35 |
| Chipaca | ok | 17:35 |
| pedronis | it seems useful, to not forget field | 17:36 |
| pedronis | s | 17:36 |
| Chipaca | pedronis: one change I'd like to make, which might be silly, is to change it to take a pointer to a struct instead of a struct | 17:36 |
| pedronis | that's fine | 17:36 |
| Chipaca | pedronis: ok, i'll do that in a separate pr then | 17:36 |
| zyga | mvo oooh | 17:37 |
| zyga | I just ran "htop" | 17:37 |
| zyga | and got the c-n-f thing :) | 17:37 |
| zyga | snap htop or deb htop | 17:37 |
| pedronis | Chipaca: also I suppose the exceptions can be ...string | 17:37 |
| zyga | what I'm missing is install instructions, we used to have those | 17:37 |
| Chipaca | pedronis: way ahead of you | 17:38 |
| pedronis | :) | 17:38 |
| * zyga doubled ram in his thinkpad for peanuts :) | 17:39 | |
| Chipaca | zyga: why do you have a thinkpad for peanuts | 17:39 |
| Chipaca | zyga: that thing must be tiny | 17:39 |
| zyga | haha | 17:39 |
| zyga | I made a good deal | 17:39 |
| zyga | sold the x250, got t470 | 17:40 |
| zyga | got money left | 17:40 |
| zyga | now at twice the ram | 17:40 |
| mup | PR snapd#4749 opened: ifacestate: be consistent passing Retry.After as named field <Created by pedronis> <https://github.com/snapcore/snapd/pull/4749> | 17:40 |
| pedronis | ^ trivial (also makes my local go vet happy) | 17:40 |
| r4co0n | Hi, I have a seemingly simple problem: I got an archive (mysql dependency boost) that's supposed to be in directory /boost during build of my snap. the archive contains itself a directy boost, which should become /boost/boost, however, I can't figure out how to make the dump plugin do that. | 17:53 |
| r4co0n | I managed to make snapcraft get locked in 'Staging' by stating to organize 'boost' to 'boost/boost' and '*' to 'boost/' | 17:56 |
| Chipaca | pedronis: and 4750 is a silly tweak to it' | 17:57 |
| r4co0n | No, now it failed, with an error stating boost/boost/boost/boost/... | 17:57 |
| Chipaca | r4co0n: boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/ | 17:57 |
| Chipaca | r4co0n: boost/boost/? | 17:57 |
| Chipaca | :-p | 17:57 |
| Chipaca | r4co0n: don't do that :-D | 17:57 |
| mup | PR snapd#4750 opened: store: getStructFields now take pointers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4750> | 17:57 |
| Chipaca | r4co0n: I mean, you can't put a booster on your booster to booster your booster | 17:58 |
| Chipaca | ok, i'll stop now | 17:58 |
| Chipaca | but it is funny :-) | 17:58 |
| * Chipaca wraps up his day and goes to get dinner ready for the hoard | 17:58 | |
| === fjay_ is now known as fjay | ||
| r4co0n | I just want a way to tell snapcraft to put everything in the dump source to a specific path. | 18:04 |
| r4co0n | my problem is, the path is existing in the source, hence everything at that location won't get moved by: "'*': /subdirectory" | 18:05 |
| r4co0n | It did get moved by the same "copy" command, that I'm trying to rewrite | 18:05 |
| nacc | r4co0n: you shouldn't be using absolute paths anyways, right? | 18:07 |
| zyga | jdstrand +1 to merge (2.32 copy of) https://github.com/snapcore/snapd/pull/4747 | 18:08 |
| mup | PR #4747: cmd/snap-update-ns: use recursive bind mounts for writable mimic (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4747> | 18:08 |
| r4co0n | I'm not, it's just a habit... | 18:08 |
| mup | PR snapd#4746 closed: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4746> | 18:08 |
| nacc | r4co0n: oh ok | 18:09 |
| r4co0n | https://paste.debian.net/hidden/c6f9fd43/ | 18:09 |
| r4co0n | This is my snap/snapcraft.yaml | 18:09 |
| nacc | r4co0n: it doesn't make sense | 18:09 |
| nacc | r4co0n: * will include banana/ | 18:10 |
| nacc | r4co0n: i think you would need to specify everything except for banana itself | 18:10 |
| r4co0n | I got only banana/banana/peach in there | 18:10 |
| nacc | r4co0n: or use filesets? | 18:10 |
| r4co0n | Isn't there something like a parent directory for dump | 18:11 |
| r4co0n | Like, dump everything under this location... | 18:11 |
| nacc | r4co0n: well, why are you doing both? | 18:12 |
| nacc | r4co0n: i mean, if you wante veryting under banana/ just do the '*: banana/' ? | 18:12 |
| nacc | r4co0n: not sure why you'd move banana itself then do something else | 18:13 |
| r4co0n | That executes a move which will leave banana/peach as banana/peach, not banana/banana/peach | 18:13 |
| r4co0n | I want boost to be at /boost, but I dont want boost/boost/funnyexecutable to be at boost/funnyexecutable | 18:14 |
| nacc | r4co0n: then do two parts | 18:15 |
| nacc | r4co0n: with different organize lines? | 18:15 |
| r4co0n | Like, extract the same archive twice? | 18:15 |
| r4co0n | Two dumps? | 18:15 |
| r4co0n | https://github.com/nextcloud/nextcloud-snap/blob/master/snap/snapcraft.yaml#L239 | 18:16 |
| r4co0n | That's the part I want to rewrite with dump | 18:16 |
| r4co0n | This tarball contains a folder /boost | 18:17 |
| r4co0n | I think I need a good reason to split up building this build dependency of a dependency | 18:19 |
| nacc | r4co0n: why can't you do exactly what that yaml does? | 18:20 |
| r4co0n | How? | 18:21 |
| nacc | r4co0n: does that yaml not work (i know copy is deprecated) | 18:21 |
| r4co0n | If I change file for organize and copy for dump, it doesn't work | 18:21 |
| nacc | r4co0n: well, right, becuase they aren't synonyms | 18:21 |
| r4co0n | I tried lots of ways and ended up with a DOS for snapcraft | 18:22 |
| nacc | r4co0n: to be clear, if all you need is the boost headers, then just grab the boost headers | 18:22 |
| nacc | r4co0n: don't grab the whole thing | 18:22 |
| nacc | r4co0n: so yes, you'd have two parts | 18:22 |
| nacc | r4co0n: one is 'boost_headers' and one is 'the rest of the boost tarball' (if you need it); afaict, that particular yaml doesn't need the second | 18:22 |
| mup | PR snapd#4741 closed: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4741> | 18:23 |
| r4co0n | mysql looks for boost during build, I don't know which files it checks under /boost ... | 18:24 |
| nacc | r4co0n: i'm not sure why that's relevant | 18:24 |
| nacc | r4co0n: perhaps you misunderstand what that part is trying to do? | 18:24 |
| r4co0n | You say I only need the headers | 18:24 |
| nacc | r4co0n: it's taking a tarball and extracting just some part of it | 18:24 |
| nacc | r4co0n: if you want to do the same thing, just ... do the same thing? | 18:24 |
| r4co0n | it's extracting everything, to /boost | 18:24 |
| r4co0n | I want to replicate that | 18:25 |
| r4co0n | that's not possible because the tarball contains boost/, which doesn't get moved to boost/boost/ | 18:25 |
| r4co0n | But if you say I only need some headers ouf of that anyways, I'm open for another solution... | 18:26 |
| r4co0n | Ideally a single command | 18:27 |
| nacc | r4co0n: sorry, i misunderstood | 18:27 |
| r4co0n | nacc, np, thank you for trying to help :) | 18:28 |
| mup | PR snapd#4747 closed: cmd/snap-update-ns: use recursive bind mounts for writable mimic (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4747> | 18:41 |
| zyga | 4644 will now get green :) | 18:42 |
| nathancahill | fyi, resolved that firefox issue. loading via the file protocol from / instead of a subdirectoy was causing an issue with sandboxing in firefox | 18:54 |
| r4co0n | If nobody has any idea how to solve my issue, I will open a bug so it doesn't pass unhandled. | 18:58 |
| mup | PR snapd#4749 closed: ifacestate: be consistent passing Retry.After as named field <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4749> | 19:00 |
| jdstrand | niemeyer: hey, I'm still not sure what to do with 'software-boutique'. I saw your answer, and I see that you intend for it to not be 'ubuntu-software-boutique', but I don't see an explicit ack for it to be classic as 'software-boutique' (maybe I missed it?) or criteria that should be applied to snaps that are like software-boutique or gnome-software | 19:01 |
| * zyga fiddles thumbs while travis picks up 4644 | 19:02 | |
| zyga | jdstrand it will be green and all I can do is wait :) | 19:02 |
| jdstrand | niemeyer: maybe you didn't mean for software-boutique to fall under this category and have it be a separate category? | 19:02 |
| jdstrand | niemeyer: if you can say +1 classic with the reasoning that is all I need. if you have additional criteria for gnome-software/software-boutique snaps, then I can incorporate it into our process | 19:03 |
| jdstrand | zyga: yeah | 19:05 |
| zyga | jdstrand wanna +1 a trivial helper PR? https://github.com/snapcore/snapd/pull/4745/files | 19:07 |
| mup | PR #4745: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <https://github.com/snapcore/snapd/pull/4745> | 19:07 |
| mup | PR snapcraft#1960 opened: extractors: add support for common-id <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1960> | 19:10 |
| niemeyer | jdstrand: Heya | 19:15 |
| niemeyer | jdstrand: Earlier today I've responded to your questions in the forum.. have you seen that? | 19:16 |
| elopio | matiasb: there seems to be a bug on the reviewer tools : The store was unable to accept this snap. | 19:16 |
| elopio | - 'common-id' must be used with 'daemon' | 19:16 |
| elopio | y | 19:17 |
| elopio | matiasb: that shouldn't be limited to daemons. | 19:17 |
| matiasb | elopio, o/ makes sense to me, I didn't set that restriction :) | 19:19 |
| jdstrand | niemeyer: yes, this was in response to that | 19:19 |
| matiasb | jdstrand, fyi ^? (re common-id) | 19:19 |
| jdstrand | let me double check | 19:20 |
| jdstrand | matiasb: ack | 19:20 |
| jdstrand | elopio: what snap? | 19:20 |
| jdstrand | I can manually approve | 19:20 |
| jdstrand | niemeyer: I think you're saying all the criteria was for welcome snaps (fine), but I don't see any criteria for gnome-software/software-boutique snaps and/or an ack for software-boutique as classic | 19:22 |
| jdstrand | maybe I missed something | 19:22 |
| === chihchun_afk is now known as chihchun | ||
| niemeyer | jdstrand: Ah, sorry, I was the one misunderstanding your question now | 19:22 |
| jdstrand | niemeyer: no worries, I thought it might go that way so opted for realtime :) | 19:23 |
| niemeyer | jdstrand: Is software boutique just a fork of gnome-software? | 19:24 |
| jdstrand | niemeyer: I don't know tbh. flexiondotorg could say for sure. what I know about it is that it used AptDaemon dbus apis for adding ppas and installing software | 19:25 |
| jdstrand | niemeyer: I was under the impression it is its own thing | 19:25 |
| jdstrand | so it is gnome-software like, but I think different | 19:25 |
| flexiondotorg | niemeyer jdstrand No, software-boutique is a from scratch "software center". | 19:26 |
| jdstrand | there we go | 19:26 |
| jdstrand | flexiondotorg: thanks | 19:26 |
| elopio | jdstrand: I was just running a test, no need to approve it. | 19:26 |
| niemeyer | flexiondotorg: Aha, okay.. hmm | 19:26 |
| flexiondotorg | Original part of Ubuntu MATE Welcome, but now decoupled. | 19:27 |
| jdstrand | elopio: can you paste your snap.yaml? | 19:27 |
| niemeyer | jdstrand: I think we can use the same rationale we used for the welcome tool.. if it is something that a given distribution wants its own users to have access to, and there's a real community behind it to justify the risk of such a classic snap in the store, then it sounds reasonable | 19:28 |
| flexiondotorg | niemeyer: Thanks :-) And as jdstrand says, I very keen to see if we can confine both in the longer term. | 19:28 |
| niemeyer | jdstrand: Also the fact it's interactive instead of a daemon that responds to external commands | 19:28 |
| flexiondotorg | Perhaps a session for next week. | 19:29 |
| jdstrand | niemeyer: that seems ok to me (in fact, I thought you were saying that all along, until today :) the question then is about criteria '3' -- prefixing with 'ubuntu' or not | 19:29 |
| niemeyer | jdstrand: So that gives some rationale for why that's okay while someone trying to do apt management with their own small tool that responds to external activity is not | 19:29 |
| jdstrand | niemeyer: flexiondotorg doesn't want that (for good reason); I don't mind it | 19:29 |
| Usysem | Wht is the command to install OPEN-vpn snap ? | 19:30 |
| niemeyer | jdstrand: Okay, that's the question I responded in the forum I think.. yes, I don't think that's sensible | 19:30 |
| jdstrand | niemeyer: and if not, is that something I should try to capture in the process criteria or just something for this one snap | 19:30 |
| niemeyer | jdstrand: The prefix suggestion was specifically to the welcome thing, because it's very closely bound to that one distribution | 19:30 |
| jdstrand | ok | 19:30 |
| jdstrand | case by case basis for others for now? | 19:31 |
| Usysem | What is the command to install OPEN-vpn snap ? | 19:31 |
| niemeyer | jdstrand: Yeah.. unless there are other foo-welcome things | 19:31 |
| jdstrand | niemeyer: budgie has a welcome snap, so renamed to ubuntu-budgie-welcome, but they don't have a software-boutique like snap | 19:32 |
| jdstrand | so we should be good for now | 19:32 |
| niemeyer | Usysem: "snap find vpn" tells me about "easy-openvpn", so maybe that one? | 19:32 |
| jdstrand | I'll take care of the approval and update the process docs slightly | 19:32 |
| jdstrand | niemeyer: thanks! | 19:32 |
| niemeyer | Usysem: Haven't tried it myself | 19:32 |
| niemeyer | jdstrand: Thanks! | 19:32 |
| Usysem | its not easy-openvpn - I've tried that & it doesn't show up in my menu, afterwards. Where is the simple OPEN-vpn ? and how do I install that snap ? | 19:33 |
| zyga | jdstrand 4644 is green :DDD | 19:34 |
| Usysem | hi - I need halp. | 19:36 |
| zyga | Usysem then perhaps there is no such snap yet | 19:36 |
| Usysem | there is . I installed it months ago - I jus forgot what its called. Can't find it on forum. | 19:36 |
| Usysem | I reinstalled my system - so I am re-installing snaps. | 19:37 |
| zyga | sorry, I don't know then | 19:37 |
| Usysem | thanks. | 19:37 |
| Pharaoh_Atem | flexiondotorg: how come sw-boutique is still using aptdaemon? | 19:37 |
| Pharaoh_Atem | didn't it switch to pk months ago? | 19:37 |
| jdstrand | niemeyer: fyi, left our process document the same but added a note: "Note that some ‘installer’ snaps (eg, gnome-software and software-boutique) are not distro-specific (eg, they work with any number of package backends) and therefore may not be required to be prefixed with <distro>-. This will be evaluated case by case using the above criteria as a starting point." | 19:41 |
| * jdstrand fixes typos :) | 19:42 | |
| mup | PR snapd#4644 closed: tests: add a spread test for layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4644> | 19:45 |
| jdstrand | zyga: are you planning on a PR for PR 4727 for 2.32? if not, it will make the 2.32 PR for 4714 more complicated | 20:05 |
| mup | PR #4727: many: simplify mocking of home-on-NFS <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4727> | 20:05 |
| jdstrand | PR 4714 | 20:06 |
| mup | PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714> | 20:06 |
| jdstrand | zyga: also, I saw your comments wrt layouts-- remember, they were conditional in 2.32 provided that per-snap s-u-n profiles are in place | 20:08 |
| mup | PR snapd#4751 opened: tests: add support for external backend executions on listing test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4751> | 20:28 |
| niemeyer | jdstrand: Thanks! | 20:32 |
| zyga | jdstrand I can, though I think it will be a bit painful | 20:35 |
| zyga | jdstrand I will look at that though | 20:35 |
| zyga | jdstrand yes, I remember and I'll ensure there are hardening patches next | 20:35 |
| mwhudson | does snapcraft have a way of verifying a source against a gpg signature? | 20:42 |
| mwhudson | hm doesn't look like it | 20:43 |
| mwhudson | should it? :) | 20:43 |
| mup | PR snapcraft#1957 closed: schema: improve the snap name's validator <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1957> | 20:44 |
| mup | PR snapd#4752 opened: tests: make interface-broadcom-asic-control test work on rpi <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4752> | 20:45 |
| === magicaltrout is now known as jujuuser | ||
| === jujuuser is now known as magicaltrout | ||
| === magicaltrout is now known as jujuuser | ||
| === jujuuser is now known as magicaltrout | ||
| === magicaltrout is now known as jujuuser | ||
| === jujuuser is now known as magicaltrout | ||
| === chihchun_afk is now known as chihchun | ||
| === ikey is now known as ikey|zzz | ||
| jdstrand | roadmr: hey, would you mind pulling r1007? | 21:42 |
| roadmr | jdstrand: sure! | 21:42 |
| jdstrand | roadmr: it isn't particularly time-sensitive | 21:42 |
| roadmr | I don't mind, I mean :) | 21:42 |
| jdstrand | cool :) | 21:42 |
| roadmr | jdstrand: ok... we've been in the crapper with rollouts due to all the mitigation madness :( | 21:43 |
| jdstrand | I bet | 21:43 |
| roadmr | 1007 is in the queue, I'll finish merging it and QAing it tomorrow | 21:59 |
| roadmr | (due to impending EOD) | 21:59 |
| jdstrand | roadmr: thanks! | 22:01 |
| mwhudson | does anyone have an example of triggering a jenkins job on a snap publication via webhooks? | 22:20 |
| jdstrand | elopio, Chipaca: fyi, that request for a store pull of the review-tools has both your fixes | 23:22 |
| jdstrand | ^ | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!