[13:59] <didrocks> who is participating to the Qt5 session? :)
[14:02] <Mirv> welcome anyone to the hangout :) https://plus.google.com/hangouts/_/7ecpjhcv91f5e2g6cvefjmia44
[14:04] <Mirv> https://plus.google.com/+TimoJyrinki/posts/NeUt19z1V3p
[14:08] <Riddell> hi
[14:08] <tsdgeos> hi
[14:11] <didrocks> hey Riddell
[14:11] <didrocks> Riddell: wants to join the hangout?
[14:14] <lool> didrocks: I think I'll drop to another session about cross-compilation now that I raised the main things I wanted to make sure was taken care of; I trust others know better than me about 5.2 issues/bugs to solve etc.
[14:14] <didrocks> Riddell: nice to see you, welcome! :)
[14:14] <didrocks> lool: agreed
[14:14] <didrocks> lool: see you!
[14:35] <Mirv> thanks everyone, adding some notes still to the pad from discussion
[14:36] <rsalveti> seems we're done already
[14:39] <Mirv> rsalveti: yeah, we finished as no new questions or topics were raised.
[14:39] <Mirv> notes in the pad
[14:48] <rsalveti> Mirv: thanks
[15:01] <didrocks> who is going to lead the mediascanner roadmap?
[15:02] <satoris> didrocks: that would be me.
[15:04] <didrocks> satoris: are you joining?
[15:05] <didrocks> https://plus.google.com/hangouts/_/72cpigmmgnfvmfg8d0qugft72c?authuser=0
[15:05] <satoris> Feel free to join.
[15:09] <jdstrand> mediascanner directly usable by apps is useful for application confinement
[15:09] <jdstrand> since it is out of process, 3rd party music players could just use it
[15:10] <jdstrand> yes, please do not allow direct access to the sql db. that will limit what 3rd party apps in the app store can do (due to application confinement)
[15:10] <jamesh> http://bazaar.launchpad.net/~mediascanner-team/mediascanner/v2/view/head:/src/mediascanner/MediaStore.hh
[15:10] <jdstrand> right now, music-app is unconfined. the apis should support it being confined
[15:13] <ahayzen> vthompson, we'll still have to store playlists in our db? but could we reduce it just to the file/uri and query the mediascanner for the metadata?
[15:14] <mhr3> QUESTION: with the new mediascanner, apps open the db themselves, right? how is that going to play with confined apps?
[15:16] <vthompson> ahayzen,  I believe we'll still need to keep track of playlists. But keeping just the URI might be a way forward. I believe we could do that with grilo as well
[15:16] <jdstrand> mhr3: it won't (see above comments). we should provide an api so confined apps don't have to do that
[15:17] <jdstrand> we special cased music-app for 13.10, but it should be confined like everything else
[15:17] <jdstrand> (unfortunately, I got called to another session)
[15:17] <ahayzen> vthompson, I would be happy working on reworking our side of things to do tht
[15:18] <bfiller> QUESTION: is their a library available to do thumbnail generation? we want the mediaplayer-app and gallery-app to use this if so
[15:20]  * jdstrand is still here if you need me
[15:21] <bfiller> cool!
[15:21] <mhr3> bfiller, i think part of it is already in the SDK
[15:22] <bfiller> does it require any special codeces?
[15:22] <bfiller> codecs
[15:22] <bfiller> i.e. ffmpeg or any -ugly stuff?
[15:22] <jdstrand> jamesh: I'm back a few minutes in the feed (cause I got pulled out). we *could* allow readonly access to the db in apparmor policy. the sqlite db has to be opened in a very specific way to do that. I kind of hoped the mediascanner library would call out to the mediascanner process and the mediascanner process could give the info rather than direct access to the db
[15:23] <jdstrand> jamesh: that could be over dbus
[15:24] <mhr3> bfiller, depends on what you want to thumbnail :)
[15:24] <mhr3> bfiller, ultimately it just pokes gstreamer
[15:24] <jamesh> jdstrand: the client library lets you open the database in SQLITE_OPEN_READONLY mode, which should be fine with read only confinement right?
[15:24] <bfiller> mhr3: thanks makes sense
[15:25] <jdstrand> jamesh: the confinement could be made to allow that. right now we don't have policy groups for that, but it could be added
[15:26] <mhr3> jhodapp, shouldn't such test be somewhere in the media stack? thumbnailer just uses gstreamer to get it
[15:26] <jdstrand> jamesh: we have a similar issues with thumbnails btw
[15:26] <jhodapp> mhr3, yes, but I'd also like to test it at this level...i think the more tests in different use-cases the better
[15:27] <mhr3> jhodapp, well it means that thumbnailer will fail only because the media stack will go through a transition
[15:28] <jdstrand> jamesh, satoris: sorry if I missed this-- will the mediascanner do the thumbnailing and then apps use these thumbnails?
[15:28] <jhodapp> mhr3, not sure I'm following
[15:28] <mhr3> jhodapp, if something breaks in media stack, it automatically breaks thumbnailer
[15:28] <jhodapp> mhr3, yes, that's what I want to catch
[15:28] <ahayzen> vthompson, is there any other info we need from the mediascanner?
[15:28] <mhr3> jhodapp, yet thumbnailer is not able to do anything about it
[15:29] <jhodapp> mhr3, right
[15:29] <mhr3> jhodapp, that's why i think the test shouldn't be there
[15:29] <jhodapp> mhr3, I guess that's up to the media scanner team then as I still think it's useful
[15:30] <jdstrand> QUESTION: what is the hangout url?
[15:30] <vthompson> ahayzen, so I think we'll need to maintain a 14.04 specific branch for this capability and possible U1 streaming if we tackle that
[15:30] <jhodapp> https://plus.google.com/hangouts/_/72cpigmmgnfvmfg8d0qugft72c?authuser=0
[15:31] <ahayzen> vthompson, ok, when is the new mediascanner expected to land?
[15:32] <vthompson> ahayzen, sounds like we'll have a PPA to access in some soon-ish timeframe
[15:32] <pstolowski_> QUESTION: is QML bindings something you would consider community could help with, or even drive?
[15:32] <ahayzen> vthompson, cool, guess we can start doing some things and still use Grilo for the moment?
[15:33] <vthompson> ahayzen, I believe we'll have to maintain grilo in Saucy.
[15:40] <jdstrand> jhodapp: thanks for the link btw :)
[15:40] <pstolowski_> QUESTION ^^ :)
[15:40] <jhodapp> jdstrand, np
[15:45] <jdstrand> vthompson: as an aside-- thanks for all the bug fixes for music-app of late :)
[15:45] <jdstrand> I can't wait to get the new player :)
[15:45] <vthompson> jdstrand, :) my pleasure
[15:46] <ahayzen> vthompson, i'm gonna go back home anything u need from me?
[15:50] <vthompson> ahayzen, nope! Safe travels!
[15:50] <ahayzen> vthompson, probably speak in ~1hr :)
[16:01] <dbarth> hiya
[16:02] <didrocks> hey dbarth!
[16:03] <alex-abreu> oa it is then
[16:05] <dbarth> who wants to hop on the hangout?
[16:05] <didrocks> kenvandine: interested?
[16:05] <dbarth> jdstrand: ?
[16:05] <dbarth> kenvandine: ?
[16:05] <kenvandine> yes
[16:06] <jdstrand> dbarth: I will be in irc. mdeslaur could join the hang out since he is leading this discussion on my team
[16:07] <dbarth> ah cool
[16:09] <mmcc> Hi folks :)
[16:09] <jdstrand> dbarth: if you need me to join, I'm here
[16:12] <dbarth> ok
[16:15] <robruds> mardy: friends uses flickr
[16:16] <ssweeny-uds> is the friends flickr plugin installed on the phone?
[16:16] <robruds> ssweeny-uds: nope ;-)
[16:17] <robruds> ssweeny-uds: only twitter and facebook by default.
[16:17] <ssweeny-uds> robruds: that's what i thought
[16:18] <robruds> ssweeny-uds: so I'm just realizing right now for the first time that friends-{flickr,instagram,linkedin} are broken on the phone because they're not installable on a readonly image.
[16:18] <ssweeny-uds> robruds: as a user of third-tier open social networks I've felt pretty marginalized on the phone with no easy way to write friends plugins :)
[16:18] <ssweeny-uds> robruds: yeah that might be a problem...
[16:19] <dbarth> ssweeny-uds: that's why we need click hooks
[16:19] <dbarth> for OA plugins / auth. providers
[16:19] <ssweeny-uds> dbarth: yeah, OA and friends both need them
[16:19] <robruds> ssweeny-uds: yeah, there was a session yesterday about the idea of installing plugins with click, so friends will have to be part of that.
[16:19] <dbarth> ssweeny-uds: but which is currently planned to be a manual process, for partners we can have an audit or agreement with
[16:20] <ssweeny-uds> robruds: we talked about this a few months ago. you said i think that friends plugins would need to be split up into their own processes to allow confinement
[16:20] <robruds> ssweeny-uds: well that was based on my understanding of confinement, more than my understanding of friends plugins.
[16:20] <ssweeny-uds> ah
[16:20] <robruds> ssweeny-uds: so i could be wrong
[16:21] <ssweeny-uds> my thinking is if a friends plugin can only access data associated with the account it's "called" with then the security issues aren't so bad
[16:21] <robruds> ssweeny-uds: the friends plugins are so simple, don't take up any space. i'd like to just have them all installed by default (I was opposed to the original work of splitting them all up into different packages)
[16:21] <ssweeny-uds> like, as long as the twitter plugin can't access your facebook profile the risk is low
[16:21] <ssweeny-uds> robruds: that makes sense
[16:22] <ssweeny-uds> robruds: i'm mostly worried about pushback against click plugins for friends
[16:22] <robruds> ssweeny-uds: haha, no. the friends plugins are python modules, they have total access to the entire friends infrastructure, they can do anything.
[16:22] <ssweeny-uds> yeah, that's what i was afraid of
[16:23] <ssweeny-uds> so there will be security concerns with third-party friends plugins
[16:24] <robruds> ssweeny-uds: hmmm, yeah, this is a tricky issue i hadn't previously considered.
[16:24] <ssweeny-uds> there was talk yesterday of manual review for certain types of packages
[16:24] <ssweeny-uds> this might have to fall under that
[16:25]  * cwayne and ssweeny-uds started work on a click-hooks for o-a
[16:25] <cwayne> ~/.local/share
[16:25] <cwayne> u-s-s-o-a needs to be modified to look for qml-plugins in ~
[16:27] <didrocks> cwayne: ssweeny-uds: robruds: one of you wanting to join the hangout?
[16:28] <dbarth> cwayne, ssweeny-uds: do you want to continue the work on that?
[16:28] <dbarth> the click hook
[16:28] <robruds> dbarth: mardy: sorry I think ssweeny-uds and i are bit offtopic here
[16:28] <dbarth> ie, to get that task done in the plan
[16:28] <ssweeny-uds> dbarth: yes please
[16:28] <cwayne> dbarth, the click hooks should probably be part of the online-accounts system settings package
[16:28] <kenvandine> cwayne has been looking at click packages for account plugins
[16:28] <dbarth> right
[16:29] <ssweeny-uds> dbarth: i'm about 70% done with the patch to the system-settings part
[16:29] <dbarth> but mardy welcomes patches, you see ;)
[16:29] <dbarth> ssweeny-uds: cool!
[16:29] <dbarth> ssweeny-uds: did that get a cjwatson review yet?
[16:29]  * cwayne also volunteers to make an sdk template for new online-accounts once we have them as clicks
[16:29] <dbarth> awesome!
[16:30] <mardy> http://developer.ubuntu.com/api/qml/sdk-1.0/
[16:30] <cwayne> i think all we're waiting on re: click hooks is getting this fixed: https://bugs.launchpad.net/ubuntu/+source/click/+bug/1245826
[16:30] <udsbotu> Launchpad bug 1245826 in click (Ubuntu) "Allow applying a hook to multiple files" [Wishlist,Triaged]
[16:30] <mmcc> QUESTION: Is there anything currently using signon-ui on ubuntu touch? Our UbuntuOne provider plugin has custom QML UI for login, and needs signon-ui to support QML so we can handle requesting re-authentication for invalidated tokens.
[16:30] <mardy> http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.OnlineAccounts/
[16:31] <ssweeny-uds> dbarth: the patch i'm working on now is just to get the settings UI to load stuff from ~/.local/share/
[16:33] <mmcc> mardy: this is re your comment on bug 1248326
[16:33] <udsbotu> Ubuntu bug 1248326 in Unity Click Scope "Handle invalidated token in a more user-friendly way" [Undecided,New] https://launchpad.net/bugs/1248326
[16:38] <ssweeny-uds> this (multiple possible domains) discussion is also useful for things like owncloud or statusnet which don't have a central server
[16:38] <dbarth> ssweeny-uds: do you have a working model for that?
[16:38] <dbarth> are you constraining urlpatterns?
[16:39] <ssweeny-uds> dbarth: i don't know if you can do that. the domain could be anything
[16:39] <dbarth> ssweeny-uds: oh, meaning, any server where you would host the service?
[16:39] <ssweeny-uds> yeah
[16:40] <dbarth> i see
[16:40] <dbarth> but are you using a webapp container for this one?
[16:40] <dbarth> or would like to do so
[16:40] <ssweeny-uds> dbarth: for instance i have statusnet and owncloud services running on my own domain
[16:40] <dbarth> want to hop on the hangout?
[16:40] <ssweeny-uds> dbarth: i'm not actually looking to use webapps. i'm talking more generally that i'd like OA to be able to handle decentralized services
[17:00] <dbarth> thanks everyone for your feedback on the topic
[17:01] <dbarth> and for the upcoming contributions more importantly!
[17:01] <dbarth> really appreciated
[17:59] <olli> who is running this track?
[18:00] <olli> got a link to the URL
[18:00] <olli> lol
[18:00] <olli> link to the HO
[18:03] <tvoss_> didrocks, r u running the hangout?
[18:03] <didrocks> tvoss_: yeah, want to come?
[18:03] <didrocks> thostr: is going to lead it
[18:04] <doko> what's the hangout URL?
[18:05] <didrocks> doko: it's about unity8 scopes
[18:05] <didrocks> doko: are you sure you are in the right room?
[18:05] <tvoss_> didrocks, listening in :)
[18:19] <Saviq> QUESTION: is JavaScript considered less resource hungry than Python/
[18:19] <Saviq> ?
[18:20] <olli> QUESTION: what's the situation re security & JS?
[18:20] <satoris> The basic memory footprint of Python interpreter is 5MB or so.
[18:21] <mhr3> didrocks, can you mute yourself?
[18:21] <didrocks> mhr3: sorry, done
[18:21] <mhr3> thx
[18:21] <davidcalle> Also, for the record, the memory footprint of a basic running scope is around 9MB.
[18:21] <davidcalle> Python ^
[18:22] <facundobatista> davidcalle, that have imported all the gio crazyness, right?
[18:22] <davidcalle> facundobatista, right
[18:23] <facundobatista> davidcalle, that's not fair ;)
[18:23] <jdstrand> fyi, https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement
[18:25] <jdstrand> (I also added ^ to the pad)
[18:27] <jdstrand> QUESTION: can you comment (for the wider community) on how you've addressed privacy wrt to scopes? (ie, briefly detail the work you've done on disabling internet scopes globally and on a per scope basis, etc)
[18:27] <jdstrand> (of course the security design feeds in to that too)
[18:28] <jdstrand> (but you already mentioned that :)
[18:29] <jdstrand> I know the answer-- but thought others might be interested in it :)
[18:33] <alecu> regarding the online switch for scopes: the click scope listens to that setting too, and disables getting "suggested apps" from the click webservice when online searches are off. It
[18:33] <alecu> it still does the search of locally installed apps
[18:42] <pedronis2> we are also proxying images, so those don't get to the original server either
[18:52] <fugue88> What's the name of that "global search" ?
[18:52] <fugue88> David mentioned it.
[18:52] <Saviq> davidcalle, ↑
[18:52] <davidcalle> fugue88, Blippex
[18:52] <fugue88> Thanks!
[18:53] <davidcalle> fugue88, np. Here is a few screenshots : https://plus.google.com/+davidcalle/posts/7E1SDPZie9p
[18:53] <pedronis2> thanks
[18:54] <fugue88> davidcalle: Cool.  Interesting that they allow you to set "dwell time" and other things.
[18:54] <davidcalle> fugue88, yes, this is a very interesting search engine.
[19:01] <tvoss_> didrocks, ping
[19:01] <tvoss_> niemeyer, hey there :) wanna join us on the hangout?
[19:01] <didrocks> tvoss_: pong
[19:01] <niemeyer> tvoss_: Sure, link?
[19:01] <tvoss_> didrocks, got the ho link for me?
[19:01] <didrocks> tvoss_: I sent you the links 5 minutes ago :p
[19:01]  * didrocks does again
[19:01] <tvoss_> didrocks, don't have it :/
[19:02] <tvoss_> didrocks, this time it worked
[19:02] <tvoss_> niemeyer, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
[19:02] <didrocks> tvoss_: I sent it to him already FYI ;)
[19:02] <tvoss_> jdstrand, wanna join the hangout, too?
[19:03] <tvoss_> jdstrand, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
[19:03] <jdstrand> tvoss_: actually, I was going to attend a different session and have two people here if you need comments from the security team
[19:03] <tvoss_> jdstrand, would like to have someone on the hangout, yes
[19:03] <jdstrand> tvoss_: if you feel my input is required, I'll attend
[19:03] <tvoss_> jdstrand, not necessary, as long as someone from security is here
[19:08] <zyga> hi
[19:09] <lool> tvoss_: do we have someone representing SDK team?
[19:09] <tvoss_> lool, nope, can you pull zoltan over?
[19:10] <lool> tvoss_: poked him
[19:10] <pmcgowan> lool, I will join for now
[19:10] <fugue88> QUESTION: By client side, do you mean GUI, or more generic than just GUI?
[19:11] <tvoss_> fugue88, more generic than just UI
[19:15] <fugue88> On the other hand, with gcc *maybe* making gccgo a default, it might get some more popularity.
[19:16] <fugue88> Of course, we don't have a crystal ball.
[19:16] <cjwatson> can I have the hangout url?
[19:16] <tvoss_> fugue88, look at https://launchpad.net/usensord for example
[19:16] <tvoss_> cjwatson, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
[19:16] <Saviq> cjwatson, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
[19:16] <cjwatson> ta
[19:16] <zyga> IIRC linaro was doing some work on porting go to aarch64
[19:16] <zyga> https://groups.google.com/forum/#!topic/golang-dev/MLaz62sHUc0
[19:17] <zyga> one of the people there is actually working for canonical
[19:19] <tedg> jdstrand, Why is compiling every application an issue?  Tooling?
[19:19] <zyga> tedg: upgrades probably
[19:19] <Saviq> tedg, no, we don't have the sources
[19:19] <zyga> tedg: imagine if everything is in go :-(
[19:20] <Saviq> tedg, think of all the apps in the store - all would need to be recompiled
[19:20] <zyga> tedg: 10GB upgrade for each security issue?
[19:20] <zyga> ah, store argument is important too
[19:20] <tedg> Well, the store is different.
[19:20] <zyga> I don't think go is designed to work well there
[19:20] <tedg> We can't apply security updates to store things mostly.
[19:20] <tedg> It's all BYOD (Bring your own deps)
[19:20] <Saviq> tedg, that's why we're talking about "go's stdlib"
[19:21] <Saviq> tedg, which would be provided by us
[19:21] <zyga> tedg: but we can ship fixed libraries (ssl, etc)
[19:21] <tedg> Plus things in click packages are confined.  We don't care about security anymore ;-)
[19:21] <fugue88> If an app dev has bundled their own crypto library in the click-package, the distro couldn't handle that anyway, right?
[19:21] <zyga> tedg: mmaaybe
[19:21] <Saviq> tedg, see, Jamie is responding right now ;0
[19:21] <Saviq> damn shift...
[19:22] <cjwatson> fugue88: their own, sure, but they should be able to use the crypto library in the stdlib without having to update their app every time there's a security vulnerability found in it
[19:22] <fugue88> cjwatson: Well, I certainly agree about that, but some things will be bundled and have security concerns nonetheless.
[19:23] <fugue88> But the burden on app devs to recompile every time the platform shifts is a big one.
[19:23] <cjwatson> the perfect must not be the enemy of the good
[19:23] <cjwatson> just because some things will end up being bundled doesn't mean we shouldn't make efforts to avoid bundling the stdlib with everything
[19:24] <fugue88> No no, I agree.
[19:24] <cjwatson> tedg: that only means the application can't compromise the rest of the system, not that it cannot be compromised itself
[19:25] <tedg> cjwatson, Sure, but that means that the attack surface is much smaller.
[19:25] <tedg> cjwatson, And the consequences of the attack.
[19:25] <cjwatson> yes, but not that it should be ignored
[19:25] <cjwatson> I don't think it would be responsible for us to ignore it
[19:25] <tedg> I'm not saying it should be ignored, but I am saying that it may not be a blocker considering its size.
[19:26] <Saviq> QUESTION: when talking Go/QML, QML in itself is very modular, allows for easy reusability between projects, would a Go QML extension/module be usable outside of a Go application?
[19:30] <kardianos> Go support hard float
[19:30] <kardianos> (It works on rpi)
[19:30] <lool> thanks for the confirmation
[19:30] <tvoss_> thx
[19:32] <jdstrand> weird, I dropped out (connection was lost)
[19:32] <lool> that's why you looked so static
[19:33] <Saviq> niemeyer, thanks, I'm game :)
[19:33] <kardianos> Go gc I'm fairly sure now generates PIC as a precursor for generating so objects. They are still attempting to fill the whole shared object story, no timeline yet, but the story is being developed.
[19:33] <cjwatson> Would this be easier if using gccgo?
[19:33] <niemeyer> kardianos: Right, and that's not even about Go 1.2..
[19:33] <kardianos> Correct
[19:34] <kardianos> I don't think it will be easier then gccgo, but I could be mistaken. Just the runtime story just haven't  been finished.
[19:35] <cjwatson> Well, I ask because I understand (at second hand) that one can already build Go shared objects with gccgo
[19:35] <Saviq> lool, no, reusable - and yes - IIUC niemeyer said it's possible - not yet, though
[19:35] <kardianos> You could be correct there.
[19:38] <kardianos> Not anymore
[19:38] <kardianos> There is no longer any runtime code generation.
[19:42] <Saviq> tvoss_, also, the main() for QML apps is usually minimal (if any), and porting that to Go wouldn't be a substantial task, if needed
[19:42] <tvoss_> Saviq, yup, +1
[19:42] <Saviq> so, yeah, goqmlscene would be enough in most cases
[19:42] <Saviq> as qmlscene is enough in most cases now
[19:43] <Saviq> QUESTION: any estimate on what could the overhead of a .so with the Go runtime be when used from a C++ application? I assume there would have to be a runtime-per-extension?
[19:44]  * Saviq poking holes, sorry
[19:44] <niemeyer> Saviq: A bit early to tell
[19:44] <Saviq> niemeyer, right, thanks
[19:58] <sergiusens> lool, Mike is using https://code.launchpad.net/~jamesh/go-dbus/trunk
[19:59] <lool> thanks
[19:59] <lool> it's listed in the bp already
[19:59] <lool> actually the topic I wanted to open were which go library bindings we missed
[19:59] <lool> but it seems dbus is not a problem anymore
[19:59] <sergiusens> lool, I'm also trying to get these into debian (as well as niemeyer's gocheck)
[20:00] <sergiusens> lool, I jsut noticed I'm not 'live' :-/
[20:00] <sergiusens> sorry :-)
[20:00] <lool> np
[20:00] <Saviq> session has ended → tvoss_ beer
[20:00] <tvoss_> Saviq, yup :)
[20:01] <didrocks> yeah, but jdstrand had a disruptive not intending to be disruptive but which can be seen as disruptive question :p
[20:01] <pmcgowan> out of battery
[20:02] <didrocks> oh, the excuse from Pat to drink beers :)
[20:03] <lool> well it's Pat's battery
[20:03] <lool> it needs beer to recharge
[20:03] <didrocks> heh
[20:04] <lool> he didn't say his *laptop* ran out  ;-)
[20:04] <ogra_> thats was a fast beer
[20:04] <lool> :-)
[20:04] <Azendale> I'm interested in learning about any bindings from Qt to Go. (Last time I looked, it didn't seem like there really was anything). Can anyone point me in a direction?
[20:04] <ogra_> beer injection :)
[20:06] <Saviq> Azendale, here's what niemeyer is working on https://github.com/niemeyer/qml
[20:07] <Azendale> Saviq: Thanks!
[20:07] <Saviq> o/