=== JoshStrobl is now known as JoshStrobl|AFK === robert_ancell_ is now known as robert_ancell [03:46] PR snapcraft#1568 closed: lxd: don't re-inject the same snaps [03:46] PR snapcraft#1618 closed: states: add scriptlets to build state [05:21] o/ [05:49] mvo: hey [05:49] just the man I wanted to see [05:51] mvo: https://github.com/snapcore/squashfuse/pull/1 [05:51] PR squashfuse#1: Tweak implementation of dummy go module [05:51] hey zyga-ubuntu [05:53] zyga-ubuntu: hyes, thanks for this PR! did you test it, does that work? I also tried a subdir approach and go get would only checkout the actual dir, not any other dirs. if it works, that would indeed be very nice [05:53] zyga-ubuntu: (i was doing it the other way around, the C source in a subdir) [05:53] mvo: it go builds but I didn't test the full govendor sync with it (I'd have to change paths) [05:53] mvo: right but that failed for me [05:53] mvo: the linker part was not working [05:54] mvo: and govendor complained if nothing referenced that [05:54] mvo: now it's working locally, if you commit I will be able to sync [05:54] zyga-ubuntu: let me try quickly based on your branch, if it works, +100, very nice [05:54] if it doesn't work we can remove that patch from history [05:54] mvo: one sec [05:54] http://paste.ubuntu.com/25757470/ [05:54] you want this in your snapd tree [05:55] zyga-ubuntu: oh, nice, yeah, this way around it works [05:55] zyga-ubuntu: \o/ [05:56] I can push this into your branch [05:56] zyga-ubuntu: please do, I will take care of the rest, that will simply some things [05:56] just say the word [05:56] done [05:56] zyga-ubuntu: thanks [05:56] zyga-ubuntu: (I guess that was the word your were looking for ;) [05:56] * mvo hugs zyga-ubuntu [05:57] woot, I hope we can quickly solve this [05:57] do you want to make .6 with this feature? [05:57] zyga-ubuntu: no more 2.28 :) it will be part of 2.29 [05:57] zyga-ubuntu: unless regression of course, then there will be a .6 [05:59] hmmmm [05:59] Obtaining dependencies [05:59] Found unused ./vendor packages: [05:59] vu github.com/snapcore/squashfuse [05:59] Please fix via 'govendor remove +unused' [05:59] darn, govendor is too picky [05:59] why doesn't it see the test reference? [06:00] is govendor really syncing sudirectories or nothing? [06:01] zyga-ubuntu: hm, it is not complaining here, strange [06:01] let me reset my tree [06:02] it didn't complain when I had the tree in $GOPATH [06:02] but now it does [06:02] now I just need to make autogen.sh work in squashfuse [06:02] darn govendor [06:02] maybe we can just make get-deps.sh not fail on that? [06:03] zyga-ubuntu: I removed everyting squashfuse from my GOPATH and ran tests again, no error [06:04] * zyga-ubuntu thinks [06:04] well [06:04] if it works in the build I'll be happy [06:04] mvo: and you want to twaek autogen for local development? [06:04] mvo: I'm building the package now [06:05] zyga-ubuntu: it complains for me about SQ_WANT_HIGHLEVEL missing [06:05] eh, "does not appear in AM_CONDITIONAL" [06:05] (not missing) [06:05] mvo: the beauty of autohell [06:05] zyga-ubuntu: did this work for you? [06:05] yes [06:05] but something odd is going on [06:05] zyga-ubuntu: I'm on artful, maybe because of that? [06:06] mvo: I just saw your dummy-{gcc,ld} output [06:06] something must be cached somewhere [06:06] ah [06:06] man, we didn't change the hash in vendor.json [06:06] zyga-ubuntu: git pull [06:06] I'm on artful too [06:06] k [06:06] zyga-ubuntu: that will update the vendor.json [06:06] got that now [06:06] fatal: Could not parse object 'f066269fbbcd0ec6232cdffbc0fe48c7e2f7ad97'. [06:07] woah [06:07] # cd /home/zyga/go/.cache/govendor/github.com/snapcore/squashfuse; git reset --hard f066269fbbcd0ec6232cdffbc0fe48c7e2f7ad97 [06:07] thats strange I just did "govendor fetch github.com/snapcore/squashfuse" [06:07] I'll kill that cache [06:08] now it worked [06:08] weird [06:08] maybe the cache was confused by my operations on the local tree earlier (I squashed/amended) [06:08] building in progress [06:08] zyga-ubuntu: yeah, just double checked, the hash i nthe vendor.json matches the git repo [06:09] it failed on three automake things now [06:09] Makefile.am:6: error: MAKE_EXPORT does not appear in AM_CONDITIONAL [06:09] Makefile.am:36: error: SQ_WANT_HIGHLEVEL does not appear in AM_CONDITIONAL [06:09] Makefile.am:48: error: SQ_WANT_LOWLEVEL does not appear in AM_CONDITIONAL [06:09] I think we are now in sync [06:10] yes [06:10] same that i get [06:10] brb, daughther goes to school [06:31] re [06:31] sorry, kids as usual :) [06:32] mvo: are you patching those? [06:32] I just started [06:32] zyga-ubuntu: hi, looks like issue #12 for squashfuse discusses the issue we are seeing [06:32] PR #12: Bugfix/lp1480248 test reenable [06:32] mvo: looking [06:32] zyga-ubuntu: I patched them but got stuck right after that :/ [06:33] hehe, look who reported it [06:34] mvo: how does it build in the archive? maybe there's a patch [06:34] zyga-ubuntu: aha, good idea [06:34] zyga-ubuntu: fwiw, feel free to attach your patch :) [06:35] mvo: I don't have anything yet, just reading the configure script now [06:36] zyga-ubuntu: mehhhh [06:36] mvo: I find it sad/silly that a half a dozen C file project is so hard to build [06:36] wat? [06:36] zyga-ubuntu: the m4 subdir is missing I think [06:36] I see it here [06:36] missing as in not copied somewhere? [06:36] zyga-ubuntu: thats govendor again, its really annyoing about subdirs [06:36] ah [06:36] zyga-ubuntu: rm -rf the squashfs and get it again [06:36] mv dummy m4/ [06:37] zyga-ubuntu: and then check the dir [06:37] ah, right, I was looking at the full git tree [06:39] did you get [06:39] extract.c:51:17: warning: implicit declaration of function ‘sqfs_makedev’; did you mean ‘sqfs_mode’? [-Wimplicit-function-declaration] [06:42] zyga-ubuntu: I wonder how to overcome the m4 subdir problem [06:42] mvo: mv dummy m4/dummy [06:42] done [06:42] we'll get the full set [06:42] (silly but, well it should work) [06:42] zyga-ubuntu: heh, smart [06:43] mvo: I'd say sad but I think we are in agreement :) [06:43] * mvo hugs zyga-ubuntu again [06:43] mvo: I'll try something entirely different to see how crazy that would be [06:44] zyga-ubuntu: I update the trees for your approach in the meantime [06:44] ok [06:45] mvo: note that squashfuse uses a library now [06:45] mvo: where will we keep it? [06:45] mvo: it seems we need to link that statically [06:46] zyga-ubuntu: yes, we need to link statically [06:46] mvo: note, just the library, the rest can be dynamic [06:46] (to avoid hair-pulling in other distros0 [06:53] zyga-ubuntu: hm, adding github.com/snapcore/squashfuse/ does no longer work for me without go files in it, it is just silently ignored [06:54] mvo: take a break from this problem for two hours please [06:54] mvo: if my approach fails we can go back to adding more hackery [06:57] zyga-ubuntu: ok [06:58] mvo: how are we calling the binary? snapfuse? [07:00] zyga-ubuntu: yes [07:00] zyga-ubuntu: https://github.com/snapcore/snapd/pull/4049/commits/bff17ef731ea8e2bc88a1ab2066b33a2bc8c0e31#diff-42c07ec7ffa970857b4e0db2614e482bR428 [07:00] PR #4049: debian,vendor: import github.com/snapcore/squashfs and use [07:02] thank you! [07:03] Lo. Is it still possible somehow to set up your own snap store and configure snap to use it? Looks like https://github.com/noise/snapstore/ stopped working a while ago and was abandoned recently. [07:03] I already asked on https://plus.google.com/+ThorstenLeemhuis/posts/HyHfxaFQWz2 but got no reply [07:10] knurd: please look at forum.snapcraft.io, this has been extensively discussed there under the topic "extenral repositories" [07:12] zyga-ubuntu: thx for the pointer! [07:14] wa [07:28] mvo: almost there, I think [07:30] zyga-ubuntu: btw i poked at 2.28.5 in debian, i didn't do the dependency updates though [07:30] i should push what i have to alioth i guess [07:30] vendor.json diffs are hard to read :( [07:32] fwiw 4047 needs a second review [07:34] mwhudson: ack [07:34] mwhudson: I'll have a look, I cannot promise anything soon though (I need to trim my PR list) [07:34] yeah. o [07:34] bah [07:35] yeah, i'll try to poke at it over the next couple of days too [07:35] mvo: http://pastebin.ubuntu.com/25757771/ [07:35] mvo: integrated into our build system [07:36] zyga-ubuntu: nice, I wonder if libfuse is installed by default [07:36] and 4028 (easy) needs a second review [07:39] zyga-ubuntu: curious what you did and how you overcame the m4 subdir issue [07:40] mvo: I can link that statically [07:40] zyga-ubuntu: I think we just need to check in the lxd base image [07:40] mvo: I just integrated that into our build, the whole set of m4 macros is needed for things we don't need [07:41] we can also drop code like non xz compression and windows support files [07:41] zyga-ubuntu: *nod* [07:47] mvo: shall I review 4028? :D [07:48] zyga-ubuntu: ;) I was hoping pstolowski or chipaca might have a look [07:50] mvo: I tweaked the build system to simplify what we need, I'll run a spread test if that works [07:50] mvo: I'll push this for reference but I want to re-do it so that we can import git history [07:51] mvo: we might be able to pull in fixes from squashfuse upstream this way [07:51] mvo: so far so good though [07:51] approved [07:51] mvo: we can also go through the code and simplify windows bits out [08:17] mvo: builds are ok, testing in spread [08:19] mvo: once this works I'll ask you to review and then let's see what to do about history, ok? [08:21] ok [08:21] mvo: https://github.com/zyga/snapd/tree/rfc/integrated-squashfuse [08:21] this is the code [08:22] mvo: and this is the new part essentially: https://github.com/zyga/snapd/commit/3545b115cb90e702779c43703f70db9e01b10cff [08:28] mvo: lxd test now running [08:28] fingers crossed [08:38] doh :) [08:38] silly mistake [08:38] fixed now, re-running tests [08:38] I didn't enable XZ [08:38] moin [08:40] Chipaca: hey [08:51] mvo: it works now, I think I need to expand this to cover more packaging [08:56] zyga-ubuntu: just cherry pick my bits from https://github.com/snapcore/snapd/pull/4030 [08:56] PR #4030: many: add internal squashfuse copy as "snapfuse" [08:56] mvo: aha, thank you [08:57] zyga-ubuntu: I will revert 4049 back to the original state, lets see what niemeyer thinks about the two approaches as they have boths pros/cons [09:00] Hello, I have a Dell atom based mini PC came pre-installed with Ubuntu Core 16. I would like to know if it is possible to install cmake and domoticz packages on it? I am a newbie to Snappy, please pardon me. [09:01] zyga-ubuntu: but maybe/probably the govendor approach is doomed as it cannot statically link selectively via configure [09:03] mvo: fingers croessed [09:03] mvo: https://github.com/snapcore/snapd/pull/4051 [09:03] PR #4051: many: add integrated snapfuse [09:03] PR snapd#4051 opened: many: add integrated snapfuse [09:03] mvo: I'll break for shower/coffee as I'm still in my pijamas today [09:03] Tazmania: if you want to develop its probably easiest if you "snap install classic; classic" [09:04] Tazmania: eh, "sudo snap install --devmode --beta classic" that is [09:04] zyga-ubuntu: heh, thank you! [09:04] Tazmania: and please look at forum.snapcraft.io, lots of friendly people there and lots of questions answered already [09:04] What's the difference between classic and the pre-installed? [09:04] zyga-ubuntu: thanks. I will check the forum [09:04] zyga-ubuntu: did you add a patch to fix the sqfs_makedev() error ? [09:05] mvo: compare diffstat in 4030 and 4051 [09:05] automake is crazy [09:05] mvo: hmmmmm, I don't think I did [09:05] Tazmania: classic is a environment that makes it easy to develop using the classic tools [09:05] mvo: thanks [09:05] mvo: have a look at my branch please, let's see what we can cut from snapfuse/*.[ch] [09:05] zyga-ubuntu: interessting, I get a warning that is turned into an error here [09:06] mvo: hmm, spread passed for me, hmmm [09:06] zyga-ubuntu: cool [09:06] maybe I did but I didn't notice :) [09:06] anyway, afk for a moment [09:07] zyga-ubuntu: lets see what gustavo thinks, I personally would like to make snapfuse as much "imported" as possible and ideally not modify it but I see the advantages so lets see how gustavo feels about what approach should be taken [09:07] zyga-ubuntu: see you [09:14] mvo: shall we prepare an alt version that has working imported approach? [09:15] mvo: I mean, it might be even this code, we could just depend on a script that gets the debian .orig tarball [09:15] mvo: (via get-deps) [09:16] diddledan: sorry for the delay, testing your corebird snap [09:18] zyga-ubuntu: lets talk after you had your shower, I'm not sure myself. [09:19] I'm back already [09:20] mvo: ok, I'll look at failing tests in one of my PRs and let's wait to see if 4051 is green [09:37] zyga-ubuntu: for when you are back - do you happen to know why none of our tests caught the typo https://github.com/snapcore/snapd/pull/3617/files#diff-ec8cacef522dbb27eeb9ceed25f03b22R249 ? I mean, we have a integration test for network-control, why does that not fail on invalid content? can we add that? [09:37] PR #3617: interfaces/builtin: use udev tagging more broadly [09:39] mvo: looking [09:39] aha, that typo [09:39] let me think [09:39] zyga-ubuntu: I'm breaking it on purpose now and run the spread test to see if our checks are insufficient [09:40] zyga-ubuntu: does udev not error when we write incorrect files? [09:40] mvo: are those tests checking tun devices? [09:40] mvo: I think the file was parsing OK, just not doing what we wanted [09:41] zyga-ubuntu: no, no checks for tun devices. hm, ok, if its valid syntax just the wrong one that is hard to test [09:41] mvo: maybe if the rules looks like `KERNEL=="foo", TAG+="...",\nKERNEL=="bar", TAG+="..."` the rule is just a no-op [09:41] mvo: as in, it will never match both "foo" and "bar" [09:41] zyga-ubuntu: there was an extra "," at the end of the line [09:41] I can test that theory but I need to get to the bottom of something failing in my branch first [09:41] (in this particular case) [09:41] mvo: right but , is a separator for udev expressions [09:42] zyga-ubuntu: sure, I can chase this [09:42] zyga-ubuntu: aha, ok [09:42] mvo: we could build a simple safeguard [09:42] mvo: add a new api to udev.Specification [09:42] mvo: that has less flexibility in it [09:42] mvo: we could then rewrite vast majority of udev rules to use that [09:43] mvo: and maybe keep {modem,network}-manager as the only uses of the more powerful, type-unchecked api [09:43] mvo: essentially there's no type checking anywhere there [09:43] mvo: we could also have a test that parses all the snippets [09:44] mvo: and ensures that some simple impossible conditions are not present [09:44] mvo: like tests that attr == "a" and attr == "b" at the same time [09:44] mvo: I did something similar-ish for apparmor rules earlier (I was fully parsing them, there's still a branch somewhere I can find) [09:44] zyga-ubuntu: ok, thank you. sounds all like some work [09:46] mvo: sorry, it's not apparmor, it was seccomp, [09:46] mvo: the branch starts at 87826dc09a7a43357500329032185544b53c5c91 [09:46] mvo: feature/typed-syscalls in my remote [09:46] mvo: that ensures that seccomp rules are well typed [09:47] mvo: udev rules are not too sopisticated, we could do something like that too [09:47] mvo: even if it's just for testing [09:47] * Chipaca realises the time and runs to make it to physio [09:47] Chipaca: o/ [09:47] run slowly and safely man [09:49] * zyga-ubuntu fixed his other brnach [09:52] pstolowski, zyga-ubuntu: related, the lxd-demo-server stopped because we had lxd as reserved for the OS, when that started to fail we changed something else, right? more strict checking in the interfaces code, does anyone remember details? [09:52] hey Chipaca [09:52] (sorry for the many questions, writing the retrospect right now) [09:53] mvo: I don't remember, let me look [09:53] mvo, there was a change recently (the week after the sprint) to that interface [09:54] Hi Guys, I'm trying to build Ubuntu Core for Nvidia TX1 it's a arm64 bit system. I'm following this guide: https://wiki.ubuntu.com/ARM64/FoundationModel but the link to download ubuntu-core-13.10-core-arm64.tar.gz is broken. I have tried to find a more recent version of the core for arm64 but without luck.. [09:54] mvo: I only found 042f9d0085bf6fe0ff82345cc58804d9e21eb318 [09:54] Does anyone know where I can find it, if it exist? [09:54] skjensen: ubuntu-core-13.10? [09:54] ogra_: ^ [09:54] I would like ubuntu-core-16.04 [09:54] I think that's something for you [09:55] pstolowski: yes, we fixed the issue in that PR a week after the sprint. I wonder what commit/PR broke it though, it was reserved for the OS since forever afaik. [09:55] zyga-ubuntu, mvo yes, that's the change I meant [09:55] mvo: I think we just never tested that combination mvo [09:55] mvo: you added a test for this later [09:55] mvo: after the brekage occurred [09:55] zyga-ubuntu: stgraber reported lxd-demo-server used to work and started breaking with 2.28 [09:56] zyga-ubuntu, pstolowski ok, I chase that, thanks for your input! [09:56] skjensen: ogra is the person for that question, I think there is (or might be) a model/gadget/kernel for TX1 but I'll let him answer with authority [09:56] wow, incredible, I can actually write a new feature now [09:56] and it's 11:56 [09:56] skjensen, the old ubuntu-core has been enamed to "ubuntu-base", tarballs can be found at http://cdimage.ubuntu.com/ubuntu-base/ [09:56] *renamed [09:57] Great thanks.. :) Is there one for the TX1? [09:58] mvo: I spoke too soon, the fuse stuff, no fuse on 14.04 [09:58] mvo: so packaging diverges [09:58] mvo: and this is now optional [09:58] mvo: meeh [09:59] skjensen: do you want classic ubuntu headless or the new snap-based ubuntu (aka ubuntu-core nowadays) [09:59] skjensen, if you want an actual snap based UbuntuCore install then you need to create a gadget snap and use ubuntu-image to build an image for it ... the jetson tk1 is supported in the llinux-generic-bbb kernel (by selecting the tegra124-jetson-tk1.dtb devicetree froom the gadget snap) [09:59] I want the new snap-based ubuntu due to the new features. It's for a IoT deployment [10:00] skjensen, the -base tarballs are just root filesystems just pick the arm64 one [10:01] skjensen: I'd suggest you open a forum thread about TX1 core image [10:01] skjensen, aha ... https://ograblog.wordpress.com/2017/05/30/building-u-boot-gadget-snap-packages-from-source/ and https://ograblog.wordpress.com/2017/06/13/patching-u-boot-for-use-in-an-ubuntu-core-gadget-snap/ ae what you want then [10:01] clobrano: hey [10:01] skjensen: you should familiarize yourself with some snappy concepts (models, gadget snaps, kernel snaps) to make a proper set of files needed to support this [10:01] kalikiana: hi [10:02] c-lobrano: You wanted to work on bug 1722650? [10:02] Bug #1722650: snapcraft requires optional VERSION_ID in os-release [10:02] skjensen: doing that on the forum is easier and many people can participate (across timezones) [10:02] skjensen, create that gadget, make it use tegra124-jetson-tk1.dtb and once you have that ping me again and we'll talk abut how you get yur own kernel build fom the linux-generic-bbb snap [10:02] ogra_: btw, do you have the TX1 or the TX2? [10:02] ogra_: are they decent machines? I was thinking about getting one simply because it has oodles of ram (for an arm board) [10:03] zyga-ubuntu, nope ... i stopped after tegra2 ... [10:03] kalikiana: yes, but before pushing a change according to what you suggested, I'd like to see what kind of file snapcraft is looking for [10:03] ogra_: aha, thank you [10:03] they shoudl be in the relam of a dragonbard [10:03] I got the TX1 and actually got a TK1 as well.. But we decided we needed the TX1 to run out software since it uses TensorFlow and that's not supported anymore on the TK1 [10:03] c-lobrano: Do you have a local checkout of snapcraft? [10:03] mvo: shall I change the snapfuse PR now or would you rather wait for gustavo's opinion first? [10:03] c-lobrano: You can have a look at the "libraries" folder [10:04] kalikiana: yes, I've already branched the project for a previous PR [10:04] *forked [10:04] It's a work project, so I got the next 2 months to dive into the snap universe and get a proper version up and running on the TX1. Thanks for all the help to get started on this. I will let you know how I get on.. :) [10:05] zyga-ubuntu: either way is fine with me [10:05] skjensen: welcome aboard, the forum has a "docs" category with useful documentation [10:06] Great :) [10:06] skjensen: there's also the "device" category for topics related to making and supporting new devices [10:06] https://forum.snapcraft.io/c/device [10:07] https://forum.snapcraft.io/c/doc [10:07] https://forum.snapcraft.io/t/the-gadget-snap/696 [10:07] skjensen, well, start with the gadget and for easiness i'd take the tk1 first ... the gadget between the two will only differ minimally so you can re-use it for tx1 with some minimal changes ... the difference between the tw is that you will need your own kernel for the tx1 so fr a start the tk1 will be easier ... [10:07] https://forum.snapcraft.io/t/the-kernel-snap/697 [10:08] skjensen, just folllow the blogposts i gave yu abve, they have a step by step guide and all links to alll docs yu need [10:08] ogra_ thanks, I will get started on the TK1 to get some experience.. and then move onto the TX1 [10:09] iirc there was also some jetson work done initially by parrot ... not sure if they put that in github though [10:12] c-lobrano: Perfect. So if you see the "libraries" folder, there's a file "16.04" in there, which if you open it contains a lot of filenames. [10:12] That's the ones that get stripped from the snap [10:13] kalikiana: oh, I see [10:13] ogra_ super, and I can guarantee you my work will go up on github for everyone to use.. [10:13] \o/ [10:14] kalikiana: so, if no VERSION_ID exists, there is no way to find "another equivalent" file, right? [10:16] c-lobrano: The code basically wants to know that it runs on Ubuntu 16.04 and do its thing. If VERSION_ID isn't there... it should probably be equivalent to a different version, like say 17.10, in which case there's no file [10:21] kalikiana: perfect, so I can propose my PR [10:23] c-lobrano: Yeah. I think kyrofa made a good point there with regard to abstracting it, tho not sure it should be done in the same PR... unless you'd like to look into that as well? [10:26] mvo, you might want to mention https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1724088 in the changelog for the release [10:26] Bug #1724088: All snap packages fail to start with 'udev_enumerate_scan failed' [10:30] kalikiana: oh, I wasn't subscribed to the bug yet, and I missed kryofa's comment. What about doing two PR, one for the bug and one for the "new feature"? [10:36] PR snapd#4052 opened: tests: check for invalid udev files during all tests [10:36] c-lobrano: Yeah, that's what I was thinking as well. The fix itself is straight-forward [10:37] kalikiana: alright. I'm in the middle of ./runtest.sh unit, then I can push the PR [10:43] c-lobrano: Awesome. Thanks for working on it! [10:44] kalikiana: yw :) [10:53] mvo: there's a typo in tihs: [10:53] 2017-10-12 Bureport from 16.04 users about udev_enumerate_scan failure not fixed until the machine is reported. This is unacceptable so we added cleanup code into snap-confine to cleanup the state that caused libudev to be erroring (releated to the udev device tagging that was incorrectly applied to nvidia devices) - PR#4042. [10:53] s/machine/machine is rebooted/ [10:54] mvo: otherwise great writeup, thank you! [10:58] * zyga-ubuntu goes to pick up his son from new school. will probably miss the standup in traffice, be back in two+ hours [11:41] PR snapcraft#1623 opened: Removed dependency on VERSION_ID in os-release [12:06] c-lobrano: Could you add a unit test for your fix? Probably in snapcraft/tests/test_libraries.py [12:06] kalikiana: sure [12:07] re, waiting for son in school [12:16] kalikiana: just let me see how to do it :) [12:26] o [12:26] o/ [12:28] \o [12:31] o/ [12:35] /o/ [12:35] \o\ [12:35] \_o_/ [12:36] mvo: What's up with snapfuse? (Wondering about zyga's comment above) [12:36] (and about the new PR) [12:36] first rule of the snappy yoga club ... don't talkk about the snappy yoga club [12:38] ogra_: You just broke it [12:38]