| linuxdaemon28 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 01:04 |
|---|---|---|
| TriangleSausage4 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 01:33 |
| ski_ | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 01:33 |
| ski_ | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 01:33 |
| ski_ | Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate | 01:33 |
| Sigals | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 01:58 |
| Sigals | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 01:58 |
| Sigals | Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate | 01:58 |
| RussellB287 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 02:33 |
| RussellB287 | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 02:33 |
| SebastianFlyte14 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 02:37 |
| SebastianFlyte14 | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 02:37 |
| Guest84053 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 02:38 |
| Guest84053 | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 02:38 |
| 7JTAEXEXK | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 03:22 |
| 7JTAEXEXK | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 03:22 |
| Ceber6 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 03:38 |
| kepler_mach3 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 03:53 |
| kepler_mach3 | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 03:53 |
| kepler_mach3 | Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate | 03:53 |
| jim24 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 04:58 |
| mborzecki | morning | 05:19 |
| ptx023 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 05:33 |
| ptx023 | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 05:33 |
| aphel | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 05:43 |
| aphel | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 05:43 |
| aphel | Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate | 05:43 |
| nullrouted | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 05:48 |
| mborzecki | so much spam | 05:50 |
| mup | PR snapd#5559 opened: tests/lib/snaps: avoid using relative command paths that go up in the directory tree <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5559> | 05:50 |
| mborzecki | yay, mup is alive again | 05:51 |
| Caraway258 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 05:58 |
| mborzecki | mvo: hi, looks like test-snapd-busybox-static has been released to edge only for i386, can you releease it to stable/beta/candidate too? | 06:13 |
| mvo | mborzecki: sure, will do now | 06:13 |
| mborzecki | mvo: ta | 06:14 |
| mvo | mborzecki: done for all arches | 06:15 |
| mborzecki | mvo: thanks i'm restarting #5456 then | 06:15 |
| mup | PR #5456: snapstate: refuse to remove bases or core if snaps need them <Created by mvo5> <https://github.com/snapcore/snapd/pull/5456> | 06:16 |
| mvo | mborzecki: thank you | 06:17 |
| mborzecki | yay, only 14 tests failing on amzn2 | 06:42 |
| pbek | Hi folks, has anyone an example of building a Qt5 app as a snap on Launchpad with the Ubuntu 18.04 envronment? The 16.04 environment worked great. But on 18.04 I get all kind of strange errors while building like in https://launchpadlibrarian.net/380104791/buildlog_snap_ubuntu_bionic_arm64_hswitch_BUILDING.txt.gz | 07:27 |
| pbek | that's the configuration: https://github.com/pbek/hswitch/blob/develop/build-systems/snap/snapcraft/snapcraft.yaml | 07:28 |
| zyga | o. | 07:41 |
| mvo | hey zyga ! good morning | 07:42 |
| mup | PR core-build#30 opened: scripts: add fixrtc-munt script to fix time issues on pi2,3 <Created by mvo5> <https://github.com/snapcore/core-build/pull/30> | 07:42 |
| mvo | zyga: right in time for -^ | 07:43 |
| mvo | zyga: I was thinking about the problem and the above seems like the quickest way out of the mess (especially since we want to release 2.34.2) | 07:43 |
| mvo | zyga: WDYT? | 07:43 |
| pedronis | what's the status of #5271 ? | 07:46 |
| mup | PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271> | 07:46 |
| pedronis | a 2nd review of #5515 would be great | 07:50 |
| mup | PR #5515: daemon: make sure most change generating handlers can produce errors with kinds <Created by pedronis> <https://github.com/snapcore/snapd/pull/5515> | 07:50 |
| mvo | pedronis: let me look at this one | 07:50 |
| mborzecki | tests continue to be unhappy :( | 07:53 |
| zyga | mvo: looking | 07:55 |
| zyga | pbek: 18.04 is not fully baked yet, | 08:02 |
| pbek | zyga: ah, thank you! | 08:02 |
| mup | PR core-build#31 opened: add shellcheck on build and fix open issues <Created by mvo5> <https://github.com/snapcore/core-build/pull/31> | 08:02 |
| mvo | zyga: I did a tiny fix and force pushed to #30 | 08:03 |
| zyga | I just noticed :) | 08:03 |
| mvo | zyga: sorry, silly thing based on #31 | 08:03 |
| mup | PR #31: Feature/snapfs refactor <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/31> | 08:03 |
| zyga | sorry for being slow, some interruptions at home and I'm the last one standing | 08:03 |
| zyga | what was the change? | 08:04 |
| mvo | zyga: for word in $(cat /proc/cmdline) must not be quoted | 08:04 |
| mvo | zyga: I did this incorrectly in the initial push | 08:05 |
| zyga | I see | 08:05 |
| zyga | right | 08:05 |
| mvo | zyga: its quite annoying that I had to disable the shellcheck test there but I don't see a good way to word split otherwise without using bash array (which we can't in initrd which uses ash iirc) | 08:06 |
| mvo | zyga: "last one standing" - are you guys sick? | 08:07 |
| zyga | mvo: not all sick but I'm the only one that can do stuff | 08:09 |
| zyga | but all is good now | 08:10 |
| mvo | ok | 08:10 |
| zyga | as in: no fires, not starving, can work :) | 08:10 |
| mborzecki | something funny about amzn, date --iso-8601=seconds -d 'tomorrow 8:05 UTC' yields '2018-07-27T08:05:00+0000', which does not parse in go, imo the output should be 018-07-27T08:05:00+00:00, https://play.golang.org/p/zfhZyaYpWKB | 08:13 |
| mborzecki | heh fixed in 2015 https://git.savannah.gnu.org/cgit/coreutils.git/commit/src/date.c?id=17bbf6ce44eb543a95695fa9d2cbd70fb52c6f42 | 08:15 |
| zyga | mvo: reviewed | 08:15 |
| zyga | mvo: thank you btw! | 08:15 |
| zyga | mvo: lastly, this is something I would much much much rather write in C | 08:15 |
| zyga | mvo: to break away from the mantra that we must endure shell | 08:16 |
| zyga | mvo: the commit message is slightly wrong | 08:18 |
| zyga | last mount time is updated | 08:18 |
| zyga | but because of the mechanism I explained on the forum, it advances very slowly | 08:18 |
| zyga | last write time is not updated | 08:18 |
| mvo | zyga: ok, let me fix the commit message (is force push ok?) | 08:19 |
| zyga | mvo: I'm looking the other way now ;) | 08:21 |
| zyga | mvo: have you tried it on your device? | 08:21 |
| mvo | zyga: not yet | 08:22 |
| mvo | zyga: its a bit painful, I'm inclinded to merge and build a new edge core | 08:22 |
| mvo | zyga: thanks for pointing the issue out, I will fix (it seems they were cargo culted) | 08:24 |
| mvo | zyga: off-by-one space? I don't see this or look for the wrong thing, can you help me please :) | 08:25 |
| NvpkD1y7Ez17 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 08:28 |
| zyga | mvo: I'd suggest actually patching initrd in the wild unless that's very tough, iteration through master is slow | 08:32 |
| zyga | mvo: there's one space ahead of "date", maybe tab-vs-spaces? | 08:32 |
| * zyga wonders if the spam will stop anytime soon | 08:32 | |
| mvo | zyga: oh, probably tab vs space, its not visible for me | 08:32 |
| zyga | mvo: also really think about coding this in C | 08:33 |
| zyga | this is like 3 function calls, stat, current date,(conversion), comparison, set date | 08:33 |
| zyga | (4 including some conversion perhaps) | 08:34 |
| zyga | mvo: all the prereq stuff can go away | 08:34 |
| zyga | all the cmdline stuff can go away | 08:34 |
| zyga | it will never be off by a typo that we don't see | 08:34 |
| mup | PR snapd#5515 closed: daemon: make sure most change generating handlers can produce errors with kinds <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5515> | 08:36 |
| mvo | zyga: what do you mean by "iteration on master is slow"? what I have in mind is a) upload the fix b) test it c) build new core image with 2.34.2 and the fix d) push core image to beta/candidate | 08:36 |
| mvo | zyga: is there an alternative that is quicker? | 08:36 |
| pedronis | mvo: thx | 08:36 |
| zyga | mvo: iteration through master -> build -> core snap -> refresh is slow | 08:36 |
| zyga | mvo: I though that is what you meant | 08:37 |
| mup | PR snapd#5434 closed: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5434> | 08:37 |
| pedronis | zyga: do you know what is the status of #5271 ? | 08:37 |
| mup | PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271> | 08:37 |
| zyga | pedronis: I don't think so, let me refresh my memory | 08:38 |
| zyga | I mean, there was just the issue of old xdg-document-portal | 08:39 |
| zyga | I will discuss this with jamie today | 08:39 |
| zyga | old portal on a distribution | 08:39 |
| mvo | zyga: hm, not sure I understand, sorry, maybe a bit slow this morning | 08:46 |
| zyga | no worries, | 08:46 |
| zyga | just do as you think is best | 08:46 |
| mvo | zyga: hm, hm, we could look at /var/lib/snapd/state.json instead of /var/lib/snapd/snaps for the date, this would give us accurate time even on snap reverts which will not pull in new snaps into the /var/lib/snapd/snaps dir | 08:49 |
| mvo | zyga: not-going-through-master> mostly worried I miss an important idea, maybe we can talk about it via a HO later so that you can explain your idea | 08:49 |
| zyga | mvo: I was under the impression that you cannot test this now without merging it first and going through the automatic core build cycle | 08:51 |
| mborzecki | Chipaca: could you take a look at #5559 ? | 08:51 |
| mup | PR #5559: tests/lib/snaps: avoid using relative command paths that go up in the directory tree <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5559> | 08:51 |
| zyga | mvo: I was suggesting, if possible, to actually build and iterate locally as once you overcome the initial cost of setup this is much faster to iterate with | 08:51 |
| Chipaca | mborzecki: no; looking now | 08:51 |
| mborzecki | Chipaca: thx | 08:52 |
| zyga | mvo: we can HO at any time if you want | 08:52 |
| mvo | zyga: aha, got it now | 08:52 |
| Chipaca | mborzecki: wrt /etc/os-release, I think we shouldn't be using the host's one | 08:52 |
| mvo | zyga: I'm very confident in the fix :) | 08:53 |
| mvo | zyga: but yeah, testing locally makes sense | 08:53 |
| mborzecki | Chipaca: agreed, need to discuss the right solution with zyga though | 08:53 |
| zyga | plus, anything you find and document as HOWTO will improve the next cycle :) | 08:53 |
| mvo | zyga: I will wait for ogra_ and/or abeato to review https://github.com/snapcore/core-build/pull/30 | 08:54 |
| mup | PR core-build#30: scripts: add fixrtc-munt script to fix time issues on pi2,3 <Created by mvo5> <https://github.com/snapcore/core-build/pull/30> | 08:54 |
| Chipaca | mborzecki: any reason not to implement dropping support for relative paths that go outside the snap, and supporting absolute paths? | 08:55 |
| Chipaca | mborzecki: other than it being a harder change i mean :-) | 08:55 |
| mborzecki | Chipaca: frankly I haven't considered that at all, would be nice to know if there are any snaps in the wild that use this first | 08:56 |
| Chipaca | mborzecki: there weren't when we checked last | 08:57 |
| mborzecki | Chipaca: let me put that in my todo list then and i'll push that in a follow-up | 08:57 |
| Chipaca | mborzecki: there's no rush imo | 08:58 |
| Yoda22 | Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ | 08:58 |
| Yoda22 | or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ | 08:58 |
| mup | PR snapd#5559 closed: tests/lib/snaps: avoid using relative command paths that go up in the directory tree <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5559> | 08:58 |
| ogra_ | mvo, zyga ... do you actually want the boot to hang when setting the clock fails ? | 09:04 |
| cjwatson | popey: It might be worth setting either +r (block unidentified users) or +q $~a (quieten them) here for a while to deflect the spam. | 09:04 |
| zyga | mvo: no | 09:04 |
| ogra_ | mvo, i'D rather remove the -e and leave exit 0 in | 09:04 |
| zyga | er, ogra_ no :) | 09:04 |
| zyga | ogra_: yes, I commented about that | 09:04 |
| cjwatson | JamieBennett: ^- | 09:04 |
| popey | I am on vacation. If I op you cjwatson can you do it? | 09:05 |
| cjwatson | Sure. | 09:05 |
| ogra_ | zyga, right, but only the exit 0 was removed ... and -e left in ... thats exactly the opposite of what i said ;) | 09:05 |
| zyga | ah, I didn't see that | 09:05 |
| zyga | mvo: ^ ogra is right | 09:05 |
| zyga | we should not set -e this scrpit | 09:05 |
| popey | Thanks | 09:05 |
| zyga | and this highlights that shell sucks and this one should be C | 09:06 |
| === cjwatson changed the topic of #snappy to: Join the forum: https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38 | If you can't send messages here, authenticate to nickserv first | ||
| zyga | popey: enjoy your time off, hide from IRC :) | 09:06 |
| cjwatson | I'll leave myself opped in case I need to deal with any fallout from that | 09:07 |
| zyga | thank you cjwatson ! | 09:07 |
| mvo | zyga: sure, let me fix that | 09:15 |
| * zyga hugs mvo | 09:16 | |
| zyga | thank you! | 09:16 |
| mvo | ogra_: might be worthwhile to do the same fix in the original fixrtc (remove the set -e) | 09:16 |
| t1mp | hello | 09:16 |
| mvo | zyga: shall I also use /var/lib/snapd/state.json? | 09:17 |
| zyga | mvo: I'd keep using the directory | 09:18 |
| zyga | mvo: and touch it in shutdown | 09:18 |
| zyga | mvo: is the state.json _always_ guranteed to be there? | 09:18 |
| zyga | guaranteed | 09:18 |
| zyga | actually, we could even stat / itself | 09:18 |
| zyga | and just touch that | 09:18 |
| zyga | no chance for that to hide :) | 09:18 |
| t1mp | I'm trying to package a python3 app using snapcraft. the snapcraft.yaml is pretty simple: https://pastebin.ubuntu.com/p/KHPy9d3Qr3/ | 09:18 |
| mvo | zyga: its not but thats easy enough to [ -f ] for | 09:18 |
| t1mp | but I always get this error: | 09:18 |
| t1mp | Could not find a version that satisfies the requirement qmenta-gui (from qmenta-app==1.95.9) (from versions: ) | 09:18 |
| t1mp | No matching distribution found for qmenta-gui (from qmenta-app==1.95.9) | 09:19 |
| mvo | zyga: touch on shutdown is one more moving part | 09:19 |
| t1mp | because snapcraft uses pip to search for dependencies.. but in this case the dependency is not on PyPI, but in a previous part.. any ideas how I can resolve this? | 09:19 |
| mvo | zyga: "/" might be readonly | 09:19 |
| zyga | mvo: yes but note that state.json is also a moving part and it may still rewind the time in bad cases | 09:19 |
| zyga | touching / on shutdown prevents that | 09:19 |
| zyga | mvo: (where rewind time is that there are _any_ files in the filesystem that would appear from the future) | 09:20 |
| t1mp | greyback_: :p | 09:20 |
| mvo | zyga: with touch on shutdown I think the current PR is final now, I addressed the feedback from ogra_ and abeato | 09:22 |
| zyga | mvo: thank you | 09:22 |
| zyga | actually | 09:23 |
| zyga | mvo: one more question | 09:23 |
| zyga | mvo: what sets the "fixrtc" in the command line? | 09:23 |
| zyga | I mean, does uboot on pi does that? | 09:23 |
| mvo | zyga: its part of the gadget | 09:23 |
| mvo | zyga: yes | 09:23 |
| zyga | where is that specified | 09:23 |
| zyga | aha | 09:23 |
| zyga | would you feel ok not checking for that | 09:23 |
| zyga | just dropping the whole cmdline parsing? | 09:23 |
| zyga | after all, it cannot hurt | 09:23 |
| zyga | if the time is more into the future we won't change it | 09:24 |
| ogra | whoops, why am i OP ? | 09:24 |
| zyga | and this would cut on complexity and need to teach other gadgets that this is a command line option and that it does something important | 09:24 |
| ogra | mvo, agreen (regarding fixrtc) but that needs to happen in the distro package ... | 09:25 |
| zyga | ogra: you have that special bit :) | 09:25 |
| ogra | *agreed | 09:25 |
| mvo | zyga: for this particular update I would prefer to keep the change as minimal as possible, because this will go into stable very soon (we need it to fix refresh issues) | 09:25 |
| mvo | ogra: yeah, was just wondering alound, not urgent or anything | 09:25 |
| ogra | zyga, well, i only changed my nick ... and registered ... wasnt aware that IRC keeps such states | 09:25 |
| zyga | mvo: are you worried that the change could regress something elsewhere? | 09:27 |
| cjwatson | ogra: baseline IRC doesn't, but chanserv has a configured access list for each channel | 09:28 |
| cjwatson | (also you can register alternate nicks if you want to return to the underscored form ...) | 09:29 |
| lool | abeato: here? | 09:29 |
| ogra | cjwatson, nah, i'm fine i was just surprised | 09:30 |
| mvo | zyga: yeah, risk is small but it would be super annoying | 09:31 |
| mvo | zyga: especially since right now the impact is limited to a subset of devices, if it turns out there is a bug somewehre and it runs now on a magnitude more x86 device that would be bad(tm) | 09:32 |
| ogra | zyga, we have fixrtc on the commandline of all relevant gadgets | 09:32 |
| ogra | (just not on pc iirc) | 09:32 |
| zyga | mvo: right but we must trust the code to DTRT where it matters | 09:32 |
| mvo | ogra: I think zyga point is that the script should be safe everywhere so why bother checking | 09:33 |
| zyga | mvo: I approved the PR and left two comments | 09:33 |
| zyga | mvo: that essentially re-state those | 09:33 |
| mvo | zyga: ta | 09:33 |
| ogra | ah, k | 09:33 |
| zyga | but I agree it's important to move | 09:33 |
| mvo | zyga: yeah, lets do this minimal fix for now, maybe its just be being overly cautious | 09:36 |
| mvo | zyga: thanks for the review and the ideas! | 09:36 |
| mvo | ogra: I guess the bug itself is not reproducible, right? i.e. it happend to you but there is no way to bring the system into the state where it failed? | 09:37 |
| ogra | mvo, just using a recent edge image and calling any "snap set" should expose it | 09:39 |
| zyga | mvo: the time issue is easy to reproduce | 09:39 |
| ogra | well ... hmm ... you might need to install an older one, install a snap with config hook and then update to latest edge actually | 09:39 |
| zyga | mvo: the apparmor issue is something I'm exploring (outside of core, to show where it happens) | 09:39 |
| zyga | s/where/how/ | 09:39 |
| ogra | so that there is an old cache file in place | 09:39 |
| t1mp | is anyone here familiar with the python plugin? | 09:41 |
| abeato | lool, ping | 10:00 |
| lool | abeato: pong | 10:00 |
| abeato | lool, ok looks like I can write here now, thanks :) | 10:01 |
| abeato | zyga, hi, I am having some issues when opening a serial port from the modem-manager snap. I see https://paste.ubuntu.com/p/t92Wf3gdZ5/ , but no apparmor denials | 10:04 |
| abeato | zyga, I created a small program that uses the same flags, and when run unconfined all is good | 10:05 |
| abeato | this does not happens for USB serial ports, I wonder what is special here | 10:05 |
| mvo | abeato: thanks for your script! its in now (and for the review) | 10:08 |
| abeato | mvo, nice to see that merged in core, it was an issue we saw in some devices :) | 10:09 |
| abeato | zyga, https://paste.ubuntu.com/p/qWV9FBzWtj/ | 10:10 |
| zyga | abeato: is that device present (major:minor) in the per-snap device cgroup? | 10:18 |
| abeato | zyga, ah, cgroups, that might be the issue... I guess no, how can I check that? | 10:19 |
| zyga | abeato: go to /sys/fs/cgroup/devices | 10:21 |
| zyga | then look at snap.foo name groups | 10:21 |
| zyga | then at various files, I think devices.allow is the one | 10:22 |
| abeato | zyga, devices.list, and yes, I do not see the majour:minor for this device there, can this be modified from an interface? | 10:23 |
| zyga | abeato: indeed it can | 10:24 |
| zyga | abeato: this is the udev backend | 10:24 |
| zyga | abeato: you can use a simple helper method to tag devices to add there according to udev rules | 10:24 |
| abeato | zyga, got it, thanks | 10:25 |
| mborzecki | pedronis: thanks for the review on snapsup/snapstate parts, do you think you'll get a chance to look at #5452 too? | 10:25 |
| zyga | abeato: let me know if you need help | 10:25 |
| abeato | :) | 10:26 |
| * mborzecki wonders if he should try linux-hardened + apparmor on arch | 10:28 | |
| abeato | zyga, hm, so not sure how snap confine builds the list of cgroup devices, should not it add ttymxc6 as the modem-manager interface has '/dev/tty[^0-9]* rw,' in apparmor rules? | 10:36 |
| zyga | no | 10:36 |
| zyga | it's not related to apparmor in any case | 10:36 |
| zyga | you need udev backend specification object to add a rule to tag a device at runtime | 10:37 |
| zyga | abeato: look t... | 10:37 |
| abeato | where can I find an example? | 10:37 |
| zyga | https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port.go#L196 | 10:38 |
| zyga | look at anything that calls TagDevice | 10:38 |
| zyga | I just found a random one | 10:38 |
| zyga | the argument is a partial udev expresssion | 10:38 |
| zyga | look at what happens to get a feeling about how this works | 10:38 |
| zyga | it essentially expands to something like this | 10:38 |
| zyga | if this-and-that-udev-expression-matches then append a tag to the device that udev is looking at, the tag is derived from snap name | 10:39 |
| zyga | then snap-confine uses those tags to pre-populate the cgroup | 10:39 |
| zyga | and also udev uses the same expression to add/remove devices as they are added/removed in the system (live changes) | 10:39 |
| abeato | zyga, ah, got it now, thanks | 10:40 |
| zyga | super, good luck! | 10:40 |
| pedronis | mborzecki: yes, this afternoon | 11:11 |
| mborzecki | pedronis: great, thank you | 11:13 |
| mborzecki | pedronis: opened another PR #5561this is snapstate changes with run through tests | 12:12 |
| mborzecki | #5561 | 12:12 |
| mborzecki | mup doesn\t work? | 12:13 |
| * Chipaca kicks mup | 12:13 | |
| Chipaca | oh wait, that was lalita | 12:13 |
| jdstrand | ogra: hi! have you ever seen this before: bbb-test kernel: [553472.131711] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_wait_vrise (90, <VBusValid), retry #3, port1 0008010c | 12:19 |
| ogra | jdstrand, well, thats the micro USB driver that has never been rock solid | 12:54 |
| ogra | though i dont remember this particular error | 12:55 |
| ogra | smells like a wrong value in the dtb | 12:55 |
| ogra | jdstrand, https://e2e.ti.com/support/arm/sitara_arm/f/791/t/324491?AM3352-USB-DRVVBUS-does-not-stay-active-when-device-connected# | 12:56 |
| ogra | hmm, seems to also be triggered if the board is underpowered and the USB port draws too much current | 12:59 |
| ogra | we should cross check that our kernel has all required MUSB options set http://processors.wiki.ti.com/index.php/MUSB_Linux_Driver_Configuration | 13:00 |
| ogra | jdstrand, is that a new kernel ? i dont see the msg here with the latest stable linux-generic-bbb | 13:12 |
| jdstrand | ogra: 4.4.0-93-1 | 13:13 |
| jdstrand | ogra: it is the first time I've seen it (saw it in my logs) | 13:13 |
| ogra | do you have any USB devices attached ? | 13:14 |
| zyga | ogra: hey, crazy idea | 13:14 |
| jdstrand | ogra: no. I don't know if the ethernet is hardwired (I have the power and an ethernet cable plugged in) | 13:15 |
| zyga | ogra: does pi have any form of RTC that runs as long as the board is powered? | 13:15 |
| ogra | oh, i should probably push 4.4.0-127-1 from edge to stable :P | 13:15 |
| zyga | ogra: and if so, could we at least retain RTC across reboot (not across poweroff) | 13:15 |
| zyga | that would be neat IMO | 13:15 |
| jdstrand | ogra: I do have the pings wired up for serial, but the usb end is not plugged into anything | 13:15 |
| ogra | ethernet is hardwired ... not USB | 13:15 |
| zyga | most of the time those devices will just reboot on upgrade | 13:15 |
| ogra | jdstrand, let me release -127-1 to stable ... and lets see if you still get that ... i definitely dont have it in dmesg | 13:16 |
| ogra | jdstrand, released ... let me know if you still see it after refresh | 13:16 |
| ogra | zyga, no, sadly not, i was mixing it up with the dragonboard (that has an rtc but no battery .. pi doesnt have any rtc at all) | 13:17 |
| zyga | nothing in the SoC ticks with 32K freq? | 13:17 |
| ogra | dunno ... perhaps it does, but you'd still need to preserve the timestamp across a reboot | 13:18 |
| ogra | there is definitely some kind of clock ... so you could count ticks, but i dont know if that doesnt get reset when you reboot | 13:19 |
| ogra | did you look at that fake-hwclock from raspbian and how it works ? | 13:19 |
| ogra | perhaps they have a better solution here | 13:21 |
| kenvandine | mvo, i've been doing some profiling of desktop snaps and their first run being slow. I've ruled out desktop-launch as the bottleneck | 13:22 |
| kenvandine | desktop-launch elapsed time: 0.994528127 | 13:22 |
| kenvandine | Now running: exec gnome-calculator | 13:22 |
| kenvandine | mvo, then it takes ~10-20 seconds for the UI to appear | 13:22 |
| kenvandine | mvo, it looks like that exec is what's taking so long | 13:23 |
| ogra | hmm, looking at the debian fake-hwclock script it does nothing with hardware, only reads and writes a file | 13:23 |
| zyga | kenvandine: how do you measure? | 13:24 |
| zyga | kenvandine: => forum is better | 13:24 |
| zyga | kenvandine: but as a profiling case, run hello-world | 13:24 |
| zyga | (shell) | 13:24 |
| zyga | everything else is overhead of helpers and the app code itself | 13:24 |
| kenvandine | yeah, that's fast... so it's puzzling | 13:24 |
| kenvandine | i added some output to desktop-launch which shows the difference in time between the beginning and the end of the script | 13:25 |
| kenvandine | the only thing i'm not timing is the exec itself | 13:25 |
| zyga | I don't know desktop-launch | 13:25 |
| zyga | can you collect this in the forum | 13:25 |
| zyga | I bet we're missing something | 13:25 |
| kenvandine | sure | 13:25 |
| zyga | thanks! | 13:25 |
| kenvandine | i'll post it | 13:26 |
| ogra | desktop-launch does a ton of filesystem operations on first start ... but that shouldnt have much impact on second start of an app anymore | 13:26 |
| kenvandine | ogra, i'm talking about the first launch | 13:27 |
| ogra | ah | 13:27 |
| kenvandine | i added profiling for that, and it's actually must faster than i thought | 13:27 |
| kenvandine | but that exec is taking ages | 13:27 |
| kenvandine | and that exec is much faster the second time | 13:27 |
| ogra | well, you are calling out to other binaries from it, probably the exec is delayed till i.e. gdk-pixbuf-foo has run, fontconfig has generated everything etc etc | 13:28 |
| kenvandine | yeah, i'm timing everything up until exec | 13:28 |
| ogra | and you are sure the external binaries have all returned by then ? | 13:29 |
| kenvandine | yes | 13:29 |
| ogra | weird | 13:29 |
| zyga | time the target of the exec | 13:30 |
| jdstrand | kenvandine: is it possible that the desktop-launch script triggers things in the background and the app is somehow signaled (dbus, gsettings, something else) to proceed when the task is done? That could explain a fast script but slow launch (or the exec itself is doing a lot on that first launch because of glib/gtk/whatever) | 13:30 |
| zyga | probably not the binary | 13:30 |
| kenvandine | maybe it's loading all the libraries into memory the first time is slow? | 13:30 |
| zyga | but just another layer of scripts | 13:30 |
| zyga | kenvandine: rm -rf $SNAP_USER_DATA | 13:30 |
| zyga | it will be slow again | 13:30 |
| zyga | it's not the libraries | 13:30 |
| jdstrand | loading all the libs would be slow after reboot. this is only after install/refresh afaik | 13:30 |
| kenvandine | zyga, i am doing that for my testing | 13:31 |
| zyga | also common I suspect | 13:31 |
| kenvandine | i'm doing a reboot to see if that exec is slow again | 13:31 |
| zyga | niemeyer, jdstrand: please let me know when you want to sync on the cache issue | 13:32 |
| zyga | I will break for lunch now | 13:32 |
| kenvandine | ah... that exec is slow again after a reboot | 13:33 |
| kenvandine | so maybe it is all just overhead of library loading | 13:33 |
| kenvandine | we do have quite a path | 13:33 |
| zyga | that would be super odd | 13:33 |
| zyga | do you have a HDD? | 13:33 |
| kenvandine | yes... this is in a VM too | 13:33 |
| zyga | kenvandine: aha | 13:33 |
| zyga | kenvandine: as a "non scientific" ballpark test | 13:33 |
| kenvandine | it is much faster in my laptop :) | 13:33 |
| zyga | open a terminal after reboot | 13:33 |
| zyga | run "dstat" in it | 13:33 |
| zyga | let it run for a few seconds | 13:33 |
| zyga | then run the app | 13:33 |
| zyga | and correlate activity | 13:34 |
| kenvandine | interesting | 13:34 |
| zyga | it shows IP | 13:34 |
| zyga | IO, CPU and lots of useful stuff | 13:34 |
| zyga | in one simple format | 13:34 |
| zyga | so you will see "aha, stuck on CPU, stuck on DISK, etc" | 13:35 |
| kenvandine | rebooting to see | 13:36 |
| kenvandine | but i did notice running a second gnome snap (which also uses gnome-3-26-1604 content interface) that exec is fast again. So first run of the snap after reboot but the 2nd snap run that uses the content interface | 13:37 |
| kenvandine | so maybe the libs from the content interface are loaded already | 13:37 |
| kenvandine | zyga, dstat did see a jump in disk read on first run of the snap | 13:40 |
| kenvandine | about 8M | 13:40 |
| kenvandine | but then next to nothing on the 2nd run | 13:40 |
| kenvandine | actually 8M and then almost immediately after that 10M | 13:41 |
| kenvandine | then on the 2nd run the biggest spike was 102k | 13:41 |
| kenvandine | zyga, then on additional runs there is no disk reads | 13:42 |
| zyga | IRC spam intensifies | 14:41 |
| cjwatson | /mode <yournick> +R may help | 14:43 |
| cjwatson | (block /msg from unregistered users) | 14:43 |
| zyga | oh, that's very useful, using that now! | 14:43 |
| roadmr | TIL about that on #freenode, but if it doesn't help I'll probably have to stay off freenode until that crap blows over :/ it's very upsetting | 14:44 |
| cjwatson | Those sort of basic strategies seem to be working OK so far | 14:47 |
| mvo | kenvandine: just read backlog, sorry, was busy with core18 work :/ | 14:49 |
| mvo | pedronis: your opinion on 5563 would be great, its a bit minimal (too much?) right now | 14:51 |
| kenvandine | mvo, no worries | 14:57 |
| kenvandine | i really think it's library loading | 14:57 |
| kenvandine | mvo, i've got it covered :) | 14:58 |
| mvo | kenvandine: excellent | 15:02 |
| Chipaca | pedronis: niemeyer: #5187 is ready for a (n+1)th look | 15:13 |
| pedronis | mvo: I commented a bit | 15:19 |
| mvo | pedronis: thanks! | 15:21 |
| mvo | pedronis: sure, I will add checks on the assertion level | 15:22 |
| mvo | pedronis: thanks for the review | 15:22 |
| * mvo has fun with kernel crng blocking the boot of core18 in the meantime | 15:22 | |
| pedronis | Chipaca: I forgot 5187 is dauntingly big | 15:23 |
| Chipaca | pedronis: … maybe :-) | 15:24 |
| pedronis | Chipaca: so forget and check don't touch snaps, but they touch things that restore and save touch? | 15:27 |
| Chipaca | pedronis: yes | 15:27 |
| pedronis | ok | 15:27 |
| pedronis | Chipaca: I skimmed a bit but I'll look at it seriously in the morning I think | 15:31 |
| Chipaca | pedronis: that is fair | 15:31 |
| jdstrand | niemeyer, mvo, zyga: fyi, gave jjohansen the context of most recent issue. he'll be ready in a little bit for the meeting and can ping us | 16:16 |
| zyga | great, thank you jdstrand | 16:17 |
| zyga | jdstrand: btw, did you see my reply on https://forum.snapcraft.io/t/apparmor-profile-caching/1268/21 | 16:19 |
| niemeyer | Thanks! | 16:19 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| === leosilva is now known as leosilva_ | ||
| jjohansen | jdstrand, zyga, niemeyer: okay I'm available | 16:45 |
| zyga | hey! | 16:46 |
| * jdstrand is ready | 16:46 | |
| jdstrand | mvo: ^ | 16:46 |
| zyga | where shall we go? | 16:46 |
| jjohansen | some where with a nice sandy beach, good weather and free drinks | 16:48 |
| jdstrand | niemeyer, zyga, mvo, jjohansen: https://meet.google.com/tdg-hhbb-dip | 16:48 |
| niemeyer | omw | 16:49 |
| mvo | omw as well | 16:54 |
| jdstrand | mvo (cc niemeyer, zyga): can you ping us if the strategic use of --skip-read-cache is deemed infeasible, which would escalate the priority on our end. If you have that change, then we can go through the proper channels on prioritizing this, but if you don't, jj and I will defend starting early | 17:46 |
| zyga | jdstrand: ack, I’m just staring on the patch right now | 19:01 |
| jdstrand | zyga: thanks | 19:35 |
| zyga | :-) | 19:35 |
| jdstrand | rbasak: hey, so for the moment I have not granted classic. can you ping me if there is agreement to grant it early? | 19:35 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/5564 | 20:13 |
| zyga | jjohansen: ^ | 20:31 |
| zyga | ah | 20:31 |
| zyga | well, #5564 | 20:31 |
| zyga | :) | 20:31 |
| zyga | PR 5564 | 20:31 |
| zyga | mup must be on holiday s:) | 20:31 |
| zyga | jjohansen: https://github.com/snapcore/snapd/pull/5564 | 20:31 |
| FreeBDSM | how to get a snap of firefox 52.9.0 ESR? | 20:32 |
| jjohansen | zyga: that looks okay | 20:36 |
| zyga | jjohansen: great, thank you! | 20:39 |
| zyga | FreeBDSM: I think you should ask in #mozilla about that, it's their snap, they are the publisher | 20:39 |
| pedronis | the esr track has 60.1 | 20:40 |
| FreeBDSM | zyga: I think they hate their users | 20:40 |
| pedronis | (afaict) | 20:40 |
| zyga | pedronis: yeah, I checked, | 20:41 |
| zyga | FreeBDSM: I don't think they do that but it's the question you should bring to mozilla | 20:41 |
| FreeBDSM | zyga: it's pointless to do | 20:41 |
| FreeBDSM | they want me to install their fresh bullshit, I refuse to | 20:41 |
| FreeBDSM | so, snap goes against freedom as well :( | 20:44 |
| zyga | ultimate freedom is anarchy, snaps are here to improve on known issues, it cannot be everything for everybody but we are here do make the world better | 20:45 |
| FreeBDSM | not at all | 20:45 |
| FreeBDSM | you could just store old versions | 20:46 |
| FreeBDSM | but you don't | 20:46 |
| abeato | t | 20:50 |
| ogra | FreeBDSM, was 52.x ESR ever in the snap store ? (i dont think it ever was, so blaming us is a bit unfair, dont you think) | 21:03 |
| FreeBDSM | ogra: looks like it was | 21:04 |
| FreeBDSM | ogra: I get google links pointing to snap of firefox-esr 52.9.0 but now there's a more recent version | 21:04 |
| ogra | AFAIK the first release to the esr track was 59.xx | 21:04 |
| ogra | (and that was not promoted since it was a pre-release, they only announced esr availablility with 60) | 21:05 |
| zyga | FreeBDSM: if debian had stored it it would also go away over time, that's not a fair thing to say, we actively give the developers the choice to publish old versions as tracks but we don't allow people to just get any version from the past because that is insecure and snaps are here to solve the update issues | 21:05 |
| ogra | if you had a former version installed you can defiitely revert to it using snap revert though | 21:05 |
| FreeBDSM | `we don't allow people to just get any version from the past because that is insecure` - b/s | 21:06 |
| ogra | so nobody *forces new stuff on you* ... quite the opposite with snaps, they allow you to go back without breaking | 21:06 |
| ogra | (that indeed only works if you had a former version) | 21:07 |
| FreeBDSM | yes, and this approach sucks | 21:07 |
| ogra | well, the rollback is a local thing ... | 21:08 |
| FreeBDSM | wouldn't be a local thing, if repo had older versions available... | 21:08 |
| zyga | FreeBDSM: it's your opinion | 21:08 |
| FreeBDSM | just like mozilla has ALL of it's versions available for public... | 21:08 |
| FreeBDSM | zyga: no, it's not, it's just some common sense | 21:08 |
| zyga | FreeBDSM: you can always get mozilla from source and build it yourself | 21:08 |
| FreeBDSM | zyga: which is like re-inventing a bicycle | 21:09 |
| zyga | FreeBDSM: no, it's not common sense | 21:09 |
| zyga | FreeBDSM: to argue you should present some facts | 21:09 |
| zyga | FreeBDSM: not "common sense" or "b/s" | 21:09 |
| FreeBDSM | Fact A. people sometimes want particular version of software | 21:09 |
| zyga | FreeBDSM: I don't actually want to argue tonight, I'm just pointing out this is an opinion of yours, not a fact that is universally agreed upon | 21:09 |
| FreeBDSM | Fact B. snappy/flatpak/etc. was partially invented to make self-contained builds distribution. | 21:10 |
| FreeBDSM | Fact C. You say it's up to upstream to decide what to upload to your repo | 21:10 |
| FreeBDSM | Fact D. You say you don't store older uploaded snaps because 'that is insecure' | 21:11 |
| ogra | who said that ? | 21:12 |
| FreeBDSM | Fact E. Uploader of snaps (mozilla) has their older versions publicly available. | 21:12 |
| FreeBDSM | Fact(?) F. (from what I understood) Mozilla decided to turn off the availability of the previous version of firefox as a snap. | 21:13 |
| FreeBDSM | ogra: grep the channel log | 21:13 |
| zyga | FreeBDSM: I didn't say we don't store old revisions, we do store them, we don't allow everyone to install old revisions | 21:13 |
| pedronis | the log says we don't allow to some degree to get them | 21:13 |
| pedronis | the issue is really that only the maintainer can decide what is maintained | 21:14 |
| FreeBDSM | zyga: I'm not everyone, please, let me download it | 21:14 |
| zyga | FreeBDSM: only mozilla can do that | 21:14 |
| FreeBDSM | pedronis: that is a dictate | 21:14 |
| ogra | lol | 21:14 |
| FreeBDSM | zyga: well, a poor decision on your part then to make it so. | 21:14 |
| pedronis | it's trade offs all the way down like turtles | 21:15 |
| FreeBDSM | yeah, that lead to digital dictate | 21:15 |
| * ogra waits for godwins law invocation ... | 21:15 | |
| zyga | FreeBDSM: that's your opinion | 21:15 |
| pedronis | the maintainer can create tracks for all the things maintained | 21:16 |
| FreeBDSM | `we don't care what you think about what we've recently did, you either just update and agree to our terms, or FU and good luck building an older version yourself` | 21:16 |
| pedronis | they have that option | 21:16 |
| FreeBDSM | pedronis: a maintaner may have semi-evil intents | 21:16 |
| pedronis | otoh I expect some of them not to want to let unmaintained stuff get installed | 21:16 |
| ogra | FreeBDSM, well, alternatively convince the responsible people to make it availble to you | 21:16 |
| ogra | the responsible people being mozilla here ... the store is just a tool ... they drive it | 21:17 |
| FreeBDSM | ogra: you've made responsible some scum, no chance I'm going to convince them shit | 21:17 |
| zyga | FreeBDSM: you can take firefox, build a snap and upload any set of tracks that have every release | 21:17 |
| zyga | FreeBDSM: but mozilla chose not to | 21:17 |
| zyga | FreeBDSM: you can still do that | 21:17 |
| zyga | FreeBDSM: you can also recommend your version to everyone | 21:17 |
| zyga | FreeBDSM: but mozilla recommends theirs | 21:17 |
| ogra | FreeBDSM, so why are you arguing with us now ? | 21:17 |
| FreeBDSM | ogra: because it was your poor decision to make some scum responsible | 21:18 |
| FreeBDSM | bad ideas are bad ideas | 21:18 |
| FreeBDSM | zyga: I could take firefox and build it statically and forget about snap as a bad dream as well. | 21:19 |
| ogra | FreeBDSM, well, you are trolling and arguing abour an app version with us that was never packaged as a snap making us responsible for the fact that you can not get it as a sanp | 21:19 |
| ogra | *about | 21:19 |
| FreeBDSM | with that kind of argument snap is useless | 21:19 |
| FreeBDSM | ogra: no, you are trolling | 21:19 |
| ogra | huh ? | 21:19 |
| FreeBDSM | go troll someone else | 21:19 |
| ogra | read the backlog please | 21:19 |
| zyga | FreeBDSM: we can keep this discussion civilized or use words like "scum" and let you talk to yourself | 21:19 |
| ogra | you are probably the most aggressive person i have seen in this channel in the last half year | 21:20 |
| FreeBDSM | your nickname is like an ogre, ogres are like trolls, thus you are a troll. | 21:20 |
| ogra | sure ... | 21:20 |
| zyga | ogra: use your @ | 21:20 |
| FreeBDSM | check and mate | 21:20 |
| ogra | in any case your complaints wont go anywhere, nobody of us can make esr52 available to you since it never existed in the snap store ... | 21:20 |
| FreeBDSM | well, I understood it quite some time ago | 21:21 |
| FreeBDSM | I just wanted to ridicule you | 21:21 |
| ogra | so why are you still agruing | 21:21 |
| FreeBDSM | because the situation is ridiculous | 21:21 |
| ogra | it is as it is | 21:21 |
| FreeBDSM | you've created an awesome util that's able to solve a problem | 21:21 |
| ogra | if you want esr52 ask FF to upload it to the store | 21:21 |
| FreeBDSM | and you make your ecosystem SO, that the problem won't be solved | 21:21 |
| FreeBDSM | kind of, defies logic | 21:22 |
| FreeBDSM | why bother with snap then? | 21:22 |
| ogra | well, thats your POV | 21:22 |
| ogra | dunno | 21:22 |
| ogra | why do you ? | 21:22 |
| FreeBDSM | I don't | 21:22 |
| FreeBDSM | I just realized it's useless | 21:22 |
| ogra | so why are you coming here then | 21:22 |
| FreeBDSM | thus I won't use it | 21:22 |
| FreeBDSM | ogra: read above | 21:22 |
| FreeBDSM | to ridicule you | 21:22 |
| ogra | thats fine and totally your right | 21:22 |
| FreeBDSM | thanks | 21:22 |
| * mvo calls it a day with an almost booting 4.15 kernel on core18 | 21:23 | |
| FreeBDSM | it is also your right to waste your time making X and then taking decision Y which nullifies the profits of X | 21:23 |
| zyga | FreeBDSM: let us agree that you have some opinion of how snaps are designed and we have another | 21:23 |
| FreeBDSM | no | 21:23 |
| FreeBDSM | snaps can be used for distributing fat packages | 21:24 |
| * ogra fully agrees :P | 21:24 | |
| zyga | FreeBDSM: can we have our opinions without you being offensive? | 21:24 |
| FreeBDSM | I'm not offensive | 21:24 |
| ogra | lol | 21:24 |
| FreeBDSM | you are being too defensive | 21:24 |
| zyga | you are not kind, you don't try to understand our opinion | 21:24 |
| FreeBDSM | defending what? | 21:24 |
| FreeBDSM | I understood your opinion | 21:24 |
| ogra | but you dont respect it :) | 21:24 |
| FreeBDSM | you wanted to delegate as much as possible | 21:24 |
| zyga | you came here to say we are ugly and stupid because we didn't do what you think | 21:24 |
| FreeBDSM | I get it | 21:24 |
| ogra | i didnt say "get" | 21:25 |
| FreeBDSM | zyga: no, I didn't | 21:25 |
| zyga | we want you to appreciate our opinion and the reasons for the design before you say this is stupid | 21:25 |
| zyga | we can share that design vision with you if you are willing to listen | 21:25 |
| FreeBDSM | I came here to say you've made an awesome tool, but you've made some horrible decisions about the way the infrastructure/service/ecosystem around that tool is built which in _some_ cases nullifies the pros of the tool | 21:25 |
| zyga | but this has to be a civilized discussion because otherwise I don't think anyone will be interested in spending their time | 21:25 |
| ogra | well, you didnt say it in that tone :) | 21:26 |
| zyga | that's much nicer | 21:26 |
| ogra | yes | 21:26 |
| zyga | yes, now we can discuss pros/cons and the why's | 21:26 |
| FreeBDSM | well, I wanted to ridicule you, after all, so I just had to make it as absurd as possible to make the point as obvious as possible | 21:26 |
| zyga | let's suppose mozilla did upload ESR 59 | 21:26 |
| FreeBDSM | okay | 21:26 |
| zyga | and it was in the store (I don't know if that's true or not( | 21:27 |
| ogra | it was | 21:27 |
| FreeBDSM | let's suppose it was | 21:27 |
| zyga | FreeBDSM: believe me, if this was a face to face conversation it would not be received well | 21:27 |
| zyga | FreeBDSM: now let's suppose we allow anyone to download any revision | 21:27 |
| ogra | then they updated to 60 and annoounced the availability | 21:27 |
| zyga | this is something we reserve to the publisher of the snap | 21:27 |
| zyga | since they can publish any revision they can also get any revision | 21:27 |
| zyga | how would the user experience look like? | 21:27 |
| FreeBDSM | zyga: believe me, it'd be go way better, as text doesn't express my emotions | 21:28 |
| zyga | you can get revision 12351 that happens to be firefox 59.0.1 build 7 (for example) | 21:28 |
| zyga | what would happen next? do you stay there forever? | 21:28 |
| zyga | do you move to 60.0 in half an hour | 21:28 |
| FreeBDSM | I tell you | 21:28 |
| zyga | do you move to 60.1 as soon as it is out? | 21:28 |
| FreeBDSM | my answer is 'let the user decide' | 21:28 |
| FreeBDSM | If they want to update - let'em | 21:28 |
| zyga | out of that set, there's only one answer that's clearly insecure: stay on 59 *especially* in a browser | 21:28 |
| FreeBDSM | if they refuse to update - let'em | 21:29 |
| zyga | FreeBDSM: but the users cannot decide, this is well known that they don't understand security and only care about convenience | 21:29 |
| FreeBDSM | don't fool yourself into thinking that you know better what's better for the user. you don't. period. | 21:29 |
| zyga | if update was opt-in a large population of the users would never update and would be on the insecure version | 21:29 |
| zyga | FreeBDSM: I'm curious, how many CVEs are in 59.0 that were fixed in 60.0 | 21:29 |
| FreeBDSM | zyga: the stupidest users don't know what linux is. | 21:29 |
| FreeBDSM | zyga: they user the OS that came with the laptop | 21:29 |
| FreeBDSM | and they ask their 'computer boi' to 'fix it when it gets to pornful' | 21:30 |
| zyga | FreeBDSM: well, we are building a coherent experience for our users, snaps are aiming to provide something better than what we had | 21:30 |
| zyga | so as a part of that design we said we would not allow people to just stay suck on old revision | 21:30 |
| FreeBDSM | I believe that you had best intentions | 21:30 |
| zyga | because even if they don't want to be insecure | 21:30 |
| zyga | they don't understand the consequences | 21:30 |
| FreeBDSM | but there's a saying: 'best intentions lead to hell' | 21:30 |
| zyga | and they can be easily fooled into following a set of instructions that keeps them stuck forever | 21:30 |
| FreeBDSM | they do understand the consequences | 21:31 |
| zyga | we've seen this time and again | 21:31 |
| FreeBDSM | every ubuntu monkey knows how to update | 21:31 |
| zyga | countless forum posts with instructions on how to pin a package | 21:31 |
| FreeBDSM | if someone doesn't - let the suffer | 21:31 |
| zyga | or download a random deb or rpm | 21:31 |
| FreeBDSM | that's their choice to be stupid | 21:31 |
| zyga | you say "let them suffer" | 21:31 |
| ogra | you miss the point | 21:31 |
| zyga | I say "I want to make the world better" | 21:31 |
| zyga | that's what we _chose_ to do | 21:31 |
| ogra | it isnt *them* who sufferes alone | 21:31 |
| FreeBDSM | and back to godwin's law | 21:31 |
| zyga | the linux landscape is full of harder options | 21:31 |
| FreeBDSM | hitler wanted to make the world better as well | 21:31 |
| zyga | nobody is forcing you or like-minded people to use snaps | 21:31 |
| ogra | they will file bugs that someone needs to handle | 21:31 |
| zyga | ogra: there you go | 21:32 |
| ogra | they will ask support questions that someone needs to deal with | 21:32 |
| FreeBDSM | yup | 21:32 |
| FreeBDSM | boil point | 21:32 |
| ogra | they take away working time of mozilla devs to fix issues in a newer version | 21:32 |
| FreeBDSM | no reason to continue the argument because you think you know better than the users what is better for them | 21:32 |
| FreeBDSM | just like some gov | 21:32 |
| FreeBDSM | I despise such approach | 21:33 |
| ogra | o it is mozillas decision if they want to cope with that | 21:33 |
| ogra | *so | 21:33 |
| ogra | they obviously dont | 21:33 |
| ogra | so they picked to only offer the latest esr | 21:33 |
| FreeBDSM | this always leads to what's described in Orwell's antiutopias | 21:33 |
| ogra | the store allows you to open tracks, and offer any number of versions you want to your users | 21:33 |
| ogra | they decided not to | 21:34 |
| FreeBDSM | mozilla is compromised. period. | 21:34 |
| FreeBDSM | they chose the evil path. | 21:34 |
| FreeBDSM | let them rot | 21:34 |
| ogra | this is *again* not our decision and you deny to accep that fact | 21:34 |
| ogra | the tool has the capability | 21:34 |
| FreeBDSM | the fact that any organization may make turns in their path | 21:34 |
| FreeBDSM | and become evil | 21:34 |
| FreeBDSM | and the fact that you delegate too much to organizations | 21:35 |
| FreeBDSM | just 2 facts | 21:35 |
| ogra | well, thats a topic for #mozilla i guess | 21:35 |
| FreeBDSM | nope | 21:35 |
| FreeBDSM | mozilla does what it does | 21:35 |
| FreeBDSM | it now does evil things | 21:35 |
| ogra | and nobody here can change that | 21:35 |
| ogra | and nobody here can change that either | 21:35 |
| FreeBDSM | but you do stupid things when you let evil corps lock older versions | 21:35 |
| ogra | we dont do *things* | 21:35 |
| FreeBDSM | and you could change that | 21:35 |
| ogra | we offer a tool | 21:36 |
| FreeBDSM | you also offer a service, don't ya? | 21:36 |
| FreeBDSM | a repo | 21:36 |
| ogra | yes, thats the tool i'm talking about | 21:36 |
| FreeBDSM | the tool is great, I'm here to blame the service | 21:36 |
| ogra | it is super easy to offer a track for each version of firefox ever released in that tool | 21:36 |
| FreeBDSM | I'm not sure I understood what you just said | 21:37 |
| ogra | but the publisher of that ackage decided to not do that | 21:37 |
| FreeBDSM | and back around | 21:37 |
| FreeBDSM | you let the publisher do evil things | 21:37 |
| FreeBDSM | now you just say `we dindo it! they did!` | 21:38 |
| ogra | so again ... in easier words ... the snap store allows a publisher to make all versions available ever released as snaps in different tracks if he wants | 21:38 |
| zyga | FreeBDSM: we shared why snaps work the way they work | 21:38 |
| ogra | there is no limitation in snaps, snapd o the store here | 21:38 |
| zyga | FreeBDSM: you shared your opinion how how that is wrong | 21:38 |
| FreeBDSM | so again, it was your decision to make it so | 21:38 |
| zyga | FreeBDSM: we disagree on principles | 21:38 |
| FreeBDSM | it was a bad decision (IMO) | 21:38 |
| ogra | if *you* would want to do that with a package fo yours you could do that at any time | 21:38 |
| zyga | FreeBDSM: let's be civilized and carry on, the great thing is that you can make a better system | 21:38 |
| kyrofa | Hey zyga, can you explain why we just split instead of supporting shell quoting? https://github.com/snapcore/snapd/blob/master/cmd/snap-exec/main.go#L181 | 21:38 |
| zyga | FreeBDSM: convince us we were wrong by doing something better | 21:39 |
| ogra | just have a track for each version ever existing | 21:39 |
| zyga | kyrofa: hey | 21:39 |
| zyga | kyrofa: I suspect the answer is "gulp" but let me look | 21:39 |
| FreeBDSM | (·̿Ĺ̯·̿ ̿) | 21:39 |
| zyga | https://github.com/snapcore/snapd/blob/master/cmd/snap-exec/main.go#L178 | 21:39 |
| zyga | is the comment above any good? | 21:39 |
| zyga | kyrofa: we split because we apparently refuse shell quoting and other magic stuff | 21:40 |
| zyga | kyrofa: so we split because the input is super restricted where that is the equivalent operation | 21:40 |
| zyga | (that's much better than "gulp" I said above) | 21:40 |
| kyrofa | zyga, the comment talks about how safe it is, but won't this blow up if the command name actually contains a space? | 21:40 |
| zyga | kyrofa: can you give me an example please? | 21:41 |
| ogra | a command name that contains a space ? in shell ?? | 21:41 |
| kyrofa | Yeah, let me actually verify my hypothesis | 21:41 |
| zyga | kyrofa: I think we disallow that but not explicitly, the command _is_ the first word | 21:41 |
| zyga | kyrofa: and since we don't allow quoting | 21:41 |
| zyga | that's that | 21:41 |
| ogra | i dont think thats possible in shell | 21:41 |
| zyga | ogra: I suspect it is | 21:41 |
| zyga | but very evil :) | 21:41 |
| ogra | zyga, commands with spaces in the name ? | 21:42 |
| zyga | yeah, just try it | 21:42 |
| ogra | unless you do weird escaping the thing after the space will always be interpreted as the first arg | 21:42 |
| FreeBDSM | zyga: ogra: by the way, thank you for the civilized discussion. Although I didn't cross any lines I know I sounded trollish (making the situation as absurd as possible -it just a way to argue). | 21:42 |
| zyga | well, "weird escaping" is just escaping | 21:42 |
| ogra | heh | 21:42 |
| FreeBDSM | it's a pity that we disagree | 21:43 |
| ogra | FreeBDSM, well, you didnt get me ... the store actually allows what you want | 21:43 |
| FreeBDSM | ogra: it allows if I'm to become a maintainer | 21:43 |
| ogra | so while we might disagree in principle, what you want it in fact possible | 21:43 |
| ogra | it is just that mozilla decided not to | 21:44 |
| FreeBDSM | and that defies the logic: why would I bother uploading stuff if I could just built something for myself and just use it? | 21:44 |
| ogra | and we dont force anyone | 21:44 |
| pedronis | kyrofa: we don't suppor quoting, so we also don't support commands with spaces in practice | 21:44 |
| ogra | dunno, because you are a social person that wants others to benefit from it too ? | 21:44 |
| FreeBDSM | ogra: please, don't repeat yourself, I already told you my counter-argument to that. | 21:44 |
| zyga | FreeBDSM: calling mozilla compromized, us evil and users stupid feels a bit strong IMO | 21:44 |
| ogra | definitely | 21:44 |
| FreeBDSM | ogra: I am an asocial person and I want comfort for myself first and I neither care, nor mind about the comfort of others. | 21:45 |
| roadmr | FreeBDSM: sorry, you did cross a line | 21:45 |
| zyga | at least I hope you can understand _why_ we made the decisions you disagree with | 21:45 |
| ogra | FreeBDSM, well, then you probably wont package what you built as a snap ... perhaps fame could bribe you ? | 21:45 |
| ogra | roadmr, multiple :) | 21:45 |
| FreeBDSM | zyga: 1. I didn't call you evil, I called mozilla evil. 2. you called users stupid and I said `that's their freedom to be stupid, you have to respect that`. 3. mozilla is in fact compromised and is now malicious. | 21:46 |
| FreeBDSM | roadmr: no. | 21:46 |
| roadmr | yes | 21:46 |
| FreeBDSM | where? | 21:46 |
| kyrofa | zyga, pedronis ah, indeed, quotes in the command actually result in an invalid snap | 21:46 |
| roadmr | there | 21:46 |
| ogra | well, by democratic vote of the people speaking here for the last hour you definitely did | 21:46 |
| FreeBDSM | trollin, I see | 21:46 |
| zyga | FreeBDSM: I don't think people are stupid, I do believe most of us are ignorant about the vast majority of topics | 21:47 |
| zyga | FreeBDSM: most people are highly ignorant of security threats | 21:47 |
| zyga | FreeBDSM: of how the software they use works | 21:47 |
| FreeBDSM | zyga: okay. And that is fine. | 21:47 |
| zyga | FreeBDSM: or what the consequences are | 21:47 |
| FreeBDSM | warn them and go on | 21:47 |
| FreeBDSM | do not limit them forcefully | 21:47 |
| zyga | FreeBDSM: for that we _chose_ to do something so that would be less hurt by their decisions _despite_ being ignorant abou tthat | 21:47 |
| FreeBDSM | because this is the road to hell | 21:47 |
| zyga | FreeBDSM: we chose not to do this for the reasons I stated already: humans largely ignore security because they are ignorant about it and choose convenience | 21:48 |
| kyrofa | zyga, pedronis so we don't expect any command args to have spaces either, then? | 21:48 |
| zyga | FreeBDSM: to effectively make their lives better by handling security we took that option away | 21:48 |
| zyga | kyrofa: not in the snap.yaml | 21:48 |
| FreeBDSM | zyga: that can be very well rephrased into `we think we know better than the users what is better for the users, we will force our decision onto the users, because majority of users is stupid` | 21:48 |
| pedronis | kyrofa: yes, no quoting anywhere, we don't support ' or " | 21:48 |
| zyga | kyrofa: we need to improve that part to allow it | 21:48 |
| pedronis | in the commands | 21:49 |
| pedronis | atm | 21:49 |
| zyga | FreeBDSM: no, that's totally not what I said | 21:49 |
| zyga | FreeBDSM: I chose the words I used very carefully | 21:49 |
| FreeBDSM | that's exactly how I understand it | 21:49 |
| zyga | being ignorant is not being stupid | 21:49 |
| zyga | FreeBDSM: well, you are ignorant of the meaning of the word ignorant then | 21:49 |
| FreeBDSM | okay, read 'stupid' as 'ignorant' | 21:49 |
| zyga | FreeBDSM: I am ignorant of tons of things | 21:49 |
| FreeBDSM | doesn't change the meaning of the sentence much | 21:49 |
| zyga | FreeBDSM: I don't know how to make electricity safe | 21:49 |
| FreeBDSM | `we think we know better than the users what is better for the users, we will force our decision onto the users, because majority of users is ignorant` | 21:50 |
| ogra | it totally changes the meaning | 21:50 |
| zyga | FreeBDSM: I accept that some people do and I let them handle electric wiring at home | 21:50 |
| ogra | one is an insult, the other isnt | 21:50 |
| zyga | FreeBDSM: this is quite like that | 21:50 |
| FreeBDSM | ogra: in my opinion it changes it a very little | 21:50 |
| zyga | FreeBDSM: as I said before, total freedom is anarchy | 21:50 |
| zyga | FreeBDSM: and we're not here to give people total freedom because we believe there's a better way | 21:50 |
| kyrofa | Thanks zyga, pedronis. Makes what I'm working on simpler, although soon folks will be exposed to that limitation (right now snapcraft users aren't), so we might think about changing it if we get complaints | 21:50 |
| zyga | FreeBDSM: those are choices we actively took to make the world better | 21:50 |
| FreeBDSM | I find this of all your choices bad | 21:51 |
| zyga | FreeBDSM: we cannot change humanity's knowledge about modern software issues, threats or consequences of certain actions | 21:51 |
| zyga | FreeBDSM: we did the thing we could | 21:51 |
| FreeBDSM | you could not use restrictions | 21:51 |
| FreeBDSM | I think it would be better | 21:51 |
| zyga | that's okay, nobody is holding a gun to your head asking you to love snaps or die | 21:51 |
| FreeBDSM | it would be more fair | 21:51 |
| FreeBDSM | but you are against fair | 21:52 |
| zyga | you can think that too, | 21:52 |
| FreeBDSM | because you think you know better | 21:52 |
| zyga | we're just saying we disagree and this is how this project is designed to operate | 21:52 |
| zyga | you also think you know better | 21:52 |
| zyga | you think you know better than some of us do | 21:52 |
| zyga | that's okay, you can do that too | 21:52 |
| FreeBDSM | I understand, I'm criticizing the obvious flaws of your design, that's all | 21:52 |
| FreeBDSM | not the whole idea, just the flaws | 21:52 |
| roadmr | and you're saying it too, FreeBDSM : you say "in my opinion", "I think", "I find". Sounds like an agreement to disagree | 21:53 |
| zyga | in absence of measurable data to the contrary we will hold our design firmly | 21:53 |
| zyga | so far we've seen the world of old software that is never updated | 21:53 |
| ogra | but what you see as flws might be seen as benefits by others ... can you accept that fact ? | 21:53 |
| zyga | because it's hard or inconvenient | 21:53 |
| FreeBDSM | in absence of data one can apply logic and logical experiment, logical judgement | 21:53 |
| roadmr | or compare people to hitler | 21:53 |
| zyga | we've seen threats spreading around the planet in half a day | 21:53 |
| zyga | FreeBDSM: we have tons of data | 21:54 |
| FreeBDSM | like what? | 21:54 |
| zyga | FreeBDSM: security is very important to idea of snaps and the people who made them | 21:54 |
| zyga | FreeBDSM: many of the same people were working on ubuntu and other distributions and saw first hand the impact of security issues | 21:54 |
| zyga | FreeBDSM: and looking at the larger ecosystem and insecure old software being the de-facto norm we didn't want to repeat those mistakes | 21:55 |
| FreeBDSM | what is a snap? | 21:55 |
| FreeBDSM | in 1 sentence, please | 21:55 |
| zyga | FreeBDSM: I'm sorry, do you understand my points? | 21:55 |
| FreeBDSM | zyga: I understand them, I'm going to prove you are wrong | 21:55 |
| zyga | I'm not playing | 21:55 |
| FreeBDSM | zyga: what is snap in 1 sentence. | 21:55 |
| zyga | I don't want to talk to you anymore, you made your point | 21:55 |
| FreeBDSM | is it a tool to bring security? | 21:55 |
| FreeBDSM | no | 21:55 |
| zyga | I tried to do my best to explain my view | 21:55 |
| FreeBDSM | it doesn't and can not solve the problem of the security | 21:56 |
| zyga | please get some rest, enjoy fresh air, ride a bike, talk to friends | 21:56 |
| zyga | if you want re-read this conversation piece by piece | 21:56 |
| ogra | he said he's antisocial ... no friends .... | 21:56 |
| FreeBDSM | containers solve some part of the problem of security, firewalls solve another part of the problem of security, anti-viruses solve another part of the problem of security, but snap is neither of them. | 21:57 |
| zyga | I was generous to spend a good chunk of my evening to explain my motivation and the design behind snaps | 21:57 |
| zyga | but I'm not offering to argue ad infinitum about that | 21:57 |
| zyga | so enjoy, maybe someone else will continue the conversation | 21:58 |
| FreeBDSM | most of the time you've repeated yourself and stood deaf towards counter-arguments | 21:58 |
| FreeBDSM | so you didn't really argue | 21:58 |
| zyga | you came here to say the design is wrong, I explained the design first because you didn't seem confident knowing that | 21:58 |
| zyga | anyway, EOT | 21:58 |
| ogra | +1 | 21:58 |
| roadmr | cheers zyga \o/ | 21:59 |
| zyga | :-) | 21:59 |
| FreeBDSM | that's disappointing | 21:59 |
| FreeBDSM | when people refuse to argue - they refuse to change | 21:59 |
| FreeBDSM | when they refuse to change - they get obsolete pretty fast | 22:00 |
| FreeBDSM | these are the laws of nature | 22:00 |
| FreeBDSM | but still, I respect that at least you behaved in a civilized way | 22:01 |
| FreeBDSM | I really came here to just ask if maybe some other user would share their snap with me | 22:01 |
| zyga | hmm, /bin/bash: line 60: killall: command not found | 22:08 |
| zyga | + echo 'Ensure no stray sleep processes are around' | 22:08 |
| zyga | Ensure no stray sleep processes are around | 22:08 |
| zyga | + killall sleep | 22:08 |
| ogra | zyga, dont use killall ... | 22:10 |
| ogra | use pkill | 22:10 |
| zyga | we probably lack killall in the core snap | 22:11 |
| ogra | killal isnt a standard | 22:11 |
| zyga | funny that the test was written with killall before | 22:11 |
| zyga | I just kept using it | 22:11 |
| ogra | pkill is a standard iirc so that should be there | 22:11 |
| zyga | thanks | 22:11 |
| zyga | killall is not in the core snap | 22:11 |
| zyga | that code never ran ^_^ | 22:11 |
| ogra | well, and you obviously dont set -e | 22:13 |
| ogra | else it would have exploded in your face :) | 22:13 |
| ogra | (or at least exited nonzero) | 22:14 |
| zyga | it's more funny than that :D | 22:16 |
| zyga | patch incoming | 22:16 |
| ogra | oh my | 22:16 |
| zyga | https://github.com/snapcore/snapd/pull/5566 | 22:17 |
| zyga | :) | 22:17 |
| zyga | I did git grep in the root of the tree so that's all of them | 22:17 |
| ogra | LOL ! | 22:17 |
| ogra | is that the "skype kills my session" issue ? | 22:18 |
| ogra | (looking at the wayland interface ...) | 22:19 |
| zyga | no, that's just a test | 22:19 |
| zyga | skype caused a segvfault in X | 22:19 |
| ogra | ah, right | 22:19 |
| zyga | no idea why | 22:19 |
| ogra | yeah, i missed the test/ at the beginning of the path | 22:20 |
| ogra | *tests | 22:20 |
| ogra | zyga, oh, btw, looks like nobody from ym team is invited to the sept. thingie ... so no beer :( | 22:25 |
| ogra | *my | 22:25 |
| zyga | oh | 22:25 |
| ogra | yeah :/ | 22:26 |
| zyga | join me at flock! :) | 22:26 |
| ogra | heh | 22:26 |
| zyga | it's in Dresden | 22:26 |
| zyga | is that far from you? | 22:26 |
| ogra | 2-3h | 22:26 |
| zyga | well, :) | 22:26 |
| zyga | just sayin' | 22:26 |
| zyga | jdstrand, jjohansen: is apparmor in 4.15 able to discover paths "across" bind mounts in a way that didn't exist in 4.4? | 22:29 |
| zyga | debugging a very very curious issue | 22:29 |
| zyga | we're seeing a denial | 22:29 |
| zyga | this is the profile: | 22:29 |
| zyga | http://paste.ubuntu.com/p/BSVrZV68RJ/ | 22:29 |
| zyga | this is the denial: | 22:30 |
| zyga | [ 318.394972] audit: type=1400 audit(1532637900.980:30): apparmor="DENIED" operation="file_mmap" profile="snap-update-ns.test-snapd-tools-core18" name="/snap/snapd/452/usr/lib/snapd/snap-update-ns" pid=1054 comm="3" requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0 | 22:30 |
| zyga | notice that it talks about snap-update-ns from the *snapd* snap | 22:30 |
| zyga | the same profile works on 4.4 | 22:30 |
| zyga | in both cases (so on 4.4 and 4.15) snap-update-ns is actually opened from /snap/snapd/(some revision)/usr/lib/snapd/snap-update-ns | 22:31 |
| zyga | now, having said that | 22:32 |
| zyga | we also bind mount /snap/snapd/(revision)/usr/lib/snapd/ to /usr/lib/snapd/ on the host | 22:32 |
| zyga | I may have a partial picture for now, this is still something we are exploring | 22:32 |
| zyga | any advice on how to debug this would be great | 22:33 |
| zyga | I'm looking for the knobs to enable kernel-level debugging of apparmor LSM | 22:33 |
| zyga | do we need a better kernel for that (better = extra options) | 22:34 |
| zyga | again, my kernel tree is in my home office so it's hard for me to check | 22:34 |
| zyga | oh and I forgot to mention | 22:35 |
| zyga | the denial went away after we tweaked the profile | 22:35 |
| zyga | to allow snap-update-ns to come from either the core snap | 22:35 |
| zyga | or from snapd snap | 22:35 |
| zyga | it's just unclear to us why exactly this happened on 4.15 kernel (running core18+snapd) and not on the 4.4 kernel (also running core18+snapd) | 22:35 |
| jjohansen | zyga: no | 22:56 |
| jjohansen | my guess is a change in dpath but it could be something to do with mount flags and mount | 22:58 |
| jjohansen | I'll have to dig | 22:59 |
| zyga | jjohansen: any hints for us on how to look? | 23:03 |
| jjohansen | zyga: well I can tell you its not in the apparmor commits | 23:08 |
| jjohansen | its something, mount/namespace related | 23:08 |
| zyga | can we somehow dump the checks that apparmor is doing? | 23:09 |
| jjohansen | and its probably going to take bisect to trace down | 23:09 |
| zyga | or get more context about the denial before we patch it | 23:09 |
| zyga | ouch | 23:09 |
| zyga | I mean, we will just add the patch that allows "snapd" in the path but it is curious what happened | 23:09 |
| jjohansen | it is curious | 23:10 |
| zyga | I will work with mvo tomorrow to get to a case we can easily reproduce and share | 23:11 |
| zyga | so far it's 'elaborate' to do so perhaps the bug is elsewhere | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!