[15:18] <mbruzek> Hello bzr folks.  I am working on a system that has limited network access.
[15:18] <mbruzek> I got this error ssh: connect to host bazaar.launchpad.net port 22: Connection timed out
[15:18] <mbruzek> when trying to run this command. bzr push lp:~mbruzek/charms/bundles/ceph/local
[15:19] <mbruzek> So I tried a different approach.
[15:19] <mbruzek> $ bzr push https://launchpad.net/~mbruzek/charms/bundles/ceph/local
[15:19] <mbruzek> bzr: ERROR: Transport operation not possible: http does not support mkdir()
[15:19] <mbruzek> Can someone help me with this problem?
[15:20] <jelmer> mbruzek: you need ssh access to launchpad to push
[15:21] <mbruzek> jelmer, can I make the dirs that I need on http://launchpad.net and then push using ssh?
[15:21] <jelmer> mbruzek: I don't see how that would help?
[15:21] <jelmer> "bzr push" would take care of creating the branch
[15:25] <mbruzek> ack thanks jelmer


[00:53] <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>
[02:47] <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:48] <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>
[03:10] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[03:11] <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>
[04:46] <mup> PR snapd#5190 opened: tests: new parameter for the journalctl rate limit <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5190>
[05:05] <mborzecki> morning
[05:45] <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>
[06:00] <mvo> mborzecki: hey, if you don't mind I look at the spread test for the symlink PR
[06:01] <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:02] <mvo> mborzecki: thanks, it pretty trivial, I will push something in a sec. got a bit of ocd sometimes, sorry
[06:03] <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:07] <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:08] <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:09] <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:11] <mborzecki> mvo: no, i don't think so
[06:19] <mvo> mborzecki: ok, I will do that in a bit then
[06:26] <jamesh> mvo: could you approve rev 2 of test-snapd-eds?  It's the same as rev 1 but built for i386
[06:27] <mvo> jamesh: sure, let me do this now
[06:27] <jamesh> thank you
[06:32] <mborzecki> mvo: echo tests/main/snap-core-symlinks/task.yaml >> tests/unit/spread-shellcheck/must
[06:34] <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:41] <mvo> mborzecki: shellcheck> aha, right, let me add this
[06:41] <mvo> mborzecki: oh? master broken?
[06:42] <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:45] <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?
[07:14] <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:18] <pstolowski> mvo: we want to target master with this revert right?
[07:20] <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:39] <mborzecki> pstolowski: hey
[07:39] <pstolowski> o/
[07:55] <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:58] <mborzecki> mvo: pushed :)
[08:00] <mvo> mborzecki: heh, thank you
[08:10] <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:11] <mvo> pstolowski: nice
[08:11] <pstolowski> mvo: no, it's depressing :(. but good we found it early enough
[08:12] <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:13] <pstolowski> mvo: right
[08:15]  * mvo hugs mborzecki for finding another real bugs with the spread-shellcheck
[08:32] <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:33] <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:34] <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:37] <pstolowski> Chipaca: in other words, yes, most likely same problem. we thought it wouldn't happen on autoconnect
[08:38] <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:39] <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:40] <pedronis> then it's related but a different bug
[08:41] <pedronis> Chipaca: pstolowski: seeding it's always serial
[08:42] <Chipaca> pedronis: even when one snap has content interfaces and such?
[08:43] <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:44] <Chipaca> pedronis: what's 'that' in this context?
[08:44] <Chipaca> snapd's performance with a lot of tasks is very very bad :-(
[08:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <Chipaca> mvo: (without tests)
[08:53] <mvo> pedronis: I think so too
[08:54] <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:55] <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:56] <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:57] <Chipaca> there's a list of caveats written down somewhere :-)
[08:59] <Chipaca> mvo: did you see my comment about symlinking snapd in core18?
[08:59] <mvo> Chipaca: no, let me look
[09:00] <mvo> Chipaca: in the forum?
[09:09] <Chipaca> pstolowski: is there a way to unstick my snapd from the megatasks bug?
[09:12] <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:13] <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:14] <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:15] <pedronis> Chipaca: also probably easier with split out snapd and epochs
[09:15] <Chipaca> pedronis: buaah
[09:16] <pstolowski> mvo: right. but i wonder how hard is it to get out of the 'broken' state and regain control
[09:17] <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:18] <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:19] <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:23] <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:25] <Chipaca> all these prepare-hook-blah tasks are killing it :-(
[09:26] <pedronis> ?
[09:27] <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:28] <pedronis> with core
[09:28] <pedronis> like network I suppose
[09:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:39] <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:40] <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:41] <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:42] <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:44] <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:45] <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:46] <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:47] <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:48] <zyga> Also no longer ill
[09:48] <zyga> Long way home
[09:51] <Chipaca> zyga: https://www.youtube.com/watch?v=qmWC5dGVvH4
[09:54] <mup> PR snapd#5192 opened: testutil: import check.v1 differently to workaround gccgo error <Created by mvo5> <https://github.com/snapcore/snapd/pull/5192>
[10:08] <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:16] <mvo> Chipaca: a new core in edge with the reverted reconnect is available now
[10:17] <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:21] <pedronis> pstolowski: well, if it is still doing, then is not done
[10:22] <pedronis> pstolowski: do you have a branch I can play with , with this and still the reconnect code ?
[10:25] <pedronis> pstolowski: lunch here, let me know
[10:34] <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:40] <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:54] <pedronis> pstolowski: is there already a different change in that branch?
[10:55] <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
[11:03] <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:04] <pedronis> it gets stuck
[11:04] <pstolowski> ineed i see it
[11:05] <pedronis> it doesn't print anything either though :/
[11:08] <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:09] <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:10] <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:12] <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:13] <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:14] <pedronis> let me see
[11:15] <pedronis> it's probably easyish
[11:19] <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:20] <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:25] <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:26] <pstolowski> pedronis: it didn't. and the tasks are waiting for restart
[11:28] <pstolowski> and i see we mock restarting in tests.. trying
[11:29] <pedronis> ah
[11:29] <pedronis> yea, because core
[11:30] <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:31] <pstolowski> pedronis: thank you very much!
[11:37] <popeycore> Wimpress: yup, my session just died when i snap installed something (again)
[11:39] <mvo> mborzecki: nice!
[11:39] <pedronis> pstolowski: let me know if you want to discuss a fix
[11:40] <pstolowski> pedronis: thanks. i need to figure out what makes the test hang when running entire suite, then will work on the fix
[11:41] <pedronis> ok
[11:49]  * cachio afk
[11:51] <mup> PR snapd#5193 opened: spread-shellcheck: port to python <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5193>
[11:52] <mup> PR snapd#5185 closed: tests: shellchecks part 2 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5185>
[11:53] <pedronis> mvo: do you remember why we  used a task adding more tasks and didn't compute bases/default-providers  when constructing the change?
[12:07] <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:08] <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:19] <pedronis> mvo: the context , is me thinking what we can simplify about conflicts etc
[12:20] <mvo> pedronis: right, this is certainly an interessting area to simplify things
[12:23] <pedronis> mvo: I'm also thinking this because we need this kind of static detection for prepare-image
[12:23] <pedronis> "static"
[12:27]  * mvo nods
[12:29] <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:30] <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:35] <mvo> mborzecki: yes
[12:36] <mup> PR snapd#5134 closed: Shrink image generated with snap prepare <Created by kubiko> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5134>
[13:00] <anarcat> so remember how i came here the other day trying to fix the "devmode" off of firefox?
[13:00] <anarcat> i did
[13:01] <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:04] <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:05] <anarcat> diddledan: no go
[13:07] <diddledan> hmm
[13:07]  * ogra_ wonders what you mean by "fix the "devmode" off of firefox"
[13:08] <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:09] <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:10] <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:11] <ogra_> but anyway ... "snap version" ?
[13:11] <anarcat> snap version: http://paste.debian.net/1026157/
[13:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:22] <diddledan> popey: https://imgs.xkcd.com/comics/update.png
[13:22] <popey> dammit, ran out of space
[13:26] <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:27] <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:28] <ogra_> you have both installed at the same time on the same session ?
[13:28] <ogra_> (perhaps thats an issue)
[13:29] <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:30] <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:31] <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:32] <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:33] <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:35]  * diddledan wonders how deep the rabbit hole is for popey's debian vm
[13:35] <popey> just rebooted
[13:36] <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:37] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:46] <anarcat> 60.0.1 no go
[13:46]  * anarcat tries sudo dpkg-reconfigure fontconfig fontconfig-config
[13:48] <anarcat> nope
[13:48] <anarcat> i can't even imagine how to begin fixing that friggin issue
[13:57] <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?
[14:00] <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:01] <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:16] <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:18] <diddledan> yey for fixing it :-)
[14:19] <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:20] <pedronis> willcooke: are you on edge?
[14:20] <willcooke> pedronis, no
[14:20] <pedronis> then not sure
[14:20] <willcooke> ah
[14:21] <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:22] <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:23] <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:25] <willcooke> oh, maybe I was running core from edge.
[14:25] <pedronis> ah
[14:26] <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:28] <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<EMAIL_ADDRESS>[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:29] <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:30] <diddledan> say it isn't so?! learning should be outlawed
[14:33] <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:48] <niemeyer> mvo: Reviewed everything pending for 2.33.. unfortunately all of them have pending issues
[15:00] <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:27] <mvo> cachio: I commented
[15:27] <pedronis> pstolowski: have you found the issue with the test?
[15:29] <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:37] <pstolowski> pedronis: and also, it's happening when run in a combination with some tests, but some other do not trigger this.
[15:38] <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:39] <pstolowski> hmm don't we hijack/mock it centrally in these tests?
[15:40] <pedronis> I'm looking
[15:42] <pedronis> pstolowski: something is not cleaning up I think
[15:44] <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:45] <pstolowski> what is that?
[15:45] <pedronis> we set a function to override something
[15:45] <pedronis> but don't clean it
[15:46] <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:47] <pstolowski> \o/
[15:47] <pstolowski> indeed, it does!
[15:48] <pstolowski> pedronis: thanks again!
[15:53] <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:54] <pedronis> pstolowski: we can have a HO now
[15:55] <pstolowski> ok, joining in a sec
[15:56] <pstolowski> pedronis: in the standup HO
[16:42] <om26er> Which interface shall I use for those errors https://paste.ubuntu.com/p/nFDXWbpgqS/
[16:43] <om26er> jdstrand: ^
[16:45] <om26er> maybe I should try network-bind, lets see.
[16:55] <om26er> nvm, that worked :)
[16:58] <om26er> popey: Hey! So whenever build.snapcraft.io is fixed, I have two tools snap packaging ready. gradle and axel.
[17:07] <popey> om26er: awesome
[17:11] <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:29] <jkridner> hi ogra.
[17:29] <jkridner> er, ogra_.
[17:30] <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:33] <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:36] <kyrofa> jkridner, you're using a beaglebone black?
[17:37] <jkridner> and Blue and PocketBeagle.
[17:37] <jkridner> all supported by the same image.
[17:37] <jkridner> Blue is Black+RoboticsCape
[17:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <ogra_> and the majority of snaps in the store will still be based on 16 for a while ...
[17:50] <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
[18:00] <jkridner> :-|
[18:00]  * jkridner has to think
[19:06] <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:51] <panter_> Are snaps basically 'devices' that get mounted to the filesystem?
[19:52] <kyrofa> panter_, essentially. They're squashfs images
[20:03] <panter_> kyrofa: Is there any way to change files in this squashfs image?
[20:06] <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:07] <kyrofa> If you're wanting to modify a snap, you're out of luck if you also want updates from the store etc
[20:10] <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:12] <panter_> Sorry, I found it in /var/lib/snapd/snaps
[20:29] <mup> PR snapcraft#2144 opened: lifecycle: automatically stage dependencies <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2144>
[20:31] <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:34] <bashfulrobot> panter_: Do you by chance have a deb version of the app installed?
[20:34] <panter_> bashfulrobot: no
[20:35] <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:37] <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:38] <panter_> Thanks for all the help!
[20:39] <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:41] <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:49] <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:52] <niemeyer> jdstrand: There's some discussion in the forum on that, in that thread under the new doc site
[20:53] <niemeyer> jdstrand: I'd like to migrate, but would like to make it look nicer at the same time
[20:55] <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:56] <jdstrand> I don't feel strongly about migrating *right now*. just thought I'd touch base
[21:10] <bashfulrobot> panter_ glad I  could help!
[21:21] <AuroraAvenue> not sure how to build this from source in solus ? & is it on github ? https://launchpad.net/audio-recorder
[21:25] <AuroraAvenue> https://imgur.com/5c1JwVX
[21:32] <bashfulrobot> in Solus?
[21:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <AuroraAvenue> 'cos there's more than 1 user in da room.
[21:40] <bashfulrobot> I mean you could also ask on the #solus-dev channel. Or on their forums. All official.
[21:42] <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.  It's like there are wiki's for this stuff or something !!!!?
[21:43] <AuroraAvenue> & where's the bot, even, for such a response - no-where !
[21:47] <AuroraAvenue> https://answers.launchpad.net/audio-recorder/+question/269584
[21:50] <bashfulrobot> Well it would be the upstream author who should provide those instructions.
[21:50] <bashfulrobot> welp - he is gone.
[21:58] <kyrofa> bashfulrobot, my usual go-to is to start pretending I'm a windows dev and don't know anything
[21:59] <bashfulrobot> kyrofa: ha ha ha. Does that happen in here often?
[21:59] <kyrofa> bashfulrobot, nah
[22:01] <bashfulrobot> kyrofa: that person was gold. from the "hackers" to the linked ancient single question on the app.
[22:07] <kyrofa> I'm kinda sad that I'm not a hacker now
[22:09] <bashfulrobot> kyrofa: Join Solus (apparently)? Hacker status restored!
[22:45] <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:51] <mwhudson> how can i tell if a snap depends on a content provider?
[22:52] <mwhudson> i don't see anything in /v2/find?name= about it
[22:53] <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>
[23:02] <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:03] <jdstrand> heading off to dinner now-- I'll read backscroll (like always)
[23:08] <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:09] <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:10] <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:31] <mwhudson> niemeyer: https://forum.snapcraft.io/t/seeding-snaps-that-plug-the-content-interface/5579


[11:26] <ev> cjwatson: my current thought for measuring installation success (which I'm going to post to ubuntu-devel by the end of the day) is taking a hash of the system uuid out of the dmi table, then sending that twice to an ubuntu server.  Once when the user has connected to the Internet, and again when the install completes.
[11:26] <ev> The pair would constitute a successful install
[11:26] <ev> sound reasonable, or do you think there's a better bit of unique, but ultimately anonymous, data?
[11:28] <ev> not sure if that would have less collisions than a certain number of bytes from /dev/urandom
[11:28] <cjwatson> maybe we could hash that together with something unique generated by the installer, so that it measures successful installations rather than successful users IYSWIM
[11:28] <cjwatson> s/users/systems/
[11:29] <ev> ah, a good point
[11:30] <cjwatson> in fact, it might be better to *just* use something unique generated by the installer; that should be more anonymous and we don't really gain anything by using the system uuid here
[11:30] <ev> how about a GUID as generated by uuidgen?
[11:30] <cjwatson> yeah, that would be fine
[11:30] <ev> awesome, thanks
[11:30] <cjwatson> install completes - before or after reboot?
[11:30] <cjwatson> maybe both
[11:31] <ev> yes, both would be good
[11:31] <cjwatson> I think this also needs a documented way to turn it off
[11:31] <ev> GUID> hm, though we have no way of potentially filtering out the user hitting cancel
[11:31] <ev> documentation> absolutely
[11:33] <cjwatson> urgh, livecd-rootfs doesn't work on a natty host system because of upstart chroot sessions plus a couple of missing rebuilds for bug 690640
[11:33] <ubot2> Launchpad bug 690640 in debhelper "dh_installinit upstart support start a job in postinst script regardless of previous status" [High,Fix released] https://launchpad.net/bugs/690640
[11:34] <ev> would an item in gfxboot to disable it be okay by you? I'm weary of shoving extra knobs in the installer that the vast majority of people wont care about.
[11:34] <ev> ouch
[11:36] <cjwatson> I don't really feel good about more items in gfxboot
[11:36] <ev> preseed?
[11:36] <cjwatson> though I also don't think it should be a *UI* knob in the installer
[11:36] <cjwatson> preseed would be OK; a lot of the audience for never-phone-home will be corporates
[11:36] <ev> wonderful
[11:44] <ev> wondering aloud if it makes sense to include some additional metadata, like the ubiquity version and the livecd build date
[11:44] <ev> but perhaps that can be proposed at a later date
[11:45] <ev> to not weigh down the initial proposal
[11:47] <cjwatson> in that case just make sure the comms method can allow for that
[12:01] <ev> indeed
[16:39] <ev> cjwatson: could you raise https://rt.admin.canonical.com/Ticket/Display.html?id=40560 in your next meeting with IS?
[16:40] <ev> I suspect you'll have better luck in that venue than me asking in #is
[16:40] <davmor2> ev: did you make it so millbank in the end
[16:41] <ev> davmor2: I was making excellent time home, then I hit Feltham where I was presented with a 15 minute wait for a train.
[16:41] <ev> The horror.
[16:42] <ev> Was nearly tempted to get a cab, but sucked it up, and made it home by 10ish.
[16:42] <ev> oh, you're referring to today's escapades
[16:42] <ev> yes, and to my delight the kitchen has been stocked with various treats people brought back from Hungary
[16:45] <davmor2> ev: I landed at bhx legged it to the bagging area bag was 5th woohoo ran to the air shuttle had to wait there, legged it to the train and then had to wait 10 minutes for the train to turn up :D
[16:47] <ev> nice
[16:47] <ev> Iris for the win. There was a massive queue at passport control.
[16:53] <cjwatson> ev: Victor's doing the IS liaison now
[16:53] <ev> Is he already aware of this RT, to your knowledge?
[16:53] <cjwatson> I don't know, so assume not
[16:53] <ev> :)
[16:53] <ev> I'll talk to him, thanks
[17:00] <ev> (apparently it's Hugh Blemmings' job now)
[17:02] <cjwatson> ah
[17:03] <cjwatson> didn't take him long to delegate that :)
[17:03] <davmor2> cjwatson: isn't that the art of good management
[17:04] <cjwatson> yes, that's why I was never a good manager
[17:05] <davmor2> cjwatson: Oh I thought you were no good cause you always had that "OH! code......hmmmmm....drool....hmmmm" homer simpsonesque way about you ;)
[17:08] <cjwatson> well, there was that
[17:26] <ev> :)


[01:20] <andresmujica> hey
[01:21] <andresmujica> anyone knows about an iwl3945 slow throughput regression?
[01:21] <andresmujica> i mean a bug reporting that?
[01:27] <andresmujica> bug #288948
[01:27] <andresmujica> but downloading.
[01:27] <andresmujica> wall actually i haven't tested uploading..
[01:28] <andresmujica> but it seems the issue is solved by this..
[01:28] <andresmujica> commit
[01:28] <andresmujica> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=2768672e7a3d1c427f436b0a91c942c2732dc320
[01:34] <andresmujica> yeap. it seems to be that issue.
[01:34] <andresmujica> ohh well, i'll triage that bugs tomorrow..
[01:40] <andresmujica> rhel-5.2-server-x86_64-dvd.iso                       100% 3442MB 452.7KB/s 2:09:46
[01:41] <andresmujica> with 54Mbps wlan
[03:22] <duanedesign> I have been working on bug #312873 I directed him to a Hotkeys/Troubleshooting. He got halfway through it and got stuck with the input-events command. Anyway I was wondering if someone could look at the info he did provide to see if there is enough there to assign a package. I noticed when he ran lshal it does not show input.keymap. Any help is appreciated.
[05:26] <rww> Hi everyone! Someone in #ubuntu mentioned https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/313353 , so I triaged it and reported it upstream. Can someone check if I did it right, since this is my first time?
[06:02] <Ryan52>  /g 19
[06:22] <rww> Anyone? It'd be nice if someone could give bug 313353 a quick look to make sure I reported it upstream properly...
[06:28] <crimsun> rww: looks good.
[06:28] <rww> crimsun: thanks :)
[08:09] <duanedesign> Bug #311415 could someone please take a look at this I think it needs to br set too 'wishlist'
[11:24] <bmhm> Hello. I got an issue with mplayer. Regardless of the version I use (Ibex, Medibuntu etc.) I got an segfault immediatly.
[12:34] <ashiswin> hello
[13:52] <bddebian> Boo
[14:40] <penguin42> hi; I've got a bug (bug 311249) that I filed that I reckon is a trivially simple performance speed up for the Human theme - but it does need others to eye it and see if it makes sense
[18:30] <MrKanister> I am unsure which is the right package for bug #240933. gnome-control-center is definitly wrong I think. The reporter suggests "gtk" which is a possibility
[18:37] <Nikson21> hi
[18:37] <Nikson21> When i first logged in after ubuntu install
[18:37] <Nikson21> it didn't
[18:38] <Nikson21> recognize
[18:38] <Nikson21> my video card
[18:38] <Nikson21> at all i had
[18:38] <Nikson21> to use my old
[18:38] <Nikson21> backup of drivers
[18:38] <Nikson21> because the new ones
[18:38] <Nikson21> wanted to work
[18:38] <Nikson21> sorry for my bad english
[18:39] <Nikson21> my video card
[18:39] <Nikson21> is Nvidia 8400 gs
[18:40] <Elbrus> Nikson21: did you try to see launchpad if somebody else filled the same bug? If not, file a bug there.
[18:40] <Rocket2DMn> Nikson21, this isn't a support channel, you should try #ubuntu
[18:41] <Nikson21> i want to help
[18:41] <Nikson21> if this is a bug
[18:41] <Nikson21> witch package should i point
[18:43] <Elbrus> Nikson21: I am not completely sure, but maybe linux-restricted-modules? what version of Ubuntu do you use?
[18:43] <Nikson21> 9.04
[18:43] <Nikson21> the alpha
[18:43] <Nikson21> version
[18:44] <Elbrus> nvidia-graphics-drivers-177 ?
[18:45] <Nikson21> yes
[18:45] <Nikson21> i had to use my backup of the same driver...
[18:45] <Nikson21> because the new ones would not work
[18:48] <penguin42> There seems to be an nvidia-glx package (with various version numbers) - I'd probably file it against that?
[18:49] <maco_> uh hang on
[18:49] <maco_> has nvidia even released a package to replace that one yet?
[18:50] <maco_> because the reason it doesnt exist is that we're waiting for nvidia to create a new driver that works with the new X
[18:50] <maco_> Nikson21, penguin42, Elbrus ^
[18:50]  * penguin42 doesn't know - I don't use Nvidia stuff
[18:51] <Nikson21> but i use the same 177 driver
[18:51] <Nikson21> but my backup from
[18:51] <Nikson21> the old kernel
[18:51] <penguin42> Nikson21: Please use longer lines - you don't need to hit return so often!
[18:51] <maco_> you can use an old version of Xorg with the old nvidia driver just fine
[18:52]  * Elbrus does not really now about drivers, just used some common sense.
[18:52] <Nikson21> sorry
[18:53] <maco_> i saw a new ati come out today
[18:53] <maco_> er...oh wait darn the binary ati is called fglrx, nevermind
[18:53]  * penguin42 wonders if it's better or worse....
[18:53] <maco_> so yeah, neither ati nor nvidia has caught up to the new X yet
[18:55] <Nikson21> so this problem will be solved in the future
[18:55] <Nikson21> This is good :)
[18:55] <maco_> whenever ati and nvidia get around to it
[18:56] <penguin42> maco_: When did the X interface change?
[19:01] <maco_> penguin42: early-to-mid december
[19:02] <duanedesign> Nikson21: you might want to try the new nvidia 180.18 beta.
[19:02] <Nikson21> ok
[19:02] <Nikson21> 10
[19:02] <Nikson21> 10x
[19:24] <penguin42> maco_ Ah, so in Jaunty but not Intrepid?
[19:24] <penguin42> maco: Ah, so in Jaunty but not Intrepid?
[19:31] <maco> penguin42: of course. X doesn't change after release
[19:31] <penguin42> nod
[19:31] <maco> i mean, maybe a security update, but not a whole new version of X
[19:31] <penguin42> sure
[19:31] <maco> there was an ABI bump
[19:33] <penguin42> don't suppose anyone happens to know about dbus dynamic loading?