| mup | PR snapcraft#2143 opened: lifecycle: don't clean priming area if the snap is being tried <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2143> | 00:53 |
|---|---|---|
| mup | PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 02:47 |
| mup | PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22> | 02:47 |
| mup | PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26> | 02:47 |
| mup | PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 02:48 |
| mup | PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22> | 02:48 |
| mup | PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26> | 02:48 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 03:10 |
| mup | PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 03:11 |
| mup | PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 03:11 |
| === pbek_ is now known as pbek | ||
| mup | PR snapd#5190 opened: tests: new parameter for the journalctl rate limit <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5190> | 04:46 |
| mborzecki | morning | 05:05 |
| mup | PR snapd#5182 closed: snapstate/hooks: reorder autoconnect and reconnect hooks <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5182> | 05:45 |
| mvo | mborzecki: hey, if you don't mind I look at the spread test for the symlink PR | 06:00 |
| mvo | 5189 looks like an easy win btw | 06:01 |
| mborzecki | mvo: hey, go ahead, had that in my queue but i'm ok looking at something else | 06:01 |
| mvo | mborzecki: thanks, it pretty trivial, I will push something in a sec. got a bit of ocd sometimes, sorry | 06:02 |
| mup | PR snapd#5189 closed: interfaces/many: miscellaneous updates for default, desktop, desktop-legacy, system-observe, hardware-observe, opengl and gpg-keys <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5189> | 06:03 |
| mvo | mborzecki: \o/ | 06:03 |
| mvo | pstolowski|afk: when you are around, can you please remind me what the problematic PR on master is that we need to look into reverting (for now). I would love to spend some time on 2.33 today | 06:07 |
| mborzecki | mvo: i can try to look into exposing appstreamid (or common-id as it was named in the forum) | 06:08 |
| mvo | mborzecki: yeah, that sounds great | 06:08 |
| mvo | mborzecki: I think we also need to ensure the roadmap is up-to-date after the last sprint, this was not updated yet, was it? | 06:09 |
| mborzecki | mvo: no, i don't think so | 06:11 |
| === chihchun is now known as chihchun_afk | ||
| mvo | mborzecki: ok, I will do that in a bit then | 06:19 |
| jamesh | mvo: could you approve rev 2 of test-snapd-eds? It's the same as rev 1 but built for i386 | 06:26 |
| === chihchun_afk is now known as chihchun | ||
| mvo | jamesh: sure, let me do this now | 06:27 |
| jamesh | thank you | 06:27 |
| mborzecki | mvo: echo tests/main/snap-core-symlinks/task.yaml >> tests/unit/spread-shellcheck/must | 06:32 |
| mborzecki | 'error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/snap-hooks": unable to copy /home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/snap-hooks/meta/hooks/install to /tmp/snappy-build-416974275/meta/hooks/install: no space left on device' | 06:34 |
| mborzecki | https://api.travis-ci.org/v3/job/382511824/log.txt current master build | 06:34 |
| mvo | mborzecki: shellcheck> aha, right, let me add this | 06:41 |
| mvo | mborzecki: oh? master broken? | 06:41 |
| mborzecki | mvo: some tests failed in prepare or eexcute due to no space left, looks weird, restarted it for now and we'll see if it repeats | 06:42 |
| mborzecki | mvo: we seem to clean up snappy-build though | 06:42 |
| mborzecki | is there anything we keep in /tmp during the tests? | 06:42 |
| mvo | mborzecki: I can't think what could fill up /tmp - long shoot - maybe we hit the bug that we discussed yesteday where the state grows? | 06:45 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:14 |
| pstolowski | mvo: i'll prepare it for you in a moment | 07:14 |
| mvo | hey pstolowski | 07:14 |
| mvo | pstolowski: thank you! | 07:14 |
| pstolowski | mvo: we want to target master with this revert right? | 07:18 |
| mvo | pstolowski: yes | 07:20 |
| pstolowski | ack | 07:20 |
| mvo | pstolowski: and once that is in I will branch 2.33 | 07:20 |
| pstolowski | yep | 07:20 |
| mborzecki | pstolowski: hey | 07:39 |
| pstolowski | o/ | 07:39 |
| mborzecki | mvo: there's a conflict in #5134 i can push a quick fix if you're busy | 07:55 |
| mup | PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134> | 07:55 |
| mborzecki | mvo: pushed :) | 07:58 |
| mvo | mborzecki: heh, thank you | 08:00 |
| mup | PR snapd#5191 opened: snapstate: revert the addition of "reconnect" task <Created by stolowski> <https://github.com/snapcore/snapd/pull/5191> | 08:10 |
| pstolowski | mvo: ^ | 08:10 |
| mvo | pstolowski: nice | 08:11 |
| pstolowski | mvo: no, it's depressing :(. but good we found it early enough | 08:11 |
| mvo | pstolowski: indeed, this won't affect anything that was using stable, right? so its fine, we push it back one release :) and it removes the pressure to fix it ASAP we can step back and look at it carefully | 08:12 |
| pstolowski | mvo: right | 08:13 |
| * mvo hugs mborzecki for finding another real bugs with the spread-shellcheck | 08:15 | |
| Chipaca | bug #1772844 is interesting | 08:32 |
| mup | Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:New for swem> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1772844> | 08:32 |
| Chipaca | pstolowski: might this be related to the issue you're working on? | 08:32 |
| Chipaca | in this one there aren't a bunch of tasks, but snapd gets stuck in 'Automatically connect eligible plugs and slots of snap "gnome-calculator"' | 08:33 |
| pstolowski | Chipaca: yes.. but it's on stable on autoconnect. so far we assumed it's only reconnect in edge | 08:34 |
| Chipaca | pstolowski: that's the most 'no' yes I've seen in a while | 08:34 |
| pstolowski | Chipaca: in other words, yes, most likely same problem. we thought it wouldn't happen on autoconnect | 08:37 |
| Chipaca | pstolowski: dangit | 08:38 |
| Chipaca | pstolowski: this is Bad | 08:38 |
| pstolowski | pedronis: ^ | 08:38 |
| Chipaca | pstolowski: I leave you to update that bug appropriately then | 08:38 |
| pedronis | I didn't say, it couldn't happen | 08:38 |
| pedronis | just that is more rare | 08:38 |
| pedronis | but maybe it's actually a different bug that what I think | 08:39 |
| * Chipaca puts the bug down and slowly backs away | 08:39 | |
| pedronis | that's seeding? | 08:39 |
| pedronis | then it's related but a different bug | 08:40 |
| pedronis | Chipaca: pstolowski: seeding it's always serial | 08:41 |
| Chipaca | pedronis: even when one snap has content interfaces and such? | 08:42 |
| pedronis | Chipaca: we don't support that | 08:43 |
| pedronis | but you should do the right thing | 08:43 |
| pedronis | otherwise you are on your own | 08:43 |
| Chipaca | pedronis: what's 'that' in this context? | 08:44 |
| Chipaca | snapd's performance with a lot of tasks is very very bad :-( | 08:44 |
| pedronis | Chipaca: prepare-image doesn't do the right thing atm | 08:45 |
| pedronis | but this is not prepare image | 08:45 |
| pstolowski | our to-be-fixed conflict logic will fix seeding case i think with no special case for seeding? | 08:45 |
| pedronis | pstolowski: no, seeding is special | 08:45 |
| pedronis | if you mess up the order of the snaps | 08:45 |
| pedronis | you are on your own | 08:46 |
| pedronis | unless we teach seeding to sort them for you | 08:46 |
| mvo | the seed.yaml is available in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1772844/comments/6 ordering looks vaguely sane | 08:46 |
| mup | Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:New for swem> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1772844> | 08:46 |
| pedronis | except themes | 08:46 |
| pedronis | if it's a default provider | 08:46 |
| pedronis | no idea about that | 08:46 |
| mvo | aha, good point, let me look | 08:47 |
| pedronis | as I said, serializing is not really a win here | 08:47 |
| pedronis | it makes thing harder not simpler | 08:47 |
| pedronis | but seeding is serial since forever | 08:47 |
| Chipaca | pedronis: fwiw if it's serialised wouldn't there be no Done tasks after the Do tasks? | 08:48 |
| pedronis | Chipaca: ? | 08:48 |
| mvo | pedronis: ha! you are right, its a content interface | 08:48 |
| pedronis | well, the question is what are the default providers listed in gnome-calculator | 08:48 |
| Chipaca | pedronis: https://pastebin.ubuntu.com/p/wfqwkFn7WC/ | 08:49 |
| Chipaca | ^ plugs from gnome-calculator | 08:49 |
| pedronis | ok, so themes | 08:49 |
| pedronis | themes | 08:49 |
| pedronis | need to come before | 08:49 |
| pedronis | the apps | 08:49 |
| pedronis | or it will never work | 08:49 |
| mvo | nice one | 08:50 |
| Chipaca | I'll tell them about it in the bug | 08:50 |
| mvo | I mean, nice that we can suggest a workaround so easily | 08:50 |
| Chipaca | pedronis: could we detect and warn about this? | 08:50 |
| pedronis | we can but in general we need to think what we want to do about this | 08:50 |
| pedronis | the fact they don't use prepare-image is also an issue | 08:50 |
| pedronis | we could teach prepare-image to do the right thing | 08:51 |
| pedronis | (as I said it doesn't) | 08:51 |
| mvo | Chipaca: what else is missing for snapshots? I wonder when to branch 2.33 | 08:51 |
| mup | PR snapd#5191 closed: snapstate: revert the addition of "reconnect" task <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5191> | 08:51 |
| Chipaca | mvo: daemon and cmd | 08:51 |
| mvo | Chipaca: ok | 08:52 |
| pedronis | prepare-image doesn't know about default-providers or bases atm | 08:52 |
| pedronis | I think | 08:52 |
| pedronis | mvo: is that ^ right ? | 08:52 |
| Chipaca | mvo: 3 files changed, 462 insertions(+), 3 deletions(-) | 08:52 |
| mvo | pedronis: I will soon need to teach it at least about bases for the core18 image work | 08:52 |
| Chipaca | mvo: (without tests) | 08:53 |
| mvo | pedronis: I think so too | 08:53 |
| mvo | Chipaca: thats not too bad, I'm sitting on the fence a bit right now if I branch now and merge these bits into release/2.33 or wait until they arrive | 08:54 |
| Chipaca | mvo: I don't think snapshots, as they stand, are useful to users | 08:54 |
| Chipaca | mvo: there's a ways to go still | 08:54 |
| mvo | Chipaca: the upside of branching now is that a) ocd b) more time to test if 2.33 builds everywhere etc | 08:54 |
| Chipaca | mvo: this is the very very basic functionality | 08:54 |
| Chipaca | mvo: but a user could easily mess up their snaps with it as it stands | 08:54 |
| mvo | Chipaca: ok, cool, I think I will branch in this case and start with getting things test-clean in cosmic etc | 08:55 |
| Chipaca | mvo: (also the most user-friendly aspect of snapshots is when they're automagic) | 08:55 |
| mvo | Chipaca: if they are actively dangerous should we hide them behind a feature flag? like we do for layouts? | 08:55 |
| Chipaca | mvo: I think hiding the commands is good enough | 08:55 |
| mvo | Chipaca: even better, less work. thank you! | 08:56 |
| Chipaca | if we want to talk about them I'd present them as a 'feature preview' | 08:56 |
| Chipaca | there's a list of caveats written down somewhere :-) | 08:57 |
| Chipaca | mvo: did you see my comment about symlinking snapd in core18? | 08:59 |
| mvo | Chipaca: no, let me look | 08:59 |
| mvo | Chipaca: in the forum? | 09:00 |
| Chipaca | pstolowski: is there a way to unstick my snapd from the megatasks bug? | 09:09 |
| pedronis | Chipaca: I think for seeding we need a stable sort that sorts bases + then default providers + then the rest, and finds and errors on cycles with the default providers | 09:12 |
| pstolowski | Chipaca: you need to get onto new edge somehow (which is in fact an older edge image that mvo reverted to yesterday) | 09:12 |
| Chipaca | my state.json is 25MB and each task takes 5 seconds to do :-( | 09:12 |
| Chipaca | when are we moving to an actual database | 09:13 |
| Chipaca | (this is not a puny machine) | 09:13 |
| pedronis | well given our todos, not this cycle | 09:13 |
| pedronis | sounds a goal for 2020 | 09:13 |
| mvo | pstolowski, Chipaca I triggered a new core sync so soon there should be a core with the reverted PR | 09:14 |
| mvo | pstolowski: each night we get a new edge so I think this is the best option (fast-track the edge with the reverted pr) | 09:14 |
| pedronis | Chipaca: also probably easier with split out snapd and epochs | 09:15 |
| Chipaca | pedronis: buaah | 09:15 |
| pstolowski | mvo: right. but i wonder how hard is it to get out of the 'broken' state and regain control | 09:16 |
| pedronis | Chipaca: btw what snaps were involved in your broken change? | 09:17 |
| Chipaca | pedronis: core, vlc | 09:17 |
| pedronis | ok | 09:17 |
| Chipaca | pedronis: if i manually update them one by one should it fix itself? | 09:17 |
| pedronis | it will stop you to do that, no? | 09:18 |
| pedronis | pending change and stuff | 09:18 |
| eraserpencil | join #ubuntu | 09:18 |
| Chipaca | pedronis: i abort the auto-refresh one every time it starts | 09:18 |
| pedronis | Chipaca: snap refresh vlc then could help | 09:19 |
| Chipaca | because all my cores get all hot and bothered | 09:19 |
| pedronis | if you sneak it in with the abort | 09:19 |
| pedronis | pstolowski: the fact that the refresh exploding is "core vlc" still makes me think my theory seems reasonable about what is the bug | 09:23 |
| Chipaca | all these prepare-hook-blah tasks are killing it :-( | 09:25 |
| pedronis | ? | 09:26 |
| pstolowski | pedronis: i'm still unlucky in reproducing it in unit test. it's probably a problem with setup/mock somewhere | 09:27 |
| pedronis | pstolowski: your 2nd snap need an interface that autoconnects | 09:27 |
| pedronis | to be clear | 09:27 |
| pstolowski | hmm | 09:27 |
| pedronis | with core | 09:28 |
| pedronis | like network I suppose | 09:28 |
| Chipaca | pedronis: i mean https://pastebin.ubuntu.com/p/8Yg5jq5wGk/ | 09:32 |
| Chipaca | pedronis: this is me trying to manually update core on its own | 09:32 |
| pedronis | Chipaca: it dies even on its own? | 09:33 |
| Chipaca | pedronis: well, it doesn't finish, and seems to be in a loop | 09:33 |
| pedronis | or just take forever? | 09:33 |
| pedronis | that is stranger | 09:33 |
| Chipaca | pedronis: note how e.g. «Run hook prepare-slot-home of snap "core"» is repeated many times | 09:34 |
| Chipaca | pedronis: with different task numbers | 09:34 |
| pedronis | that is expected | 09:34 |
| pedronis | one for each plug | 09:34 |
| pedronis | of home | 09:34 |
| Chipaca | I just got tired and aborted it, but even abort is taking ages | 09:34 |
| pedronis | I mean, it might be that even the correct behavior | 09:35 |
| pedronis | is too heavy | 09:35 |
| Chipaca | (and the fans are spinning away like mad) | 09:35 |
| Chipaca | load average is > 2 of just snapd | 09:35 |
| pedronis | Chipaca: it's going to create connect and hook tasks for each plug to core into the system | 09:35 |
| Chipaca | at >2s per task, that's insane | 09:36 |
| pedronis | because your db is big ? | 09:36 |
| pedronis | because of the previous error | 09:36 |
| pedronis | ? | 09:36 |
| Chipaca | pedronis: it might be | 09:36 |
| pedronis | or in general | 09:36 |
| Chipaca | well, they're never quick | 09:36 |
| Chipaca | but the >2s is because my state is too big | 09:36 |
| Chipaca | (i'm not going to call it a db :-) ) | 09:37 |
| pedronis | Chipaca: compile a snapd with lower prune times and run it? | 09:37 |
| Chipaca | i have 22 installed snaps of different complexity | 09:37 |
| pstolowski | we shouldn't create hook tasks at all if not needed, they will be no-op for 99% of snaps i suppose | 09:37 |
| Chipaca | 22 installed snaps -> 92 entries in /data/conns | 09:39 |
| Chipaca | -> 184 tasks | 09:39 |
| Chipaca | at 2s per task, that's 5 minutes on just this | 09:39 |
| pedronis | even more | 09:39 |
| Chipaca | 6 | 09:40 |
| pedronis | Chipaca: you need to prune your state | 09:40 |
| pedronis | see suggestion above | 09:40 |
| Chipaca | but, even at 200ms per task, that's 30 seconds on just this | 09:40 |
| Chipaca | that's _still_ too much | 09:40 |
| pedronis | this is reverted | 09:41 |
| pedronis | but yes, it might be that we need to think | 09:41 |
| pedronis | what reconnect really needs to do | 09:41 |
| pedronis | to be sane | 09:41 |
| Chipaca | there are also some O(N²) that could be pared down, but that's for later | 09:42 |
| Chipaca | at least reading the code :-) | 09:42 |
| pedronis | pstolowski: reconnect could do the connect only if the snap being installed has hooks on that connection | 09:44 |
| pedronis | but we should probably fix the bigger issue first (infinite retries) | 09:44 |
| pstolowski | pedronis: yes, we shouldn't create hook tasks if not needed | 09:45 |
| Chipaca | ok, with the pruned state it got through the changes ok | 09:45 |
| Chipaca | pstolowski: pedronis: note there's also the thing of regenerating apparmor every time instead of just once at the end, which zyga was going to look at at some point | 09:46 |
| Chipaca | (this one is visible in the long time the interfaces-many test takes) | 09:46 |
| pstolowski | pedronis: another improvement would be to run reconnect/autoconnect only once if two connected snaps are refreshed in one operation | 09:46 |
| zyga | That thing may be a but larger but yeah. | 09:47 |
| Chipaca | zyga: ohai | 09:47 |
| Chipaca | zyga: i thought you were basking in the sun somewhere | 09:47 |
| zyga | Hi | 09:47 |
| zyga | I’m going home already | 09:47 |
| zyga | Also no longer ill | 09:48 |
| zyga | Long way home | 09:48 |
| Chipaca | zyga: https://www.youtube.com/watch?v=qmWC5dGVvH4 | 09:51 |
| mup | PR snapd#5192 opened: testutil: import check.v1 differently to workaround gccgo error <Created by mvo5> <https://github.com/snapcore/snapd/pull/5192> | 09:54 |
| === chihchun is now known as chihchun_afk | ||
| pstolowski | pedronis: can you think of anything i could have missed in this managers test - https://pastebin.ubuntu.com/p/fDZMGN8Wmt/ ? all tasks done, 2 connections exist as expected at the end, no conflict/retry reported; only unexpected think is the very last check of 'Done' status on entire change (it's still Doing) | 10:08 |
| mvo | Chipaca: a new core in edge with the reverted reconnect is available now | 10:16 |
| Chipaca | installing it | 10:17 |
| Chipaca | pedronis: pstolowski: about the tasks taking too long: note that i pruned the state back very aggressively to get unstuck, and the first refresh after that was reasonably fast, but the second one after that is already too slow (taking >30s for the 'connecting stuff' phase) | 10:17 |
| pedronis | pstolowski: well, if it is still doing, then is not done | 10:21 |
| pedronis | pstolowski: do you have a branch I can play with , with this and still the reconnect code ? | 10:22 |
| pedronis | pstolowski: lunch here, let me know | 10:25 |
| pstolowski | pedronis: i've pushed it to https://github.com/stolowski/snapd/tree/fix-reconnect-conflictcheck | 10:34 |
| pstolowski | pedronis: yes, the change is not done, but all tasks in the state are done (including auto-connect and reconnect) | 10:34 |
| === chihchun_afk is now known as chihchun | ||
| pstolowski | 2018-05-23T10:38:28Z INFO no handler for task "reconnect", task ignored | 10:40 |
| pstolowski | i think that may be the first time i see it in action | 10:40 |
| pstolowski | turned out to be useful | 10:40 |
| pedronis | pstolowski: is there already a different change in that branch? | 10:54 |
| pstolowski | pedronis: yes i changed the logic to check all conflicts upfront | 10:55 |
| pstolowski | shouldn't make a difference, but if you want just the test, it's managers_test.go | 10:55 |
| pedronis | pstolowski: it doesn't pass if run together with other tests | 11:03 |
| pedronis | afaict | 11:03 |
| pstolowski | ok, that's possible, i was mostly running it alone, let me check | 11:03 |
| pedronis | it gets stuck | 11:04 |
| pstolowski | ineed i see it | 11:04 |
| pedronis | it doesn't print anything either though :/ | 11:05 |
| pedronis | pstolowski: I know why it doesn't fail btw | 11:08 |
| pedronis | which is probably unrelated to the other issue | 11:08 |
| pedronis | with all the tests | 11:08 |
| pedronis | pstolowski: the mocking of the response from the server for core has the wrong snap type | 11:09 |
| pedronis | so the ordering doesn't happen | 11:09 |
| pstolowski | ahh | 11:09 |
| pedronis | without the forced order the current code is fine | 11:10 |
| pstolowski | where is that exactly? | 11:10 |
| pedronis | what? | 11:10 |
| pedronis | that=? | 11:10 |
| pstolowski | the mocking; what makes it correct/incorrect? | 11:12 |
| pedronis | that we default to app | 11:12 |
| pedronis | it needs to grow some smarts about type | 11:12 |
| pstolowski | uhm, not familiar with that, do we havy any example in any other test? | 11:12 |
| pedronis | no | 11:13 |
| pedronis | by definition | 11:13 |
| pedronis | if we had it would do the right thing | 11:13 |
| pedronis | I'm talking about fillHit to be clear | 11:13 |
| pedronis | let me see | 11:14 |
| pedronis | it's probably easyish | 11:15 |
| pedronis | pstolowski: something like this: https://pastebin.ubuntu.com/p/3HRNvjZMg7/ (haven't checked if it creates other problems with the other tests though) | 11:19 |
| pedronis | it also makes the other test fail | 11:19 |
| pstolowski | pedronis: thanks a lot! i'll play with it | 11:19 |
| pedronis | there is still some other problem with that the test and the others though | 11:19 |
| mborzecki | mvo: rewrote spread-shellcheck in python in pyyaml, on my desktop the old shell version needed 3:18 to run through 'spread.yaml tests', the new one does the same in 29s, checking the same number of files | 11:20 |
| pedronis | pstolowski: I skipped the new one with that change (@TYPE@), seems it doesn't break other tests | 11:20 |
| pstolowski | pedronis: and the new test now behaves completely different (and fails on connections check). now many tests are still not started | 11:25 |
| pedronis | pstolowski: it should print RETRY | 11:25 |
| pedronis | I suppose | 11:25 |
| pedronis | at least once | 11:25 |
| pstolowski | pedronis: it didn't. and the tasks are waiting for restart | 11:26 |
| pstolowski | and i see we mock restarting in tests.. trying | 11:28 |
| pedronis | ah | 11:29 |
| pedronis | yea, because core | 11:29 |
| kjackal | Hi everyone, what is the proper way to "simulate" a snap refresh? I would like to test the snap refreshing/upgrading before releasing new revisions. | 11:30 |
| pstolowski | yes!! | 11:30 |
| pstolowski | pedronis: getting RETRY now | 11:30 |
| pedronis | good | 11:30 |
| pstolowski | pedronis: thank you very much! | 11:31 |
| popeycore | Wimpress: yup, my session just died when i snap installed something (again) | 11:37 |
| mvo | mborzecki: nice! | 11:39 |
| pedronis | pstolowski: let me know if you want to discuss a fix | 11:39 |
| pstolowski | pedronis: thanks. i need to figure out what makes the test hang when running entire suite, then will work on the fix | 11:40 |
| pedronis | ok | 11:41 |
| * cachio afk | 11:49 | |
| mup | PR snapd#5193 opened: spread-shellcheck: port to python <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5193> | 11:51 |
| mup | PR snapd#5185 closed: tests: shellchecks part 2 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5185> | 11:52 |
| pedronis | mvo: do you remember why we used a task adding more tasks and didn't compute bases/default-providers when constructing the change? | 11:53 |
| mvo | pedronis: I don't remember exactly, I think it was related to the fact that when there are multiple changes that needed the same baseit was difficult to ensure the right ordering and also what to do if one of the changes gets aborted/fails but other changes need the base in question | 12:07 |
| pedronis | mvo: I see but in practice those changes need to conflict (the bit we are missing) so we lose that | 12:08 |
| pedronis | there can be at most one change doing things with one of the bases | 12:08 |
| pedronis | mvo: the context , is me thinking what we can simplify about conflicts etc | 12:19 |
| mvo | pedronis: right, this is certainly an interessting area to simplify things | 12:20 |
| pedronis | mvo: I'm also thinking this because we need this kind of static detection for prepare-image | 12:23 |
| pedronis | "static" | 12:23 |
| * mvo nods | 12:27 | |
| mup | PR snapd#5192 closed: testutil: import check.v1 differently to workaround gccgo error <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5192> | 12:29 |
| mborzecki | mvo: shall we land #5134 ? | 12:30 |
| mup | PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134> | 12:30 |
| mvo | mborzecki: yes | 12:35 |
| mup | PR snapd#5134 closed: Shrink image generated with snap prepare <Created by kubiko> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5134> | 12:36 |
| anarcat | so remember how i came here the other day trying to fix the "devmode" off of firefox? | 13:00 |
| anarcat | i did | 13:00 |
| anarcat | and now it's running 60.0-2 | 13:01 |
| anarcat | but the fonts exploded somewhat | 13:01 |
| anarcat | http://paste.anarc.at/snaps/snap-2018.05.23-08.32.25.png | 13:01 |
| anarcat | anyone has a clue wf is going on there? | 13:01 |
| anarcat | no problem in chromium, terminals or emacs | 13:01 |
| diddledan | anarcat: try closing firefox, `rm ~/snap/firefox/current/.last_revision`, then start firefox again (it should take a few moments to launch because it recaches everything) | 13:04 |
| anarcat | diddledan: no go | 13:05 |
| diddledan | hmm | 13:07 |
| * ogra_ wonders what you mean by "fix the "devmode" off of firefox" | 13:07 | |
| anarcat | ogra_: for some reason, snap wouldn't update firefox recently - it was stuck on 59... there was a "devmode" flag on the "snap info" output... uninstall firefox and reinstall fixed that problem | 13:08 |
| anarcat | but now fonts are all fubar'd | 13:08 |
| ogra_ | ah | 13:08 |
| popey | thats why | 13:08 |
| popey | don't use --devmode | 13:08 |
| ogra_ | well you must have installed it with --devmode at some point | 13:09 |
| ogra_ | then it wont update ... since thats "developer mode" ... | 13:09 |
| anarcat | well thanks | 13:09 |
| anarcat | i don't remember using devmode | 13:09 |
| anarcat | but that'S not the point here now | 13:09 |
| ogra_ | right ... | 13:09 |
| ogra_ | what does "snap version" print ? | 13:09 |
| popey | well, it kinda is. if you install in devmode, you break confinement for that application. It might start writing outside the container, where it normally can't. | 13:10 |
| popey | which may adversely affect it when you make it confined again | 13:10 |
| anarcat | well i totally uninstalled it | 13:10 |
| ogra_ | well, uninstall/reinstall should theoretically clean that up | 13:10 |
| ogra_ | but anyway ... "snap version" ? | 13:11 |
| anarcat | snap version: http://paste.debian.net/1026157/ | 13:11 |
| ogra_ | hmm, debian | 13:12 |
| popey | hm, should work. | 13:12 |
| popey | lemme try here. I have a debian vm | 13:12 |
| anarcat | i suspect the problem may not be with snappy too | 13:12 |
| popey | whats your default locale on the desktop? | 13:13 |
| diddledan | my default locale is my computer chair | 13:13 |
| anarcat | damn - even "--ProfileManager --new-instance" has screwed up fonts on the first dialog | 13:13 |
| anarcat | popey: fr_CA.UTF-8 | 13:13 |
| popey | hmmm | 13:14 |
| popey | ok, testing | 13:14 |
| anarcat | actually no, that's the locale i picked on login, the default is "none" (dpkg-reconfigure locales) | 13:14 |
| anarcat | damn it | 13:14 |
| diddledan | yeah, that's your problem. you should only ever use "C" or "en-US" because languages other than murrican are wrong </troll> | 13:14 |
| anarcat | that kind of stuff is so weird | 13:14 |
| ogra_ | diddledan, wait, what ?!? ... | 13:15 |
| diddledan | :-p | 13:15 |
| ogra_ | diddledan, you should always use C.UTF-8 or en-US.UTF-8 ... ! | 13:15 |
| ogra_ | not just C or en-US | 13:15 |
| ogra_ | think of the emojis !!! | 13:15 |
| anarcat | so how would i clean my firefox profile in the snap universe? | 13:16 |
| diddledan | good point | 13:16 |
| ogra_ | :) | 13:16 |
| anarcat | normally, i would just mv .mozilla{,.orig} and try again - would that work here? | 13:16 |
| ogra_ | anarcat, well, snaps store stuff under ~/snap/firefox/ | 13:16 |
| popey | if you remove the snap it should go away | 13:16 |
| ogra_ | right | 13:16 |
| diddledan | 👻 | 13:16 |
| anarcat | well that's one way of fixing the problem :p | 13:16 |
| ogra_ | uninstalling still removes all user data too | 13:16 |
| anarcat | i have a hard time figuring out how the stuff under ~/snap relates to the normal stuff in ~ | 13:17 |
| anarcat | okay | 13:17 |
| ogra_ | inore ~ | 13:17 |
| anarcat | so how can i make a non-destructive test? | 13:17 |
| ogra_ | ignore ~ | 13:17 |
| anarcat | tarball ~/snap/firefox/ and rm -rf? | 13:17 |
| ogra_ | the only really interesting bit is ~/snap/<packagename> | 13:17 |
| anarcat | i'd sure like to keep that profile | 13:17 |
| ogra_ | mv ? | 13:17 |
| anarcat | well whatever | 13:18 |
| mborzecki | ogra_: C.UTF-8 is not in vanilla glibc, but is patched in debian & rhel | 13:18 |
| ogra_ | like you'd do with the mozilla dir | 13:18 |
| ogra_ | mborzecki, so in all relevant distros then :P | 13:18 |
| mborzecki | haha ! | 13:18 |
| diddledan | wait, rhel is "relevant" now? | 13:18 |
| ogra_ | at NYSE it surely is somehow :) | 13:18 |
| ogra_ | ... a little ... | 13:19 |
| anarcat | okay, so mv ~/snap/firefox{,.orig} && firefox still has garbled fonts | 13:19 |
| diddledan | I thought rhel was purely for accountants and lawyers to mark their little tickboxes of compliance | 13:19 |
| anarcat | sigh | 13:19 |
| anarcat | can i rollback to a previous version or something? | 13:19 |
| popey | still updating my debian vm | 13:19 |
| popey | lemme confirm first | 13:19 |
| anarcat | okay | 13:19 |
| diddledan | popey: https://imgs.xkcd.com/comics/update.png | 13:22 |
| popey | dammit, ran out of space | 13:22 |
| anarcat | FWIW, firefox-esr 52 from the stable debian packages doesn't exhibit the same behavior | 13:26 |
| diddledan | well no, it wouldn't, because that's not a snap | 13:26 |
| anarcat | well the problem is not necessarily with the snap | 13:27 |
| anarcat | s/is/was/, now that i made that experiment i guess | 13:27 |
| anarcat | or it's with some quantum shit | 13:27 |
| anarcat | although i'm running the same version on my desktop (although with the upstream tarballs) without problems | 13:27 |
| anarcat | well, 60.0.1 on the desktop, not 60.0-2 | 13:27 |
| anarcat | whatever -2 means in that snap | 13:27 |
| ogra_ | you have both installed at the same time on the same session ? | 13:28 |
| ogra_ | (perhaps thats an issue) | 13:28 |
| diddledan | both _running_ at the same time will be an issue | 13:29 |
| diddledan | firefox reuses an already running instance so if you have it running twice from different places that will lead to weirdness | 13:29 |
| anarcat | i have both installed at the same time on the same machine | 13:30 |
| anarcat | but i do not have both running at once | 13:30 |
| anarcat | i would have expected snap isolation to keep such mixups from happening | 13:30 |
| diddledan | with X11 you can't isolate to that degree | 13:31 |
| anarcat | who said i was running x11? ;) | 13:31 |
| anarcat | (i am, but i don't see how it relates, really) | 13:31 |
| anarcat | firefox doesn't use x11 to talk to existing processes, as far as i know | 13:31 |
| diddledan | X11 is a shared memory system, so if firefox is running externally and inside a snap then they can talk to each other through X11 | 13:32 |
| anarcat | sure, i know that | 13:33 |
| anarcat | but does firefox talk to other ff process over X11? | 13:33 |
| anarcat | i would very much doubt that | 13:33 |
| anarcat | but whatever, that's besides the point | 13:33 |
| anarcat | i started firefox-esr just to confirm the problem didn't happen there | 13:33 |
| anarcat | i stopped it | 13:33 |
| anarcat | so now we can go back to pretending it doesn't exist | 13:33 |
| anarcat | i can remove the files on disk if that makes you feel any better too :p | 13:33 |
| * diddledan wonders how deep the rabbit hole is for popey's debian vm | 13:35 | |
| popey | just rebooted | 13:35 |
| popey | installing firefox rev 85 from stable | 13:36 |
| diddledan | reboot: https://www.youtube.com/watch?v=l8B5dqjsZUs | 13:36 |
| cjwatson | It used to work via X properties, though I can't find any current documentation on how the remote commands stuff works today | 13:36 |
| anarcat | cjwatson: really! | 13:36 |
| anarcat | cjwatson: i would assume it's just a socket or something simple | 13:37 |
| cjwatson | You used to be able to run firefox and have it do stuff to a browser running on another system via X forwarding | 13:37 |
| cjwatson | Whether you still can I have no idea - haven't X-forwarded firefox in many years | 13:37 |
| anarcat | yuck | 13:39 |
| cjwatson | https://hg.mozilla.org/mozilla-central/file/tip/widget/xremoteclient/XRemoteClient.cpp | 13:39 |
| anarcat | sounds nasty :) | 13:39 |
| anarcat | does FF work in wayland at all? | 13:39 |
| cjwatson | There's a d-bus implementation as well | 13:39 |
| cjwatson | Dunno how it chooses which to use | 13:39 |
| cjwatson | I'm running Wayland and Firefox, but I don't know how to tell whether Firefox is using Xwayland | 13:40 |
| anarcat | that's surprisingly hard | 13:40 |
| anarcat | even figuring out if your whole session is wayland is non-intuitive | 13:40 |
| popey | env | grep SESS | 13:40 |
| cjwatson | Ah, you can use xeyes to tell you | 13:40 |
| cjwatson | (It can't follow mouse movements over a native Wayland window) | 13:41 |
| popey | firefox snap works fine here. | 13:41 |
| popey | on debian 9 | 13:41 |
| cjwatson | So Firefox uses Xwayland AFAICS | 13:41 |
| anarcat | cjwatson: yeah, that's the trick i heard | 13:41 |
| anarcat | popey: and that too | 13:41 |
| anarcat | popey: i'm not surprised | 13:41 |
| anarcat | (that it works for you) | 13:41 |
| anarcat | i tell you i'm doomed | 13:41 |
| popey | sorry :( | 13:41 |
| anarcat | i don't even know where to begin to fix those fonts | 13:41 |
| anarcat | i haven't touched that machine in days, it's my travel laptop | 13:42 |
| anarcat | all of a sudden, boom | 13:42 |
| anarcat | and right after i upgrade to 60 | 13:42 |
| anarcat | so back to that question: how do i downgrade? | 13:42 |
| anarcat | or maybe i can try chasing the candidate? | 13:42 |
| * Chipaca ~> school run (slow) | 13:42 | |
| popey | you can switch to any other channel in snap info firefox | 13:42 |
| anarcat | last i changed channels i was told it was bad | 13:42 |
| anarcat | or is devmode a different thing | 13:42 |
| popey | other channels aren't "bad", but if you chose != stable, then you're opting into the risk level that inferrs | 13:43 |
| anarcat | maybe i can try "candidate" - 60.0.1 | 13:43 |
| anarcat | how do i switch channels? | 13:43 |
| cjwatson | snap install --candidate firefox | 13:43 |
| anarcat | snap "firefox" is already installed, see "snap refresh --help" | 13:44 |
| anarcat | i guess i need refresh | 13:44 |
| cjwatson | er sorry yes | 13:44 |
| anarcat | sudo snap refresh --candidate firefox # seems to work | 13:44 |
| anarcat | well | 13:44 |
| anarcat | it downloads anyways, i doubt it will actually fix the issue | 13:44 |
| anarcat | the weird thing is that *some* website can show fonts correctly | 13:44 |
| anarcat | i wonder if i might have a font cache corruption issue somewhere that gets triggered only by firefox | 13:44 |
| anarcat | i had that before, i just don't remember wtf happened | 13:44 |
| anarcat | 60.0.1 no go | 13:46 |
| * anarcat tries sudo dpkg-reconfigure fontconfig fontconfig-config | 13:46 | |
| anarcat | nope | 13:48 |
| anarcat | i can't even imagine how to begin fixing that friggin issue | 13:48 |
| anarcat | any other suggestions? | 13:57 |
| anarcat | maybe i could clear out everything in snap? like uninstall snap and clear out ~/snap? | 13:57 |
| anarcat | er uninstall firefox? | 13:57 |
| anarcat | would that help? | 13:57 |
| anarcat | well well well | 14:00 |
| anarcat | sudo snap remove firefox && sudo snap install firefox # works | 14:00 |
| diddledan | you said you'd done that | 14:00 |
| anarcat | i did that a few days ago yes | 14:00 |
| popey | ahhh | 14:00 |
| popey | awesome | 14:00 |
| popey | good to hear it's fixed | 14:00 |
| anarcat | popey: isn't it? :p | 14:00 |
| popey | :D | 14:01 |
| anarcat | i have still no frigging clue what happened and that was scary as hell but yaaaay | 14:01 |
| anarcat | can't wait for quantum to hit debian packages so i can go back to normal packaging and have someone else to blame, to be honest :p | 14:01 |
| anarcat | i guess i could upgrade to buster already | 14:01 |
| anarcat | anyways | 14:01 |
| anarcat | thanks for the help, popey! | 14:01 |
| popey | :) | 14:01 |
| diddledan | wow, that'll speed up some builds: https://github.com/snapcore/snapcraft/pull/2111 | 14:16 |
| mup | PR snapcraft#2111: repo: rollback to using dpkg-deb for deb extraction <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2111> | 14:16 |
| diddledan | bet that was the problem with the desktop-helpers | 14:16 |
| sergiusens | diddledan: it was | 14:16 |
| diddledan | yey for fixing it :-) | 14:18 |
| willcooke | hi all, my snapd process has been pegged at 100% for about 30 mins now. How can I tell what it's doing? journalctl and syslog dont really tell me anything | 14:19 |
| pedronis | willcooke: are you on edge? | 14:20 |
| willcooke | pedronis, no | 14:20 |
| pedronis | then not sure | 14:20 |
| willcooke | ah | 14:20 |
| diddledan | that sounds wonky | 14:21 |
| willcooke | snap changes tells me it's trying to do something to remmina which I have loaded | 14:21 |
| willcooke | maybe if I quit remmina | 14:21 |
| willcooke | hm, nope | 14:21 |
| willcooke | $ snap changes | 14:21 |
| willcooke | ID Status Spawn Ready Summary | 14:21 |
| willcooke | 309 Doing today at 11:02 BST - Auto-refresh snaps "core", "remmina" | 14:21 |
| diddledan | would be an interesting test to try quitting remmina to see if that clears the blockage - if so then sounds like a bug in snapd for updating snaps that are active | 14:21 |
| popey | This has been brought up on the forum before now. | 14:22 |
| diddledan | aah, it's refreshing core, too.. | 14:22 |
| popey | I think mcpha il brought it up | 14:22 |
| diddledan | mcphail did too | 14:22 |
| diddledan | I don't worry about people getting pings :-p | 14:23 |
| pedronis | willcooke: snap tasks 309 will tell you excatly what is doing | 14:23 |
| * mcphail scrolls back | 14:23 | |
| willcooke | oh, maybe I was running core from edge. | 14:25 |
| pedronis | ah | 14:25 |
| pedronis | we had a bug that we just reverted there | 14:26 |
| mcphail | willcooke: the problem i've had with snap refreshes is the older iteration cannot save state or information after the snap refresh. it may not be relevant to your situation | 14:26 |
| pedronis | willcooke: can you confirm if you had edge? snap list or snap info core | 14:28 |
| willcooke | pedronis, $ snap info core | 14:28 |
| willcooke | name: core | 14:28 |
| willcooke | summary: snapd runtime environment | 14:28 |
| willcooke | publisher: canonical | 14:28 |
| willcooke | contact: snappy-canonical-storeaccount@canonical.com | 14:28 |
| willcooke | license: unknown | 14:28 |
| willcooke | description: | | 14:28 |
| willcooke | The core runtime environment for snapd | 14:28 |
| willcooke | type: core | 14:28 |
| willcooke | snap-id: 99T7MUlRhtI3U0QFgl5mXXESAiSwt776 | 14:28 |
| willcooke | tracking: edge | 14:28 |
| willcooke | refresh-date: today at 15:26 BST | 14:28 |
| willcooke | channels: | 14:28 |
| willcooke | stable: 16-2.32.8 (4650) 90MB - | 14:28 |
| pedronis | yea, tracking edge | 14:28 |
| willcooke | candidate: 16-2.32.8 (4650) 90MB - | 14:28 |
| willcooke | beta: 16-2.32.8 (4650) 90MB - | 14:28 |
| pedronis | so you have edge | 14:28 |
| willcooke | edge: 16-2.32.9+git739.16d2434 (4725) 91MB - | 14:28 |
| willcooke | installed: 16-2.32.9+git739.16d2434 (4725) 91MB core | 14:28 |
| willcooke | I stopped the task and ran it again "manually" | 14:28 |
| willcooke | and now it's happy :) | 14:28 |
| diddledan | pastebinit | 14:29 |
| pedronis | willcooke: ok, yes it was a bug in edge, we reverted the code and are working on a fix | 14:29 |
| willcooke | pedronis, nice one, thanks! | 14:29 |
| willcooke | also I learned something today :) | 14:29 |
| diddledan | say it isn't so?! learning should be outlawed | 14:30 |
| cachio | mvo, hey, it should be great if we could include #5143 as part of 2.33 | 14:33 |
| mup | PR #5143: tests: speed up save/restore snapd state for all-snap systems suring tests execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143> | 14:33 |
| cachio | mvo, if you could take a look that would be great, thanks | 14:33 |
| === chihchun is now known as chihchun_afk | ||
| niemeyer | mvo: Reviewed everything pending for 2.33.. unfortunately all of them have pending issues | 14:48 |
| mvo | cachio: sure, lets add 2.33 | 15:00 |
| * cachio lunch | 15:00 | |
| cachio | mvo, great, thanks | 15:00 |
| mvo | niemeyer: no worries, I can wait until tomorrow and/or cherry-pick the missing PRs | 15:00 |
| mvo | niemeyer: thanks for the review! | 15:00 |
| mvo | cachio: I commented | 15:27 |
| pedronis | pstolowski: have you found the issue with the test? | 15:27 |
| pstolowski | pedronis: nope. i only found out that it hangs in snapmgr.Wait() when looping over tombs and waiting on one of them | 15:29 |
| pstolowski | this is very weird | 15:29 |
| pstolowski | pedronis: and also, it's happening when run in a combination with some tests, but some other do not trigger this. | 15:37 |
| pstolowski | for example, running $ go test -check.v -check.f "mgrsSuite.TestHappyStop|TestUpdateManyW" -> hangs | 15:38 |
| pedronis | it's the download | 15:38 |
| pedronis | that hangs | 15:38 |
| pstolowski | but $ go test -check.v -check.f "mgrsSuite.TestHappyR|TestUpdateManyW" -> doesn't | 15:38 |
| pstolowski | hmm don't we hijack/mock it centrally in these tests? | 15:39 |
| pedronis | I'm looking | 15:40 |
| pedronis | pstolowski: something is not cleaning up I think | 15:42 |
| pstolowski | pedronis: the TestHappyStop* tests (there are 2) are enough to trigger this | 15:44 |
| pedronis | I think I understand what happens | 15:44 |
| pedronis | bit mysterious we didn't hit it before | 15:44 |
| pstolowski | what is that? | 15:45 |
| pedronis | we set a function to override something | 15:45 |
| pedronis | but don't clean it | 15:45 |
| pedronis | I'm just surprised we weren't bitten before | 15:46 |
| pedronis | pstolowski: this fixes it for me: https://pastebin.ubuntu.com/p/9jZRjRh6pc/ | 15:46 |
| pstolowski | \o/ | 15:47 |
| pstolowski | indeed, it does! | 15:47 |
| pstolowski | pedronis: thanks again! | 15:48 |
| pstolowski | pedronis: are you about to eod or can we have a HO to talk about the fix? | 15:53 |
| pedronis | pstolowski: this is the debugging I added btw to find that: https://pastebin.ubuntu.com/p/5P8zrGFjxh/, once you told me it was stuck in wait, first the bit in snapmgr, then taskrunner and when I saw it was dowload, then the bits in managers_test.go itself | 15:53 |
| pedronis | pstolowski: we can have a HO now | 15:54 |
| pstolowski | ok, joining in a sec | 15:55 |
| pstolowski | pedronis: in the standup HO | 15:56 |
| om26er | Which interface shall I use for those errors https://paste.ubuntu.com/p/nFDXWbpgqS/ | 16:42 |
| om26er | jdstrand: ^ | 16:43 |
| om26er | maybe I should try network-bind, lets see. | 16:45 |
| === pstolowski is now known as pstolowski|afk | ||
| om26er | nvm, that worked :) | 16:55 |
| om26er | popey: Hey! So whenever build.snapcraft.io is fixed, I have two tools snap packaging ready. gradle and axel. | 16:58 |
| popey | om26er: awesome | 17:07 |
| Chipaca | I'm so glad I decided to start with the spread tests for the last chunk of snapshots work | 17:11 |
| Chipaca | already found two integration-y issues :-D | 17:11 |
| Chipaca | (comes from all the little changes done to the PRs …) | 17:11 |
| === jkridner|pd is now known as jkridner | ||
| jkridner | hi ogra. | 17:29 |
| jkridner | er, ogra_. | 17:29 |
| jkridner | ogra_: anything newer than http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf-bbb.img.xz to start with? | 17:30 |
| jkridner | ogra_: should we get an updated kernel/bootloader from rcn-ee. | 17:30 |
| jkridner | ogra_: fyi, we've been looking into Ubuntu more seriously due to ROS. | 17:33 |
| jkridner | ogra_: the sales guys have all changed, so no one is calling on me anymore. :-) | 17:33 |
| kyrofa | jkridner, you're using a beaglebone black? | 17:36 |
| jkridner | and Blue and PocketBeagle. | 17:37 |
| jkridner | all supported by the same image. | 17:37 |
| jkridner | Blue is Black+RoboticsCape | 17:37 |
| jkridner | so, ROS is huge. We need an out-of-box experience for ROS. Debian is still a challenge in that regard. | 17:38 |
| kyrofa | Ah, okay. None are officially supported, I don't think. Ubuntu Core 15.04 is very old, and not recommended. ogra_ will know if there's a community port for it | 17:38 |
| * jkridner won't be around long and will check back in later. | 17:38 | |
| jkridner | unfortunately, I'm not on this channel via Resin.io. | 17:39 |
| kyrofa | jkridner, oh yes, I'm very familiar with ROS :) | 17:39 |
| jkridner | should we just go with Bionic and not Snappy Ubuntu Core? | 17:39 |
| kyrofa | When you say "out of the box" you mean the experience you provide to end users? | 17:39 |
| jkridner | just do a minimal Bionic to run snaps and ROS? | 17:39 |
| jkridner | kyrofa: exactly. | 17:39 |
| jkridner | where the community how-tos "just work". | 17:39 |
| ogra_ | jkridner, i have unofficial images at http://people.canonical.com/~ogra/snappy/all-snaps/daily-stable/current/ | 17:40 |
| jkridner | vs. a bunch of semi-maintained repos of our own (because we don't use ROS everyday). | 17:40 |
| kyrofa | There we go, that's the port of ubuntu core 16.04 ^ | 17:41 |
| jkridner | ogra_: thanks! | 17:41 |
| ogra_ | jkridner, and kyrofa is our ROS specialist ;) | 17:41 |
| jkridner | ah! | 17:41 |
| jkridner | kyrofa: does moving to Bionic for ROS support make the best sense? | 17:42 |
| kyrofa | jkridner, what ROS version are you using? | 17:42 |
| jkridner | then, I just need a sales guy to talk to me about what the impact of shipping Ubuntu on our boards would be. | 17:42 |
| jkridner | kyrofa: I want the "latest". | 17:42 |
| jkridner | kyrofa: this is mostly in support of universities. | 17:43 |
| kyrofa | Yeah, you mentioned you were talking to sales, but the communication has been less than stellar. Can you PM me your contact details so I can fix that? | 17:43 |
| * ogra_ would rather go with the "most widely used" ;) | 17:43 | |
| kyrofa | jkridner, indeed, I agree with ogra, you probably want the LTS | 17:43 |
| jkridner | kyrofa: you can find it on bbb.io/about, but I'll PM a direct phone # | 17:43 |
| jdstrand | om26er: network-bind, yes. I suggest you take a look at 'sudo snap install snappy-debug ; sudo snappy-debug security' | 17:44 |
| jdstrand | :) | 17:44 |
| jkridner | ogra_: i think we'd rather be close to the development tip for fixing issues. | 17:44 |
| jkridner | ogra_: stable is nice, but a bit against our methodology. | 17:44 |
| ogra_ | well, there is hope that a ROS-LTS version wont need too many of them :) | 17:45 |
| kyrofa | jkridner, alright, kinetic is the current LTS, with Lunar being the most recent release | 17:45 |
| kyrofa | Both of which run on 16.04 | 17:45 |
| jkridner | is that really where we should be? | 17:46 |
| jkridner | :-( | 17:46 |
| kyrofa | The next release will only be 18.04 | 17:46 |
| kyrofa | It's due any day | 17:46 |
| kyrofa | But there is no ubuntu core based on 18.04 just yet | 17:46 |
| ogra_ | regarding core i'd clearly go with core 16 which in turn means when you build your ROS snaps you'll also do it on top of 16.04 | 17:47 |
| ogra_ | core 18 might/will/should be around by fall ... but even then it will be young (core is rolling ... but on top of a picked base ... 16 ... 18 etc ... ) | 17:48 |
| ogra_ | and the majority of snaps in the store will still be based on 16 for a while ... | 17:49 |
| ogra_ | (18 will allow you to run core16 snaps but that comes indeed with a cost ... since you need the base installed alongside) | 17:50 |
| * ogra_ -> afk for a while | 17:50 | |
| jkridner | :-| | 18:00 |
| * jkridner has to think | 18:00 | |
| mup | PR snapd#5194 opened: interfaces/apparmor: add 'mediate_deleted' profile flag for all snaps <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5194> | 19:06 |
| panter_ | Are snaps basically 'devices' that get mounted to the filesystem? | 19:51 |
| kyrofa | panter_, essentially. They're squashfs images | 19:52 |
| panter_ | kyrofa: Is there any way to change files in this squashfs image? | 20:03 |
| kyrofa | panter_, squashfs is by definition read-only. You can always unsquash and re-squash an image after modifations, but whether or not that works for you depends on your goal | 20:06 |
| kyrofa | If you're wanting to modify a snap, you're out of luck if you also want updates from the store etc | 20:07 |
| panter_ | kyrofa: but how would you be able to unsquash it. I only find a directory with files not a .squashfs file? btw it is no problem that it gets overwritten after updates | 20:10 |
| panter_ | Sorry, I found it in /var/lib/snapd/snaps | 20:12 |
| mup | PR snapcraft#2144 opened: lifecycle: automatically stage dependencies <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2144> | 20:29 |
| panter_ | I have created a snap without any .desktop files in it. However I still see an icon on between my applications. Where does it come from? | 20:31 |
| bashfulrobot | panter_: Do you by chance have a deb version of the app installed? | 20:34 |
| panter_ | bashfulrobot: no | 20:34 |
| bashfulrobot | Or a straggler desktop file in say `/usr/share/applications`? | 20:35 |
| panter_ | no | 20:35 |
| bashfulrobot | In the past - that is how I have had this issue | 20:35 |
| bashfulrobot | I'm not sure otherwise | 20:35 |
| panter_ | find is running currently so I guess I will know the issue after the command has finished | 20:35 |
| panter_ | Yeah, there is another .desktop file in /var/lib/snapd/desktop/applications. So I guess when you install/update a snap it gets unsquashfs'ed and then the .desktop file gets placed in another directory, so the file in the read-only mounted part isn't really important | 20:37 |
| panter_ | Thanks for all the help! | 20:38 |
| mup | PR snapd#5102 closed: tests: new utility to save and restore the snap state <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5102> | 20:39 |
| mup | PR snapd#5016 closed: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5016> | 20:41 |
| jdstrand | niemeyer: hey, I've been keeping https://github.com/snapcore/snapd/wiki/Interfaces up to date, but the wiki is obsoleted. Seems like the page should be moved to 'doc' category in the forum? | 20:49 |
| jdstrand | niemeyer: shall I do that? | 20:49 |
| niemeyer | jdstrand: There's some discussion in the forum on that, in that thread under the new doc site | 20:52 |
| niemeyer | jdstrand: I'd like to migrate, but would like to make it look nicer at the same time | 20:53 |
| jdstrand | niemeyer: if you have an idea on how to make it nicer, I could do that. I do like the information it conveys so hopefully the new format will not be lossy | 20:55 |
| jdstrand | niemeyer: I can also wait and keep updating the old one for now | 20:55 |
| jdstrand | I don't feel strongly about migrating *right now*. just thought I'd touch base | 20:56 |
| bashfulrobot | panter_ glad I could help! | 21:10 |
| AuroraAvenue | not sure how to build this from source in solus ? & is it on github ? https://launchpad.net/audio-recorder | 21:21 |
| AuroraAvenue | https://imgur.com/5c1JwVX | 21:25 |
| bashfulrobot | in Solus? | 21:32 |
| bashfulrobot | Suspect might need to build in a LXD container or something. I mean snapcraft is a snap, but have no experience using it htere. | 21:33 |
| bashfulrobot | (on Solus) | 21:33 |
| bashfulrobot | If I was going to try, would snap install LXD. | 21:34 |
| bashfulrobot | Then build in a 16.04 container | 21:34 |
| AuroraAvenue | right, but apart fromn creating a snap.... how do I build from source ? | 21:34 |
| bashfulrobot | ohhh - I would say that is out of scope in the snap package channel. ha ha. But if I hazard to guess? You would need the required build tools installed and then have to satisfy the dependencies on the system. Either through the package manager, or if not available there, build those forst. | 21:35 |
| bashfulrobot | You might have vmore luck in the Solus IRC channels | 21:36 |
| bashfulrobot | #Solus on freenode I beleive | 21:36 |
| bashfulrobot | Sorry - originally thought you meant how to build a snap on Solus | 21:36 |
| AuroraAvenue | but I don't want to give them my ip address , though - they are hackers, lest I forget. ... | 21:37 |
| bashfulrobot | huh? | 21:37 |
| bashfulrobot | Why do you sy that??? | 21:37 |
| AuroraAvenue | I trust this channel for basic info links though :) | 21:37 |
| AuroraAvenue | snappy is cool | 21:37 |
| bashfulrobot | I mean if you didnlt trust them - I mean why are you running Solus? They already could own the system through the pakaging, etc. | 21:37 |
| bashfulrobot | I mean - they write the software. | 21:38 |
| AuroraAvenue | Well - that's lost in the system - IRC ip address have more eyes on them. | 21:38 |
| AuroraAvenue | 'cos there's more than 1 user in da room. | 21:39 |
| bashfulrobot | I mean you could also ask on the #solus-dev channel. Or on their forums. All official. | 21:40 |
| AuroraAvenue | Basically I know that snappy channel cannot afford a basic response (& I shall go now). But it would have been nice to build a linux app from source. Not relaying simple info. like that seems stupid to me. It's like there are wiki's for this stuff or something !!!!? | 21:42 |
| AuroraAvenue | & where's the bot, even, for such a response - no-where ! | 21:43 |
| AuroraAvenue | https://answers.launchpad.net/audio-recorder/+question/269584 | 21:47 |
| bashfulrobot | Well it would be the upstream author who should provide those instructions. | 21:50 |
| bashfulrobot | welp - he is gone. | 21:50 |
| === JanC_ is now known as JanC | ||
| kyrofa | bashfulrobot, my usual go-to is to start pretending I'm a windows dev and don't know anything | 21:58 |
| bashfulrobot | kyrofa: ha ha ha. Does that happen in here often? | 21:59 |
| kyrofa | bashfulrobot, nah | 21:59 |
| bashfulrobot | kyrofa: that person was gold. from the "hackers" to the linked ancient single question on the app. | 22:01 |
| kyrofa | I'm kinda sad that I'm not a hacker now | 22:07 |
| bashfulrobot | kyrofa: Join Solus (apparently)? Hacker status restored! | 22:09 |
| niemeyer | jdstrand: I have some vague plans about how to split it at least.. I did write some notes in that thread I think.. but for actually making it look nice, I was planning on just experimenting | 22:45 |
| niemeyer | jdstrand: If you'd like to push that forward, I'd love your help on that | 22:45 |
| mwhudson | how can i tell if a snap depends on a content provider? | 22:51 |
| mwhudson | i don't see anything in /v2/find?name= about it | 22:52 |
| mwhudson | does it have to be fished out of meta/snap.yaml? | 22:53 |
| mup | PR snapcraft#2145 opened: lifecycle: automatically clean dirty steps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2145> | 22:53 |
| jdstrand | niemeyer: can you give me a pointer to the topic you are referring to? I'm having trouble finding it. perhaps I can carve out some time for that | 23:02 |
| jdstrand | heading off to dinner now-- I'll read backscroll (like always) | 23:03 |
| niemeyer | jdstrand: I was thinking of https://forum.snapcraft.io/t/experimental-documentation-site/3806/5 | 23:08 |
| niemeyer | jdstrand: But maybe I'm misremembering.. the detailing there is for the daemon api | 23:08 |
| niemeyer | mwhudson: No, we have interface details in the API too | 23:08 |
| niemeyer | mwhudson: We want to improve those a bit, but if you look at the implementation of the "interface" (singular) command, for example, you might get some ideas | 23:09 |
| mwhudson | niemeyer: ok, i'll have a look | 23:10 |
| mwhudson | thanks | 23:10 |
| niemeyer | jdstrand: Let's meet tomorrow.. I'm sure we can quickly brainstorm some ideas for how we want the page to look | 23:10 |
| mwhudson | niemeyer: i mean for a snap not yet installed btw | 23:10 |
| mwhudson | niemeyer: i'll make a forum post with more details i think | 23:10 |
| niemeyer | mwhudson: Oh | 23:10 |
| niemeyer | mwhudson: That might be trickier | 23:10 |
| * mwhudson afk for a few | 23:10 | |
| mwhudson | niemeyer: https://forum.snapcraft.io/t/seeding-snaps-that-plug-the-content-interface/5579 | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
