| kyrofa | Man... I've spent all day commenting out tests trying to find which one is actually interfering with another. I need a drink | 00:01 |
|---|---|---|
| ikey | built: solus-runtime-gaming_0.0.0_all.snap | 00:12 |
| ikey | heh | 00:12 |
| mcphail | kyrofa: https://ovh.themcphails.uk/index.php/s/LbKIquTSxMernmM | 00:14 |
| kyrofa | mcphail, you're too kind | 00:15 |
| mcphail | ikey: so is this the "core" snap side of things? | 00:15 |
| ikey | right | 00:15 |
| ikey | just gonna be cheap and dirty and use 'snap pack' | 00:15 |
| ikey | but i think im gonna need to force some stuff like 'architectures' field, etc | 00:16 |
| ikey | built: solus-runtime-gaming_0.0.0_amd64.snap | 00:17 |
| ikey | bit better :p | 00:17 |
| mcphail | This is very exciting | 00:18 |
| ikey | certainly a learning experience for me | 00:18 |
| ikey | i imagine the initial 0.0.0 is gonna be nasty a.f. | 00:18 |
| ikey | but then i can start optimising it and cleaning it up | 00:18 |
| ikey | and allow us to do builds with local overlay layers onto the image | 00:19 |
| ikey | i.e. so we can stage mesa properly, etc | 00:19 |
| ikey | and part of this is gonna be a cleanup process to unjank the image | 00:19 |
| ikey | as long as i got `snap pack` command now i'm golden | 00:19 |
| mcphail | yes, I like that way of doing things | 00:20 |
| ikey | i strongly suspect we're gonna just rename linux-steam-integration to `LSI` and add an `lsi-exec` command, because I can think of a few games where this will help even outside steam.. | 00:20 |
| ikey | but one thing at a time :D | 00:20 |
| mup | PR snapd#4184 opened: tests: adding new test for uhid interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4184> | 00:21 |
| kyrofa | What does `snap pack` do that `snapcraft snap <dir>` doesn't? | 00:22 |
| ikey | doesn't use dpkg/apt/etc | 00:23 |
| ikey | :P | 00:23 |
| ikey | i'm creating a base snap | 00:23 |
| ikey | i.e. not ubuntu | 00:23 |
| ikey | snapcraft is bricked for solus | 00:23 |
| ikey | because its basically ubuntu specific last we looked | 00:23 |
| kyrofa | ikey, yeah `snapcraft snap <dir>` just runs `mksquashfs` with all the magical flags. It doesn't actually do anything with the dir | 00:28 |
| kyrofa | Although actually getting snapcraft ON there might be hard, unless classic snaps work | 00:28 |
| ikey | classic snaps work | 00:28 |
| ikey | classic "i think im ubuntu" not so much | 00:28 |
| ikey | this saves me a bit of work just having the command directly there | 00:28 |
| ikey | and yeah i saw its basically cleanup + meta + mksquashfs | 00:29 |
| ikey | basically im just tryna be hella lazy | 00:29 |
| === jero is now known as Guest81164 | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === wgrant_ is now known as wgrant | ||
| mborzecki | morning everyone | 05:59 |
| zyga-ubuntu | o/ | 06:02 |
| zyga-ubuntu | hmm | 06:04 |
| zyga-ubuntu | - linode:ubuntu-16.04-32:tests/main/xdg-open-compat | 06:04 |
| zyga-ubuntu | - linode:ubuntu-16.04-64:tests/main/xdg-open-compat | 06:04 |
| zyga-ubuntu | I'm seeing those fail in 2.29 branches | 06:04 |
| zyga-ubuntu | ... | 06:26 |
| mborzecki | zyga-ubuntu: hey | 06:39 |
| zyga-ubuntu | ho | 06:40 |
| zyga-ubuntu | eating breakfast | 06:40 |
| mup | PR snapd#4185 opened: interfaces/builtin/account_control: drop group filter from seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185> | 06:40 |
| zyga-ubuntu | neetd to look into those failing tests | 06:40 |
| mborzecki | yeah, noticed that sergiusens spread tests were failing because of those | 06:41 |
| zyga-ubuntu | commented | 06:41 |
| zyga-ubuntu | look at 4185 | 06:41 |
| mborzecki | ha, good catch, do you know if I could feed this rule to snap-seccomp locally to see if it compiles? | 06:42 |
| zyga-ubuntu | yes | 06:43 |
| zyga-ubuntu | I think it will compile | 06:43 |
| zyga-ubuntu | it just needs to run to see what happens | 06:43 |
| zyga-ubuntu | compile vs run | 06:43 |
| mborzecki | hm there's tests/main/interfaces-account-control i'll run it to see what will happen | 06:44 |
| zyga-ubuntu | ok | 06:45 |
| zyga-ubuntu | morning mvo | 06:45 |
| mvo | hey zyga-ubuntu | 06:45 |
| zyga-ubuntu | mvo: we have a problem with one spread test, it fails very very often across many PRs (including 2.29) | 06:45 |
| zyga-ubuntu | tests/main/xdg-open-compat | 06:45 |
| mvo | zyga-ubuntu: ok, I have a look. do you happen to have the error at hand? | 06:47 |
| zyga-ubuntu | no, sorry, running it now to see | 06:47 |
| mborzecki | mvo: https://s3.amazonaws.com/archive.travis-ci.org/jobs/299323286/log.txt there's some error log here | 06:50 |
| mvo | mborzecki: hm, <Message>Access Denied</Message> - anyway I will find one if its common :) | 06:52 |
| mvo | 49 PRs, woah | 06:52 |
| zyga-ubuntu | I think it's review sprint time | 06:52 |
| zyga-ubuntu | mvo: many are approved and need 2nd review | 06:52 |
| zyga-ubuntu | https://s3.amazonaws.com/archive.travis-ci.org/jobs/299180299/log.txt?X-Amz-Expires=30&X-Amz-Date=20171109T065333Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171109/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=b2c9efa5b8cf4fe1b35132841d988eeaa70be47b26b4d84a68d849221c1b553d | 06:53 |
| zyga-ubuntu | mvo: ^ failure | 06:53 |
| zyga-ubuntu | + apt download snapd-xdg-open=0.0.0~16.04 | 06:54 |
| zyga-ubuntu | WARNING: apt does not have a stable CLI interface. Use with caution in scripts. | 06:54 |
| zyga-ubuntu | E: Version '0.0.0~16.04' for 'snapd-xdg-open' was not found | 06:54 |
| zyga-ubuntu | that's it | 06:54 |
| zyga-ubuntu | aha | 06:54 |
| zyga-ubuntu | seems simple | 06:54 |
| mvo | zyga-ubuntu: aha, I think that happens because snapd 2.28.5 is now in xenail-updates and we have the older version not available anymore | 06:54 |
| mvo | zyga-ubuntu: it should fail consistently though | 06:54 |
| zyga-ubuntu | https://packages.ubuntu.com/search?keywords=snapd-xdg-open&searchon=names&suite=all§ion=all | 06:55 |
| zyga-ubuntu | yes | 06:55 |
| zyga-ubuntu | magic, right? | 06:55 |
| zyga-ubuntu | maybe the non-xenial-updates version is cached on some images? | 06:55 |
| zyga-ubuntu | (just pulling ideas out ..) | 06:55 |
| mvo | zyga-ubuntu: thats how mborzecki name is pronounced ;) | 06:55 |
| mvo | zyga-ubuntu: a good question, or maybe not all mirrors are up-to-date or something | 06:55 |
| zyga-ubuntu | haha :) | 06:55 |
| mvo | zyga-ubuntu: definitely strange | 06:55 |
| mborzecki | close enough :) | 06:55 |
| mvo | mborzecki: I will learn it eventually :) | 06:56 |
| zyga-ubuntu | m-a-ch-e-y | 06:56 |
| === chihchun_afk is now known as chihchun | ||
| zyga-ubuntu | mvo: curiously I didn't hit this locally yesterday, after running spread extensively | 06:56 |
| zyga-ubuntu | let's see if today's any different | 06:56 |
| zyga-ubuntu | offtopic: I found this very funny to read: http://www.sciencemag.org/careers/2016/01/how-read-scientific-paper :) | 06:57 |
| zyga-ubuntu | while I make some tea | 06:57 |
| mvo | zyga-ubuntu: yeah, but we need to fix it for 2.29 or autopkgtest in the distro will be unahppy :( | 06:57 |
| zyga-ubuntu | yes | 06:59 |
| zyga-ubuntu | ha, failed now | 06:59 |
| zyga-ubuntu | so maybe old package was garbage collected | 07:00 |
| mvo | zyga-ubuntu: heh, this how-to-read- article reminds me of https://www.youtube.com/watch?v=ILysMhm8lXs which is about taxes but otherwise similar | 07:00 |
| mvo | zyga-ubuntu: yes | 07:00 |
| zyga-ubuntu | only 2.28.5 is in the archive now | 07:00 |
| * zyga-ubuntu tries a simple fix | 07:00 | |
| mvo | zyga-ubuntu: we need to thing what to do, maybe the only thing we can do is to kill the test :( | 07:00 |
| mvo | zyga-ubuntu: aha, cool. simple++ | 07:00 |
| zyga-ubuntu | running now | 07:01 |
| * zyga-ubuntu looks at tea | 07:01 | |
| mborzecki | is there a way to mark it as expected failure (provided it fails consistently), like pytest.xfail or sth? | 07:02 |
| zyga-ubuntu | nope | 07:02 |
| zyga-ubuntu | mborzecki: sorry about my last answer, it was a mental shortcut | 07:14 |
| mborzecki | hm? | 07:15 |
| zyga-ubuntu | mborzecki: there's no direct way, we can echo "blah blah"; exit 0, or switch a test to manual: true to skip it | 07:15 |
| zyga-ubuntu | mborzecki: we can also patch spread, it's github.com/snapcore/spread after all | 07:15 |
| zyga-ubuntu | mborzecki: it's just that we traditinally tried to fix tests rather than improve the infra | 07:15 |
| mvo | zyga-ubuntu: I wonder why we did not notice 4182 ourselfs | 07:16 |
| zyga-ubuntu | mvo: it's curious | 07:16 |
| zyga-ubuntu | mvo: I ran snap-confine counltess times recently | 07:17 |
| mvo | zyga-ubuntu: does your fix for the download thing works? | 07:17 |
| zyga-ubuntu | and it did work | 07:17 |
| zyga-ubuntu | mvo: I made two tweaks to the policy that I haven't upstreamed yet but they are not for os-release | 07:17 |
| mvo | zyga-ubuntu: yeah, looking at the code we should check for os-release often and yet | 07:17 |
| zyga-ubuntu | maybe the real issue is more subtle and we're missing something? | 07:17 |
| zyga-ubuntu | # Allow reading the os-release file (possibly a symlink to /usr/lib). | 07:18 |
| zyga-ubuntu | /{etc/,usr/lib/}os-release r, | 07:18 |
| zyga-ubuntu | this is in the profile, but for snap-update-ns | 07:18 |
| zyga-ubuntu | not for snap-confine | 07:18 |
| mup | PR snapd#4181 closed: interfaces/many: misc policy updates for browser-support, cups-control and network-status (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4181> | 07:18 |
| mborzecki | i'm trying to run linode:ubuntu-core-16-64:tests/main/interfaces-account-control and got `cp: error writing '/mnt/user-data/gopath/bin/fakestore': No space left on device` :/ | 07:19 |
| zyga-ubuntu | ha | 07:19 |
| zyga-ubuntu | mvo: it's silly | 07:19 |
| zyga-ubuntu | mvo: this why http://pastebin.ubuntu.com/25923441/ | 07:19 |
| zyga-ubuntu | fopen fails, no worries, return true | 07:20 |
| zyga-ubuntu | we don't even log it | 07:20 |
| zyga-ubuntu | it would only show up on core | 07:20 |
| mvo | autsch | 07:20 |
| mvo | ok | 07:20 |
| zyga-ubuntu | and when we run on core and we treat it as classic we do the normal thing | 07:20 |
| zyga-ubuntu | and because it's actually meant to work | 07:20 |
| zyga-ubuntu | nothing failed | 07:20 |
| zyga-ubuntu | we did "base snaps" on core since this code was introduced | 07:20 |
| zyga-ubuntu | if you know what I mean by this shortcut | 07:20 |
| zyga-ubuntu | we were treating core as classic systems, setting up separate namespaces, constricting them out of base snaps | 07:21 |
| zyga-ubuntu | mvo: as for your earlier question, no it's still running | 07:21 |
| zyga-ubuntu | not sure if stuck | 07:21 |
| zyga-ubuntu | http://pastebin.ubuntu.com/25923446/ | 07:21 |
| zyga-ubuntu | (feels broken) | 07:22 |
| mvo | zyga-ubuntu: yeah, what did you do to fix it? | 07:23 |
| zyga-ubuntu | mvo: I just pushed fix/xdg-open-compat | 07:23 |
| zyga-ubuntu | but it's not a real fix I think (it's not working) | 07:23 |
| zyga-ubuntu | I just changed the version | 07:23 |
| zyga-ubuntu | --dest=com.canonical.SafeLauncher | 07:24 |
| zyga-ubuntu | I wonder if we are missing a service file for the legacy object path | 07:25 |
| zyga-ubuntu | (not the one at io.snapcraft....) | 07:25 |
| zyga-ubuntu | aha | 07:25 |
| zyga-ubuntu | yeah, no such launcher in data/dbus | 07:25 |
| mvo | zyga-ubuntu: yeah, that will just pull in the empty transitional package | 07:26 |
| mup | PR snapd#4186 opened: tests: disable xdg-open-compat test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4186> | 07:26 |
| zyga-ubuntu | mvo: yeah, let's kill this test for now | 07:29 |
| mup | PR snapd#4187 opened: tests: fix xdg-open-compat <Created by mvo5> <https://github.com/snapcore/snapd/pull/4187> | 07:29 |
| mvo | zyga-ubuntu: I pushed also a followup which just downloads the right deb from LP - I pushed both so that we have at least one working, we need to unblock 2.29, I fear we will be starved by travis not doing tests for us | 07:30 |
| mborzecki | i can also kill cgo'ed user lookup while fixing the groups | 07:30 |
| mvo | zyga-ubuntu: so when we push the fix into the open PRs we need to make sure we push only to the important ones we want for 2.29 | 07:30 |
| mvo | mborzecki: \o/ | 07:30 |
| mvo | mborzecki: +1 for that | 07:30 |
| zyga-ubuntu | mvo: +1 | 07:33 |
| zyga-ubuntu | ok, I'll re-focus on lxd issues now | 07:34 |
| pedronis | mvo: hi, I got that error (apt snap-xdg-open) also on my last PRs, it seems consistent afaict | 07:35 |
| * pedronis breakfast | 07:35 | |
| mvo | pedronis: yes, we are fixing it as we speak | 07:37 |
| === JoshStrobl|Away is now known as JoshStrobl | ||
| mup | PR snapd#4160 closed: cmd/snap-confine: add slave PTYs and let devpts newinstance perform mediation (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4160> | 08:11 |
| mvo | zyga-ubuntu: does 4146 needs further changes ? it looks like there are commits for 4144 which are not part of 4146? | 08:13 |
| mup | PR snapd#4188 opened: osutil: replace cgo bits with non-cgo, vendered os/user <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4188> | 08:15 |
| pedronis | mvo: what's the status of #4049, seems old but nobody ever looked at it? | 08:17 |
| mup | PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049> | 08:17 |
| mvo | pedronis: its in a sad state, its not fully working and its unclear if the vendor approach is powerful enough, go get/govendor make some assumptions that are hard to workaround | 08:18 |
| mvo | pedronis: I need to get back to it but have not managed it yet, we may need to do something simpler and abandon this (simpler as in not using govendoring but copy code/git submodule or smilar | 08:19 |
| pedronis | mvo: #4046 has two +1 but mentions spread-cron, so not sure what to do with it | 08:20 |
| mup | PR #4046: release: snapd 2.28.5 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4046> | 08:20 |
| pedronis | heh sorry | 08:20 |
| pedronis | mvo: #4043 has two +1 but mentions spread-cron, so not sure what to do with it | 08:20 |
| mup | PR #4043: cmd/snap-confine: update valid security tag regexp <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4043> | 08:20 |
| pedronis | oops | 08:20 |
| * pedronis is not sure to be actually awake | 08:20 | |
| mvo | lol | 08:20 |
| * mvo hugs pedronis | 08:20 | |
| * mvo hands pedronis a cup of coffee as well | 08:20 | |
| pedronis | mvo: I meant #4063 | 08:21 |
| mup | PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063> | 08:21 |
| pedronis | mvo: also unsure what needs to happen with #4059 | 08:22 |
| mup | PR #4059: tests: add test that checks core reverts on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/4059> | 08:22 |
| mvo | pedronis: I think this one can go in and needs the coresponding spread cron branch to get merged. let me do this now | 08:24 |
| mup | PR snapd#4059 closed: tests: add test that checks core reverts on core devices <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4059> | 08:24 |
| mvo | pedronis: uh, it did not actually have two +1 :/ | 08:24 |
| mvo | pedronis: sorry, I mixed this up with the previous one. its manual: true so no harm | 08:24 |
| zyga-ubuntu | mvo: no, 4146 can go in as-is | 08:26 |
| pedronis | mvo: #4129 has also two +1 , made a small comment there though | 08:26 |
| mup | PR #4129: wrappers: do not error on incorrect Exec= lines <Created by mvo5> <https://github.com/snapcore/snapd/pull/4129> | 08:26 |
| zyga-ubuntu | mvo: 4146 has the same fix without the extra pretty printing | 08:26 |
| mvo | zyga-ubuntu: ok | 08:27 |
| pedronis | mvo: #4173 has also two +1 , but not sure where you want to redo the disabling of auto-refreshes in tests | 08:31 |
| mup | PR #4173: corecfg: validate refresh.schedule when it is applied <Created by mvo5> <https://github.com/snapcore/snapd/pull/4173> | 08:31 |
| mvo | pedronis: I can fix that there (in a bit, need to go over the 2.29 PRs as we need a new 2.29.3 :( | 08:33 |
| pedronis | sorry, I'm distracting you | 08:33 |
| pedronis | mvo: otoh you should garden your old PRs a bit more (friendly nag) | 08:34 |
| mvo | pedronis: no worries about distracting. and yes, agreed sorry for this | 08:36 |
| pedronis | mvo: should we close #4049 for now then? | 08:40 |
| mup | PR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049> | 08:40 |
| === pachulo_ is now known as pachulo | ||
| mvo | pedronis: if we close we need another reminder that we need to do this work soon, it felt off the agenda once before. but yeah, in its current form it is not close to be mergable | 08:43 |
| pedronis | mvo: I can mark it blocked if you prefer that way | 08:44 |
| pedronis | is there no matching topic? | 08:44 |
| mvo | pedronis: please mark it as blocked | 08:45 |
| mvo | pedronis: no topic it seems, thats sad | 08:46 |
| mvo | zyga-ubuntu: I have some questions for 4146, how confident are you in the changes? | 08:46 |
| mvo | zyga-ubuntu: there are actual review questions in there too :) | 08:46 |
| mvo | pedronis: a second review for 4146 would be great | 08:47 |
| mvo | (or someone else, maybe pstolowski ?) | 08:47 |
| pedronis | mvo: marked as blocked, but yes best would be to have an upcoming topic and close it if the approach is non-viable | 08:47 |
| pedronis | mvo: #4063 has two +1 but it is failing afaict | 08:48 |
| mup | PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063> | 08:48 |
| mvo | pedronis: agreed, I updated the bug | 08:49 |
| mvo | pedronis: I will look into the failure | 08:49 |
| pstolowski | mvo, sure, gladly | 08:49 |
| pedronis | zyga-ubuntu: I looked at #4146 , seems alright, I have an unrelated (in the sense it was like that before) there though | 08:59 |
| mup | PR #4146: interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4146> | 08:59 |
| pedronis | unrelated question | 08:59 |
| Tribaal | Hey so whoever snapped Electrum: thanks a lot! | 09:00 |
| Tribaal | beer++ | 09:00 |
| zyga-ubuntu | pedronis: yes? | 09:00 |
| pedronis | zyga-ubuntu: sorry, see PR | 09:00 |
| pedronis | now | 09:00 |
| zyga-ubuntu | ah, ok | 09:00 |
| zyga-ubuntu | ah, great question, let me check | 09:01 |
| mvo | thanks for your review pedronis | 09:02 |
| mvo | zyga-ubuntu: please don't get me wrong, I want to merge it (and like a lot of it). I'm just worried about the churn | 09:02 |
| zyga-ubuntu | pedronis: so looking at 61a4a0e442ab329f10773098448eb931fe6c355b I'm not sure | 09:02 |
| zyga-ubuntu | jamie patched one specific instance, not any of the generic helpers | 09:02 |
| === __chip__ is now known as Chipaca | ||
| zyga-ubuntu | I think we need jdstrand to answer that; I don't quite know how that works | 09:03 |
| pedronis | zyga-ubuntu: maybe something to chat with him about, anyway the code was like that before | 09:03 |
| zyga-ubuntu | jdstrand: (and I'd love to know) | 09:03 |
| zyga-ubuntu | yes, definitely | 09:04 |
| pedronis | so it's not a blocker for the PR | 09:04 |
| mvo | yay | 09:04 |
| pedronis | #4122 needs a 2nd review | 09:04 |
| mup | PR #4122: configstate: add support for configure-snapd for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122> | 09:04 |
| zyga-ubuntu | mvo, pedronis: I agree about finding a better way to work on spec objects; | 09:04 |
| zyga-ubuntu | to explain it quickly, I wanted to stay consistent and not introduce a huge argument change patch | 09:05 |
| mup | PR snapd#4186 closed: tests: disable xdg-open-compat test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4186> | 09:07 |
| mvo | zyga-ubuntu: yeah, thats ok, thank you. I was not aware it was a common pattern | 09:07 |
| mvo | zyga-ubuntu: (I still dislike it but not something for the PR in question :) | 09:08 |
| zyga-ubuntu | mvo: yes, no disagreement there | 09:10 |
| pedronis | zyga-ubuntu: in #4062 seems you promised a couple more comment tweaks ... also probably then mvo and pstolowski should look at it again | 09:11 |
| mup | PR #4062: cmd/snap: warn when a snap is not from the tracking channel <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4062> | 09:11 |
| pedronis | wrong PR | 09:11 |
| pedronis | sorry | 09:11 |
| pedronis | zyga-ubuntu: I meant #4068 | 09:11 |
| mup | PR #4068: interfaces/builtin: add support for content "source" section <Created by zyga> <https://github.com/snapcore/snapd/pull/4068> | 09:11 |
| zyga-ubuntu | pedronis: 4068 is not ready for landing, I'll add a "blocked" tag there, it's meant to land after most of the layout patches are ready | 09:12 |
| pedronis | heh ok | 09:12 |
| pedronis | #4100 needs niemeyer | 09:12 |
| mup | PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100> | 09:12 |
| pstolowski | pedronis, zyga-ubuntu I think my general comment about cleanSubPath still needs addressing, would be good to fix it with 4068 | 09:15 |
| pstolowski | unless I miss something | 09:16 |
| * zyga-ubuntu looks | 09:17 | |
| zyga-ubuntu | interesting | 09:17 |
| zyga-ubuntu | anyway, I'll return to that after bulk of layout code is in | 09:17 |
| mvo | zyga-ubuntu: sorry for being annoying - did you idea about the lxd fix work out? | 09:19 |
| zyga-ubuntu | mvo: no, not yet :/ | 09:20 |
| zyga-ubuntu | mvo: I'm writing a test that reproduces it | 09:20 |
| zyga-ubuntu | at least will be a start for another look | 09:20 |
| mvo | zyga-ubuntu: cool, still keen to have it for .3 if its small and targeted | 09:21 |
| pedronis | pstolowski: there are still open questions how the API should work in #4108 | 09:26 |
| mup | PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108> | 09:26 |
| pstolowski | pedronis, I know, i'm getting to it, got sidetracked by the snapctl and cookie issues | 09:26 |
| pstolowski | pedronis, can you take a look at lanes helper PR? | 09:27 |
| pedronis | pstolowski: yes, I'm going through PRs cronologically (mostly) | 09:27 |
| pstolowski | thanks | 09:27 |
| pedronis | doing only reviews this morning | 09:27 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| === JanC_ is now known as JanC | ||
| zyga-ubuntu | hmm | 09:30 |
| zyga-ubuntu | [ 1280.959106] audit: type=1400 audit(1510219691.912:133): apparmor="DENIED" operation="open" profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/usr/lib/os-release" pid=29008 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 09:30 |
| zyga-ubuntu | (unrelated but something we probably want to fix) | 09:31 |
| zyga-ubuntu | if anyone wants to make a quick PR for lxd interface | 09:31 |
| mborzecki | i can take a look at it | 09:34 |
| mborzecki | i'm going through review anyway, so might as well take a look at something else :) | 09:35 |
| pstolowski | zyga-ubuntu, commented on #4146 | 09:37 |
| mup | PR #4146: interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4146> | 09:37 |
| zyga-ubuntu | pstolowski: ack on one, not sure about other | 09:38 |
| zyga-ubuntu | I'm deep in lxd if you wnat to push small tweak there please do | 09:38 |
| pedronis | zyga-ubuntu: do all snap-update-ns PRs need a jdstrand review ? | 09:41 |
| zyga-ubuntu | pedronis: not all but some surely do | 09:41 |
| zyga-ubuntu | pedronis: the one about designing the "writable mimic" is the one I need a review on | 09:41 |
| zyga-ubuntu | pedronis: the ones about secure-mk{dir,file} do as well | 09:42 |
| pedronis | ok, I have a bunch of older/big ones to go through first though | 09:43 |
| mup | PR snapd#4172 closed: interfaces/kmod: simplify loadModules now that errors are ignored <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4172> | 09:43 |
| mvo | pedronis: 4122 is good from your POV, right? just needs a second review? | 09:48 |
| pedronis | mvo: yes, needs 2nd review | 09:54 |
| mvo | ta | 09:55 |
| pedronis | pstolowski: #4152 has my +1, needs a re-review by zyga-ubuntu | 10:05 |
| mup | PR #4152: snapd: fix snap cookie bugs <Created by stolowski> <https://github.com/snapcore/snapd/pull/4152> | 10:05 |
| Chipaca | so... we're moving exclusively to /etc/{passwd,group} for lookups? | 10:05 |
| Chipaca | mborzecki: or were we already there and I hadn't noticed? | 10:06 |
| pstolowski | pedronis, thanks! | 10:06 |
| Chipaca | because if this is what we want to do, we need to refactor some code | 10:06 |
| Chipaca | in particular the code that looks up user dirs | 10:06 |
| Chipaca | this is relevant to my current work, so i can whip up the refactor right now | 10:06 |
| mborzecki | Chipaca: something we discussed yesterday with niemeyer, the idea is to kill cgo code (or most of it at least) | 10:06 |
| mborzecki | i've pulled in non-cgo pieces of os/user as osutil/user for now and put it up for the review | 10:08 |
| Chipaca | right, but this could lead to inconsistencies, which is why i'm checking -- if this is what we want to do i need to refactor a bit of code | 10:08 |
| Chipaca | i can do it after we merge the osutil/user pr | 10:08 |
| mborzecki | as i understand that's the direction we want to go, zyga-ubuntu mvo ? | 10:09 |
| zyga-ubuntu | Chipaca: I think we wanted to be cgo free and decided to kill the c-goat on the altar to attain that | 10:09 |
| zyga-ubuntu | Chipaca: whatever you need / do I think we're not adding more cgo | 10:10 |
| Chipaca | zyga-ubuntu: my question is: is /etc/passwd and /etc/group going to be the canonical (heh) source of users and groups on all snappy systems | 10:10 |
| Chipaca | because that's the impact in practice | 10:10 |
| Chipaca | we're not even looking at extrausers/groups | 10:10 |
| zyga-ubuntu | Chipaca: no, (see extrausers) | 10:10 |
| zyga-ubuntu | Chipaca: it's more subtle | 10:10 |
| zyga-ubuntu | Chipaca: we're killing reasons to know | 10:10 |
| zyga-ubuntu | Chipaca: not picking means to know | 10:11 |
| Chipaca | zyga-ubuntu: sorry, i don't understand | 10:11 |
| Chipaca | the code in #4188 looks up things only in /etc, no extra | 10:11 |
| mup | PR #4188: osutil: replace cgo bits with non-cgo, vendored os/user <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4188> | 10:11 |
| pedronis | pstolowski: about LaneTasks, I said something wrong I think about lane 0 and then corrected myself but it got missed, I think lane 0 behavior is wrong, probably easy to find out with a different test | 10:11 |
| Chipaca | from this conversation i suspect the lack of extra is oversight | 10:12 |
| Chipaca | easily fixable | 10:12 |
| zyga-ubuntu | Chipaca: I mean, as far as I understand it, is that we haven't said we'll use /etc/passwd exclusively (yet), more like we said for each of the reasons to lookup users/groups _so far_ we want to avoid that reason | 10:12 |
| Chipaca | but the approach of making files the only source of users, that's policy now? (fine by me) (still needs a refactor from me) | 10:12 |
| * zyga-ubuntu killed qemu to "refresh" kernel state | 10:12 | |
| zyga-ubuntu | man this mount business | 10:12 |
| pedronis | zyga-ubuntu: did we discuss this changes with jdstrand btw ? he added that stuff I think | 10:12 |
| zyga-ubuntu | fishy stuff | 10:12 |
| Chipaca | zyga-ubuntu: in core we will be creating users and groups we will then fail to find | 10:13 |
| zyga-ubuntu | pedronis: no, | 10:13 |
| zyga-ubuntu | pedronis: we plan to today | 10:13 |
| zyga-ubuntu | that was just yesterday | 10:13 |
| pedronis | ok | 10:13 |
| Chipaca | so I maintain that that aspect at least is a bug | 10:13 |
| pstolowski | pedronis, ah, thanks, will fix | 10:13 |
| Chipaca | zyga-ubuntu: your sentence about avoiding looking up things clashes with the pr we have which has a bunch of code for looking up things | 10:14 |
| zyga-ubuntu | Chipaca: yeah, I probably miss something then | 10:14 |
| Chipaca | you might be thinking about us not wanting to list all users | 10:14 |
| mborzecki | Chipaca: there's a related PR #4185 where we remove group from seccom rules, if that does not fly because of security concerns, we'll probably need to look into #4188 | 10:14 |
| mup | PR #4185: interfaces/builtin/account_control: drop group filter from seccomp rules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4185> | 10:14 |
| mup | PR #4188: osutil: replace cgo bits with non-cgo, vendored os/user <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4188> | 10:14 |
| Chipaca | which is valid, unless we limit our users/groups to files -- then we can list them all no problem | 10:15 |
| mborzecki | at least that that's how i undestood the discussion from yday | 10:15 |
| Chipaca | mborzecki: doesn't 4188 make 4185 pointless? | 10:16 |
| Chipaca | feels like we're trying to solve problems breadth-first | 10:17 |
| mborzecki | yes, it does, but I guess we'll see where 4185 takes us | 10:18 |
| mvo | Chipaca: sorry for coming in late, was distracted. so I think its worth checking with niemeyer if we really want to go as far as to kill off the cgo user lookup bits. we certainly do not want to add more cgo code (this is the first part of the work that mborzecki is doing). we need to check that we really do not need anything from nss on classic systems, i.e. that we don't accidentally break snapd there | 10:28 |
| mvo | meh, all four pending 2.29 PRs have not even started yet in travis :/ | 10:30 |
| pedronis | mvo: we should not push anything to other PRs I suppose :/ | 10:33 |
| * zyga-ubuntu scratches head | 10:35 | |
| Chipaca | mborzecki, mvo, niemeyer, pedronis, zyga-ubuntu: https://forum.snapcraft.io/t/system-user-lookup/2753 | 10:35 |
| mvo | pedronis: yeah | 10:36 |
| mvo | Chipaca: thank you, reading | 10:36 |
| zyga-ubuntu | aha | 10:39 |
| Chipaca | gah, mis-edit | 10:40 |
| * Chipaca fixes | 10:40 | |
| mvo | Chipaca: silly question, from looking at the code we use user.Current().HomeDir a bunch of time, if the user is on ldap (or whatnot) will this still work in the new world? if not I think we will break a bunch of users | 10:40 |
| Chipaca | mvo: it won't work for arbitrary users, but in general you can count on the local users to also being in passwd | 10:41 |
| Chipaca | *not always* | 10:42 |
| Chipaca | so, no in the general case | 10:42 |
| mup | PR snapd#4189 opened: interfaces/builtin/lxd_support: allow discovering of host's os-release <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4189> | 10:42 |
| mvo | Chipaca: thats my concerns, in large deploys with ldap-nss or similar suddenly snaps might stop working because our env setup code fails | 10:42 |
| Chipaca | mvo: but … the general case, looking at /home is horrible also | 10:42 |
| mvo | Chipaca: yes, I mean, I am not sure we can get around nss for those systems | 10:43 |
| Chipaca | mvo: i agree. do we care? | 10:43 |
| mvo | Chipaca: unless we do stuff like blindly trusting the HOME env or something | 10:43 |
| Chipaca | that's basically the question :-) | 10:43 |
| greyback | zyga-ubuntu: hey, would you mind having a look and see if you have anyting to suggest: https://forum.snapcraft.io/t/mir-snap-not-detecting-new-input-devices/2742 | 10:43 |
| mvo | Chipaca: right, thats the question we need to answer: is not having cgo worth breaking users on ldap-nss and similar | 10:44 |
| Chipaca | mvo: yes. i'll add this. | 10:45 |
| mvo | thank you | 10:45 |
| zyga-ubuntu | greyback: I'm debugging something else now but quick question: | 10:47 |
| greyback | zyga-ubuntu: no hurry, whatsoever, but thanks | 10:47 |
| zyga-ubuntu | greyback: go to /sys/fs/cgroup/devices/_the_one_for_mir/ and look at devices.list | 10:48 |
| zyga-ubuntu | please add that to the post | 10:48 |
| zyga-ubuntu | that will help understand things a lot | 10:48 |
| greyback | zyga-ubuntu: ack | 10:48 |
| * zyga-ubuntu is back into insanity land | 10:48 | |
| zyga-ubuntu | but now has a working reproducer for the bug | 10:48 |
| zyga-ubuntu | and I think I can now test my idea | 10:48 |
| zyga-ubuntu | greyback: I can look at this issue as soon as I'm done with lxd/14.04 issue | 10:54 |
| zyga-ubuntu | mvo: I have a test that breaks now, I can share that and I am testing theories | 10:54 |
| zyga-ubuntu | greyback: great, | 10:55 |
| greyback | zyga-ubuntu: appreciated. I've learned a lot while debugging, but I expect you'll make progress much faster | 10:55 |
| zyga-ubuntu | greyback: what is the major/minor of the input device that gets added? | 10:55 |
| mvo | zyga-ubuntu: cool, curious to know what the test looks like | 10:55 |
| zyga-ubuntu | mvo: ha, it's an iteration of your lxd test (thank you very very much for that) | 10:55 |
| zyga-ubuntu | mvo: though a simpler 14.04 test will do the same | 10:55 |
| zyga-ubuntu | still, I kept it lxd since it may be something lxd specific in the end | 10:55 |
| mvo | zyga-ubuntu: cool, thanks | 10:56 |
| zyga-ubuntu | SPREAD_DEBUG_EACH=0 spread -reuse -shell-after -v qemu:ubuntu-16.04-64:tests/main/lxd-refresh-cycle | 10:59 |
| zyga-ubuntu | code is in rfc/lxd-issue-test in my remote | 10:59 |
| zyga-ubuntu | I'm not 100% sure qemu can survive too many -reuse cycles with this one, | 10:59 |
| zyga-ubuntu | just FYI | 10:59 |
| greyback | zyga-ubuntu: udevadm info -rq name /sys/dev/shar/13:69 return the correct thing: /dev/input/event5, so 13:69? Sound right? | 11:00 |
| zyga-ubuntu | greyback: (not sure, but it's not present in that file) | 11:01 |
| zyga-ubuntu | greyback: so this is why it doesn't work | 11:01 |
| zyga-ubuntu | now the question that's really interesting: why :) | 11:01 |
| greyback | zyga-ubuntu: ok. What should be updating that? | 11:01 |
| zyga-ubuntu | greyback: it's updated by snappy-app-dev | 11:02 |
| zyga-ubuntu | and udev rules | 11:02 |
| zyga-ubuntu | what is the profile generated for mir ? | 11:02 |
| zyga-ubuntu | (/etc/udev/rules.d/) | 11:03 |
| greyback | zyga-ubuntu: http://pastebin.ubuntu.com/25924450/ | 11:04 |
| zyga-ubuntu | so KERNEL=="event[0-9]*", TAG+="snap_mir-kiosk_mir-kiosk" looks like something that ought to make this work | 11:05 |
| zyga-ubuntu | greyback: TBH, now I don't know more | 11:06 |
| zyga-ubuntu | greyback: look at udev events when you plug this in | 11:06 |
| zyga-ubuntu | is it matchin? | 11:06 |
| greyback | zyga-ubuntu: tbh I'm not sure how to tell. http://pastebin.ubuntu.com/25924507/ ?? | 11:08 |
| zyga-ubuntu | greyback: good, just add the options to show kernel and other things | 11:09 |
| zyga-ubuntu | and annotate the log with like "idle", "inserted", "removed" | 11:09 |
| zyga-ubuntu | so we know where's happening | 11:09 |
| zyga-ubuntu | greyback: if you add that to the post it will help a lot | 11:14 |
| greyback | zyga-ubuntu: just about to | 11:14 |
| greyback | done, added to last post | 11:15 |
| zyga-ubuntu | thank you | 11:16 |
| zyga-ubuntu | greyback: does it work if you run the app after plugging the mouse? | 11:19 |
| greyback | zyga-ubuntu: yes | 11:19 |
| greyback | and after that, removal and re-insertion is working fine | 11:19 |
| zyga-ubuntu | ok | 11:20 |
| zyga-ubuntu | can you please edit /lib/udev/snappy-app-dev | 11:20 |
| zyga-ubuntu | comment out the debug section | 11:20 |
| zyga-ubuntu | and see what happens when you plug it in | 11:20 |
| zyga-ubuntu | also add that to the post when ready | 11:20 |
| greyback | ack | 11:21 |
| zyga-ubuntu | http://pastebin.ubuntu.com/25924595/ | 11:28 |
| zyga-ubuntu | ha | 11:33 |
| zyga-ubuntu | really interesting | 11:33 |
| mup | PR snapd#4176 closed: cmd: fix re-exec bug with classic confinement for host snapd < 2.28 <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4176> | 11:33 |
| zyga-ubuntu | mvo: I think (is) I understand it now | 11:37 |
| zyga-ubuntu | mvo: but not ready with patch yet | 11:37 |
| zyga-ubuntu | mvo: I'll keep you posted | 11:37 |
| mvo | thanks for the heads up | 11:39 |
| zyga-ubuntu | mvo: not a trivial one liner but something I may have a fix for for evaluation (kyrofa, et all) | 11:39 |
| * zyga-ubuntu -> coffee && power | 11:40 | |
| mvo | zyga-ubuntu: if you could quickly jump into the HO channel, I want to see if the external cam I organized works well enough | 11:44 |
| zyga-ubuntu | sure | 11:44 |
| zyga-ubuntu | one moment | 11:44 |
| pstolowski | do we have any (expected) travis/store hiccups today? | 11:44 |
| zyga-ubuntu | mvo: joining | 11:45 |
| zyga-ubuntu | pstolowski: nobody expects the unexpected issues | 11:53 |
| pstolowski | :) | 11:54 |
| zyga-ubuntu | ok, so I confirmed what is hanging inside lxd now (just ran a patched version), let me explore this further with some C code | 11:54 |
| mup | PR snapd#4190 opened: cmd/snap-seccomp: do not use group 'shadow' in tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4190> | 11:56 |
| pstolowski | mvo, +1 on 4122 with little nitpick | 11:58 |
| mup | PR snapd#4146 closed: interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4146> | 12:04 |
| mup | PR snapd#4182 closed: cmd/snap-confine: Ensure snap-confine is allowed to access os-release <Created by ikeydoherty> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4182> | 12:08 |
| mup | PR snapd#4183 closed: cmd/snap-confine: Respect biarch nature of libdirs <Created by ikeydoherty> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4183> | 12:09 |
| zyga-ubuntu | gah, darn it | 12:11 |
| zyga-ubuntu | in linux it's impossible to know what's really mounted :P | 12:11 |
| * zyga-ubuntu -> thinking | 12:12 | |
| mvo | pstolowski: thanks for your review | 12:16 |
| mup | PR snapd#4191 opened: cmd/snap-update-ns: do not assume 'nogroup' exists <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4191> | 12:17 |
| * kalikiana croissant&coffee break | 12:26 | |
| greyback | zyga-ubuntu: I've done as you suggested, but I see no debug log file being created at all, suggesting /lib/udev/snappy-app-dev isn't ever being called | 12:29 |
| mup | Issue snapcraft#1462 closed: update story <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1462> | 12:29 |
| mup | PR snapcraft#1412 closed: lxd: snapcraft refresh in containers <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1412> | 12:29 |
| kalikiana | sergiusens: thanks for merging! | 12:39 |
| zyga-ubuntu | greyback: interesting, I'll investigate myself later | 12:41 |
| zyga-ubuntu | mvo: I have a much much simpler solution in my head now, trying it out | 12:41 |
| greyback | zyga-ubuntu: thank you. | 12:42 |
| mup | PR snapcraft#1721 closed: integration tests: use ruby v2.4.2 <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1721> | 12:44 |
| zyga-ubuntu | running now, fingers crossed | 12:46 |
| jdstrand | mborzecki: I gave some other options, but before you change anything, please let's get consensus on the direction | 12:49 |
| mborzecki | jdstrand: thanks for the review | 12:49 |
| zyga-ubuntu | jdstrand: o/ | 12:50 |
| jdstrand | hey zyga-ubuntu :) | 12:50 |
| zyga-ubuntu | jdstrand: maybe we want to have a call about that? | 12:50 |
| zyga-ubuntu | jdstrand: btw, I found a (hopefully) super simple solution for the bane of systems without rshared / | 12:50 |
| jdstrand | I don't think it needs a call. there is a very simple path that can be taken | 12:50 |
| mvo | zyga-ubuntu: whats your timeline? I have a local 2.29.3 here that I would like to make push to beta | 12:51 |
| zyga-ubuntu | jdstrand: I'll ask you to look at the diff today (fits on my screen) | 12:51 |
| mborzecki | agreed, vwe've been there before, although I unnecessarily used group name to setup g:<name>, should have used just group ID at that point | 12:51 |
| zyga-ubuntu | mvo: it's testing now | 12:51 |
| zyga-ubuntu | mvo: I'll run the full suite in LXD (external) if that works | 12:51 |
| zyga-ubuntu | mvo: let's chat in HO | 12:51 |
| mup | PR snapd#4192 opened: osutil: add helper for obtaining group ID of given file path <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4192> | 12:52 |
| mvo | zyga-ubuntu: sure | 12:52 |
| zyga-ubuntu | mvo: it works :) | 12:56 |
| zyga-ubuntu | mvo: I'll run all of main now | 12:56 |
| zyga-ubuntu | mvo: and while that runs I'll look at running all of main in lxd | 12:57 |
| zyga-ubuntu | mvo: do you know if we have any helpers for that? | 12:57 |
| mvo | zyga-ubuntu: I think we don't have helpers for that :/ | 13:00 |
| mvo | zyga-ubuntu: keen to see your fix, great work! | 13:00 |
| === lborda is now known as lborda_afk | ||
| pstolowski | mvo, one more comment to your change ;) | 13:02 |
| mvo | pstolowski: ta | 13:03 |
| sergiusens | kalikiana no problem | 13:17 |
| zyga-ubuntu | kyrofa: hey | 13:18 |
| jdstrand | mvo: hey, not sure you got the message, but no mpris PR from me for 2.29 | 13:19 |
| zyga-ubuntu | jdstrand: https://github.com/snapcore/snapd/compare/master...zyga:rfc/lxd-issue-test?expand=1 (not fully spread-tested yet) | 13:20 |
| mvo | jdstrand: aha, I did not get this message. thank you, one less worry | 13:26 |
| jdstrand | yep | 13:26 |
| Son_Goku | mvo: I'm updating the build in Fedora Rawhide to 2.29.2 | 13:33 |
| Son_Goku | so I should have an updated Provides list matching the subsystems exposed in snapd-devel | 13:33 |
| mvo | Son_Goku: thank you, if you could merge master into your fedora PR I will pull it in | 13:34 |
| mvo | Son_Goku: I will do a 2.29.3 today | 13:34 |
| Son_Goku | give me a few minutes and I will have that | 13:34 |
| mvo | Son_Goku: small issue related to classic snaps, nothing terrible but want to fix it | 13:34 |
| Son_Goku | sure | 13:34 |
| mvo | Son_Goku: no worries, all the time you need | 13:34 |
| Son_Goku | and it's a nice time to fix the Fedora build | 13:34 |
| mvo | Son_Goku: and *thank you* | 13:34 |
| jdstrand | zyga-ubuntu: interesting. can you add a comment above sc_ensure_shared_snap_mount() describing why it needs to be shared and why mounting all the snaps as shared addresses things? | 13:45 |
| zyga-ubuntu | jdstrand: yes, sure | 13:49 |
| Son_Goku | mvo: https://github.com/snapcore/snapd/pull/4193 | 14:01 |
| mup | PR #4193: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4193> | 14:01 |
| mup | PR snapd#4155 closed: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <Closed by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4155> | 14:02 |
| mup | PR snapd#4193 opened: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4193> | 14:02 |
| cachio | mvo, where did you uploaded the snaps? | 14:03 |
| * zyga-ubuntu is silly and ran 14.04 tests on 3.14 kernel | 14:04 | |
| zyga-ubuntu | I need to fix my image | 14:04 |
| Son_Goku | mvo, do you plan to make 2.29.3 right after merging my spec changes in? | 14:06 |
| * Son_Goku is trying to weigh whether to submit a build for 2.29.2 at all | 14:07 | |
| Son_Goku | I'm thinking I shouldn't if you're going to make a 2.29.3 release before I have to leave for work | 14:07 |
| mvo | Son_Goku: 2.29.3 will go out today, waiting for one more branch still | 14:11 |
| mvo | cachio: I pushed them to the store you should have mail from the store. i only build locally so far | 14:11 |
| Son_Goku | mvo: anyway, you should pull those spec changes in and merge it back into 2.29 | 14:11 |
| popey | jdstrand: Whats the process if an upstream wants a snap name and it's the same name as the same app in the deb archive? They get it, right? | 14:11 |
| Son_Goku | this is also now adjusted for the new tarball scheme | 14:11 |
| mvo | cachio: one easy way to get it build for everything is to push just the snaps to a LP branch and setup snap building for that branch and auto-store upload. that should work as you are the "owner" of the snaps now | 14:12 |
| mvo | Son_Goku: yeah, once tests are green I will merge | 14:12 |
| popey | jdstrand: i.e. they ask on the forum, we grant it, they upload, and the path means users get the snap in preference to the deb? | 14:12 |
| Son_Goku | mvo: the tests seem to be red for unrelated reasons :/ | 14:12 |
| jdstrand | popey: iirc, there needs to be a store override. noise][ could comment (I don't typically handle name registration questions) | 14:12 |
| Son_Goku | that happened with the other spec change | 14:12 |
| popey | oh, sorry. | 14:12 |
| cachio | mvo, I don't see those snaps in the store | 14:12 |
| mvo | greyback, zyga-ubuntu if its a cgroup problem, could you uncomment the debug lines in /lib/udev/snappy-app-dev ? maybe that gives us a hint | 14:13 |
| cachio | I mvo I just got the email | 14:13 |
| mvo | cachio: hm, could you /msg me your primary SSO address? maybe that is the problem, in the past the store only send the invite to that | 14:13 |
| jdstrand | popey: as for snap in preference to the deb: no. /snap/bin is after /usr/bin in PATH | 14:13 |
| mvo | cachio: aha, ok. woah, I added the snaps hours ago :) | 14:13 |
| greyback | mvo: zyga-ubuntu suggests I do that, but I saw no log file being created at all | 14:13 |
| greyback | -s+ed | 14:14 |
| mvo | Son_Goku: yeah, tests are red, please merge master | 14:14 |
| diddledan | popey: I believe the store has marked all the names of debs in the ubuntu repo as reserved so you need to file a claim using the request name form when you try to register the snap | 14:14 |
| mvo | greyback: autsch, thats bad | 14:14 |
| popey | yeah, thats the problem | 14:14 |
| jdstrand | those don't work | 14:14 |
| popey | someone tried to register and never got a reply | 14:14 |
| mvo | Son_Goku: I wanted to do that and push to your branch but it looks like you disabled that I can push to your PRs ;) | 14:14 |
| cachio | mvo, a rule remove that email from my inbox | 14:14 |
| popey | I'm trying to smooth it out. | 14:14 |
| mvo | cachio: aha, ok. | 14:14 |
| cachio | mvo, sorry | 14:14 |
| jdstrand | mvo, greyback: those debug lines don't work iirc | 14:14 |
| Son_Goku | mvo: gimme a sec to rebase | 14:14 |
| mvo | cachio: no problem | 14:14 |
| Son_Goku | I thought I had already done it this morning | 14:14 |
| mvo | jdstrand: they worked at some point, if they no longer do we should remove them :( | 14:15 |
| mvo | Son_Goku: thank you | 14:15 |
| Son_Goku | mvo: done | 14:15 |
| jdstrand | mvo: yes and yes | 14:15 |
| mvo | jdstrand: and YES :) | 14:15 |
| jdstrand | mvo: YES!! | 14:15 |
| jdstrand | :) | 14:15 |
| * mvo hugs jdstrand | 14:15 | |
| noise][ | popey: i don't see any outstanding name dispute requests | 14:15 |
| noise][ | what name? | 14:16 |
| popey | htmldoc | 14:16 |
| popey | I'm mailing the dev and will cc you | 14:16 |
| jdstrand | mvo, greyback: istr an issue with reexec or it being in the readonly squashfs and not being able to have the system recognize the overlay | 14:16 |
| popey | they added numbers to the name to get it, but say they got no response, but I don't know when / where they asked | 14:16 |
| * jdstrand will sometimes use overlayfs to test things on a core image | 14:16 | |
| noise][ | i see an htmldoc19 approved | 14:17 |
| noise][ | that's the only one | 14:17 |
| popey | yeah, he did that because he said he got no reply for htmldoc | 14:17 |
| noise][ | hmm | 14:17 |
| popey | will get clarification over email | 14:17 |
| popey | You Have Mail! </aol> | 14:18 |
| mvo | popey: lol | 14:18 |
| jdstrand | mvo, greyback: I think(?) it might be possible to cp it somewhere, adjust that to output to a file (eg 'echo $@ > /var/tmp/foo'), then overlayfs that (maybe a bind mount would do?), then stop and start udev | 14:20 |
| jdstrand | zyga-ubuntu: I guess you are looking at this. fyi ^ | 14:22 |
| greyback | jdstrand: yeah I thought it best to let an expert have a go :) | 14:23 |
| greyback | though I'd still exect those debug lines to create the log file on a Classic system | 14:24 |
| pedronis | Chipaca: did a pass over #4154 | 14:26 |
| mup | PR #4154: overlord/snapstate: support completion for command aliases <Created by chipaca> <https://github.com/snapcore/snapd/pull/4154> | 14:26 |
| zyga-ubuntu | jdstrand: I plan to next | 14:27 |
| zyga-ubuntu | jdstrand: still looking at the rshare issue, some initial enthusiasm is receeding | 14:27 |
| jdstrand | zyga-ubuntu: why don't you let me look at greyback's issue | 14:28 |
| jdstrand | I was planning on reaching out today anyway | 14:29 |
| zyga-ubuntu | jdstrand: go ahead, I don't block you | 14:29 |
| jdstrand | greyback, mvo: ^ | 14:29 |
| jdstrand | I'll be looking at this | 14:29 |
| greyback | jdstrand: if I can help at all, let me know | 14:29 |
| mvo | jdstrand: ta | 14:30 |
| jdstrand | greyback: is it possible to reproduce in a vm? eg, sub hotplug a moue via virsh or something? | 14:30 |
| jdstrand | man | 14:31 |
| jdstrand | that was some mighty poor typing | 14:31 |
| jdstrand | usb hotplug a mouse via virsh* | 14:31 |
| zyga-ubuntu | jdstrand: at some point the acronyms take over english and it's all ok | 14:31 |
| jdstrand | haha | 14:31 |
| mup | PR snapd#4194 opened: daemon: for /v2/logs, 404 when no services are found <Created by chipaca> <https://github.com/snapcore/snapd/pull/4194> | 14:34 |
| Chipaca | mvo: ^ | 14:34 |
| greyback | jdstrand: mir should work fine inside a vms yes | 14:34 |
| greyback | jdstrand: I don't know how to simulate mouse plug/unplug to a vm though | 14:35 |
| jdstrand | greyback: I'll play with it a little. I have a physical device I can try too though | 14:35 |
| greyback | jdstrand: yeah I tend to use a separate machine when working on mir | 14:35 |
| * jdstrand has wanted to document debugging this part of snapd anyway | 14:36 | |
| jdstrand | (the udev hotplug) | 14:36 |
| * mvo hugs Chipaca | 14:36 | |
| zyga-ubuntu | jdstrand: there's a way to do that | 14:36 |
| mvo | Chipaca: thank you! | 14:36 |
| zyga-ubuntu | jdstrand: using the qemu monitor | 14:36 |
| jdstrand | zyga-ubuntu: yeah. I just need to recall how to do it :) | 14:36 |
| zyga-ubuntu | jdstrand: I wrote some python that could help but not something you can spread test easily (AFAIK) without nested spread | 14:37 |
| jdstrand | that's fine | 14:37 |
| zyga-ubuntu | https://en.wikibooks.org/wiki/QEMU/Monitor#usb_add | 14:37 |
| jdstrand | oh bummer, my core vm is hosed | 14:38 |
| * jdstrand creates a new one | 14:38 | |
| mvo | Chipaca: lets hope travis builds it reasonable soon | 14:38 |
| zyga-ubuntu | jdstrand: -snapshot to the rescue | 14:39 |
| elopio | snappy-m-o echo test | 14:40 |
| Chipaca | mvo: dumb fix for dumb bug :-) | 14:41 |
| jdstrand | zyga-ubuntu: well, that is the problem. I did -snapshot and it was broken | 14:41 |
| zyga-ubuntu | that's interesting, so it wrote back? | 14:41 |
| jdstrand | no idea. I've already destroyed it and will have a new one in a moment | 14:42 |
| Chipaca | mborzecki: what was your usecase of group lookup? was it "who is the owner of /etc/shadow"? | 14:42 |
| jdstrand | Chipaca: it was to know what to use with 'g:<group>'. but we already have the gid with stat so no point finding the group name to then lookup the gid | 14:44 |
| Chipaca | heh | 14:45 |
| Chipaca | jdstrand: nice | 14:45 |
| Chipaca | so that's all going away? | 14:45 |
| * ikey had no idea that snaps were held together with silly string and environmental variables.. | 14:46 | |
| jdstrand | Chipaca: his PR doesn't get rid of lookupGroup, no. lookupGroup *could* go away if the template.go was similarly updated, but I would argue to keep it for when we need it, but use my alternative suggestion of shelling out | 14:47 |
| jdstrand | (see my comments in the PR) | 14:47 |
| Chipaca | will do | 14:48 |
| Chipaca | this is relevant to some work coming out of the standup | 14:48 |
| Chipaca | but right now, i need to go regruntle a chid | 14:48 |
| jdstrand | Chipaca: a faster alternative since we don't have it today would be to update template.go as I mentioned in the PR, remove all cgo code related to this, keep FindGid() but have it return an err that points to my PR comment. that way whoever needs it next would know how to proceed. since that would likely be me, I'm ok with implementing my design | 14:51 |
| Son_Goku | ikey: you finally figured it out | 14:51 |
| jdstrand | s/don't have it today/don't need it today/ | 14:52 |
| zyga-ubuntu | ikey: environment variables and tongue at the right angle | 14:54 |
| ikey | so, amusing fact | 14:54 |
| ikey | my solus based snap refuses to accept the nvidia GL libraries in /var/lib/snapd/gl | 14:54 |
| ikey | or w/e the path is | 14:54 |
| ikey | because it sets secure execution mode as the binaries + libs are mostly all full relro and ignores LD_LIBRARY_PATH | 14:55 |
| ikey | ergo, solus snap binaries are more secure in nature than ubuntu ones :p | 14:55 |
| elopio | snappy-m-o echo test | 14:55 |
| snappy-m-o | test | 14:55 |
| ikey | im gonna need to work around it with ld.so.conf | 14:56 |
| === kenvandine_ is now known as kenvadine | ||
| === kenvadine is now known as kenvandine | ||
| * zyga-ubuntu is sleepy now | 15:02 | |
| zyga-ubuntu | damn it | 15:02 |
| zyga-ubuntu | I hate that sun is over at 16:00 | 15:02 |
| zyga-ubuntu | :/ | 15:02 |
| zyga-ubuntu | ok, you win | 15:05 |
| zyga-ubuntu | I'll get some coffee | 15:05 |
| zyga-ubuntu | darn sun | 15:05 |
| kalikiana | ikey: what do you mean by "solus based" here? built on solus or running on solus? | 15:07 |
| ikey | both | 15:07 |
| ikey | the snap has `base: solus-runtime-gaming` | 15:07 |
| ikey | and solus-runtime-gaming has `type: base` | 15:08 |
| zyga-ubuntu | kalikiana: the rootfs is solus | 15:14 |
| zyga-ubuntu | kalikiana: (at runtime) | 15:14 |
| zyga-ubuntu | kalikiana: base snaps :) | 15:14 |
| === cachio is now known as cachio_lunch | ||
| ikey | i found some assumptions that i had to cater for in the rootfs | 15:15 |
| ikey | and it really doesn't like lib64 | 15:16 |
| ikey | i think the most surprising one was the expectation for /lib/udev/snappy-app-dev to be present | 15:17 |
| zyga-ubuntu | ikey: that's correct, we need to make more things configurable in base snap's layout section | 15:18 |
| zyga-ubuntu | ikey: we can correct those as we go, thank you for pushing the boundaries | 15:18 |
| ikey | ah my pleasure :D | 15:18 |
| zyga-ubuntu | ikey: much of what I do now relates to that | 15:18 |
| ikey | right now my script is an abomination | 15:18 |
| zyga-ubuntu | ikey: but you are ahead of the curve :) | 15:18 |
| ikey | https://github.com/solus-project/runtime-snaps/blob/master/round1.sh | 15:18 |
| ikey | but you can kinda get a feel for whats going on easily enough | 15:18 |
| kalikiana | ikey: oooohhhh sweet | 15:19 |
| ikey | i mean its kinda nasty but it does the job, right? | 15:19 |
| ikey | and the main yaml is here https://github.com/solus-project/runtime-snaps/blob/master/runtimes/gaming/meta/snap.yaml | 15:19 |
| ikey | i added a debug apps: part to it to let me poke it | 15:19 |
| ikey | so now my next test is to see if i can prefix ld.so.conf so that the SNAP_LIBRARY_PATH portions would be respected | 15:20 |
| ikey | as right now my poor snap is using mesa | 15:20 |
| jdstrand | greyback (cc zyga-ubuntu): fyi, virsh qemu-monitor-command snappy-16-amd64 '{"execute":"device_add","arguments":{"driver":"virtio-mouse-pci","id":"input1","bus":"pci.0","addr":"0xa"}}' | 15:22 |
| jdstrand | greyback (cc zyga-ubuntu): virsh qemu-monitor-command snappy-16-amd64 '{"execute":"device_del","arguments":{"id":"input1"}}' | 15:23 |
| zyga-ubuntu | jdstrand: oh, you are using the qemu qpi interface | 15:23 |
| zyga-ubuntu | jdstrand: nice, does it work? | 15:23 |
| jdstrand | yep | 15:23 |
| greyback | jdstrand: sweet | 15:24 |
| zyga-ubuntu | i mean, does snapd part work? | 15:24 |
| jdstrand | udevadm monitor shows them coming and going | 15:24 |
| jdstrand | the udev tagging works too (it is getting assigned to mir-kiosk) | 15:24 |
| jdstrand | the adding to the cgroup is not working | 15:24 |
| jdstrand | I'm looking into that | 15:24 |
| jdstrand | E: TAGS=:snap_mir-kiosk_mir-kiosk: | 15:24 |
| zyga-ubuntu | jdstrand: ha | 15:27 |
| zyga-ubuntu | jdstrand: same result as what the reporter found | 15:27 |
| jdstrand | yes. that's a good thing :) | 15:28 |
| jdstrand | I have reproduced it | 15:28 |
| * greyback sighs with relief | 15:28 | |
| zyga-ubuntu | jdstrand: as a side note | 15:29 |
| zyga-ubuntu | jdstrand: that script is -e, right? | 15:29 |
| jdstrand | it is | 15:29 |
| zyga-ubuntu | jdstrand: just sayin :) | 15:29 |
| zyga-ubuntu | jdstrand: we should burn that script with fire | 15:29 |
| zyga-ubuntu | jdstrand: and write it in C | 15:30 |
| jdstrand | it is on our trello board | 15:30 |
| jdstrand | we hate the shell script | 15:30 |
| zyga-ubuntu | that sounds like a line from a song | 15:30 |
| ikey | We didn't start the shell script.... | 15:31 |
| ikey | It was always churning from before snapd was turning.. | 15:31 |
| * ikey sees himself out | 15:31 | |
| jdstrand | hehe | 15:31 |
| * popey shuts the door | 15:31 | |
| zyga-ubuntu | ah | 15:31 |
| zyga-ubuntu | it was "we love the pain" | 15:31 |
| zyga-ubuntu | but I somehow translated that to "we have the shell script" | 15:31 |
| ikey | popey, just turn around now | 15:31 |
| kalikiana | ikey: kinda wonder if that couldn't be baked into --shell... so you don't have to add those awkward "apps" | 15:32 |
| ikey | >_> | 15:32 |
| ikey | kalikiana, *prolly* but the apps shouldn't really be in the runtime | 15:32 |
| ikey | it was there for le debugging | 15:32 |
| ikey | once i have the higher layer working properly ill remove it | 15:32 |
| kalikiana | ikey: right, it's more that you need to add something solely for debugging | 15:32 |
| kalikiana | that strikes me as awkward | 15:33 |
| ikey | yeah spose | 15:33 |
| kalikiana | just thinking out loud | 15:33 |
| ikey | tbh it was mostly "can i chroot" | 15:33 |
| ikey | then later i had fun due to not using dash in the image | 15:34 |
| * zyga-ubuntu now wants to listen to "we love the pain" | 15:34 | |
| ikey | turns out readline + ncurses, pretty important.. lol | 15:34 |
| ikey | confinement wouldn't let em load ^^ | 15:34 |
| ikey | oh, le Q | 15:34 |
| zyga-ubuntu | https://www.youtube.com/watch?v=jkXP-aqKmPQ ^_^ | 15:34 |
| ikey | my snap can't seem to execute stuff from /usr/bin | 15:34 |
| ikey | despite the runtime having zenity there | 15:34 |
| ikey | i mean sure its janky to have zenity there | 15:35 |
| ikey | but still | 15:35 |
| ikey | curious why it can't execute stuff | 15:35 |
| zyga-ubuntu | ikey: what's the error? | 15:35 |
| ikey | ehm it was permission denied | 15:36 |
| zyga-ubuntu | ikey: typically you get the answer from audit log | 15:36 |
| ikey | ill need to rebuild me whatchacallits | 15:36 |
| ikey | my snaps and install and find out what their issue is | 15:36 |
| zyga-ubuntu | jdstrand: not sure if you were trying to tell me politely "explain how it works so that you will see it doesn't" or was that just an accident but I think I need another (much more annoying) solution | 15:42 |
| zyga-ubuntu | annoying as in complex | 15:43 |
| === chihchun is now known as chihchun_afk | ||
| * mvo is unhappy because the travis run for 4194 has not even started yet | 15:51 | |
| zyga-ubuntu | mvo: :/ | 15:52 |
| * zyga-ubuntu has a very crazy idea on how to fix the problem affecting lxd | 15:54 | |
| mvo | zyga-ubuntu: tell me more | 15:55 |
| zyga-ubuntu | mvo: it goes away if we move snap mounts to /var/lib/snapd/snap and then have an unconditional mount unit that bind mounts /var/lib/snapd/snap to /snap | 15:57 |
| zyga-ubuntu | mvo: then /snap is a real mount unit with correct options | 15:57 |
| zyga-ubuntu | mvo: and the hack goes away | 15:57 |
| zyga-ubuntu | mvo: as for fixing this in snap-confine: we could keep the hack we had but we need to unmount everything first | 15:57 |
| zyga-ubuntu | mvo: then create the bind mount (/snap -> /snap) | 15:58 |
| zyga-ubuntu | mvo: and then re-mount all the mount units | 15:58 |
| zyga-ubuntu | mvo: (re-start them, we cannot mount ourselves as we don't know what was there) | 15:58 |
| zyga-ubuntu | mvo: (then there's confinement that will make this more complex) | 15:58 |
| ikey | im seeeing lots of spam for NSS modules in my snap: https://hastebin.com/cumofisodi.sql | 15:59 |
| ikey | but nothing that could explain why this is still refusing to use my NVIDIA libraries | 15:59 |
| ikey | for zenity execution: | 16:02 |
| ikey | Nov 09 16:01:48 ironhide audit[11528]: AVC apparmor="DENIED" operation="exec" profile="snap.linux-steam-integration.settings" name="/usr/bin/zenity" pid=11528 comm="sh" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 | 16:02 |
| ikey | is there some kind of plug i need to add so i can actually execute stuff from my runtime? | 16:03 |
| ikey | otherwise it gets a bit pointless having a runtime.. | 16:03 |
| mvo | zyga-ubuntu: hm, interessting | 16:03 |
| pedronis | interesting is the word | 16:03 |
| nacc | ikey: it *might* help to run `snap run --shell <app>` and try to run it by hand? | 16:03 |
| mvo | zyga-ubuntu: and funny in some way as this would be fhs compliant by "accident" | 16:04 |
| mvo | pedronis: lol | 16:04 |
| nacc | ikey: dunno if you'd get more logging, or be able to see what precisely is failing | 16:04 |
| ikey | can't see /usr/bin | 16:04 |
| nacc | ikey: confined snap? | 16:04 |
| ikey | yeah | 16:04 |
| ikey | ok i can see some of /usr/bin.. | 16:04 |
| ikey | bash: /usr/bin/file: Permission denied | 16:05 |
| nacc | ikey: well ... it should't be able to see /usr/bin; not sure if hte apparmor logging is showing you the confined view or not (i'm not deep enough into snappy to know) | 16:05 |
| ikey | basically i cannot execute anything from /usr/bin | 16:05 |
| nacc | ikey: a confined snap should be able to use the core snap it's running on and the snap's contents only, I think? | 16:05 |
| pedronis | zyga-ubuntu: will that not confuse snapd vs snap-confine? are all the relevant ops done with the snap-confine lock? | 16:05 |
| ikey | right, and zenity is in my core snap | 16:05 |
| ikey | but /bin works.. | 16:05 |
| ikey | /usr/bin doesn't | 16:05 |
| ikey | curious. | 16:05 |
| nacc | ikey: that's weird :/ | 16:05 |
| ikey | i.e /bin/ls is fine | 16:06 |
| nacc | ikey: sounds like you need an actual snap developer, sorry :) | 16:06 |
| ikey | heh | 16:06 |
| ikey | but i can't ls /bin | 16:06 |
| zyga-ubuntu | pedronis: this would be done at system level, before we get to run;; but honestly this is lala land for now; | 16:06 |
| ikey | -_- | 16:06 |
| ikey | this is jank of the highest order lol | 16:06 |
| zyga-ubuntu | pedronis: I'd like to find easier solution | 16:06 |
| pedronis | zyga-ubuntu: hope so, both of those don't sound very appealing | 16:06 |
| nacc | ikey: so you can read but not execute? | 16:07 |
| pedronis | at first sight | 16:07 |
| ikey | i can read /usr/bin, not execute, execute /bin, not read dir | 16:07 |
| ikey | ok so symlinks seem to work ok if its symlinked into /bin | 16:07 |
| ikey | workarounds intensify | 16:07 |
| nacc | ikey: to be clear it's possible `ls /bin` and `/bin/ls /bin` are different | 16:07 |
| nacc | ikey: but this sounds like AA madness :) | 16:07 |
| ikey | yeah | 16:07 |
| ikey | ima test a theory. | 16:08 |
| ikey | symlink the runtime | 16:08 |
| ikey | at this point i really wish snaps were implemented using overlayfs | 16:10 |
| ikey | and not having mangled /snap/* trees and LD_LIBRARY_PATH hacks | 16:10 |
| kyrofa | zyga-ubuntu, hey there! I'm around now | 16:10 |
| ikey | could have a core snap mounted as a lowerdir, a tmpfs mounted as an intermediary with snapd requirements on top (such as gl overrides), and then a new overlayfs using that tmpfs as a bottom dir | 16:10 |
| ikey | and the compounded Thingy would have a natural filesystem layout | 16:11 |
| ikey | and no need for the butchered scripts anymore | 16:11 |
| === cachio_lunch is now known as cachio | ||
| zyga-ubuntu | kyrofa: I had a up/down cycle today | 16:13 |
| zyga-ubuntu | kyrofa: fixing that bug all day | 16:13 |
| kyrofa | zyga-ubuntu, hahaha | 16:14 |
| kyrofa | zyga-ubuntu, did it end with success? | 16:14 |
| mup | PR snapd#4195 opened: daemon: for /v2/logs, 404 when no services are found (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4195> | 16:15 |
| zyga-ubuntu | kyrofa: yes, I didn't jump off a cliff ;) | 16:15 |
| mvo | can someone review 4195 please? it's 4194 for 2.29 | 16:15 |
| zyga-ubuntu | kyrofa: no, not fixed yet, mostly understood now but still trying to fix it | 16:15 |
| zyga-ubuntu | mvo: I cna | 16:15 |
| ikey | bash: /bin/zenity: Permission denied | 16:16 |
| ikey | *gah* | 16:16 |
| mvo | zyga-ubuntu: ta! | 16:16 |
| zyga-ubuntu | mvo: man, ∀, I always find that confusing "All or Every it was?" | 16:16 |
| zyga-ubuntu | mvo: :) | 16:16 |
| ikey | apparmor is a pain in the ass. just sayin. | 16:18 |
| zyga-ubuntu | ikey: you should try selinux | 16:19 |
| zyga-ubuntu | ikey: then you'll say "man, remember that pain in the ass, haha, that was just tingling" | 16:19 |
| ikey | at that point id fork smack and bring it up to scratch again | 16:19 |
| ikey | for the love of christ why can it still not run stuff | 16:20 |
| zyga-ubuntu | ikey: you can recompile the policy | 16:22 |
| zyga-ubuntu | ikey: and make it permissive | 16:22 |
| zyga-ubuntu | ikey: then you can just do stuff until you get proper logging to see the denials | 16:22 |
| ikey | ugh | 16:22 |
| ikey | i found out why | 16:22 |
| ikey | interfaces/apparmor/template.go | 16:22 |
| nacc | ikey: i wonder if it's acustom core snap (iirc?) then maybe you need to do apparmor modifications? | 16:22 |
| ikey | hard-coded permitted commands? | 16:23 |
| ikey | cmon guys | 16:23 |
| niemeyer | Chipaca: ping | 16:23 |
| zyga-ubuntu | ikey: yes, because then we cannot change the base snaps otherwise | 16:24 |
| zyga-ubuntu | ikey: if we allow anything then everything is backwards compatible stone that is by your leg | 16:24 |
| ikey | i cant even ldconfig -_- | 16:25 |
| ikey | this also means i cant do an update to an icon theme asset in the secondary snap | 16:26 |
| ikey | because the gtk-update-icon-cache is inside the core runtime | 16:26 |
| ikey | and i cant execute commands there | 16:27 |
| zyga-ubuntu | ikey: I think base snaps should have a base apparmor template | 16:27 |
| zyga-ubuntu | ikey: it's just something we haven't done yet | 16:28 |
| Chipaca | niemeyer: pong | 16:28 |
| niemeyer | Chipaca: Yo | 16:28 |
| Chipaca | niemeyer: 'sup | 16:28 |
| niemeyer | Chipaca: Looking at the fixes for /v2/logs | 16:28 |
| niemeyer | Chipaca: Got me thinking about our old issues with 404s on valid endpoints | 16:28 |
| niemeyer | Chipaca: Do we have a pattern already established of returning 404s in similar cases? | 16:29 |
| Chipaca | niemeyer: /v2/logs?names=rubbish 404s | 16:29 |
| ikey | can i have all the magical chroot esque functionality of strict snaps **without** the apparmor denials? | 16:29 |
| ikey | like some magic "i dont want this" flag? :P | 16:29 |
| kyrofa | zyga-ubuntu, glad to hear it :) | 16:31 |
| jdstrand | ikey: what specifically are you trying to do. launch zenity from your snap? | 16:31 |
| ikey | ya, but have zenity in my base snap | 16:31 |
| ikey | and apparmor denials make it impossible to have my useful executables there | 16:31 |
| ikey | sorta defeating the point of "runtime" :p | 16:32 |
| * jdstrand notes that base snaps are a very new thing and the security policy needs to be designed for it | 16:32 | |
| nacc | ikey: i think that's what i was tryign to say earlier --^ | 16:32 |
| Chipaca | niemeyer: /v2/snaps/rubbish 404s | 16:33 |
| Chipaca | etc | 16:33 |
| Chipaca | niemeyer: 404 isn't "this is not a valid endpoint" | 16:33 |
| jdstrand | like, should each base snap have it's own policy? should base snaps extend existing policy? | 16:33 |
| * ikey will make magic workarounds | 16:34 | |
| ikey | and stick zenity into the secondary snap | 16:34 |
| nacc | jdstrand: really good questions :) | 16:34 |
| niemeyer | Chipaca: I guess it's a bit late to be changing that in this case, but we should at least try to consider further similar cases | 16:34 |
| jdstrand | ikey: now, for zenity in particular, perhaps it makes sense to add it to the desktop or desktop-legacy interface | 16:35 |
| ikey | also gotta wonder what the SDK/debug story is for base runtimes | 16:35 |
| niemeyer | Chipaca: I guess in our case it's a bit less of a problem as we are indeed returning a richer value despite the status code | 16:35 |
| ikey | jdstrand, tbf i shouldn't be copping out and using zenity in the first place | 16:35 |
| ikey | but there it is ^^ | 16:35 |
| ikey | i should have been less lazy and used a real GtkDialog | 16:35 |
| niemeyer | Chipaca: But I've learned to be afraid of that exact behavior after recurring bugs | 16:35 |
| ikey | ** (zenity:26283): WARNING **: Could not load ui file /usr/share/zenity/zenity.ui: Failed to open file ?/usr/share/zenity/zenity.ui?: No such file or directory | 16:36 |
| ikey | ah for feck sake | 16:36 |
| Chipaca | niemeyer: nice json 404 in appserver resulting in nasty plain text 404 from load balancer? | 16:36 |
| * ikey punches a baby donkey | 16:36 | |
| jdstrand | ikey: that's a good question. I don't know tbh. I think the idea is get the concept out there and see how people are using them and design the next steps | 16:36 |
| * jdstrand hasn't been part of most base snap discussions | 16:36 | |
| niemeyer | Chipaca: Problem is that there's little difference between a real response, and a broken configuration with a wrong path, or a broken configuration with a wrong endpoint altogether, or even a broken configuration talking to a proxy that is getting in the way | 16:36 |
| ikey | jdstrand, it'd be a whole lot easier if we could rely on real usable system paths | 16:37 |
| ikey | and not mangle every single package.. | 16:37 |
| ikey | wonder if i can cheat here and install zenity twice. | 16:37 |
| Chipaca | ikey: https://i.imgur.com/5jysoQE.jpg | 16:37 |
| ikey | ls: cannot open directory '/usr/share/locale': Permission denied | 16:38 |
| ikey | *gah!!* | 16:38 |
| niemeyer | Chipaca: Also, clients getting 404s for different reasons out of the same endpoint (missing snap, or missing service, or missing ...) | 16:38 |
| niemeyer | Chipaca: We even got one of those cases in our buying endpoint ("Please login" when really it was "This stuff is free dude!") | 16:38 |
| Chipaca | niemeyer: yeah; in our case it's an error response, so it's not _just_ a 404, but yes, agreed | 16:38 |
| ikey | ok new objective, make snap work, then make strict confinement work later. | 16:39 |
| ikey | less stress | 16:39 |
| mup | PR snapd#4168 closed: cmd/snap-update-ns: add new helpers for mount entries <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4168> | 16:40 |
| ikey | heh now i can run zenity xD | 16:45 |
| mup | PR snapd#4196 opened: daemon: cherry-picked /v2/logs fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/4196> | 16:45 |
| Chipaca | ^ cherry-picking the v2/logs fixes for 2.29, plz | 16:46 |
| * ikey still has that one cute donkey jpeg open | 16:49 | |
| ikey | i couldn't punch that | 16:49 |
| ikey | https://ibin.co/3gibO7Bha09C.png :D | 16:51 |
| Chipaca | ikey: https://i.imgur.com/6G3FTUC.jpg | 16:51 |
| popey | diddledan: apologies for the mail store spam | 16:51 |
| ikey | ok that one looks like it already took a slap | 16:51 |
| ikey | libGL error: unable to load driver: swrast_dri.so | 16:52 |
| ikey | libGL error: failed to load driver: swrast | 16:52 |
| diddledan | :-) | 16:52 |
| ikey | ok so the last thing to work out now is how to expose the NVIDIA | 16:52 |
| * diddledan clicks on ALL the links! :-p | 16:52 | |
| ikey | but yeah i have steam trying to install itself now | 16:52 |
| ikey | from within the solus runtime | 16:52 |
| ikey | i think jdstrand is right about custom apparmor profiles <in future> | 16:53 |
| ikey | because the solus base is gonna be wildly different (lib32s and such) | 16:53 |
| ikey | but - ignoring confinement for now, the concept is working. | 16:53 |
| Chipaca | diddledan: https://gfycat.com/QuickWaterloggedAmurminnow | 16:53 |
| popey | awwwwww | 17:00 |
| popey | if i filmed that my cat would run up and devour the little birdie | 17:01 |
| diddledan | tasty | 17:02 |
| ikey | nomnom :p | 17:06 |
| pedronis | Chipaca: mvo: do I see it correctly that #4196 supersedes #4195 | 17:07 |
| mup | PR #4196: daemon: cherry-picked /v2/logs fixes (2.29) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4196> | 17:07 |
| mup | PR #4195: daemon: for /v2/logs, 404 when no services are found (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4195> | 17:07 |
| ikey | so how do you guys make the magical /var/lib/snapd/lib/gl thingy work? | 17:08 |
| ikey | if anyone knows the innards on it | 17:08 |
| * ikey is curious if the fact libGL already exists in the root is the issue | 17:08 | |
| ikey | wait maybe thats it | 17:08 |
| ikey | its in the place its meant to be! | 17:09 |
| ikey | *duh* | 17:09 |
| ikey | (if i had brains id be dangerous.) | 17:10 |
| * zyga-ubuntu does one more try | 17:11 | |
| zyga-ubuntu | (proably won't work but due to typos or others, let's see) | 17:11 |
| zyga-ubuntu | mvo: mount based solution | 17:11 |
| zyga-ubuntu | mvo: not as crazy | 17:12 |
| zyga-ubuntu | mvo: as in mount unit based | 17:12 |
| * ikey is suddenly more fond of mad environmental variables and sillystring | 17:13 | |
| zyga-ubuntu | ikey: what happened? | 17:13 |
| ikey | zyga-ubuntu, well i figured i can *abuse* the linker | 17:13 |
| ikey | its looking for /usr/lib/libGL* and finds them | 17:13 |
| ikey | so why not nuke them | 17:14 |
| ikey | and abuse LD_LIBRARY_PATH to *force* it to lookup even for mesa | 17:14 |
| ikey | and i think thats more similar to what your snaps do already actually.. | 17:14 |
| ikey | mesa/mesa-default | 17:14 |
| diddledan | ikey: abuse is never the right solution. Please seek counciling for your abbarant behaviour :-p | 17:15 |
| ikey | xD | 17:15 |
| ikey | 7fd36217d000-7fd36218e000 r-xp 00000000 103:03 8133128 /var/lib/snapd/hostfs/usr/lib64/glx-provider/nvidia/libEGL.so.384.98 | 17:15 |
| ikey | omg | 17:15 |
| ikey | :3 | 17:15 |
| ikey | its using the nvidias | 17:16 |
| diddledan | oops | 17:16 |
| ikey | no thats good | 17:16 |
| ikey | im on nvidia | 17:16 |
| ikey | before it was stuck on mesa drivers | 17:16 |
| zyga-ubuntu | AEVA - anonymous environment variable abusers | 17:16 |
| ikey | XD | 17:17 |
| diddledan | sounds like a political movement | 17:17 |
| ikey | omg so close | 17:17 |
| ikey | i need to teach snapd about 32-bit drivers | 17:18 |
| ikey | https://ibin.co/3gijqdorLIW2.png | 17:19 |
| ikey | ^_^ | 17:19 |
| zyga-ubuntu | mmm | 17:22 |
| zyga-ubuntu | just install those them drivers | 17:22 |
| ikey | i have them host side | 17:22 |
| ikey | i need to teach snapd to expose them | 17:22 |
| ikey | needs 32-bit *and* 64-bit exposed | 17:23 |
| zyga-ubuntu | them verygenuinedriversforeverything.ru/themdrivers.exe | 17:23 |
| * zyga-ubuntu is in funky mode | 17:23 | |
| ikey | lol | 17:23 |
| zyga-ubuntu | .txt.exe (or something) | 17:23 |
| diddledan | that url doesn't work | 17:23 |
| diddledan | (yes I clicked it :-p) | 17:23 |
| mup | PR snapd#4197 opened: cmd/snap-confine: Support bash as base runtime entry <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4197> | 17:23 |
| ikey | ah crap we'd need a secondary directory | 17:24 |
| ikey | maybe /var/lib/snapd/lib/gl/32 ? | 17:24 |
| zyga-ubuntu | why for snap-confine? | 17:24 |
| zyga-ubuntu | I don't get it | 17:24 |
| ikey | ? | 17:24 |
| ikey | mount-support-nvidia.c | 17:25 |
| zyga-ubuntu | huh | 17:25 |
| ikey | it only copies 64-bit drivers | 17:25 |
| zyga-ubuntu | I mean | 17:25 |
| zyga-ubuntu | why did you change the apparmor profile for snap-confine | 17:25 |
| zyga-ubuntu | it doesn't run bash, does it? | 17:25 |
| ikey | it does if you run --shell | 17:25 |
| ikey | and both of my entry points are bash based | 17:25 |
| ikey | we don't use dash in solus | 17:26 |
| ikey | so our /bin/sh == /bin/bash | 17:26 |
| ikey | and any "system" style calls will also use /bin/sh | 17:26 |
| zyga-ubuntu | no, wait, it doesn't | 17:27 |
| zyga-ubuntu | it runs snap-exec which does that | 17:27 |
| Chipaca | has travis had a breakfast of snails today? | 17:27 |
| zyga-ubuntu | Chipaca: travis is on holidays | 17:27 |
| zyga-ubuntu | trying to tell us stuff | 17:27 |
| ikey | well i had apparmor denials for it yesterday anyway | 17:27 |
| ikey | and bash was broken | 17:27 |
| zyga-ubuntu | ikey: --shell runs under the confinement of the app | 17:27 |
| zyga-ubuntu | ikey: were they for snap-confine profile? | 17:28 |
| zyga-ubuntu | ikey: ah, maybe it is (jdstrand: maybe) snappy-app-dev | 17:28 |
| ikey | i cant remember this was yesterday, but without that patch stuff wouldn't work | 17:28 |
| zyga-ubuntu | which is written in shell | 17:28 |
| zyga-ubuntu | sadly I think you are right | 17:28 |
| ikey | this was before i'd even gotten my LSI snap made | 17:28 |
| zyga-ubuntu | jdstrand: if I rewrite that into C will you review it? | 17:28 |
| ikey | just the core stuff | 17:28 |
| ikey | i can't see where we create /var/lib/snapd/lib/gl | 17:29 |
| zyga-ubuntu | it's baked into packaging | 17:30 |
| zyga-ubuntu | I need a break | 17:30 |
| zyga-ubuntu | I just have to leave this place | 17:31 |
| zyga-ubuntu | (tests are running) | 17:35 |
| Chipaca | mvo: i suspect we both cherry-picked for 2.29 ¯\_(ツ)_/¯ | 17:44 |
| zyga-ubuntu | I'll go for a walk now | 17:47 |
| zyga-ubuntu | I'll be back later to see if the tests pass | 17:47 |
| Chipaca | EOD is nigh | 18:01 |
| Chipaca | o/ | 18:01 |
| === alan_g is now known as alan_g|EOD | ||
| cachio | mvo, hey, is it comming 2.29.3 today? | 18:05 |
| diddledan | I heard 2.29.3 was for Monday, but that might be the stable release rather than candidate or such | 18:06 |
| mvo | cachio: it is coming, it a bit slow though, we had one more PR that needs to go in | 18:13 |
| mvo | cachio: I'm looking at the status right now | 18:13 |
| * kalikiana edo'ing as well now | 18:13 | |
| cachio | mvo, good, tx | 18:15 |
| mup | PR snapd#4195 closed: daemon: for /v2/logs, 404 when no services are found (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4195> | 18:15 |
| mup | PR snapd#4196 closed: daemon: cherry-picked /v2/logs fixes (2.29) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4196> | 18:16 |
| mvo | cachio: 2.29.3 is now uploaded to the image ppa, build there is running so should be build in ~10min and then I trigger a core snap build | 18:22 |
| mvo | cachio: so total turnaround hopefully ~1h and we have a new beta | 18:22 |
| cachio | mvo, nice | 18:22 |
| cachio | mvo, tx | 18:23 |
| pedronis | niemeyer: btw, I don't know if you noticed among all the things but there are 2 or 3 open PRs that have you specifically requested as reviewer | 18:57 |
| mvo | cachio: i386/amd64 ready in beta | 19:07 |
| cachio | mvo, nice, starting now :) | 19:08 |
| diddledan | that was quick | 19:16 |
| mvo | cachio: armhf ready now too | 19:16 |
| mup | PR snapd#4198 opened: release: 2.29.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4198> | 19:19 |
| * elopio <- lunch + nap. I'll be back in 2 hours. | 19:22 | |
| mvo | cachio: and arm64 as well, go wild! | 19:24 |
| cachio | mvo, great, thanks, I'll have results by tomorrow | 19:24 |
| mvo | cachio: could you also please notify CE about this so that they can run their tests? iirc the automatic tests are run by a US timezone team, right? | 19:25 |
| cachio | mvo, sure, doing that | 19:25 |
| mvo | cachio: so with a bit of luck we might get results tonight | 19:25 |
| mvo | cachio: thank you! | 19:25 |
| mvo | cachio: eh, I mean results today(ish) | 19:25 |
| cachio | mvo, yes, in few hours I'll see the first set of results | 19:25 |
| cachio | and complete the suites during the night | 19:26 |
| cachio | mvo, tomorrow morning you should see 80% of the results updated | 19:26 |
| Pharaoh_Atem | mvo: you didn't merge the spec changes into 2.29.3? | 19:27 |
| Pharaoh_Atem | mvo: :'( | 19:28 |
| Pharaoh_Atem | I had it ready this morning so that you could do it | 19:28 |
| Pharaoh_Atem | it's even got the green checkmarks :/ | 19:28 |
| mvo | cachio: thanks | 19:29 |
| mvo | Pharaoh_Atem: so sorry! I can do a special .4 just for you with this in | 19:29 |
| mvo | Pharaoh_Atem: there was a bit of turmoil because of two other last minute PRs, apologies again | 19:30 |
| Pharaoh_Atem | mvo: please do, thanks | 19:31 |
| Pharaoh_Atem | I'd like to get everything properly in sync | 19:31 |
| mup | PR snapd#4193 closed: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4193> | 19:31 |
| Pharaoh_Atem | especially since there were build changes this time around | 19:31 |
| mvo | Pharaoh_Atem: its in the release/2.29 branch now, I will do the formal GH release in my morning that includes your updates | 19:33 |
| Pharaoh_Atem | excellent | 19:33 |
| Pharaoh_Atem | but 2.29.4 was tagged now? | 19:33 |
| Pharaoh_Atem | I just need the regular tag for Fedora builds ;) | 19:33 |
| mup | PR snapd#4194 closed: daemon: for /v2/logs, 404 when no services are found <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4194> | 19:33 |
| Pharaoh_Atem | the special tarballs are needed only for my prototype EL7 builds | 19:34 |
| mvo | Pharaoh_Atem: oh, I can give you 2.29.3.1 as a tag | 19:35 |
| Pharaoh_Atem | that works too | 19:35 |
| Pharaoh_Atem | I just need a release to work from | 19:35 |
| Pharaoh_Atem | though I suppose I can work from 2.29.3 as-is | 19:36 |
| Pharaoh_Atem | I just wanted to make sure that it was in the branch and in master | 19:36 |
| mvo | Pharaoh_Atem: ok, its there now | 19:36 |
| Pharaoh_Atem | excellent | 19:36 |
| mvo | Pharaoh_Atem: gtg, but I will read scrollback | 19:36 |
| * mvo waves | 19:36 | |
| Pharaoh_Atem | bye | 19:37 |
| === JanC_ is now known as JanC | ||
| === ParkerR_ is now known as ParkerR | ||
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| mup | PR snapcraft#1722 opened: unit tests: reset log level after test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1722> | 21:08 |
| * zyga-ubuntu fights the mount issue a little more | 21:09 | |
| sergiusens | snappy-m-o autopkgtest 1657 xenial:amd64 | 21:17 |
| snappy-m-o | sergiusens: I've just triggered your test. | 21:17 |
| sergiusens | elopio mind addressing the comment in snapcraft#1633 ? | 21:19 |
| mup | PR snapcraft#1633: recording: record information from the image in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1633> | 21:19 |
| sergiusens | at least the one about the use of `format` in the unit test? | 21:19 |
| mariogrip | jdstrand: ping | 21:28 |
| jdstrand | mariogrip: hey | 21:38 |
| elopio | sergiusens on it | 21:41 |
| mariogrip | how do i make a file executable with snapcraft, now the the apps command does not seem to get +x | 21:42 |
| mariogrip | using the plugin sump | 21:43 |
| mariogrip | dump* | 21:43 |
| sergiusens | kyrofa were you manually running snapcraft#1717 ? | 21:43 |
| mup | PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717> | 21:43 |
| sergiusens | adt for it that is | 21:44 |
| kyrofa | sergiusens, wanted to, ran into breakage :D | 21:44 |
| kyrofa | sergiusens, fixed in snapcraft#1722 which is running now | 21:44 |
| mup | PR snapcraft#1722: unit tests: reset log level after test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1722> | 21:44 |
| sergiusens | mariogrip is the tar not tarred up correctly? You can tell it too with the `install` script in the part | 21:44 |
| jdstrand | mariogrip: I'm not a snapcraft expert, which is why I mentioned you come here (so others could help). the dump plugin should keep the exec bit set. I've certainly used it | 21:44 |
| sergiusens | jdstrand unless it isn't exec at all in the first place | 21:45 |
| sergiusens | or a strange umask is in place | 21:45 |
| mariogrip | It is +x in the zip file | 21:45 |
| elopio | sergiusens: didn't we agree on squashing our own pull requests? I like more the squash and merge button, but I thought I was following the new rules. | 21:45 |
| sergiusens | kyrofa are you running them merged together locally? | 21:46 |
| kyrofa | sergiusens, no, heck I'm just making sure master passes at this point | 21:46 |
| kyrofa | sergiusens, it doesn't, I already see more errors | 21:46 |
| sergiusens | elopio at one point, but then over a month ago we said we wouldn't do that anymore as there was little point as the hash was rewritten anyways | 21:46 |
| kyrofa | sergiusens, elopio is there a reason our tests keep going even though we know they're errored out? | 21:47 |
| sergiusens | kyrofa maybe a PEBKAC ? | 21:47 |
| kyrofa | Should we fail fast? | 21:47 |
| kyrofa | sergiusens, never! | 21:47 |
| sergiusens | kyrofa we want all the errors, to fix them all (we assume tests are independent for this to work) | 21:47 |
| sergiusens | kyrofa what errors do you see now? | 21:48 |
| kyrofa | sergiusens, no idea, just ERROR and I assume I'll see a summary at the end | 21:48 |
| kyrofa | sergiusens, I know if I cancel I won't see them | 21:49 |
| kyrofa | Which seems like a waste of time | 21:49 |
| mariogrip | ok if i extract it first to a folder and told snapcraft to use that it worked (without modifying any chmod's) | 21:50 |
| kyrofa | sergiusens, errors look like build-snap related, I wonder if it's a squashfuse issue | 21:50 |
| sergiusens | kyrofa how long do they tak locally? | 21:50 |
| kyrofa | sergiusens, unknown, I haven't had a success yet | 21:51 |
| sergiusens | mariogrip are you up for a bug fixing opportunity ? :-) | 21:51 |
| sergiusens | kyrofa you can tell the system to error out quickly before running | 21:51 |
| kyrofa | Yeah I'm changing it now | 21:51 |
| sergiusens | elopio also snapcraft#1530 ... given the use of ros more aggressively now, we could take advantage of the caching as kyrofa mentions, but let's limit it to the ros class | 21:53 |
| mup | PR snapcraft#1530: tests: share the cache dir in the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1530> | 21:53 |
| kyrofa | sergiusens, worried about side-effects? | 21:53 |
| kyrofa | Seems like a sensible first step | 21:53 |
| mariogrip | jdstrand: think i found my adb problem, no cluse what has changed, but now i get symbol __mmap error, also since we haven't updated the snap in a while, not sure what has changed to make this error | 21:53 |
| sergiusens | kyrofa worried about doing it for no benefits and then yes, missing out on catching a bug just because we were lazy to think about what we are trying to solve :-) | 21:54 |
| kyrofa | Makes sense | 21:54 |
| mariogrip | sergiusens: sure | 21:54 |
| kyrofa | So maybe a "SaveCacheTest" base class of some sort | 21:54 |
| sergiusens | kyrofa it should be a mixin if that is the case, but it also doesn't need to much thinking, just applied to the test class defined for ROS and done | 21:55 |
| sergiusens | I will be back later tonight and save my phone from tethering for a bit (isp blackout for the past 6 hours) | 21:55 |
| kyrofa | Well there isn't a common base class for ROS right now, so something will need to be written one way or another. But yeah | 21:55 |
| elopio | kyrofa: I feel that we wait a long time for the runners to be assigned, so running as much as possible when we have it sounded good. But that has obvious down sides, I wouldn't mind trying failfast. | 21:56 |
| mariogrip | jdstrand: I can try switching to a the adb version that comes with ubuntu (right now we use never directly from google) | 21:56 |
| kyrofa | elopio, I think that's probably the right call for the real deal. It's a pain running locally, but adding -f everywhere isn't hard | 21:57 |
| kyrofa | Maybe we can bake a nicer solution in the script, but nothing to worry about now | 21:57 |
| jdstrand | mariogrip: huh, interesting. maybe that is the difference between devmode (which would use libc, etc from the core snap) and classic which would use whatever is on your system | 22:02 |
| mariogrip | base snap is xenial right? | 22:03 |
| jdstrand | mariogrip: if it helps, the core snap is built from 16.04, so if you are building/etc, build on 16.04 so everything matches up | 22:03 |
| mariogrip | yeah, using xenial and classic works there | 22:04 |
| jdstrand | fyi, we still are using the core snap as the implied base snap. that will soon change (just clarifying our different terminology) | 22:04 |
| jdstrand | mariogrip: could be a missing stage package. note, I'm kinda guessing here-- sergiusens, kyrofa, et al will be able to help more if you get stuck getting it to work in devmode | 22:05 |
| jdstrand | mariogrip: once we get to tryingto get it to work in strict mode, I will be able to help more :) | 22:06 |
| mariogrip | tried with this (older adb version) that seems to work https://github.com/ubports/android-tools | 22:06 |
| ikey | what would you guys say to supporting /var/lib/snapd/lib/gl/32 for biarch nvidia driver support? | 22:07 |
| jdstrand | mariogrip: I'm going to eod, but feel free to post questions here or in the forum (we all read backscroll and forum posts) | 22:11 |
| mariogrip | jdstrand: Ok, Thanks for you help :) | 22:11 |
| jdstrand | mariogrip: glad https://github.com/ubports/android-tools works for you, that'll be a good start. good luck! :) | 22:11 |
| mariogrip | sergiusens: found a fix for the zip not preserving permission problem, pr coming up | 22:12 |
| sergiusens | mariogrip thanks | 22:13 |
| * ikey has a local patch for the 32 thing fwiw | 22:14 | |
| sergiusens | ikey is there a reason not to support it? | 22:17 |
| ikey | i dont think so | 22:17 |
| sergiusens | great :-) | 22:17 |
| sergiusens | mariogrip jdstrand about the missing symbol, smells like building on 17.04 or greater | 22:18 |
| sergiusens | as you suggest jdstrand | 22:18 |
| sergiusens | mariogrip you want to wait for our "building with libraries from the future" task to get completed | 22:19 |
| mariogrip | the binaries are from google, no clue what they are built on | 22:19 |
| sergiusens | where building, is not really building but dumping | 22:19 |
| sergiusens | if you build all your deps, it should work | 22:19 |
| sergiusens | which is really the only supported way we have for classic until we finish of the daunting task of elf patching ;-) | 22:20 |
| mariogrip | can do that :) but this is an crossplatform application so we wanted to use same adb for all the os | 22:20 |
| sergiusens | mariogrip it would be the same adb once it is in the snap | 22:21 |
| mariogrip | for linux yes | 22:21 |
| sergiusens | mariogrip wait, google has a cross-os build of adb? | 22:21 |
| mariogrip | but i wont get started on even building windows adb | 22:21 |
| mariogrip | well they provide for all the os, but it's the same adb version | 22:22 |
| sergiusens | oh, they certainly provide sources, right? | 22:22 |
| sergiusens | anyways, you can also wait for that other work | 22:22 |
| sergiusens | unless you go strict/devmode, then you do not need to wait | 22:22 |
| mariogrip | i guess it's easier to just use the version https://github.com/ubports/android-tools then start importing the android source to get hold of the adb source | 22:23 |
| sergiusens | kyrofa I've been thinking, no need to really run adt; just create a container of a different release to 16.04 and run the snap as we do on travis | 22:23 |
| sergiusens | or are you doing another arch? | 22:24 |
| kyrofa | sergiusens, right now I'm just doing xenial:amd64 so I can make sure it actually works, then I can start running other releases. Even if I did the snaps tests, we need adt to pass, right? | 22:26 |
| mariogrip | sergiusens: https://github.com/snapcore/snapcraft/pull/1723 | 22:39 |
| mup | PR snapcraft#1723: Workaround for ZipFile.extractall not preserving permission <Created by mariogrip> <https://github.com/snapcore/snapcraft/pull/1723> | 22:39 |
| mup | PR snapcraft#1723 opened: Workaround for ZipFile.extractall not preserving permission <Created by mariogrip> <https://github.com/snapcore/snapcraft/pull/1723> | 22:41 |
| elopio | kyrofa: so, my patch didn't solve your adt log errors? | 22:44 |
| kyrofa | elopio, wait, which patch? | 22:44 |
| kyrofa | Huh, -f isn't failing fast, either | 22:44 |
| kyrofa | This definitely has something to do with build-snaps, though | 22:45 |
| elopio | kyrofa: http://paste.ubuntu.com/25920819/ | 22:46 |
| elopio | sorry, I misunderstood your next ping as an ack. | 22:46 |
| kyrofa | elopio, wait, what is this? I'm so lost now :P | 22:47 |
| kyrofa | Oh, we don't use runtests.sh in adt, nice | 22:50 |
| elopio | kyrofa: we are sooo out of sync :) | 22:50 |
| kyrofa | elopio, no kidding :D | 22:50 |
| elopio | kyrofa: is your test failing because it prints some extra v2/snaps GET ? | 22:50 |
| kyrofa | elopio, no, I fixed that in snapcraft#1722 | 22:51 |
| mup | PR snapcraft#1722: unit tests: reset log level after test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1722> | 22:51 |
| kyrofa | elopio, you fixed it another way, eh? Hahaha | 22:51 |
| elopio | kyrofa: yes, I'm reviewing that PR and not liking your solution. | 22:51 |
| elopio | :) | 22:51 |
| kyrofa | elopio, meanie. Well YOUR solution doesn't make any sense! | 22:52 |
| kyrofa | elopio, why would that only cause issues occasionally? | 22:52 |
| elopio | kyrofa: about that, I'm not sure. There's a nuke option on the fake logger, that maybe is combining with a few other things that are wrong on the way we use the log. | 22:54 |
| kyrofa | Hahaha | 22:54 |
| elopio | so, my fix makes the fake snapd server to not print to stdout. All the other fakes print to debug, but it wasn't using the common base class. | 22:54 |
| elopio | my guess is that sometimes it prints to stdout, and that is collected by the following test. | 22:54 |
| elopio | no wait, it always prints to stdout and that sometimes is collected by the following test. | 22:55 |
| kyrofa | elopio, hmm.... that ALSO sounds like a problem | 22:56 |
| kyrofa | But a different one | 22:56 |
| elopio | that's why I was wondering if the patch fixed the problem for you. Because I no longer get those spurious GETs printed, and my adt unit tests are all green. | 22:57 |
| kyrofa | elopio, I didn't even see the patch, I must have missed your ping | 22:58 |
| elopio | now the real problem to me is that most of our tests shouldn't be checking the log. But that will take a long time to fix. | 22:58 |
| kyrofa | Yeah | 22:58 |
| elopio | I'm not -1 on your branch. It's just that it's not a reset. If it works, I'm ok landing it. Anyway we'll need to improve that soon. | 22:59 |
| kyrofa | It's not a reset? | 22:59 |
| kyrofa | How is it not a reset? | 22:59 |
| kyrofa | It always sets it to whatever is default at the end of each test | 22:59 |
| elopio | kyrofa: most of our tests never call log.configure. Only the ones that excercise the cli module. | 23:00 |
| kyrofa | elopio, right, the issue seems to be that the logging level sticks around and effects other tests | 23:00 |
| elopio | so for the tests that have nothing to do with that configure, you are calling it at the end of the test, which is weird. | 23:00 |
| elopio | kyrofa: and that about the logging level sticking is what I don't understand. The fixture does this: https://github.com/testing-cabal/fixtures/blob/master/fixtures/_fixtures/logger.py#L54 | 23:01 |
| elopio | so, summary, there are many things wrong. I will propose my patch, because I think all the fake servers should do the same. I think that will have the side effect of fixing the issue for you too. | 23:03 |
| elopio | I could +1 your branch if you still like it, because calling log.configure always will not affect anything. Or at least, it's clearly not more wrong than all the wrong things that are happening around :) | 23:04 |
| kyrofa | elopio, yeah fair enough, propose your branch, I'll +1 if it fixes it, and we can close mine | 23:04 |
| elopio | kyrofa: I would also like to see if the nuke option solves the problem, it could be a good safeguard. | 23:06 |
| kyrofa | Yeah that's an interesting-sounding option | 23:06 |
| mup | PR snapcraft#1724 opened: tests: use the common base handler on the fake snapd server <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1724> | 23:14 |
| * ikey is uploading a video.. | 23:34 | |
| ikey | https://plus.google.com/+Solus-Project/posts/cTzfduUHht8 | 23:38 |
| kyrofa | Atta boy ikey! | 23:41 |
| ikey | :D | 23:41 |
| mup | PR snapcraft#1725 opened: tests: share the cache in ros tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1725> | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
