| kyrofa | NickZ, yeah that's a question for jdstrand | 00:09 |
|---|---|---|
| mup | PR snapcraft#2263 opened: project: catch parent YAML exceptions <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2263> | 00:10 |
| NickZ | jdstrand: any progress on that feature since the last update? | 00:18 |
| mup | PR snapd#5819 opened: tests: fix for nested test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5819> | 04:22 |
| mup | PR snapcraft#2264 opened: Fix issue where cross compile target is ignored <Created by eberkund> <https://github.com/snapcore/snapcraft/pull/2264> | 04:40 |
| === cpaelzer_ is now known as cpaelzer | ||
| mborzecki | morning | 05:06 |
| zyga | Good morning | 06:18 |
| zyga | Is github working now? | 06:18 |
| mvo | zyga: good morning | 06:19 |
| mvo | zyga: it looks like it, I see a lot of green today | 06:19 |
| zyga | :-) | 06:19 |
| zyga | Great | 06:19 |
| mup | PR snapd#5816 closed: overlord/assertstate: propagate TaskSnapSetup error <Simple> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5816> | 06:20 |
| mborzecki | zyga: mvo: hey | 06:23 |
| mvo | mborzecki: good morning | 06:24 |
| mup | PR snapd#5808 closed: snapd-env-generator: fix when PATH is empty or unset <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5808> | 06:29 |
| mvo | pedronis: 5765 may be something you like, it splits bits of the store tests into their own file | 06:35 |
| mborzecki | #5777 triggers one annoying bug in wrappers and map iteration order | 06:38 |
| mup | PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777> | 06:38 |
| mup | PR snapd#5820 opened: wrappers: fix snap services order in tests <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5820> | 06:49 |
| mborzecki | super simple ^^ | 06:49 |
| mvo | mborzecki: I'm curious about 5820 - I ran this test with -count 1000 and got no failure. is that a go 1.11 thing? | 07:05 |
| mborzecki | mvo: i was doing some changes on top of 5777 and it failed like this https://paste.ubuntu.com/p/6T3JVzK7fj/ | 07:06 |
| mup | PR snapd#5803 closed: ifacestate: fix hang when retrying content providers <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5803> | 07:06 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:06 |
| mborzecki | mvo: it's a bug nonetheless. info.Apps is a map, so the order of iteration is random-ish | 07:07 |
| mborzecki | pstolowski: hey | 07:07 |
| mup | PR snapd#5804 closed: ifacestate: fix hang when retrying content providers (2.35) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5804> | 07:07 |
| mvo | mborzecki: yes, I'm just surprised we don't see it more often | 07:07 |
| mborzecki | mvo: wouldn't be surprised if changing some strings or order of operations in the test would be enough to trigger it | 07:08 |
| mvo | zyga: whats the status of 1791814 | 07:16 |
| mvo | zyga: do we need a fix for the interfaces issue in 2.35.2? | 07:16 |
| pedronis | mvo: hi, I see, I need to finish something I was trying to finish yesterday before doing new reviews | 07:29 |
| mvo | pedronis: no problem, this was just a fyi | 07:29 |
| Chipaca | morning all | 07:40 |
| Chipaca | was up stupid late last night, so I might zonk off at some point (but y'all woke up to a lot more green PRs, so that's ok i guess) | 07:41 |
| zyga | mvo: re | 07:47 |
| zyga | mvo: sorry for the lag | 07:47 |
| zyga | mvo: there's a small PR but it's not critical | 07:47 |
| mvo | zyga: ok, I release 2.35.2 without that, we can always do a .3 | 07:48 |
| zyga | that's fie | 07:48 |
| zyga | fine | 07:48 |
| pstolowski | pedronis: hey, my plan for solving yesterday's issue is to check the wait-chain (using the helper mvo just landed) and not retry if i see setup-profiles ahead, wdyt? | 07:49 |
| pedronis | pstolowski: ? | 07:50 |
| pedronis | pstolowski: didn't you say this was setup-profiles of gopkg | 07:51 |
| pedronis | you shouldn't need to follow the chain to know that | 07:52 |
| pedronis | pstolowski: also it should be possible to write a test, right? | 07:52 |
| pedronis | pstolowski: also I remember why we put auto-connect where we put it, because setup-profiles phase2 is a nop anyway in the new world | 07:59 |
| pedronis | pstolowski: another approach would be to check if setup-profiles has the phase2 flag and ignore it | 07:59 |
| pedronis | either way, I hope we don't need to follow the chain | 08:00 |
| pedronis | pstolowski: you basically need an installingSnap like for the disconnect check? then the two are the same again? | 08:01 |
| pstolowski | pedronis: yes, it was setup-profiles of gopkg, but rather than checking if we have setup-profiles for same snap (which would also need to check if it's from same change i think), we would check if setup-profiles is waiting on us. | 08:01 |
| pstolowski | pedronis: but you're right about setup-profiles phase 2 being noop, i forgot that | 08:02 |
| pstolowski | pedronis: yeah, looking at if corePhase2 -> do nothing... seems to be most straightforward to ignore setup-profiles conflict in such case | 08:04 |
| pstolowski | pedronis: and of course test is possible and a must | 08:05 |
| pedronis | thx | 08:06 |
| pedronis | pstolowski: the tricky bit is that it needs to be a spread test with an old snapd, or we need to manually construct what an old InstallPath would build | 08:08 |
| pedronis | in terms of tasks | 08:08 |
| pstolowski | pedronis: should be possible to have a spread test for just 16.04 system with snapd from distro, don't we do that already to test upgrades somewhere? | 08:10 |
| pedronis | pstolowski: we do but I don't know which snapd we want, desktop images and cloud images vs archive have different versions | 08:11 |
| pstolowski | ah | 08:11 |
| pedronis | we sru snapd into 16.04 | 08:11 |
| pstolowski | right | 08:11 |
| mup | PR snapd#5821 opened: release: 2.35.2 <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5821> | 08:14 |
| pedronis | pstolowski: mvo maybe can help navigate that | 08:16 |
| pstolowski | thx | 08:16 |
| mup | PR snapd#5770 closed: many: provide salt for generating instance-key in store requests <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5770> | 08:24 |
| zyga | is jdstrand back today? | 08:27 |
| pedronis | he should be | 08:29 |
| mup | PR snapd#5820 closed: wrappers: fix snap services order in tests <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5820> | 08:48 |
| zyga | https://twitter.com/ismonkeyuser/status/1039392972339523586 ;) | 09:03 |
| zyga | mvo: may 2.35.2 live long and prosper | 09:04 |
| mup | PR snapd#5812 closed: snapstate: refactor tests to use SetModel* <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5812> | 09:06 |
| mup | PR snapd#5814 closed: daemon: fix snap list --all with parallel snap instances <Parallel installs> <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5814> | 09:06 |
| zyga | pstolowski hey, there's a small conflict here: https://github.com/snapcore/snapd/pull/5497 | 09:15 |
| mup | PR #5497: overlord/patch: patch for static plug/slot attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/5497> | 09:15 |
| pstolowski | zyga: thanks! will fix in a bit | 09:16 |
| zyga | pstolowski: is this https://github.com/snapcore/snapd/pull/5680 something we ought to review? | 09:17 |
| mup | PR #5680: [RFC] hotplug: handling of simple add/remove scenario <Blocked> <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5680> | 09:17 |
| zyga | I need a 2nd review for https://github.com/snapcore/snapd/pull/5802 | 09:18 |
| mup | PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802> | 09:18 |
| pstolowski | zyga: this is RFC brach for high-level comments, i'm chopping smaller pieces from there into separate PRs | 09:19 |
| zyga | ah, ok | 09:19 |
| pstolowski | zyga: and it needs updating after existing hotplug PRs land | 09:20 |
| mborzecki | zyga: so the last decision is system/core fix goes to the `snap interfaces` command but the API stays right? | 09:24 |
| zyga | mborzecki: please land https://github.com/snapcore/snapd/pull/5713 once jdstrand ack's it | 09:24 |
| zyga | mborzecki: yes | 09:24 |
| mup | PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713> | 09:24 |
| zyga | mborzecki: I implemented that here: https://github.com/snapcore/snapd/pull/5818 | 09:24 |
| mup | PR #5818: cmd/snap: handle "snap interfaces core" better <Created by zyga> <https://github.com/snapcore/snapd/pull/5818> | 09:24 |
| mborzecki | zyga: yeah, i'm looking it now | 09:24 |
| zyga | mborzecki: I think we will need one more change | 09:25 |
| zyga | mborzecki: once snapd is the holder | 09:25 |
| zyga | mborzecki: the mapper needs to keep translating "core" and "system" to "snapd" | 09:25 |
| zyga | mborzecki: right? | 09:25 |
| zyga | mborzecki: I will make a PR for that | 09:25 |
| mborzecki | zyga: probably, iirc the slots will appear on snapd now (pstolowski added the change?) but i'd expect the api to return 'system' there nonetheless | 09:29 |
| pstolowski | mborzecki: i haven't changed that, i think the initial bits come from zyga | 09:33 |
| zyga | mborzecki: the api does return "system" when "snapd" holds implicit slots | 09:33 |
| pstolowski | mvo: hey, yt? | 09:36 |
| mborzecki | zyga: you think you could extort a review from someone and land #5802 ? | 09:38 |
| mup | PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802> | 09:38 |
| mup | PR snapd#5822 opened: wrappers: allow user mode systemd daemons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822> | 09:39 |
| mvo | pstolowski: yes | 09:41 |
| mvo | pstolowski: s'up? | 09:41 |
| pstolowski | mvo: hey, i was discussing writing a spread test for yesterday's issue with pedronis (see above ~1h ago); i'd need a spread test for 16.04 running an old snapd binary (the one from desktop image i think) | 09:43 |
| pstolowski | mvo: do you know if we do anything like that already? | 09:44 |
| pstolowski | mvo: i basically need to run from an "old" state into new snapd | 09:45 |
| mvo | pstolowski: we have a upgrade test already | 09:46 |
| mvo | pstolowski: I have not looked into the details in a long time | 09:46 |
| mvo | pstolowski: there is also the option to use the snapd from the released 16.04 version | 09:46 |
| mvo | pstolowski: but thats 2.0.2 which is pretty ancient | 09:47 |
| mvo | pstolowski: tests/upgrade/basic/task.yaml - let me refresh my memory on this one | 09:48 |
| mup | PR snapd#5823 opened: snapcraft.yaml: add workaround for LP:#1791871 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5823> | 09:55 |
| pstolowski | mvo: looking | 09:57 |
| zyga | mborzecki: I'd love to :) | 10:00 |
| zyga | mvo: can you have a look at 5802 perhaps? | 10:01 |
| pstolowski | mvo: right. the question is how to enforce a well known old version, not a newer one after SRUs | 10:02 |
| mvo | pstolowski: that is hard | 10:03 |
| mvo | pstolowski: what is the version we need? | 10:03 |
| zyga | mvo: some failures on https://github.com/snapcore/core18/pull/70 | 10:03 |
| mup | PR core18#70: hooks: add rfkill <Created by mvo5> <https://github.com/snapcore/core18/pull/70> | 10:03 |
| zyga | mvo: https://github.com/systemd/systemd/issues/10068 :) | 10:04 |
| pstolowski | mvo: i need to find out yet; it needs to be a version that creates setup-profiles tasks with core-phase-2=true; Gustavo had it with a fresh install of 16.04 | 10:05 |
| mvo | ok | 10:06 |
| mvo | zyga: aha, nice. /me hugs xnox | 10:06 |
| zyga | mborzecki: added test to https://github.com/snapcore/snapd/pull/5818 | 10:07 |
| mup | PR #5818: cmd/snap: handle "snap interfaces core" better <Created by zyga> <https://github.com/snapcore/snapd/pull/5818> | 10:07 |
| xnox | mvo, hm? =) are people stalking me on github or something? | 10:07 |
| xnox | i just filed it. | 10:07 |
| cjwatson | mvo: Hi - does https://bugs.launchpad.net/launchpad-buildd/+bug/1791907 ring any bells with you? | 10:07 |
| mup | Bug #1791907: Cannot build base snaps <launchpad-buildd:New> <https://launchpad.net/bugs/1791907> | 10:07 |
| cjwatson | It's pretty weird and I don't see how it can be launchpad-buildd's fault, but don't know where to reassign it | 10:08 |
| pstolowski | mvo: looking at debian changelog, it would need to be snapd <= 2.33 | 10:18 |
| mvo | pstolowski: hm, the best option is probably to download it from https://launchpad.net/ubuntu/+source/snapd/2.32.9 | 10:29 |
| mvo | pstolowski: i.e. "curl https://launchpad.net/ubuntu/+source/snapd/2.32.9/+build/14895451/+files/snapd_2.32.9_amd64.deb ; sudo apt install -y ./snapd_2.32.9_amd64.deb" | 10:29 |
| pstolowski | mvo: nice, is this something we can rely on to stay there for the lifetime of 16.04? | 10:32 |
| mvo | pstolowski: | 10:33 |
| mvo | pstolowski: yes | 10:33 |
| pstolowski | mvo: great, thank you! | 10:33 |
| mvo | pstolowski: yw | 10:34 |
| zyga | xnox: I'm following systemd on github | 10:38 |
| mup | PR snapd#5821 closed: release: 2.35.2 <Simple> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5821> | 10:40 |
| mup | PR snapd#5819 closed: tests: fix for nested test suite <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5819> | 10:47 |
| zyga | pstolowski: some comments on https://github.com/snapcore/snapd/pull/5807 | 11:12 |
| mup | PR #5807: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot <Created by stolowski> <https://github.com/snapcore/snapd/pull/5807> | 11:12 |
| zyga | you wanted to land it quickly for conflict avoidance | 11:12 |
| pstolowski | zyga: yes, thank you, yesterday's issue caught all my attention | 11:15 |
| zyga | pstolowski: also some small feedback on the racy append fix: https://github.com/snapcore/snapd/pull/5817 | 11:15 |
| mup | PR #5817: snapstate/tests: serialize all appeneds in fake backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/5817> | 11:15 |
| zyga | Sep 12 10:54:56 sep121046-033697 snapd[27140]: helpers.go:174: cannot regenerate seccomp profile for snap "core": signal: terminated | 11:19 |
| zyga | hmm | 11:19 |
| mup | PR snapd#5824 opened: [WIP] fetch store assertions together and in the context of interpreting snap-declarations <Created by pedronis> <https://github.com/snapcore/snapd/pull/5824> | 11:33 |
| jamesh | zyga: thanks for the initial review of my branch. If you've got any ideas about how to wrangle a spread test for this kind of thing, I'm all ears. I haven't had any luck so far. | 11:40 |
| zyga | jamesh: I think that's tricky, we'd have to start systemd as a user session manager in tests somehow | 11:41 |
| zyga | jamesh: I don't have any ideas, perhaps it's doable, perhaps it's doable but requires extensive work | 11:41 |
| zyga | I fixed formatting and pushed to your branch to unbreak unit tests | 11:41 |
| mup | PR snapd#5799 closed: Install snap-failure binary on Fedora <Created by eyusupov> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5799> | 11:41 |
| jamesh | zyga: sorry about that. I pushed the branch up just before going out for a walk (wanted to get out of the house before it was dark) | 11:42 |
| zyga | no need to be sorry :) | 11:42 |
| jamesh | It was nice to see how little I needed to change | 11:43 |
| === pstolowski is now known as pstolowski|lunch | ||
| jamesh | and I think some of the changes might be able to go away or be minimised further w.r.t. enable/disable | 11:43 |
| mup | PR snapd#5806 closed: tests: fix install snaps test by adding link to /snap <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5806> | 11:48 |
| om26er | How to get a snap publisher "verified" ? | 11:49 |
| zyga | om26er: not sure, is there anything about it on the forum? | 11:49 |
| om26er | https://forum.snapcraft.io/t/verified-developers/2005 | 11:51 |
| popey | We haven't published details of that internal process om26er | 11:52 |
| popey | We're not planning on verifying everyone. | 11:53 |
| zyga | jamesh: some tweaks for tests are probably needed to mock presence of a browser | 11:56 |
| zyga | https://api.travis-ci.org/v3/job/425653825/log.txt | 11:56 |
| mup | PR snapd#5785 closed: tests,interfaces: run interfaces-account-control on UC18 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5785> | 11:58 |
| om26er | popey: we'd like to verify our company account at least. | 11:59 |
| zyga | oh, I could verify my own company too | 12:02 |
| zyga | oh man, time flies today | 12:33 |
| kravietz | hello, I'm building a Python snap and getting this | 12:33 |
| kravietz | The linker version '2.23' used by the base 'core' is incompatible with files in this snap: | 12:33 |
| kravietz | At the priming stage | 12:33 |
| kravietz | Any idea how to debug this? | 12:33 |
| zyga | if you are building natively then your host must match the base snap of the applications in your snap | 12:34 |
| zyga | in practice, if you don't say "base: core18" and build on ubuntu 18.04 you will see issues like this | 12:34 |
| kravietz | Exactly, I'm using 18.04 as host | 12:35 |
| zyga | the universal remedy is to build in a container/vm but I'll defer to kyrofa or sergiusens for details | 12:35 |
| zyga | kravietz: just add "base: core18" | 12:35 |
| kravietz | Let me try | 12:35 |
| zyga | this will make your snap execute against the ubuntu 18.04 runtime | 12:35 |
| zyga | so newer libraries and everything | 12:35 |
| zyga | and compatible linker :) | 12:35 |
| === pstolowski|lunch is now known as pstolowski | ||
| kravietz | zyga: it worked, thanks! | 12:53 |
| === mborzeck1 is now known as mborzecki | ||
| zyga | kravietz: that's great, good luck :) | 12:53 |
| mborzecki | pstolowski: some conflicts in https://github.com/snapcore/snapd/pull/5817 | 12:58 |
| mup | PR #5817: snapstate/tests: serialize all appends in fake backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/5817> | 12:58 |
| pstolowski | mborzecki: thanks, will fix in a moment | 13:01 |
| zyga | Chipaca: standup? | 13:03 |
| zyga | ijohnson: some responses on your branch | 13:19 |
| zyga | thank you for pushing it | 13:19 |
| sergiusens | mvo: remeber when you told me interpreter symlinks would be relative? :-) | 13:37 |
| sergiusens | (snapcraft) ubuntu@snapcraft-xenial-dev:~/source/keepalived$ ls /snap/core18/current/lib64/ld-linux-x86-64.so.2 -l | 13:38 |
| sergiusens | lrwxrwxrwx 1 root root 32 Apr 2 21:07 /snap/core18/current/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.27.so | 13:38 |
| mvo | sergiusens: uh, let me fix this | 13:53 |
| mvo | sergiusens: this sounds like a regression from core18 vs core | 13:53 |
| mvo | sergiusens: while i have you here - my snapd builds are failing in LP currently with"The source has changed on disk." and "Build failed" in https://launchpadlibrarian.net/387957761/buildlog_snap_ubuntu_xenial_arm64_snapd-2.35_BUILDING.txt.gz | 13:54 |
| mvo | sergiusens: I tried to workaround with source-type: git | 13:54 |
| mvo | sergiusens: but no luck | 13:55 |
| mvo | sergiusens: I'm currently trying to trigger the build using the beta snapcraft (once I manage to convince lp-shell) | 13:55 |
| mvo | sergiusens: but that is only good for a one-off build :/ | 13:55 |
| mvo | sergiusens: any ideas what I can try? | 13:55 |
| sergiusens | mvo: can you try with edge? | 14:10 |
| sergiusens | mvo: this is something kyrofa has been working on, mind waiting an hour until he comes on? | 14:11 |
| sergiusens | mvo: or give me the source where snapcraft.yaml lives on | 14:11 |
| mvo | sergiusens: this comes from https://github.com/snapcore/snapd | 14:12 |
| mvo | sergiusens: and the build is https://code.launchpad.net/~mvo/+snap/snapd-2.35 | 14:12 |
| ijohnson | zyga: I refreshed the branch again, do you have any recommendations on a concise snap name for the test? | 14:14 |
| sergiusens | mvo: you probably do not need that plugin anymore as you can script most of that in override-build | 14:15 |
| sergiusens | mvo: but this is your issue https://github.com/snapcore/snapd/blob/master/parts/plugins/x_builddeb.py#L21 | 14:15 |
| sergiusens | mvo: if you want to continue that hack you will have to do more to not trigger "change detection" | 14:16 |
| mvo | sergiusens: hm, I added that because of lp: #1772584 | 14:17 |
| mup | Bug #1772584: Having a "snap" directory with actual content causes build failures <Snapcraft:Triaged> <https://launchpad.net/bugs/1772584> | 14:17 |
| mvo | sergiusens: I can play with override-build but last I worked on this having a populated "snap/" dir was a no-go and snapcraft would simply not work. but maybe that has changed? any hints welcome :) | 14:18 |
| sergiusens | mvo: yeah, snap directory is special in snapcraft as things in there trigger special behavior | 14:18 |
| sergiusens | just like debian/conrol means something | 14:19 |
| sergiusens | mvo: I'll let kyrofa go over that with you to find a good path forward | 14:20 |
| ppisati | uhm, i thought snapcraft's advanced grammar was transparent, and i could exploit it whenever i expected a string, but i guess i was wrong: | 14:20 |
| ppisati | http://paste.ubuntu.com/p/hHvJXvghR5/ | 14:20 |
| ppisati | when i try this: | 14:20 |
| sergiusens | debian/conrol means nothing though as I managed to typo my point | 14:20 |
| mvo | sergiusens: ok, I understand that the naming of the dir is unfortunate - but at the same time, refactoring our code to call it notsnap would be unfortunate as well | 14:20 |
| ppisati | http://paste.ubuntu.com/p/cpcnxm9Ttt/ | 14:20 |
| mvo | sergiusens: heh, no worries, I got your point | 14:20 |
| zyga | ijohnson: test-snapd-... not sure :) | 14:20 |
| * zyga gets dinner | 14:20 | |
| sergiusens | mvo: you could always do your packaging out of tree, that might be cleaner | 14:21 |
| ppisati | sergiusens: any idea? ^ | 14:21 |
| mvo | sergiusens: a separate repo you mean? one nice benefit from the current approach is that we get a new LP build every time our repo changes, not sure if that would be possible with an extra repo? | 14:22 |
| ppisati | kyrofa: ^ | 14:22 |
| sergiusens | ppisati: that grammar thing needs to be enabled for that key, it is not for everything | 14:22 |
| sergiusens | mvo: LP has tracking for that for "source" entries in parts | 14:22 |
| sergiusens | build.snapcraft.io does at least, which means LP does too, just need to figure out where | 14:23 |
| sergiusens | if it is not automatic | 14:23 |
| ppisati | sergiusens: uhm, ok, so i need to patch the kernel plugin to accept it - any example of plugin / key that was patched to accept it? so i can read it and learn what i have to do? | 14:23 |
| mvo | sergiusens: ok | 14:23 |
| mvo | sergiusens: I like that the snapcraft.yaml is git right now, but maybe I just need to get used to the idea to move it out | 14:24 |
| cjwatson | debian/control is a bad example anyway, since it's perfectly permissible and quite common practice to drop extra packaging-related helper files into debian/ | 14:27 |
| * mvo nods | 14:29 | |
| cjwatson | sergiusens: no, LP has no such tracking. BSI handles this itself by having a poller script that parses snapcraft.yaml and looks for other parts to poll | 14:30 |
| sergiusens | cjwatson: it is, our problem is that we gave meaning to so many paths... and what you say is true as long as you do not squat ones that do have meaning | 14:30 |
| mvo | this is unfortunate for us because it blocks the snapd 2.35.2 snap release so having some agreement on the way forward would be good | 14:30 |
| sergiusens | cjwatson: thanks for confirming that | 14:30 |
| mup | PR # closed: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5713, snapd#5714, snapd#5717, snapd#5724, snapd#5727, snapd#5739, snapd#5758, | 14:30 |
| mup | snapd#5759, snapd#5762, snapd#5765, snapd#5768, snapd#5771, snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5802, snapd#5805, snapd#5807, snapd#5809, snapd#5811, snapd#5813, snapd#5817, snapd#5818, snapd#5822, snapd#5823, snapd#5824 | 14:30 |
| cjwatson | perhaps you should define something under snap/ that snapcraft won't touch | 14:30 |
| cjwatson | for instance, I often put things under debian/local/ | 14:30 |
| sergiusens | cjwatson: in the case of mvo, it is an entire source tree | 14:31 |
| cjwatson | last I checked directories could contain directories :) | 14:31 |
| mup | PR # opened: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5713, snapd#5714, snapd#5717, snapd#5724, snapd#5727, snapd#5739, snapd#5758, | 14:31 |
| mup | snapd#5759, snapd#5762, snapd#5765, snapd#5768, snapd#5771, snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5802, snapd#5805, snapd#5807, snapd#5809, snapd#5811, snapd#5813, snapd#5817, snapd#5818, snapd#5822, snapd#5823, snapd#5824 | 14:31 |
| sergiusens | cjwatson: yeah, but in go, that would change the import path | 14:31 |
| cjwatson | that sort of approach would allow people to keep things that are essentially part of snap-specific packaging somewhere under snap/, which would be tidy, while not interfering | 14:31 |
| mvo | sergiusens: could we have logic like if os.path.exists(".snap"): ignore("snap") or something? | 14:31 |
| cjwatson | surely you could set GOPATH | 14:31 |
| mvo | sergiusens: or snap/.i-own-this-really or something? | 14:32 |
| sergiusens | mvo: so kyrofa is the person to talk to as he is taking care of this thing | 14:32 |
| mvo | sergiusens: ok, sorry, I thought it would need your architectural blessing or something. if not thats fine I will talk to him | 14:33 |
| sergiusens | cjwatson: snap dir lives next to another source dir they have that does "import <>/snap" | 14:33 |
| mvo | sergiusens: thanks for your help in any case! | 14:33 |
| sergiusens | mvo: no, it does not need my architectural blessing | 14:33 |
| cjwatson | ah, that's a bit different from the sort of thing I was thinking of | 14:34 |
| cjwatson | I do generally think that a subdir reserved for use by the packaging as opposed to snapcraft would be helpful | 14:35 |
| sergiusens | cjwatson: yes, this is a ver special snowflake case where they got around it by monkey patching our code base through an external plugin :-) | 14:35 |
| sergiusens | cjwatson: the snap/local seems like a very good idea we could move forward on that | 14:35 |
| sergiusens | kyrofa: ^ | 14:36 |
| mvo | kyrofa: so once you are around I would love to talk to you about 1772584 (after having pestered sergiusens way too long about it) | 14:36 |
| cjwatson | (It's true that name collisions in debian/ are possible, but in practice I've never run into them because they're basically always hidden behind debhelper compatibility level changes, at least if they're something that it's remotely plausible people might collide with by accident) | 14:37 |
| cjwatson | (and the debhelper maintainer tends to do test rebuilds to spot problems with major changes AIUI) | 14:38 |
| cjwatson | snapcraft has nothing like http://manpages.ubuntu.com/manpages/cosmic/en/man7/debhelper.7.html#compatibility%20levels AIUI ... | 14:39 |
| sergiusens | no, our plan was to introduce that with build environments but that item got killed off high above | 14:40 |
| sergiusens | cjwatson: speaking of testing, I switched some test jobs to use the snap and it seems they still use the deb (https://launchpad.net/~sergiusens/+snap/multipass-test). Are there any obvious mistakes here? | 14:41 |
| cjwatson | build environments would be kind of orthogonal I thought - this kind of thing in packaging toolchains is more about the semantics of the packaging | 14:41 |
| cjwatson | sergiusens: there's a bug where you have to request the builds using the API - the UI currently disregards auto_build_channels | 14:42 |
| sergiusens | build environment is not the vm thing | 14:42 |
| sergiusens | we were redesigning the yaml to be versioned, so you subscribe to certain semantics | 14:42 |
| cjwatson | combination of https://bugs.launchpad.net/launchpad/+bug/1791265, https://bugs.launchpad.net/launchpad/+bug/1791269, and https://bugs.launchpad.net/launchpad/+bug/1791272 | 14:42 |
| mup | Bug #1791265: Manual snap builds don't allow for snapcraft/snapd channel selection <Launchpad itself:New> <https://launchpad.net/bugs/1791265> | 14:43 |
| mup | Bug #1791269: Options for automatic builds could be defaults for all builds in a snap <Launchpad itself:New> <https://launchpad.net/bugs/1791269> | 14:43 |
| mup | Bug #1791272: Manual snap builds could use a target channel override <Launchpad itself:New> <https://launchpad.net/bugs/1791272> | 14:43 |
| cjwatson | ah, OK, well if it ever comes up again maybe you can get a less confusing name while you're there :) | 14:43 |
| sergiusens | we are planning on bring that versioning piece back, but next cycle | 14:43 |
| cjwatson | in the meantime, you should be able to use https://launchpad.net/+apidoc/devel.html#snap-requestBuilds | 14:44 |
| sergiusens | thanks for the bug pointers | 14:44 |
| cjwatson | explicitly passing the desired channels | 14:44 |
| cjwatson | or https://launchpad.net/+apidoc/devel.html#snap-requestAutoBuilds should work too | 14:44 |
| sergiusens | thanks | 14:45 |
| cjwatson | I'll try to get at least the worst of those bugs fixed soon - they are absolutely confusing | 14:47 |
| sergiusens | cjwatson: btw, someone proposed snap/x- as an ignore pattern | 14:47 |
| cjwatson | same idea but x- seems cumbersome compared to a subdirectory. I think you use x- in situations where you don't have other kinds of structure available | 14:50 |
| cjwatson | but it's your project :) | 14:50 |
| sergiusens | cjwatson: I wanted your opinion actually :-) and it is good | 14:51 |
| cjwatson | I don't think exact choice of name is super-important, but structure is nice | 14:52 |
| ijohnson | zyga: what about test-snapd-svcs-disable-install-hook as the name? | 14:54 |
| zyga | Yeah that sounds good | 14:55 |
| ijohnson | cool | 14:56 |
| kyrofa | ppisati, I'm afraid it's not just generically used for all strings, whatever is responsible for processing it needs to actually call a function to make it happen | 15:02 |
| ppisati | kyrofa: do you happen to remember what's the name of this function? | 15:05 |
| kyrofa | ppisati, yeah let me show you, one sec | 15:06 |
| kyrofa | ppisati, this may not be quite as simple as you were hoping, but here's how it works today: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/project_loader/_parts_config.py#L219 | 15:08 |
| kyrofa | There are two processors, one for global/root properties, one for part properties | 15:08 |
| ppisati | kyrofa: /me scratches his head | 15:11 |
| kyrofa | mvo, I'm looking at what you've got now, see if we can get you unblocked short-term and come up with something better long-term | 15:11 |
| ppisati | kyrofa: ok, let me play around with it, let's see if i can bend my mind around it | 15:12 |
| kyrofa | ppisati, let me know if you have any questions | 15:13 |
| kyrofa | mvo, your monkey patch still works, have you tried building on edge? bug #1791871 is fixed there | 15:31 |
| mup | Bug #1791871: 2.43 breaks when you run "snapcraft pull" first <Snapcraft:Fix Committed by kyrofa> <https://launchpad.net/bugs/1791871> | 15:31 |
| kyrofa | Might be able to patch around the bug too... let's see | 15:32 |
| mvo | kyrofa: thanks, I have not tried in lp with edge yet | 15:33 |
| * cachio lunch | 15:34 | |
| kyrofa | mvo, try this, no edge required: https://paste.ubuntu.com/p/DXhkWMJbpD/ | 15:35 |
| kyrofa | Obviously a hack, essentially disables change detection | 15:35 |
| mvo | kyrofa: cool, will do in a tiny bit (in a meeting right now). thanks a lot | 15:36 |
| mvo | kyrofa: getting us unblocked for now is great, we can talk in brussels about a longer term solution | 15:36 |
| pstolowski | niemeyer: you said in the standup you had some new feedback for one of my PRs, but i haven't received anything; have you saved/submitted? | 15:43 |
| niemeyer | pstolowski: No, I've just been looking at a camera and microphone for that many hours | 15:44 |
| pstolowski | niemeyer: ah, sure, understood; didn't mean to push you, just got worried for it get lost | 15:53 |
| niemeyer | pstolowski: Oh, no worries.. I was indeed hoping to get more reviews finished, but didn't manage to | 15:54 |
| mup | PR snapcraft#2259 closed: cli: show trace if no tty <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2259> | 16:21 |
| thresh | hmm, using qt 5.11 it seems statx syscall is now being used | 16:23 |
| thresh | which is caught with apparmor it seems and results in "[28964.168141] audit: type=1326 audit(1536769071.191:214): auid=1000 uid=1000 gid=1000 ses=3 pid=4815 comm="vlc-qt-check" exe="/snap/vlc/x4/usr/libexec/vlc/vlc-qt-check" sig=0 arch=c000003e syscall=332 compat=0 ip=0x7f12e1428839 code=0x50000" | 16:23 |
| thresh | no denials though | 16:25 |
| mup | PR snapcraft#2255 closed: catkin plugin: use SnapcraftException <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2255> | 16:27 |
| thresh | how would I go about whitelisting that syscall for my snap? | 16:39 |
| thresh | looks like popey already hit that with Neon repos as well, in https://forum.snapcraft.io/t/unknown-syscall-when-running-an-18-04-built-snap/7094/8 | 16:41 |
| sergiusens | thresh: best to get either jdstrand or zyga on that thread | 16:45 |
| === pstolowski is now known as pstolowski|afk | ||
| sergiusens | mvo, kyrofa: now that the urgency on that is gone, we should checkpoint on this in Brussels | 16:45 |
| kyrofa | Agreed | 16:46 |
| thresh | thanks sergiusens! | 16:47 |
| zyga | thresh: I’ll read that now | 16:49 |
| zyga | That is interesting | 16:50 |
| zyga | I think statx should be allowed by default | 16:50 |
| zyga | jdstrand: ^ if you agree I can prepare the PR | 16:50 |
| zyga | I’ll prepare the PR and we can discuss it there | 16:52 |
| jdstrand | zyga: how do we know that 332 corresponds to statx? | 16:52 |
| zyga | I dont know yet, if this is not statx then my suggestion is moot | 16:54 |
| zyga | I’m walking to my desk now | 16:54 |
| om26er | if snapd becomes a snap, how will you install it in the first place ? | 16:58 |
| om26er | I just found there is a snapd snap available as well. | 16:59 |
| zyga | re | 17:01 |
| zyga | om26er: that's a great question :) | 17:01 |
| zyga | om26er: it will be installed with a imaging tool | 17:01 |
| zyga | on classic systems deb/rpm package will be used to install snapd which can then install snapd snap | 17:01 |
| Chipaca | popey: on the laptop that becomes unusable on resume, do you have SNAPD_DEBUG enabled? | 17:02 |
| Chipaca | popey: is it actually unusable, or is it hogging the network? | 17:02 |
| om26er | zyga: so once my deb based snapd installs the snap based snapd, will I then be able to remove the deb based snapd ? (That would be a tongue twister if spoken) | 17:03 |
| zyga | jdstrand: scmp_sys_resolver claims that it is statx | 17:03 |
| zyga | om26er: I suspect so but we are not planning on removing the deb | 17:05 |
| zyga | om26er: though maybe eventually that will be supported | 17:05 |
| zyga | om26er: snapd as a snap is required in the multi-base world we are going towards | 17:05 |
| zyga | om26er: where core16, core18 and future core20 will be co-installed to support diverse apps on a single system | 17:06 |
| om26er | cool stuff! | 17:06 |
| zyga | om26er: indeed :) | 17:07 |
| cjwatson | om26er: Note that snapd already re-execs snapd inside the core snap, and has done for some time; moving that bit to a dedicated snapd snap is a refactoring, AIUI | 17:09 |
| Chipaca | cjwatson: re-exec is a distro choice, though | 17:10 |
| Chipaca | (ubuntu does) | 17:10 |
| cjwatson | True | 17:10 |
| jdstrand | zyga: interesting. are you on cosmic? | 17:10 |
| om26er | cjwatson: I guess making that a separate snap will make updating snapd on a UbuntuCore system quicker | 17:10 |
| zyga | jdstrand: indeed | 17:10 |
| zyga | om26er: yes, it will no longer require a reboot | 17:13 |
| ahayzen | jdstrand, thresh, BTW i think that this is related to Qt apps not running with core18 https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1774739 and this https://github.com/snapcore/core18/issues/4 | 17:19 |
| mup | Bug #1774739: Running Qt apps inside a 18.04 container crashes <qtbase-opensource-src (Ubuntu):New> <https://launchpad.net/bugs/1774739> | 17:19 |
| mvo | sergiusens: I added it to https://forum.snapcraft.io/t/developer-sprint-sep-17th-2018/7336 | 17:36 |
| mup | PR snapd#5825 opened: tests: add snap install hook with base: core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5825> | 17:38 |
| jdstrand | ahayzen: yes, for sure. zyga, if you are doing a PR, can you reference that bug ^ | 17:39 |
| zyga | thanks, will do | 17:40 |
| joc | what's the simplest method to check in a shell script if a device has a serial assertion? would `snap known serial` exit with an error code if there wasnt one? | 17:41 |
| ahayzen | zyga, thanks ! do you know if a fix would also help out docker containers ? Or would it be specific to snapd ? | 17:43 |
| zyga | ahayzen: I'm not sure I understand | 17:43 |
| zyga | unless those containers are inside snapd | 17:43 |
| zyga | the change will allow all snap applications to use the new system call | 17:43 |
| jdstrand | ahayzen: it is possible that docker is missing the statx syscall | 17:44 |
| ahayzen | one bug was about running Qt applications under a straight docker container (no snapd), one was about running Qt apps with core18 snap | 17:44 |
| jdstrand | ahayzen: I don't know how to adjust docker's policy to allow extra syscalls, but that is certainly possible | 17:44 |
| ahayzen | apparently it works on debian sid, so i wondered if it was a general missing syscall for $container related things | 17:45 |
| thresh | ahayzen, for docker, you need 18.04 docker engine and libseccomp 2.3.3 on a host | 17:45 |
| thresh | that works | 17:45 |
| thresh | 18.04 or later that is | 17:45 |
| ahayzen | thresh, ah! So 17.12.1-0ubuntu1 from the archive is "too old" :-) ... i should use the snap ;-) | 17:45 |
| jdstrand | 18.04 only has 2.3.1 of libseccomp | 17:45 |
| jdstrand | which is why it shows up as unknown | 17:45 |
| ahayzen | yeah i'm using 17.12.1-0ubuntu1 docker + 2.3.1-2.1ubuntu4 libseccomp | 17:46 |
| jdstrand | zyga: note that golang seccomp might need to be adjusted to find statx | 17:47 |
| thresh | maybe upstream docker wont use the systems libseccomp | 17:48 |
| zyga | yeah, I suspect this will be a bit annoying to release | 17:48 |
| mup | PR snapcraft#2265 opened: build providers: allow snapcraft channel selection <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2265> | 17:48 |
| jdstrand | zyga: or rather, to resolve it. you might want to create a test case for this to make sure it is covered everywhere | 17:48 |
| zyga | for sure | 17:48 |
| ahayzen | yeah so debian testing has 2.3.3 seccomp and a newer docker.io, so makes sense it works. Thanks for the info! | 17:49 |
| Chipaca | ok, EOD for me. Tomorrow: tests. | 18:46 |
| * cachio afk | 19:05 | |
| kyrofa | jdstrand, I suddenly had a few PRs fail the review tools tests that pull from edge, did something odd happen? | 19:16 |
| kyrofa | There didn't seem to be an actual error, just an exit 1. I'm re-running one now | 19:19 |
| kyrofa | (I just got a pass locally) | 19:20 |
| kyrofa | Wonder if it has something to do with trusty, I'll try it out on there | 19:25 |
| kyrofa | Oh nevermind, this runs in a bionic lxd | 19:25 |
| jdstrand | kyrofa: I'm neverminding | 20:34 |
| kyrofa | jdstrand, found the issue. Running a bionic lxd: cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_cJIipS//lib/modules: No such file or directory | 20:45 |
| kyrofa | stable core, edge review tools | 20:46 |
| kyrofa | Works fine on bionic (without lxd) | 20:46 |
| kyrofa | I'm able to reproduce simply by running review tools in a bionic lxd container on a bionic host | 20:53 |
| kyrofa | jdstrand, we'll need to skip those tests for now | 20:53 |
| jdstrand | kyrofa: that is something outside of the review-tools. they run as non-root and don't do anything like that | 21:01 |
| kyrofa | jdstrand, https://forum.snapcraft.io/t/snaps-are-broken-in-bionic-lxd-container/7339 | 21:01 |
| kyrofa | Indeed, all snaps are broken in lxd bionic | 21:01 |
| kyrofa | Which makes me want to scream "why don't we have tests for this yet?" again after the last LXD fiasco | 21:02 |
| NickZ | well that's no good | 21:02 |
| jdstrand | I thought they were added. maybe only for core 16 since core18 wasn't a thing? | 21:02 |
| kyrofa | core16 is fine, and things still seem to work in xenial containers. But not bionic (still core, not core18) | 21:03 |
| NickZ | i was just about to start looking into deploying the snaps in an lxd container, too :P | 21:04 |
| sergiusens | jdstrand: this is lxd launch ubuntu:bionic and installing and running snaps in there | 21:06 |
| jdstrand | kyrofa, sergiusens: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L645 | 21:09 |
| jdstrand | kyrofa, sergiusens: it sounds like the container doesn't ship /lib/modules? | 21:09 |
| kyrofa | NickZ, worth the investigation, but leave yourself options. It seems not many people do that | 21:09 |
| jdstrand | kyrofa: if so, what happens if you 'mkdir /lib/modules' in the container? | 21:10 |
| kyrofa | jdstrand, it works | 21:10 |
| kyrofa | I'll add that to the forum | 21:10 |
| jdstrand | kyrofa: maybe changing the aforementioned line to '{"/lib/modules",.is_optional = true},' would be a viable fix | 21:11 |
| kyrofa | jdstrand, perhaps so. Not sure what side effects that might have | 21:14 |
| kyrofa | Hopefully the snapd folks see that tomorrow | 21:14 |
| mup | PR snapcraft#2266 opened: integration tests: disable tests using bionic container <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2266> | 21:15 |
| kyrofa | sergiusens, ^ there you go | 21:15 |
| NickZ | kyrofa: yeah, but we kind of have to if we want to test juju deployment on a local server | 21:18 |
| kyrofa | NickZ, this took roughly a year to fix: https://forum.snapcraft.io/t/lxc-snaps-dont-update/786 | 21:23 |
| NickZ | haha welp | 21:24 |
| NickZ | its not a huge issue, we can test deployment on xenial | 21:24 |
| kyrofa | Yeah I can't wholeheartedly recommend it until the spread suite includes relevant releases of lxd | 21:25 |
| mup | PR snapcraft#2128 closed: project_loader: stop setting LD_LIBRARY_PATH <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2128> | 21:39 |
| mup | PR snapcraft#2267 opened: build providers: refresh packages on bring up <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2267> | 21:45 |
| mup | PR snapcraft#2250 closed: project_loader: add preflight check <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2250> | 21:54 |
| mup | PR snapcraft#2265 closed: build providers: allow snapcraft channel selection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2265> | 22:03 |
| mup | PR snapcraft#2263 closed: project: catch parent YAML exceptions <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2263> | 22:12 |
| mup | PR snapcraft#2268 opened: sanity checks: allow snap/local dir <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2268> | 22:15 |
| mup | PR snapcraft#2269 opened: Provider decides on the image <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2269> | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!