[05:33] <mup> PR snapcraft#1760 opened: tests: move the catkin integration tests to a separate suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1760>
[06:06] <mborzecki> good morning
[06:55] <mborzecki> it's not possible to REBOOT in prepare in spread?
[06:56] <zyga-ubuntu> good morning
[06:56] <mborzecki> zyga-ubuntu: hey
[06:56] <zyga-ubuntu> I'm not working today, just doing some tax follow up
[06:57] <zyga-ubuntu> REBOOT is defined in spread as a bit of shell, I haven't tried it in prepare
[06:57] <mborzecki> i'm trying to upgrade arch in prepare && REBOOT, but got REBOOT: command not found instead
[06:58] <zyga-ubuntu> mborzecki: then it probably isnt
[06:58] <zyga-ubuntu> look at spread source code, it probably does something in sync with the host
[06:59] <mborzecki> zyga-ubuntu: thanks
[07:38] <mborzecki> omg i know, it's the refactor :) sorry zyga-ubuntu
[07:55] <kalikiana> o/
[08:12] <zyga-ubuntu> mvo: do you know what might make snapd-notify and the classic-ubuntu-core-transition both fail
[08:12] <zyga-ubuntu> mvo: on my system snapd-notify fails reliably
[08:20] <niemeyer> Morning all
[08:24] <mvo> hey zyga-ubuntu
[08:25] <mvo> zyga-ubuntu: I'm not sure why this fails, can you pastebin the error
[08:25] <mvo> hey niemeyer ! good morning
[08:26] <pstolowski> morning!
[08:27] <mup> PR snapd#4290 closed: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4290>
[08:28] <niemeyer> Yos
[08:29] <niemeyer> I could swear it was Thursday.. I lost a day this week
[08:30] <zyga> mvo: http://pastebin.ubuntu.com/26032995/
[08:32] <mborzecki> niemeyer: morning
[08:32] <mborzecki> you're up early
[08:32] <mvo> zyga: hm, strange. can you get into a debug shell?
[08:33] <zyga-ubuntu> I'm in one
[08:33] <mvo> zyga-ubuntu: xcould you please pastebin "journalctl -u snapd"
[08:33] <mvo> zyga-ubuntu: is this a regular ubuntu system?
[08:33] <zyga-ubuntu> mvo: yes, 16.04
[08:33] <zyga-ubuntu> mvo: the pastebin above has the entire journal, there's nothing more
[08:34] <mvo> zyga-ubuntu: aha, no SNAPD_DEBUG=1 maybe?
[08:34] <zyga-ubuntu> no, but I can add that and re-run
[08:35] <mvo> zyga-ubuntu: that is the culprit, the message is only printed on debug
[08:35] <mvo> zyga-ubuntu: probably the smae for the other test
[08:40] <zyga-ubuntu> hmm, how to inject snapd debug
[08:40] <mborzecki> /etc/environment ?
[08:40] <mborzecki> or whatever you use in ubuntu
[08:41] <zyga-ubuntu> right but in this test we just look at syslog
[08:41] <zyga-ubuntu> and I don't want to inject it everywhere
[08:41]  * ikey just kills snapd and manually invokes it these days
[08:41] <ikey>  sudo SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=3 SNAP_CONFINE_DEBUG=1 /usr/lib64/snapd/snapd   does the job for me
[08:41] <mvo> zyga-ubuntu: you could add a file to /etc/systemd/system/snapd.service.d/debug.conf or something
[08:42] <mvo> zyga-ubuntu: just for this test, the restart. but why do you not want global debug enabled? its often very useful when inspecting why tests fail, no?
[08:42] <Guest13703> hello all will my dell edge gateway support any sim
[08:43]  * ikey blinks
[08:43] <zyga-ubuntu> yeah, actualy
[08:44] <mborzecki> zyga-ubuntu: btw. weren't you supposed to be taking a day off today? :)
[08:45] <zyga-ubuntu> yes, just waiting for the traffic to go away :)
[08:45] <zyga-ubuntu> I was eating breakfast and doing some taxes
[08:45] <ikey> man knows how to start the day
[08:45] <ikey> xD
[08:45] <zyga-ubuntu> but you know, that debug machine is so tempting
[08:45]  * mvo hugs zyga-ubuntu
[08:46] <mvo>  /nick zyga-ubuntu -> zyga-debugger
[08:46]  * ikey gets back to staring at prime numbers with contempt
[08:59] <mup> PR snapd#4252 closed: store: fix download caching and add integration test <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4252>
[09:00] <mborzecki> uhh i have a feeling that linode boots arch images with their kernel regarless of what's int the image
[09:08] <mup> PR snapd#4259 closed: snapd: fix handling of undo in the taskrunner <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4259>
[09:11] <mvo> hey pedronis, good morning. I'm just looking at 4292 and wonder if you think the right behavior is that the UserID is whoever installed it (and we keep it to that user) or whoever "touched it last"?
[09:14] <pedronis> mvo: the latter has a better chance of making sure we are using workin creds, the former feels nice
[09:16] <pedronis> another approach is to use for refresh the creds of the installer, not the refresher, which then would make no difference
[09:16] <mvo> pedronis: yeah, I currently went with the former but I'm sitting on the fence
[09:16] <pedronis> I mean doing that even if the refresh is manual
[09:16] <mvo> pedronis: oh, interessting
[09:17] <pedronis> we would still take the refresher though if UserID is currently 0
[09:17] <mvo> right
[09:18] <mvo> pedronis: I think that sounds good, so it would be a) keep userID of installer b) on refresh, take userID from snapstate (regardless of who refreshes)?
[09:18] <pedronis> yes, except if UserID is currently 0
[09:19] <pedronis> so that we have a way out of the current situation
[09:19] <mvo> pedronis: indeed, I like that
[09:20] <pedronis> in practice for a system with one user it should create too many confusing situations
[09:20] <pedronis> *it shouldn't
[09:20] <mvo> pedronis: :)
[09:20] <mvo> pedronis: yeah, I will go with this, I update the PR with the snapstate recording and then will look into configure task handlign first, then into auto-refresh with auth
[09:21] <mvo> pedronis: thanks (as always) for your input!
[09:21] <pedronis> np
[09:24] <pedronis> mvo: btw given  that we are working in this area, it might make sense to capture somehow that a snap is paid (like we capture it's private atm)
[09:31] <zyga-ubuntu> mvo: so, I actuall _had_ SNAPD_DEBUG=1 set, that's what local.conf does
[09:31] <zyga-ubuntu> mvo: yet the logs are exactly the same as before
[09:32] <zyga-ubuntu> anyway, that's for next week
[09:32] <zyga-ubuntu> ttyl
[09:36] <Guest13703> hi can i use any sim module in ubuntu
[09:36] <Guest13703> And where can i get the settings
[09:37] <Guest13703> I am trying to install it on dell edge gateway
[09:42] <mborzecki> mvo: are we particularly tied to calling adduser in osutil/user.go?
[09:44] <mvo> mborzecki: I think not, what do you need to use for arch?
[09:44] <mborzecki> useradd ..
[09:44] <mvo> ok
[09:44] <ikey> think i broke snap
[09:44] <mvo> mborzecki: i think thats fine, however please note that the user adding stuff is mostly for core systems
[09:45] <mvo> mborzecki: which are ubuntu currently so it should not be urgent to change this (or do you have a different use case?)
[09:45] <mborzecki> mvo: great point, i'll disable the test then :)
[09:45] <ikey> https://hastebin.com/xibuyorobu.pl <- even after unsetting them all as reviewable i cant make the newest one reviewable..
[09:45] <ikey> on the plus side my snapcraft segfault is gone
[09:46] <ikey> `Ready to release!
[09:46] <ikey> Revision 7 of 'linux-steam-integration' created.
[09:46] <ikey> `
[09:46] <mborzecki> mvo: btw. the unit tests are only ran on debian and ubuntu, is this intentional?
[09:46] <mvo> ikey: autsch, sorry for that, that probably needs jdstrand but he is iirc not around today
[09:46] <ikey> yeah no worries
[09:46] <mvo> mborzecki: not intentional, I vaguely remember I enabled them everywhere at some point :/
[09:46] <ikey> just managed to make the dashboard fart so i thought id headsup y'all
[09:47] <mvo> ikey: maybe the store people can help
[09:47] <ikey> ta
[09:48] <ikey> hm, found some missing libs with abireport
[09:48] <ikey> *fixes*
[09:54] <ikey> niemeyer, this is what i meant about the abireport stuff btw, highlighted missing libraries from the root: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_used_libs
[09:54]  * ikey is fixing ^^
[09:54] <ikey> and the abi_symbols file is 5.23MB :p
[09:54] <mvo> ikey: hm, I don't see anything in the review queue, so it does look like somehting in the store is wonky, nessita can probably help with your https://hastebin.com/xibuyorobu.pl store issue, but she is in a .ar timezone
[09:55] <ikey> ok - gonna get another image uploaded first before i chase it further tbh
[09:55] <ikey> stabilise the ABI
[10:09] <niemeyer> ikey: Nice, that's exactly what we need I think
[10:10] <niemeyer> ikey: For the base-reviewing tasks
[10:10] <ikey> yeah
[10:10] <niemeyer> ikey: Probably also binaries that were removed, for similar reasons
[10:10] <ikey> warning 5MB: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_symbols
[10:10] <ikey> yeah ive just done the same, and ripped some systemd binaries out of the rootfs
[10:11] <ikey> it doesnt do c++filt mutations - they wouldn't let you know that ABI changed
[10:11] <ikey> just API really
[10:11] <ikey> besides nobody really cares *what* the symbols are as such, just that "oh crap I lost 4000 symbols on this change"
[10:12] <niemeyer> ikey: Right, spot on
[10:13] <ikey> fwiw we do this at the packaging level too, its great for an early warning that somethings amiss or pain is due ^^
[10:59] <jamesh> ikey: if you want more certainty about ABI changes, check out Abigail: https://sourceware.org/libabigail/
[10:59] <ikey> seen it, overkill :D
[10:59] <ikey> tis why i built abireport in the first place
[10:59] <ikey> its a high level overview basically
[10:59] <ikey> https://github.com/clearlinux/abireport
[11:00] <ikey> we can quickly track changes like so: https://dev.solus-project.com/R545:81e86e35ad503ce3df7387a3b9b6f17671a06b1a
[11:00] <ikey> all part of the build process
[11:00] <jamesh> on a previous project we used abi-compliance-checker, but it is slow and hard to configure
[11:01] <jamesh> ikey: there's so many ABI changes that won't show up in the symbol table though
[11:01] <ikey> sure - but it requires being a sensible distro dev
[11:01] <ikey> the vast majority of ABI-you-should-care-about will show up
[11:02] <ikey> sonames, linker versions and actual symbols
[11:02] <ikey> its more similar to nm -g --dynamic --defined-only
[11:02] <ikey> saved my backside more times than i care to count
[11:03] <ikey> the abi_used_libs{,32} files come from DT_NEEDED cruft
[11:03] <ikey> as solus forces -as-needed at the toolchain level (via binutils)
[11:03] <ikey> i.e. not via cflags
[11:03] <jamesh> so does Ubuntu, IIRC
[11:03] <ikey> ah handy
[11:04] <ikey> it causes some problems for janky build systems that have link order incorrect
[11:04] <ikey> but we can unset LD_AS_NEEDED in environment to workaround it
[11:04] <ikey> btw nice work on the startup times for desktop snaps :D
[11:04] <jamesh> well, the package build infrastructure.  It doesn't change the behaviour of the tools you install on Ubuntu
[11:04] <ikey> right, our build  stuff (ypkg) sets LD_AS_NEEDED in the environment
[11:04] <ikey> which triggers the change in binutils to force the behaviour
[11:05] <ikey> default user environment doesnt trigger it
[11:05] <ikey> so in the package.yml we'd just do: unset LD_AS_NEEDED
[11:06] <ikey> example: https://github.com/solus-project/runtime-snaps/blob/master/support_packages/mesa/package.yml#L48
[11:08] <mborzecki> pstolowski: thanks for the review :)
[11:16] <mup> PR snapd#4293 opened: snapstate: store if a snap is a payed snap in the sideinfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/4293>
[11:18] <ikey> surely we mean Paid?
[11:18] <ikey> >_>
[11:22] <Chipaca> ikey: yes
[11:23] <Chipaca> ikey: English is hard
[11:23] <ikey> cool - i just didnt know if i was misreading :p
[11:24] <Chipaca> ikey: maybe it's a typo and we're working on snaps reaching plaid speed
[11:25] <ikey> aha
[11:25] <pedronis> mvo: thanks, I can pick up that PR after lunch, there's also a couple of places in store that can use that flag I think
[11:26] <pstolowski> mborzecki, np, still reviewing
[11:27] <mborzecki> any idea what might be the reason for 'stateengine.go:98: state ensure error: devicemgr: cannot find account (testrootorg)' ?
[11:31]  * sergiusens waves good morning
[11:49] <mvo> pedronis: sounds good, thank you
[11:49] <mvo> mborzecki: this error indicates the testrootorg account was not added in some test. where do you see that?
[11:50] <mborzecki> mvo: when running linode:arch-2017.07.01:tests/main/classic-custom-device-reg
[11:51] <mvo> mborzecki: is this snapd compiled with the "testkeys" option?
[11:52] <mvo> mborzecki: build tag for go is: "withtestkeys"
[11:53] <mborzecki> hmm that would explain it, the package is built without any additional tags passed to go
[11:53] <mvo> mborzecki: yeah, but I think you still found a bug :)
[11:53] <mvo> mborzecki: usually we ahve a if [ trusted keys ] guard for tests that need it
[11:54] <mborzecki> can't tell, i'm randomly jumping around asserts/database.go and overlord/assertstate :)
[11:55] <mvo> mborzecki: it seems like our code could be smarter that sets TRUST_TEST_KEYS
[11:55] <mvo> mborzecki: anyway, the error itself should go away if you build it with this flag
[11:55] <nessita> mvo, ikey checking
[11:55] <mborzecki> mvo: i think it's on me, the package that's built for arch does not have this tag set
[11:55] <mvo> mborzecki: (obviously this is only for testing)
[11:55] <mborzecki> i see now that the rpm built during tests sets this
[11:55] <ikey> checking what on the who now
[11:56] <mvo> mborzecki: cool, good luck
[11:56] <ikey> *squirrel*
[12:02] <nessita> mvo, ikey I moved revision 6 to manual review and then as reviewer I ran the automated checks agains, there is one failure
[12:02] <nessita> "
[12:02] <nessita> (NEEDS REVIEW) type 'base' not allowed lint-snap-v2_snap_type_redflag
[12:02] <nessita> "
[12:03] <ikey> yeah that one i know about :D
[12:03] <Chipaca> ikey: mborzecki: fyi the static checks caught the payed vs paid thing
[12:03] <nessita> the revision 7 review should start soon
[12:03] <ikey> i wouldnt bother nessita honestly
[12:03] <pedronis> Chipaca: I'm taking up that PR
[12:03] <ikey> im building revision 8
[12:03] <ikey> to fix one last issue with the runtime
[12:03] <ikey> then that'll be my final runtime for jdstrand to sign off on
[12:03] <Chipaca> "one last issue" <- lol
[12:03] <ikey> lol
[12:03] <ikey> it was missing libkmod
[12:03] <nessita> ikey, well but until revision 7 is reviewed, revision 8 will not be -- you can reject revision 7 yourself
[12:04] <ikey> sure but none of them will pass review right now anyway :D
[12:04] <ikey> they're all base
[12:04] <ikey> autoreject
[12:04] <nessita> ikey, kk
[12:04] <ikey> thanks though - i just wanted to unclog whatever it was i busted earlier xD
[12:05] <ikey> well im also compiling mesa + glibc again so it might take a small while before this snap is done.. >_>
[12:05]  * ikey adds weekend TODO about having caching for this process
[12:49] <mborzecki> we're setting LANG=C.UTF-8 in environment for the tests, would switching to LANG=C and probably LC_ALL=C be a big issue?
[12:51] <mup> PR snapd#4294 opened: Mount with x-gdu.hide option <Created by azzar1> <https://github.com/snapcore/snapd/pull/4294>
[12:53] <mup> PR snapcraft#1761 opened: lxd: ContainerConnectionError on failed launch/ start <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1761>
[12:54] <Chipaca> mborzecki: in what distro?
[12:54] <Chipaca> afaik c.utf-8 is a debianism
[12:54] <Chipaca> althouh i think redhat picked that up as well; not sure
[12:55] <mvo> mborzecki: we mostly use C.UTF-8 to avoid python3 exploding all over the place if it is not in a utf-8 locale (at least iirc)
[12:55] <pedronis> mvo: Chipaca: I updated the paid PR
[12:55] <mvo> pedronis: \o/
[12:58] <mborzecki> hm arch
[12:58] <mborzecki> yeah, it doesn't like C.UTF-8 at all
[12:59] <ikey> C.UTF-8 is non-standard
[12:59] <mborzecki> i've added an override LC_ALL=C in the test to workaround this
[12:59] <mborzecki> this will have to do probably :)
[13:00] <ikey> failing that, en_US.utf8
[13:11] <cjwatson> while C.UTF-8 is non-standard, it might be worth generating it with localedef if it isn't there, because there's no standard way to get a UTF-8 locale and the tests probably do need one
[13:11] <mup> PR snapd#4295 opened: tests/main/manpages: set LC_ALL=C as man may complain if the locale is unset or unsupported <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4295>
[13:11] <cjwatson> I forget the exact invocation of localedef you need but it's not hard
[13:17] <Chipaca> there's an example at the end of locale(1) that'll probably get you most of the way there
[13:18] <ikey> hm snapcraft is being rather communicative
[13:18] <ogra_> it likes you !
[13:18] <ikey> https://ibin.co/3iOpZnKAHMIs.png <- is there an expectation that i have xdelta installed?
[13:19] <ogra_> if oyu want to save bandwith you want xdelta
[13:19] <ogra_> well xdelta3
[13:20] <ikey> sure but im wondering if this needs to be in the snapcraft snap
[13:20] <ikey> because there are a lot of xdeltas
[13:20] <ogra_> sounds reasonable that it ships it, yeah
[13:20] <ikey> i mean im happy to install ofc - just wondering about the intricacies of it
[13:20] <ikey> i like that i get the feedback in the terminal now
[13:21] <ikey> and i will reluctantly admit that its handy to select revisions for promotion from the cli
[13:23] <cjwatson> Chipaca: that's close to what I was thinking of, yes.  In fact the specific invocation for C.UTF-8 should be in the Debian glibc packaging
[13:23] <cjwatson> debian/rules.d/build.mk:108:        I18NPATH=$(CURDIR)/localedata GCONV_PATH=$(DEB_BUILDDIR)/iconvdata localedef --quiet -c -f UTF-8 -i C $(CURDIR)/build-tree/C.UTF-8 ; \
[13:23] <cjwatson> should be able to drop I18NPATH and GCONV_PATH from that
[13:25] <cjwatson> right, so looks like localedef --quiet -c -f UTF-8 -i C ./C.UTF-8 would work, and then point LOCPATH to that
[13:37] <mborzecki> cjwatson: thanks for the tips, that's something that could probably be applied to arch at disto level
[13:38] <cjwatson> Could just be done globally - no reason for that to be distro-specific I think
[13:38] <cjwatson> I mean, Debian-derived distros have a C.UTF-8, but you can generate another local version of it harmlessly
[13:41] <cachio> pedronis, the issue about gpg is that the dir "/root/.snap/gnupg/private-keys-v1.d" is missing
[13:41] <pedronis> cachio: mmh
[13:41] <pedronis> cachio: I need to dig, I have seen that dir sometimes, but I don't know why it's there/created
[13:41] <cachio> pedronis, I created this and the snap create-key started working
[13:42] <pedronis> it's probably a really bug
[13:42] <pedronis> *real bug
[13:42] <pedronis> not a serious one but annoying
[13:42] <cachio> pedronis, but, the first time it works
[13:43] <cachio> I execute snap-create-key test alone and it pass
[13:43] <cachio> but if I use -repeat 2 the secont execution fails
[13:44] <pedronis> mmh, no, I was confused
[13:44] <pedronis> this is from gpg itself
[13:45] <pedronis> or something else
[13:45] <pedronis> I'm confused
[13:47] <cachio> pedronis, I am gonna run again and see it this fir exists the first time
[13:48] <pedronis> cachio: there's some explanation about that dir here:  https://www.gnupg.org/faq/whats-new-in-2.1.html  , see  Removal of the secret keyring
[13:49] <pedronis> cachio: do we cleanup  ~/.snap/gnupg  between tests?
[13:51] <cachio> pedronis, I think so
[13:52] <cachio> pedronis, checking
[13:53] <pedronis> in reset_classic we do:  rm -rf /root/.snap/gnupg
[13:54] <cachio> yes
[13:57] <cprov> elopio: would you be familiar with the test failures in https://travis-ci.org/snapcore/snapcraft/jobs/306445933 ?  locally it is passing, would you know how to reproduce it in xenial ?
[14:09] <mup> PR snapd#4296 opened: packaging/arch: pre-create snapd directories when packaging <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4296>
[14:12] <mup> PR snapd#4108 closed: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4108>
[14:15] <niemeyer> Lunch, biab
[14:18] <cachio> pedronis, I pushed the fix
[14:18] <cachio> pedronis, thanks for helping
[14:21] <pedronis> cachio: ah
[14:21] <sergiusens> ikey it is in the snapcraft snap (xdelta3), you just found a bug that's all :-)
[14:22] <ikey> ah gotcha
[14:23] <pedronis> cachio: wondering if we shouldn't stop/restart the agent instead ?
[14:23]  * kalikiana food
[14:27] <cachio> pedronis, testing that
[14:27] <cachio> pedronis, the change works
[14:30] <cachio> pedronis, In sid the agent is creating that dir in case it does not exist any more
[14:30] <cachio> pedronis, I supose they fixed after v 2.1.18
[14:30] <cachio> pedronis, I'll take a look to che changelog
[14:47] <cachio> niemeyer, fedora 26 passed
[14:47] <niemeyer> cachio: \o/
[14:47] <cachio> niemeyer, should I add this as manual execution?
[14:47] <niemeyer> cachio: Any reason not to do automatic, other than the extra worker?
[14:48] <cachio> niemeyer, no, just the workers needed
[14:48] <niemeyer> Son_Goku: Any ideas here?
[14:48] <cachio> niemeyer, then we will have fedora 27
[14:48] <Son_Goku> niemeyer: eh?
[14:48] <cachio> and rawhide
[14:48] <Son_Goku> ideas for what?
[14:49] <niemeyer> Son_Goku: Value of running tests on Fedora 26 at all times.. we'll be working on 27 and rawhide next
[14:49] <Son_Goku> well, 26 is a currently supported stable release for a year
[14:49] <Son_Goku> but if you'd rather only support 27 and rawhide, that's fine
[14:49] <Son_Goku> let's just not be in a position where we're stuck on an old version for too long
[14:49] <niemeyer> Son_Goku: Any stats on user base?  Do we have a significant percentage of users there still?
[14:50] <Son_Goku> no idea
[14:50] <Son_Goku> Fedora doesn't collect stats
[14:50] <niemeyer> Son_Goku: Well, I'm sure file servers have logs
[14:50] <Son_Goku> in the mirror network, probably
[14:50] <Son_Goku> but the best way to figure this out would be the store side logs
[14:51] <niemeyer> Son_Goku: Good point
[14:51] <Son_Goku> each snapd version is encoded with their package release version
[14:51] <Son_Goku> which has the .fcXX suffix encoded
[14:52] <niemeyer> cachio: Ok, I suggest enabling 27 and rawhide first, and let's talk to the store team to see if we can figure out any hints of demand
[14:52] <Son_Goku> so snapd 2.29.4 from Fedora 26 will say its version is 2.29.4-2.fc26
[14:52] <niemeyer> cachio: We can keep manual meanwhile
[14:52] <cachio> niemeyer, sure
[14:52] <niemeyer> Son_Goku: Thanks for the details
[14:52] <Son_Goku> np
[14:53] <cachio> niemeyer, I'll continue with fedora 27
[14:53] <ikey> got at least 12 solus users with snapd
[14:53] <Son_Goku> incidentally, I encode this data in the snapd version because from time to time, I do patches/backports that differ from you guys
[14:53] <Son_Goku> makes it easier to identify where a breakage might happen (if it ever does)
[14:53] <niemeyer> ikey: It's a good start! :)
[14:54] <ikey> :D
[14:54] <Son_Goku> there's *probably* more than 12 Fedora users :P
[14:54] <ikey> nah
[14:54] <ikey> never heard of it
[14:54] <ikey> >_>
[14:55] <mborzecki> Son_Goku: idk I stopped using it ~3 months ago :)
[14:55] <Son_Goku> ...
[14:55] <ikey> :O
[14:55] <ikey> niemeyer, happy: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_used_libs
[14:55] <ikey> is empty ^_^
[14:55]  * Son_Goku collapses in glum agony
[14:56] <mborzecki> yeah, got lazy at some point, didn't want to go through another upgrade and installed tumbleweed just for the lulz
[14:56] <ikey> when i move to implementing apparmor confinement (post snapd stable release and store inclusion of both edges) - then ill need to move stuff like theme assets from runtime to the lsi snap itself
[14:56] <ikey> mborzecki, they still got their sysvinit-on-top-of-systemd thing going on?
[14:57] <Son_Goku> ikey: btw, are there any changes of yours left that aren't part of snapd 2.29.4?
[14:57] <ikey> that i dont know
[14:57] <Son_Goku> I may want to cherry-pick those into Fedora snapd
[14:57] <mborzecki> maybe, can't tell, it was awkward, everything seemed broken, spent the last 3 months or so fighting with policykit as it kept asking me for root (yeah root) password to authorize any operation
[14:58] <ikey> i dont think i have pending PRs
[14:58] <Son_Goku> mborzecki: with snapd?
[14:58] <Son_Goku> on Fedora?
[14:58] <ikey> mborzecki, ah that reminds me i need to upstream my polkit patches this weekend..
[14:58] <ikey> in solus we removed JS from polkit
[14:58] <ikey> >_>
[14:58] <Son_Goku> mborzecki: I literally just fixed that last week
[14:58] <niemeyer> cachio: I'm seeing errors being reported about fedora-25 in travis
[14:58] <niemeyer> cachio: In unrelated PRs
[14:58] <niemeyer>   Status code: 502 for https://mirrors.fedoraproject.org/metalink?repo=fedora-25&arch=x86_64
[14:59] <ikey> this is our polkit policy definition :P https://dev.solus-project.com/source/gvfs/browse/master/files/org.gtk.vfs.file-operations.keyrules
[14:59] <niemeyer> cachio: Known?
[14:59] <niemeyer> Son_Goku: ^
[14:59] <Son_Goku> niemeyer: that's the Linode mirror being broken
[14:59] <mborzecki> Son_Goku: if it's any consolation, my wife, who's got nothing to do with IT whatsoever is runnig the latest fedora on her laptop  and prefers it to any other distro i had installed her before
[14:59] <ikey> Son_Goku, i dont see any open PRs from me on github
[14:59] <niemeyer> Son_Goku: ;(
[15:00] <ikey> so my nvidia work is in
[15:00] <Son_Goku> I believe Linode has a mirror override for their IP block (Fedora MirrorManager lets you register private and public mirrors in that manner) and their mirror is awful
[15:00] <ikey> we might want to flesh out desktop-helpers to support the new system though?
[15:00] <Son_Goku> niemeyer: I have a similar override in place for my workplace for its local mirror
[15:00] <ikey> for vulkan + biarch nvidia..
[15:00] <Son_Goku> ikey: right
[15:01] <Son_Goku> but RADV and Intel Vulkan should work, right?
[15:01] <ikey> wait i just said 'we'
[15:01] <ikey> y'all done stockholmed me
[15:01] <Son_Goku> :P
[15:01] <ikey> Son_Goku, as long as they're present
[15:01] <ikey> and accessible in some fashion
[15:01] <ikey> f.e. solus-runtime-gaming ships a full weight mesa with the vulkan drivers
[15:01] <Son_Goku> hmm
[15:01] <ikey> and can use the "host" vulkan for nvidia support
[15:02] <ikey> but it requires the icd loader inside the snap runtime or snap itself
[15:02] <ikey> i.e. libvulkan.so.1
[15:02] <ikey> i suspect we've got some apparmor confinement nightmares to work out there
[15:02] <ikey> but lsi is a good place to debug that
[15:02] <ikey> as its a meaty runtime
[15:02] <Son_Goku> uh oh
[15:02] <Son_Goku> I fucked up
[15:02] <ikey> onoes
[15:03] <Son_Goku> oh wait
[15:03] <Son_Goku> panic averted
[15:03] <Son_Goku> snapd-selinux is there
[15:03] <ikey> yeah tell that to golang
[15:03] <ikey> >_>
[15:03] <Son_Goku> hahah
[15:03] <ikey> and now im making programming jokes
[15:03] <Son_Goku> for a minute there, I thought I might have accidentally not built it
[15:03]  * ikey is taking himself out tonight
[15:03] <ikey> like, out to a pub
[15:03] <ikey> not gonna mobhit myself as i have dinner
[15:03] <Son_Goku> haha
[15:04] <ikey> can't even begin to work out the logistics for having myself still surprised by the event *and* having meaningful last words..
[15:05] <Son_Goku> haha
[15:06] <Son_Goku> be drunk when you order your hit?
[15:07] <ikey> ah that could do it
[15:07] <ikey> so taking myself out will actually take me out
[15:07] <ikey> i do love the beauty of that
[15:07] <cachio> niemeyer, taking a look
[15:07] <mup> PR snapd#4297 opened: Adding fedora-26 image to snapd spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4297>
[15:08] <Chipaca> ikey: is that some sort of extrovert kalsarikännit?
[15:09]  * ikey googles this word
[15:09] <ikey> oh
[15:09] <ikey> hm
[15:09] <ikey> lol. i guess?
[15:09] <ikey> just.. with the pants
[15:09] <ikey> well i mean i cant make promises on that count but its the intent anyway
[15:15] <kalikiana> apparently there's even an emoji for that
[15:20] <elopio> kyrofa: hey, we can remove the shared ros demo now, right? I see we have almost the same code in snapcraft/tests/integration/snaps/catkin-shared-ros
[15:20] <elopio> the thing we are missing seems to be a test that installs and executes that snap.
[15:21] <niemeyer> cachio_lunch: Sorry, I forgot we had fedora *25* tests running automatically.. I suggest moving those to manual, and running 26 instead
[15:23] <sergiusens> kalikiana hey, did you see the bug I logged yesterday? It is quite critical to a good experience
[15:25] <kalikiana> sergiusens: You mean bug 1734145? I haven't checked it yet. But I'm going to take a look in a moment and see what's going on there
[15:25] <mup> Bug #1734145: snapcraft clean <part-name> destroys everything when using containers <Snapcraft:Triaged by kalikiana> <https://launchpad.net/bugs/1734145>
[15:25] <mborzecki> ok guys, i'm done for today, enjoy your weekend
[15:31] <zyga-ubuntu> hey guys
[15:31] <zyga-ubuntu> not working feels refreshing for a change
[15:31] <zyga-ubuntu> mid day I was no longer thinking about solving work problems
[15:32] <zyga-ubuntu> I hope you all had a fantastic day and I will happily see you next week :)
[15:33] <Son_Goku> bye :)
[15:33] <zyga-ubuntu> hey Son_Goku
[15:33] <Son_Goku> zyga-ubuntu: hey
[15:33] <zyga-ubuntu> enjoy your weekend :)
[15:33] <Son_Goku> I will!
[15:33] <Son_Goku> zyga-ubuntu: test the fedora snapd packages :)
[15:33] <zyga-ubuntu> I bought a pair of gloves today
[15:34] <zyga-ubuntu> poland is so cold so quickly
[15:34] <zyga-ubuntu> it's not even sub-zero yet
[15:34] <Son_Goku> heh
[15:34] <zyga-ubuntu> Son_Goku: ok, I recently installed F27
[15:34] <Son_Goku> it's already getting to subzero here
[15:34] <zyga-ubuntu> Son_Goku: here too but it's not like that daily and all the time (yet)
[15:34] <Son_Goku> also, if you want to have some fun, we have mir packages in Fedora 26 and 27 testing
[15:34] <Son_Goku> zyga-ubuntu: every day after 6pm, it's subzero
[15:34] <zyga-ubuntu> ok so poland is still warmer
[15:34] <zyga-ubuntu> man, I'm complaining too much :D
[15:38] <mup> PR snapd#4295 closed: tests/main/manpages: set LC_ALL=C as man may complain if the locale is unset or unsupported <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4295>
[15:40] <niemeyer> Good news: compression on spread works
[15:41] <niemeyer> Bad news: it doesn't seem to improve timing much
[15:41] <niemeyer> https://travis-ci.org/snapcore/snapd/builds/306754148
[15:41] <niemeyer> This one was run entirely with compression on with server=>client
[15:56] <sergiusens> kyrofa mind looking at my latest PR?
[15:56] <kalikiana> sergiusens: I confirmed the bug. I need to investigate why the unit test didn't fail.
[15:56] <kalikiana> elopio: maybe you could help me here find out what is wrong?
[15:57] <kalikiana> the checks *look* right...
[15:57] <elopio> kalikiana: which bug?
[15:58] <kalikiana> elopio: bug 1734145 - https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/unit/commands/test_clean.py#L178
[15:58] <mup> Bug #1734145: snapcraft clean <part-name> destroys everything when using containers <Snapcraft:In Progress by kalikiana> <https://launchpad.net/bugs/1734145>
[15:59] <kalikiana> elopio: I have an idea what's wrong with the code. But the test passing puzzles me
[16:01] <elopio> kalikiana: to check what's in the call args, just change it to assertEqual and give it a try.
[16:01] <cachio> niemeyer, sure
[16:01] <kalikiana> elopio: nothing is in the call args
[16:01] <kalikiana> elopio: which *would* mean all is fine, no bug
[16:02] <elopio> that would be a better check, instead of NotEquals, check that there are no calls.
[16:02] <kalikiana> I'm saying there are none
[16:02] <elopio> but why it is passing despite the bug, I don't know. The mock might be wrong.
[16:03] <kalikiana> oh.... I just realized why
[16:03] <kalikiana> the test doesn't set fake_lxd.status
[16:04] <kalikiana> so fake_lxd has no container which would be deleted...
[16:05] <mup> PR snapd#4298 opened: many: remove configure-snapd task again and handle internally <Created by mvo5> <https://github.com/snapcore/snapd/pull/4298>
[16:06] <mup> PR snapd#4296 closed: packaging/arch: pre-create snapd directories when packaging <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4296>
[16:08] <kalikiana> elopio: if you see the test, can you tell me what you expected it to do? without looking at the fixture source
[16:09] <mvo> pedronis: not urgent but early sniff test on 4298 would be appreciated
[16:10] <elopio> kalikiana: to check that the container was not deleted when a part is passed as an argument.
[16:16] <mup> PR snapd#4265 closed: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4265>
[16:19] <zyga-ubuntu> we have < 25 PRs, that's very refreshing
[16:21] <mup> PR snapd#4293 closed: snapstate,store: store if a snap is a paid snap in the sideinfo <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4293>
[16:28] <kyrofa> sergiusens, yeah, making it through a few older ones, on my way up
[16:32] <kyrofa> sergiusens, could use your thoughts on snapcraft#1746
[16:32] <mup> PR snapcraft#1746: cli: add version command <Created by gsilvapt> <https://github.com/snapcore/snapcraft/pull/1746>
[16:32] <kalikiana> elopio: that is correct. I'm thinking if it's also clear what fake_lxd provides - without .status - 'Stopped' it doesn't do what you expect. Maybe a method like .creater_container('foo')? I think the property assignments aren't good enough
[16:32] <kalikiana> Neither of us saw that it was wrong
[16:39] <elopio> kalikiana it's clear when you call status. It's not clear when you forget it. The joy of mocks...
[16:39]  * elopio relocates
[16:39]  * zyga-ubuntu wonders why snap-run-link performs reset.sh in its prepare state?
[16:39] <zyga-ubuntu> prepare *step*
[16:40] <zyga-ubuntu> then installs core from beta
[16:40] <zyga-ubuntu> feels totally bogus
[16:40] <zyga-ubuntu> there, patched locally not to do this
[16:40] <zyga-ubuntu> let's see what's next
[16:41] <kalikiana> elopio: Yeah.... it's difficult to avoid that kind of thing...
[17:03] <mup> PR snapcraft#1762 opened: lxd: delete container only if parts is empty <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1762>
[17:04] <kalikiana> sergiusens: the tmp_dir fix is here snapcraft#1742
[17:04] <mup> PR snapcraft#1742: lxd: always remove tmp_dir after execution <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1742>
[17:10] <Son_Goku> cachio: we can probably drop fedora-25 entirely
[17:10] <Son_Goku> as it's EOL is in December
[17:10] <Son_Goku> I certainly don't plan to make new updates for Fedora 25 past 2.29.x
[17:13] <ikey> heads up, brave browser lacks japanese font support: https://dev.solus-project.com/T5080
[17:13] <ikey> we're gonna have them forward to snapcraft forum
[17:13] <ikey> fully confined snap, nothing we can do our side
[17:16] <elopio> kalikiana you could make the fake smarter. If lxc start is called, update the internal status.
[17:16] <zyga-ubuntu> ikey: you can!
[17:16] <zyga-ubuntu> ikey: we have host font support now
[17:16] <zyga-ubuntu> ikey: fonts from /usr/share/fonts are ahred
[17:16] <zyga-ubuntu> *shared
[17:16] <ikey> ah gdi
[17:16] <ikey> lol
[17:16] <ikey> literally just closed it xD
[17:16] <kalikiana> elopio: that's what it already does! the properties are only used to eg. fake an existing container
[17:17] <ikey> is this upcoming or in release?
[17:17] <ikey> and if its in git i can backport to solus snapd for this guy
[17:18] <cachio> Son_Goku, ok
[17:18] <zyga-ubuntu> ikey: I think it's released now, it's a part of one of the interfaces
[17:18] <zyga-ubuntu> ikey: I forgot, look for "fonts" in interfaces/builtin
[17:18] <zyga-ubuntu> ikey: it should just work now
[17:18] <cachio> Son_Goku, It is gonna be manual after 26 is added
[17:18] <Son_Goku> cool
[17:18] <ikey> nothing in 'snap interfaces' listing here
[17:18] <zyga-ubuntu> ikey: no no, I mean "grep the code luke"
[17:19] <ikey> oh XD
[17:19] <zyga-ubuntu> btw
[17:19] <zyga-ubuntu> do you know anything that shows network usage
[17:19] <zyga-ubuntu> akin to "time"
[17:19] <ikey> ehm not off the top of me head
[17:19] <ikey> netstat is a bit meh
[17:20] <zyga-ubuntu> I read about the new BPF based tools on LWN
[17:20] <zyga-ubuntu> I need to try those
[17:21] <ikey> vnstat but i dont think it has the granularity
[17:21] <ikey> its more system wide
[17:21] <ikey> vs this thingy is using that much
[17:21] <zyga-ubuntu> there was something that tracks TCP
[17:23] <mup> PR snapd#4297 closed: Adding fedora-26 image to snapd spread.yaml <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4297>
[17:24] <elopio> kalikiana then maybe don't fake an existing container, always set up the fake from scratch.
[17:24]  * kalikiana hopping on a tram now
[17:25] <kalikiana> elopio: I'm not sure what you mean. I am setting up the fake here
[17:27] <kalikiana> I guess we should brainstorm the fakes at some point and see if we can improve it
[17:44] <cachio> niemeyer, fedora 27 ready in the 45.56.91.42
[17:49] <kyrofa> Dude, patchelf is kind of awesome
[17:51] <niemeyer> cachio: Sweet
[17:51] <niemeyer> cachio: Which spread is that?
[17:51] <niemeyer> Which machine is that, I mean
[17:54] <cachio> niemeyer, dont know which spread
[17:54] <cachio> it is the fedora-27-x86_64
[17:54] <niemeyer> cachio: I need to know the machine number..
[17:54] <niemeyer> Spread-N
[17:55] <cachio> I don'thave it
[17:56] <cachio> I just saved the ips long time ago
[17:56] <cachio> let me check in the irc logs
[17:57] <niemeyer> cachio: Your own messages say this is Spread45
[17:57] <niemeyer> cachio: Your own messages say this is Spread-45
[17:57] <niemeyer> Looking into it
[17:58] <niemeyer> cachio: ... and I'm being silly, sorry. The main machine table does list the public IP address. I just never used/noticed it there.
[17:59] <cachio> niemeyer, :)
[18:00] <Chipaca> zyga-ubuntu: i didn't understand your comment about x-snapd
[18:00] <niemeyer> I always go to the configuration tab, and it woudn't be fun to scan 80 machines for the IP address.. that's why I was asking for it
[18:00] <zyga-ubuntu> Chipaca: look at entry.go
[18:01] <zyga-ubuntu> Chipaca: there are functions there
[18:01] <Chipaca> zyga-ubuntu: yes
[18:01] <zyga-ubuntu> Chipaca: I was referring to the fact you made that const, I wonder why
[18:01] <Chipaca> zyga-ubuntu: the things i made consts aren't used as variables afaict
[18:01] <zyga-ubuntu> yeo
[18:01] <zyga-ubuntu> yep
[18:02] <zyga-ubuntu> Chipaca: anyway, that's fine :)
[18:02] <zyga-ubuntu> I was just curious
[18:02] <Chipaca> zyga-ubuntu: the reason i made the change is laziness
[18:02] <Chipaca> that's all
[18:03] <Chipaca> zyga-ubuntu: otherwise i'dd have to import sys and make uid and gid be sys.UserID(0) and sys.GroupID(0)
[18:03] <Chipaca> zyga-ubuntu: "but Chipaca", you say, "being lazy isn't a good reason for doing that"
[18:03] <Chipaca> zyga-ubuntu: and you might be right :-)
[18:04] <ikey> id say laziness makes the world go round, but ideally the world would keep itself turning and report issues to itself
[18:04] <zyga-ubuntu> haha,  no, it's fine :)
[18:04] <zyga-ubuntu> YAGNI
[18:04] <zyga-ubuntu> if I need it, I'll change it
[18:04] <Chipaca> zyga-ubuntu: TBH i was very close to just inlining the constants
[18:07] <Chipaca> ikey: with you on that
[18:07] <ikey> ^^
[18:07] <Chipaca> also: it's 1807 on a friday
[18:07] <ikey> in the US? :P
[18:07] <ikey> or we talking hours
[18:07]  * ikey runs
[18:07] <Chipaca> i'm off to bathe smelly boys and make smelly pizza
[18:07] <Chipaca> o/
[18:08] <ikey> \o
[18:08]  * ikey contemplates The Going Out
[18:08] <Chipaca> ikey: The Great Goingoutening of 2017
[18:08] <ikey> mm
[18:11] <niemeyer> cachio: You've got an image.. machine is back up in case you need it
[18:11] <cachio> niemeyer, great, I'll test it
[18:11] <niemeyer> and I'm taking a break
[18:11] <cachio> sure, in 20 minutes fedora 28 will be ready
[18:11] <niemeyer> A good weekend for those reaching their EOD
[18:13] <mup> Bug #1734213 changed: Python scripts named pip* filtered out of snaps <Snapcraft:New> <https://launchpad.net/bugs/1734213>
[18:15] <mup> PR snapcraft#1763 opened: Make the pip filtering in the Python plugin more fine-grained <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/1763>
[18:28] <cachio> niemeyer, fedora 28 ready on 45.79.183.239
[18:28] <cachio> fedora-rawhide-64
[18:29] <zyga-ubuntu> cachio: note that rawhide is not 28
[18:29] <zyga-ubuntu> cachio: it will stay as rawhide forever
[18:30] <zyga-ubuntu> cachio: f28 didn't branch yet
[18:31] <cachio> zyga-ubuntu, ah, ok
[18:42] <sergiusens> kyrofa elopio thanks for the reviews, question, does that failing test pass for you guys when running locally?
[18:42] <zyga-ubuntu> 30 / 166
[18:43] <zyga-ubuntu> slow but predictable progress
[18:43] <kyrofa> sergiusens, I didn't run that particular test locally, but I tested with binaries from the archive and it worked
[18:43] <kyrofa> I'll run it in a minute
[18:43] <sergiusens> kyrofa right, that is what I did; I am considering there to be an issue with the testbed
[18:44] <kyrofa> sergiusens, wonder if it's not properly changing to classic
[18:44] <sergiusens> kyrofa it works fine locally, so I assume it does
[18:45] <kyrofa> Weird. I don't know what it could be, then
[19:37] <elopio> sergiusens: I can try in an hour, after the ubuntu on air.
[19:37] <elopio> kyrofa and anybody else who wants to join: https://hangouts.google.com/hangouts/_/urbvfds645aehgjqxmbuxjpuzme
[19:43] <zyga-ubuntu> 41 tests passed and counting :)
[19:49] <sergiusens> elopio kyrofa having SNAPCRAFT_CONTAINER_BUILDS set and running the tests has very weird hidden side effects
[19:50] <elopio> zyga-ubuntu: we are doing a thing live ^ I know  you like thouse :)
[19:50] <elopio> sergiusens: oh, maybe we should clean all the env vars on setup.
[19:50] <zyga-ubuntu> elopio: I'm in my pyjama already and kind of scruffy looking
[19:51] <zyga-ubuntu> elopio: is it weekly as before
[19:51] <zyga-ubuntu> elopio: I can join next week, today I'm not in shape
[19:55] <elopio> zyga-ubuntu: it's monthly for now. You can always wear a mask
[19:56] <kyrofa> zyga-ubuntu, dang, don't join, you sound like an open-source hacker. We don't want those
[19:57] <zyga-ubuntu> kyrofa: achievement unlocked :D
[19:58] <kyrofa> :P
[19:58] <zyga-ubuntu> kyrofa: I'm in my undies, running tests, playing a game and chatting on 3 computers
[19:58] <kyrofa> You only get the achievement if you're also eating something
[19:59] <zyga-ubuntu> well
[19:59] <kyrofa> Hot pockets, preferably
[19:59] <zyga-ubuntu> unlocked :D
[19:59] <zyga-ubuntu> "serek waniliowy"
[19:59] <zyga-ubuntu> google if you want to see
[19:59] <zyga-ubuntu> but
[19:59] <zyga-ubuntu> drinking pure water out of my "rostopic pub 2016" glass
[20:14] <niemeyer> cachio: fedora-28-64 is ready
[20:21] <cachio> niemeyer, the name is fedora-rawhide-64
[20:21] <cachio> could you please rename the image?
[21:18] <elopio> relocating again...
[22:04] <sergiusens> elopio kyrofa my branch is ready for another look
[22:04] <sergiusens> elopio I would appreciate if you could look into that test failure
[22:07] <mup> PR snapcraft#1764 opened: snapcraft.yaml: use gcc to detect triplet <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1764>
[22:14] <kyrofa> sergiusens, that one is pretty critical ^, and easy to review
[22:23] <sergiusens> kyrofa sure, I'll trade you ;-)
[22:23] <kyrofa> So not equivalent :P
[22:23] <kyrofa> But okay
[22:34] <kyrofa> sergiusens, question. Why did you decide on using a sitecustomize.py versus .pth files?
[22:48] <kyrofa> sergiusens, few doc suggestions left, but it looks quite nice
[22:49] <sergiusens> kyrofa I'll fix those docs
[22:50] <sergiusens> kyrofa .pth are not dynamic between part's install, stage and the actual snap
[22:50] <kyrofa> sergiusens, excellent, that's what I was hoping
[22:50] <sergiusens> kyrofa why are you asking I wonder :-)
[23:06] <Son_Goku> woo