[01:04] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [01:33] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [01:33] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [01:33] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [01:33] Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate [01:58] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [01:58] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [01:58] Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate [02:33] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [02:33] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [02:37] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [02:37] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [02:38] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [02:38] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [03:22] <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:38] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [03:53] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [03:53] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [03:53] Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate [04:58] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [05:19] morning [05:33] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [05:33] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [05:43] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [05:43] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [05:43] Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate [05:48] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [05:50] so much spam [05:50] PR snapd#5559 opened: tests/lib/snaps: avoid using relative command paths that go up in the directory tree [05:51] yay, mup is alive again [05:58] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [06:13] 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] mborzecki: sure, will do now [06:14] mvo: ta [06:15] mborzecki: done for all arches [06:15] mvo: thanks i'm restarting #5456 then [06:16] PR #5456: snapstate: refuse to remove bases or core if snaps need them [06:17] mborzecki: thank you [06:42] yay, only 14 tests failing on amzn2 [07:27] 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:28] that's the configuration: https://github.com/pbek/hswitch/blob/develop/build-systems/snap/snapcraft/snapcraft.yaml [07:41] o. [07:42] hey zyga ! good morning [07:42] PR core-build#30 opened: scripts: add fixrtc-munt script to fix time issues on pi2,3 [07:43] zyga: right in time for -^ [07:43] 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] zyga: WDYT? [07:46] what's the status of #5271 ? [07:46] PR #5271: cmd/snap: attempt to start the document portal if running with a session bus [07:50] a 2nd review of #5515 would be great [07:50] PR #5515: daemon: make sure most change generating handlers can produce errors with kinds [07:50] pedronis: let me look at this one [07:53] tests continue to be unhappy :( [07:55] mvo: looking [08:02] pbek: 18.04 is not fully baked yet, [08:02] zyga: ah, thank you! [08:02] PR core-build#31 opened: add shellcheck on build and fix open issues [08:03] zyga: I did a tiny fix and force pushed to #30 [08:03] I just noticed :) [08:03] zyga: sorry, silly thing based on #31 [08:03] PR #31: Feature/snapfs refactor [08:03] sorry for being slow, some interruptions at home and I'm the last one standing [08:04] what was the change? [08:04] zyga: for word in $(cat /proc/cmdline) must not be quoted [08:05] zyga: I did this incorrectly in the initial push [08:05] I see [08:05] right [08:06] 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:07] zyga: "last one standing" - are you guys sick? [08:09] mvo: not all sick but I'm the only one that can do stuff [08:10] but all is good now [08:10] ok [08:10] as in: no fires, not starving, can work :) [08:13] 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:15] heh fixed in 2015 https://git.savannah.gnu.org/cgit/coreutils.git/commit/src/date.c?id=17bbf6ce44eb543a95695fa9d2cbd70fb52c6f42 [08:15] mvo: reviewed [08:15] mvo: thank you btw! [08:15] mvo: lastly, this is something I would much much much rather write in C [08:16] mvo: to break away from the mantra that we must endure shell [08:18] mvo: the commit message is slightly wrong [08:18] last mount time is updated [08:18] but because of the mechanism I explained on the forum, it advances very slowly [08:18] last write time is not updated [08:19] zyga: ok, let me fix the commit message (is force push ok?) [08:21] mvo: I'm looking the other way now ;) [08:21] mvo: have you tried it on your device? [08:22] zyga: not yet [08:22] zyga: its a bit painful, I'm inclinded to merge and build a new edge core [08:24] zyga: thanks for pointing the issue out, I will fix (it seems they were cargo culted) [08:25] zyga: off-by-one space? I don't see this or look for the wrong thing, can you help me please :) [08:28] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [08:32] mvo: I'd suggest actually patching initrd in the wild unless that's very tough, iteration through master is slow [08:32] 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] zyga: oh, probably tab vs space, its not visible for me [08:33] mvo: also really think about coding this in C [08:33] this is like 3 function calls, stat, current date,(conversion), comparison, set date [08:34] (4 including some conversion perhaps) [08:34] mvo: all the prereq stuff can go away [08:34] all the cmdline stuff can go away [08:34] it will never be off by a typo that we don't see [08:36] PR snapd#5515 closed: daemon: make sure most change generating handlers can produce errors with kinds [08:36] 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] zyga: is there an alternative that is quicker? [08:36] mvo: thx [08:36] mvo: iteration through master -> build -> core snap -> refresh is slow [08:37] mvo: I though that is what you meant [08:37] PR snapd#5434 closed: overlord: introduce InstanceKey to SnapState and SnapSetup, renames [08:37] zyga: do you know what is the status of #5271 ? [08:37] PR #5271: cmd/snap: attempt to start the document portal if running with a session bus [08:38] pedronis: I don't think so, let me refresh my memory [08:39] I mean, there was just the issue of old xdg-document-portal [08:39] I will discuss this with jamie today [08:39] old portal on a distribution [08:46] zyga: hm, not sure I understand, sorry, maybe a bit slow this morning [08:46] no worries, [08:46] just do as you think is best [08:49] 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] 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:51] 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] Chipaca: could you take a look at #5559 ? [08:51] PR #5559: tests/lib/snaps: avoid using relative command paths that go up in the directory tree [08:51] 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] mborzecki: no; looking now [08:52] Chipaca: thx [08:52] mvo: we can HO at any time if you want [08:52] zyga: aha, got it now [08:52] mborzecki: wrt /etc/os-release, I think we shouldn't be using the host's one [08:53] zyga: I'm very confident in the fix :) [08:53] zyga: but yeah, testing locally makes sense [08:53] Chipaca: agreed, need to discuss the right solution with zyga though [08:53] plus, anything you find and document as HOWTO will improve the next cycle :) [08:54] zyga: I will wait for ogra_ and/or abeato to review https://github.com/snapcore/core-build/pull/30 [08:54] PR core-build#30: scripts: add fixrtc-munt script to fix time issues on pi2,3 [08:55] mborzecki: any reason not to implement dropping support for relative paths that go outside the snap, and supporting absolute paths? [08:55] mborzecki: other than it being a harder change i mean :-) [08:56] 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:57] mborzecki: there weren't when we checked last [08:57] Chipaca: let me put that in my todo list then and i'll push that in a follow-up [08:58] mborzecki: there's no rush imo [08:58] Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [08:58] or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [08:58] PR snapd#5559 closed: tests/lib/snaps: avoid using relative command paths that go up in the directory tree [09:04] mvo, zyga ... do you actually want the boot to hang when setting the clock fails ? [09:04] 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] mvo: no [09:04] mvo, i'D rather remove the -e and leave exit 0 in [09:04] er, ogra_ no :) [09:04] ogra_: yes, I commented about that [09:04] JamieBennett: ^- [09:05] I am on vacation. If I op you cjwatson can you do it? [09:05] Sure. [09:05] zyga, right, but only the exit 0 was removed ... and -e left in ... thats exactly the opposite of what i said ;) [09:05] ah, I didn't see that [09:05] mvo: ^ ogra is right [09:05] we should not set -e this scrpit [09:05] Thanks [09:06] and this highlights that shell sucks and this one should be C === 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 [09:06] popey: enjoy your time off, hide from IRC :) [09:07] I'll leave myself opped in case I need to deal with any fallout from that [09:07] thank you cjwatson ! [09:15] zyga: sure, let me fix that [09:16] * zyga hugs mvo [09:16] thank you! [09:16] ogra_: might be worthwhile to do the same fix in the original fixrtc (remove the set -e) [09:16] hello [09:17] zyga: shall I also use /var/lib/snapd/state.json? [09:18] mvo: I'd keep using the directory [09:18] mvo: and touch it in shutdown [09:18] mvo: is the state.json _always_ guranteed to be there? [09:18] guaranteed [09:18] actually, we could even stat / itself [09:18] and just touch that [09:18] no chance for that to hide :) [09:18] I'm trying to package a python3 app using snapcraft. the snapcraft.yaml is pretty simple: https://pastebin.ubuntu.com/p/KHPy9d3Qr3/ [09:18] zyga: its not but thats easy enough to [ -f ] for [09:18] but I always get this error: [09:18] Could not find a version that satisfies the requirement qmenta-gui (from qmenta-app==1.95.9) (from versions: ) [09:19] No matching distribution found for qmenta-gui (from qmenta-app==1.95.9) [09:19] zyga: touch on shutdown is one more moving part [09:19] 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] zyga: "/" might be readonly [09:19] mvo: yes but note that state.json is also a moving part and it may still rewind the time in bad cases [09:19] touching / on shutdown prevents that [09:20] mvo: (where rewind time is that there are _any_ files in the filesystem that would appear from the future) [09:20] greyback_: :p [09:22] zyga: with touch on shutdown I think the current PR is final now, I addressed the feedback from ogra_ and abeato [09:22] mvo: thank you [09:23] actually [09:23] mvo: one more question [09:23] mvo: what sets the "fixrtc" in the command line? [09:23] I mean, does uboot on pi does that? [09:23] zyga: its part of the gadget [09:23] zyga: yes [09:23] where is that specified [09:23] aha [09:23] would you feel ok not checking for that [09:23] just dropping the whole cmdline parsing? [09:23] after all, it cannot hurt [09:24] if the time is more into the future we won't change it [09:24] whoops, why am i OP ? [09:24] 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:25] mvo, agreen (regarding fixrtc) but that needs to happen in the distro package ... [09:25] ogra: you have that special bit :) [09:25] *agreed [09:25] 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] ogra: yeah, was just wondering alound, not urgent or anything [09:25] zyga, well, i only changed my nick ... and registered ... wasnt aware that IRC keeps such states [09:27] mvo: are you worried that the change could regress something elsewhere? [09:28] ogra: baseline IRC doesn't, but chanserv has a configured access list for each channel [09:29] (also you can register alternate nicks if you want to return to the underscored form ...) [09:29] abeato: here? [09:30] cjwatson, nah, i'm fine i was just surprised [09:31] zyga: yeah, risk is small but it would be super annoying [09:32] 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] zyga, we have fixrtc on the commandline of all relevant gadgets [09:32] (just not on pc iirc) [09:32] mvo: right but we must trust the code to DTRT where it matters [09:33] ogra: I think zyga point is that the script should be safe everywhere so why bother checking [09:33] mvo: I approved the PR and left two comments [09:33] mvo: that essentially re-state those [09:33] zyga: ta [09:33] ah, k [09:33] but I agree it's important to move [09:36] zyga: yeah, lets do this minimal fix for now, maybe its just be being overly cautious [09:36] zyga: thanks for the review and the ideas! [09:37] 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:39] mvo, just using a recent edge image and calling any "snap set" should expose it [09:39] mvo: the time issue is easy to reproduce [09:39] 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] mvo: the apparmor issue is something I'm exploring (outside of core, to show where it happens) [09:39] s/where/how/ [09:39] so that there is an old cache file in place [09:41] is anyone here familiar with the python plugin? [10:00] lool, ping [10:00] abeato: pong [10:01] lool, ok looks like I can write here now, thanks :) [10:04] 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:05] zyga, I created a small program that uses the same flags, and when run unconfined all is good [10:05] this does not happens for USB serial ports, I wonder what is special here [10:08] abeato: thanks for your script! its in now (and for the review) [10:09] mvo, nice to see that merged in core, it was an issue we saw in some devices :) [10:10] zyga, https://paste.ubuntu.com/p/qWV9FBzWtj/ [10:18] abeato: is that device present (major:minor) in the per-snap device cgroup? [10:19] zyga, ah, cgroups, that might be the issue... I guess no, how can I check that? [10:21] abeato: go to /sys/fs/cgroup/devices [10:21] then look at snap.foo name groups [10:22] then at various files, I think devices.allow is the one [10:23] zyga, devices.list, and yes, I do not see the majour:minor for this device there, can this be modified from an interface? [10:24] abeato: indeed it can [10:24] abeato: this is the udev backend [10:24] abeato: you can use a simple helper method to tag devices to add there according to udev rules [10:25] zyga, got it, thanks [10:25] pedronis: thanks for the review on snapsup/snapstate parts, do you think you'll get a chance to look at #5452 too? [10:25] abeato: let me know if you need help [10:26] :) [10:28] * mborzecki wonders if he should try linux-hardened + apparmor on arch [10:36] 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] no [10:36] it's not related to apparmor in any case [10:37] you need udev backend specification object to add a rule to tag a device at runtime [10:37] abeato: look t... [10:37] where can I find an example? [10:38] https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port.go#L196 [10:38] look at anything that calls TagDevice [10:38] I just found a random one [10:38] the argument is a partial udev expresssion [10:38] look at what happens to get a feeling about how this works [10:38] it essentially expands to something like this [10:39] 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] then snap-confine uses those tags to pre-populate the cgroup [10:39] and also udev uses the same expression to add/remove devices as they are added/removed in the system (live changes) [10:40] zyga, ah, got it now, thanks [10:40] super, good luck! [11:11] mborzecki: yes, this afternoon [11:13] pedronis: great, thank you [12:12] pedronis: opened another PR #5561this is snapstate changes with run through tests [12:12] #5561 [12:13] mup doesn\t work? [12:13] * Chipaca kicks mup [12:13] oh wait, that was lalita [12:19] 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, jdstrand, well, thats the micro USB driver that has never been rock solid [12:55] though i dont remember this particular error [12:55] smells like a wrong value in the dtb [12:56] jdstrand, https://e2e.ti.com/support/arm/sitara_arm/f/791/t/324491?AM3352-USB-DRVVBUS-does-not-stay-active-when-device-connected# [12:59] hmm, seems to also be triggered if the board is underpowered and the USB port draws too much current [13:00] 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:12] jdstrand, is that a new kernel ? i dont see the msg here with the latest stable linux-generic-bbb [13:13] ogra: 4.4.0-93-1 [13:13] ogra: it is the first time I've seen it (saw it in my logs) [13:14] do you have any USB devices attached ? [13:14] ogra: hey, crazy idea [13:15] ogra: no. I don't know if the ethernet is hardwired (I have the power and an ethernet cable plugged in) [13:15] ogra: does pi have any form of RTC that runs as long as the board is powered? [13:15] oh, i should probably push 4.4.0-127-1 from edge to stable :P [13:15] ogra: and if so, could we at least retain RTC across reboot (not across poweroff) [13:15] that would be neat IMO [13:15] ogra: I do have the pings wired up for serial, but the usb end is not plugged into anything [13:15] ethernet is hardwired ... not USB [13:15] most of the time those devices will just reboot on upgrade [13:16] 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] jdstrand, released ... let me know if you still see it after refresh [13:17] 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] nothing in the SoC ticks with 32K freq? [13:18] dunno ... perhaps it does, but you'd still need to preserve the timestamp across a reboot [13:19] 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] did you look at that fake-hwclock from raspbian and how it works ? [13:21] perhaps they have a better solution here [13:22] 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] desktop-launch elapsed time: 0.994528127 [13:22] Now running: exec gnome-calculator [13:22] mvo, then it takes ~10-20 seconds for the UI to appear [13:23] mvo, it looks like that exec is what's taking so long [13:23] hmm, looking at the debian fake-hwclock script it does nothing with hardware, only reads and writes a file [13:24] kenvandine: how do you measure? [13:24] kenvandine: => forum is better [13:24] kenvandine: but as a profiling case, run hello-world [13:24] (shell) [13:24] everything else is overhead of helpers and the app code itself [13:24] yeah, that's fast... so it's puzzling [13:25] i added some output to desktop-launch which shows the difference in time between the beginning and the end of the script [13:25] the only thing i'm not timing is the exec itself [13:25] I don't know desktop-launch [13:25] can you collect this in the forum [13:25] I bet we're missing something [13:25] sure [13:25] thanks! [13:26] i'll post it [13:26] 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:27] ogra, i'm talking about the first launch [13:27] ah [13:27] i added profiling for that, and it's actually must faster than i thought [13:27] but that exec is taking ages [13:27] and that exec is much faster the second time [13:28] 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] yeah, i'm timing everything up until exec [13:29] and you are sure the external binaries have all returned by then ? [13:29] yes [13:29] weird [13:30] time the target of the exec [13:30] 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] probably not the binary [13:30] maybe it's loading all the libraries into memory the first time is slow? [13:30] but just another layer of scripts [13:30] kenvandine: rm -rf $SNAP_USER_DATA [13:30] it will be slow again [13:30] it's not the libraries [13:30] loading all the libs would be slow after reboot. this is only after install/refresh afaik [13:31] zyga, i am doing that for my testing [13:31] also common I suspect [13:31] i'm doing a reboot to see if that exec is slow again [13:32] niemeyer, jdstrand: please let me know when you want to sync on the cache issue [13:32] I will break for lunch now [13:33] ah... that exec is slow again after a reboot [13:33] so maybe it is all just overhead of library loading [13:33] we do have quite a path [13:33] that would be super odd [13:33] do you have a HDD? [13:33] yes... this is in a VM too [13:33] kenvandine: aha [13:33] kenvandine: as a "non scientific" ballpark test [13:33] it is much faster in my laptop :) [13:33] open a terminal after reboot [13:33] run "dstat" in it [13:33] let it run for a few seconds [13:33] then run the app [13:34] and correlate activity [13:34] interesting [13:34] it shows IP [13:34] IO, CPU and lots of useful stuff [13:34] in one simple format [13:35]