Open Source Meeting/2009-04-02

== Agenda ==
== Transcript ==
* [14:01] Rob Linden: howdy folks
* [14:01] Morgaine Dinova: Hi Rob!
* [14:01] Dale Glass: hi Rob
* [14:01] Robin Cornelius: Hey
* [14:01] Atashi Toshihiko: hello Rob :)
* [14:01] Saijanai Kuhn: hey rob. just farting around
* [14:01] JB Kraft: hey rob :)
* [14:01] Morgaine Dinova: hands out noseplugs
* [14:02] Rob Linden: standard caveat: I'll be posting the transcript from this meeting on wiki.secondlife.com. keep that in mind as you type
* [14:03] Rob Linden: I'm assuming you all saw Philip's blog post ... :)
* [14:03] Morgaine Dinova: Yep!
* [14:03] Rob Linden: He'd be here today if he weren't giving a talk at Web 2.0 today
* [14:03] JB Kraft: aye, woke me up it did
* [14:04] Rob Linden: he asked that I set up a public meeting on Tuesday with voice as sort of a supplement to our normal Thursday chats
* [14:04] Rob Linden: (next week only, at least for now).
* [14:05] Dale Glass: hi Soft
* [14:05] Rob Linden: I'll send mail out to sldev when I actaully get a time figured out
* [14:05] Soft Linden: Hey hey
* [14:05] Morgaine Dinova: It's always nice to see more open source initiatives. It still seems to be rooted in the "LL control" paradigm though, oddly. Or maybe I misunderstood.
* [14:05] Rob Linden: Morgaine: well....
* [14:06] Aimee Trescothick: you have to avoid "Horse designed by committee syndrome" somehow
* [14:06] Rob Linden: there's nothing stopping anyone from forking, which should continue to keep us honest, but Aimee is exactly right
* [14:06] JB Kraft: sounded to me like a way to cut down on the jira backlog. but maybe i misunderstood too :)
* [14:06] Rob Linden: in proprietary software, there's exactly one dictator, and the license prevents you from taking your ball and going somewhere else
* [14:07] Morgaine Dinova: That's what we have now though, multiple forks. I was hoping for fork reduction, but this central management won't encourage that.
* [14:07] Rob Linden: in open source, you don't get rid of the dictator, but the dictator can't overplay their hand, because a fork could take over
* [14:07] Dale Glass: not everybody is interested in reducing forks though
* [14:08] Techwolf Lupindo: looks at his gentoo overlay "There is currently four alternitiver SL viewers in there now"
* [14:08] Saijanai Kuhn: counting pyogp? ;-)
* [14:08] Techwolf Lupindo: pyogp? Is that another one i've havn't heard about yet?
* [14:08] Saijanai Kuhn: python test client
* [14:09] Rob Linden: forks and branches aren't inherently bad things, especially when there's still a clear "central" project
* [14:09] Morgaine Dinova: Sai: pyogp can't be emerged because of its lack of coherent dependency control.
* [14:09] Saijanai Kuhn: shrugs
* [14:09] Saijanai Kuhn: sttrictly a pirate flag operation at this point
* [14:10] Rob Linden: anyway, what's different now than before about this new thing is that you're going to get to know a lot more of the developers checking in code
* [14:10] Techwolf Lupindo: I just need a URL to the home page and i'll consider adding or creating an ebuild. :-)
* [14:10] Saijanai Kuhn: 
* [14:10] Robin Cornelius: oh Rob with more code checkins live, #opensl-svn is quite revelant then ;-p
* [14:11] Techwolf Lupindo: on what IRC network?
* [14:11] Morgaine Dinova: Rob: I think it's a good thing, but not quite far enough. Perhaps there's room for 3 tiers: LL, LL+, and LL++, and then the multiple forks beyond that :-)
* [14:11] Robin Cornelius: EFNet
* [14:11] Rob Linden: Robin: is #opensl-svn a separate channel?
* [14:12] Robin Cornelius: yes, it was looking too spammy for #opensl so i created an extra one
* [14:12] Rob Linden: didn't know that....
* [14:12] Rob Linden: joins
* [14:12] Robin Cornelius: i did it about 4 mins ago
* [14:12] Morgaine Dinova: chuckles
* [14:12] Robin Cornelius: only started messing with the svn feed today
* [14:13] Rob Linden: I personally think it's just fine on one channel
* [14:13] Rob Linden: but we don't need to debate that here
* [14:13] Robin Cornelius: kelly was not so keen, we can see how it plays out and make a desision again
* [14:13] Rob Linden: (and I don't have a strong opinion)
* [14:14] Rob Linden: back to the subject of talking about the http-texture project....
* [14:15] Soft Linden: My take on channels is it's good to split them - but only after they have enough volume to warrant it
* [14:15] Soft Linden: Too few checkins right now for a bot to be spammy.
* [14:15] Techwolf Lupindo: agrees with solf.
* [14:15] Techwolf Lupindo: soft
* [14:16] Rob Linden: I guess a key difference is that we're more open to be convinced on our development direction than we might have been in the past
* [14:17] Rob Linden: ...and we're all pretty committed to giving people more of an opportunity to collaborate as peers
* [14:17] Techwolf Lupindo: http-texture is a good. If properlly impleted using static timestamps, e-tag, static URL, and use cookies for auth. This would make it compatiable with the hundreds of http cache servers out there that have been installed by ISP for there customers.
* [14:17] Rob Linden: Techwolf: exactly. that was part of the appeal
* [14:18] Techwolf Lupindo: Image downloading all the texture from a local catcha at full 20Mbs speed.
* [14:18] Morgaine Dinova: waves at Nyx
* [14:18] Soft Linden: (Plus - having Philip involved is like adding a bulldozer with twin bullhorns and the CEO's cell number to the team)
* [14:18] Techwolf Lupindo: lol
* [14:19] Rob Linden: yeah....I was downplaying that, but it definitely helps
* [14:19] Soft Linden: :)
* [14:19] Techwolf Lupindo: Added benifent to LL, greatly reduced bandwith bill. My guess it would cut down the bandwith by over half. But that a rough guess on my part.
* [14:20] Soft Linden: Do we have people here who have really dug into the full texture pipeline?
* [14:20] Robin Cornelius: i've got dirty enough in it
* [14:20] Merov Linden: reduce the load on the asset server big time
* [14:20] Soft Linden: From the moment a list of needed textures is identified to the moment they're completely decoded?
* [14:20] Techwolf Lupindo: I have an http-texture ebuild and did play with it yesterday.
* [14:20] Robin Cornelius: i've poked and prodded most of the way through yes
* [14:20] Robin Cornelius: actualy found what might be a bug to
* [14:20] Morgaine Dinova: checks Techwolf's overlay
* [14:21] Robin Cornelius: its not cashing small textures less than about 1000 bytes (the old implementation)
* [14:21] Techwolf Lupindo: gentoo.techwolf.net </plug>
* [14:21] Soft Linden: Wild - deliberately?
* [14:21] Merov Linden: Robin: what makes you think that?
* [14:21] Morgaine Dinova: Yeah, got you in layman already
* [14:21] Merov Linden: there's no down limit on texture size to be cached
* [14:21] Robin Cornelius: i found hard evidence that textures that i could see were not in the cache
* [14:22] Robin Cornelius: and there is a lovely if statement that blocks
* [14:22] Merov Linden: would you mind to share those evidences?
* [14:22] Robin Cornelius: i'll find it a moment
* [14:22] Squirrel Wood: The client cache indeed needs a total rewrite
* [14:22] Morgaine Dinova: Robin really need a medal you know. (A few others too :P)
* [14:23] Merov Linden: yeap, I emailed sldev about this
* [14:23] Merov Linden: this is one of the objective of that branch
* [14:23] Robin Cornelius: check out this paste bin 
* [14:23] Merov Linden: checks
* [14:23] Robin Cornelius: when it comes from the fetcher to the save routine it runs through a couple of if's
* [14:24] Robin Cornelius: if it does nor pass if (datasize >= TEXTURE_CACHE_ENTRY_SIZE) then ir is just deleted
* [14:24] Techwolf Lupindo: My experence with textures downloading is that after I fully downloaded a textrue and re-log or re-tp to a sim, the textures are re-downloaded again, but not all of it. They are downloaded quicker due to all the data in the catche, but the client/server still has to send the data to tell the client that it can use the cache for decoding. This causes many fuzzy textures for a minute or more for me.
* [14:24] Merov Linden: Robin: this is becaus the texture is so small it fits into the header cache
* [14:24] Merov Linden: it *is* cached, but it's all in the header cache file
* [14:25] Merov Linden: see my writing on : 
* [14:25] Robin Cornelius: no its not ;-)
* [14:25] Robin Cornelius: i did some extensive testing
* [14:25] Merov Linden: there's no "body" file but there's an entry and a 600 bytes record in the header cache
* [14:25] Robin Cornelius: i was calling this LLAppViewer::getTextureCache()->readFromCache(id,LLWorkerThread::PRIORITY_HIGH,0,999999,responder);
* [14:25] Squirrel Wood: ripping headers and bodies apart.. and then having to find both again... isn't that causing unneccessary overhead?
* [14:25] Merov Linden: that all depends what you checked
* [14:26] Robin Cornelius: the responder i get back from texture cache reports there is no entry in the index/headers only file
* [14:26] Rob Linden: smells a unit test in the making.....
* [14:26] Merov Linden: hmmm... then *that* would be a bug
* [14:26] Merov Linden: not the intended design for sure
* [14:26] Merov Linden: I'm surprised though but willing to investigate
* [14:27] Morgaine Dinova: WTB Advanced->TextureCache->Grep
* [14:27] Robin Cornelius: by commenting out as per that paste bin, it works
* [14:27] Robin Cornelius: i can then find the texture in the cahse using readFromCache()
* [14:27] Rob Linden: let's talk about unit testing for a second, because it's a really hot topic around here, and this seems like a fantastic example to talk through
* [14:28] Q Linden: is this related to the delete responder? That looks like leaky code
* [14:28] Morgaine Dinova: Yes!
* [14:28] Q Linden: whoops, sorry
* [14:28] Merov Linden: will checks Robin finding, suspects a bug
* [14:28] Rob Linden: not knowing myself how one would go about adding a unit test, I'm hoping someone will chime in on exactly how a unit test for this problem would be composed
* [14:29] Techwolf Lupindo: ears perk up "What is unit testing? I could guess, but i am sure I will be wrong. :-)"
* [14:29] JB Kraft: are there some UT frameworks on the table?
* [14:29] Robin Cornelius: well the basic principle here is to test the cache works
* [14:29] Robin Cornelius: we need to inject test textures and check they can be recalled
* [14:29] Rob Linden: ^^^^ that was an invitation for other Lindens to chime in
* [14:30] Robin Cornelius: the functions in lltexturecache can be exposed seperatly enough for this to work quite easly in this case
* [14:30] Merov Linden: I did wrote unit tests for the map
* [14:30] Rob Linden: (especially the ones with fantasies of the community chipping in on new unit tests) :)
* [14:30] Merov Linden: they are on the http-texture branch
* [14:30] Merov Linden: check under newview/tests
* [14:30] Robin Cornelius: notice the unit tests on that build
* [14:31] Saijanai Kuhn: would it be possible to use SLproxy to inject textures at the client side so you don't need to mod the server much, if any?
* [14:31] Morgaine Dinova: Rob: well unit testing in this area certainly involves being able to check state before and after an operation. My "->Grep" line wasn't a complete joke. If you can't see the effect of something you do, you can never be sure it's done.
* [14:31] Merov Linden: it's using a framework called "tut" and, basically, allow a module (understood as a cpp file) to be exercised independently of everything else
* [14:31] Mm Alder: Finding repeated cache misses of the same file would help find problems.
* [14:32] Q Linden: The point of a unit test is NOT to be doing fetches from the server; that's not a unit test any more
* [14:32] Morgaine Dinova: Q++
* [14:32] Merov Linden: thanks Q
* [14:32] Merov Linden: I was about to write a complex line to talk about this :)
* [14:32] Q Linden: we'd love a set of tests around the caching system that tested it without making connections
* [14:32] Robin Cornelius: in this case readFromCache(0 and writeToCache() could be isolated and tested
* [14:33] Q Linden: for those interested, we're pretty enamored of a book by Michael Feathers
* [14:33] Robin Cornelius: you just feed in data, it will cache what every you feed that function, 600 bytes in the header, the rest in a file
* [14:33] Q Linden: called Working Effectively with Legacy Code
* [14:33] Q Linden: It's got a lot of practical techniques for injecting tests into existing codebases
* [14:33] Merov Linden: I actually think that the cache system could be tested to stick something in (fake) and read back it's there without fetching anything or relying on local cacle
* [14:33] Merov Linden: cache
* [14:34] Q Linden: right, exactly
* [14:34] Merov Linden: that *should* test the "smaller than the header cache" issue Robin alluded to
* [14:34] Techwolf Lupindo: Being able to start the SL client and connect to a db/file instead of the grid and explore a "fake" sim would be a neat thing and could possibley help in testing.
* [14:34] Merov Linden: at least, some aspects of it
* [14:34] Rob Linden: this is a really really good area for a new developer to get involved
* [14:34] Saijanai Kuhn: very vauge thought: can MacOS X instruments be used to fake data from the server?
* [14:34] Q Linden: Techwolf -- you're thinking too high-level for unit tests
* [14:35] Q Linden: that's a great use case, yes, but not a unit test
* [14:36] Merov Linden: Another thing I need to work on is perf data gathering: start the viewer in auto run, time how long it takes to get to the loggin screen, exit
* [14:36] Mm Alder: Although unit test are good while the system is being developed, you really should do full function tests if you can.
* [14:36] Morgaine Dinova: Q: the fact that Michael Feathers' own website links to a broken page for his book is an interesting commentary on the state of things :P
* [14:36] Merov Linden: that's not a unit test but an interesting metric
* [14:36] Q Linden: mm -- eventually
* [14:36] Q Linden: I don't disagree AT ALL
* [14:36] Q Linden: but if you hold out for the perfect you may never get there
* [14:37] Mm Alder: The advantage of using live data rather than fake write/reads is that you get cases that you would never think to put into your unit test.
* [14:38] Merov Linden: and vice versa Mm Alder :)
* [14:38] Mm Alder: True
* [14:39] Merov Linden: like: tests things don't blow up if throwing complete garbage into a jpeg buffer
* [14:39] Morgaine Dinova: So, being practical .... how can we add more testability into the client?
* [14:39] Robin Cornelius: heh tried that
* [14:39] Mm Alder: Oh I'm sure the live test will do that too. :-)
* [14:40] Robin Cornelius: uploaded total rubbish to a jpeg on my opensim and DOS myself, LL servers wont do that
* [14:40] Techwolf Lupindo: So true. I'me on a good connection and havn't had my client crash in over a week. But on my old connection, it crashed every hour due to either missing packets or garbage in the data. SL is the only client I know of that can't handle garbage in the data.
* [14:40] Rob Linden: do we have a "writing your first unit test" document on the public wiki?
* [14:40] Q Linden: morgaine, that's a huge focus of our efforts over the next few months; at first, it's very hard
* [14:41] Q Linden: rob, not quite yet...but I'll take that as a task
* [14:41] Merov Linden: I wrote such a doc for the internal wiki
* [14:41] Merov Linden: Could be a good spring board Q
* [14:41] Q Linden: Yes, Merov -- exactly
* [14:41] Morgaine Dinova: Q: wondering how community can help.
* [14:42] Q Linden: Morgaine: we really WANT your help
* [14:42] Merov Linden: Morgaine: writing unit tests would help for sure :)
* [14:42] Q Linden: so that's why I want to write down how we'd like it, so we can most easily take it
* [14:42] JB Kraft: merov: how to get them to you?
* [14:42] Merov Linden: log a PJIRA and attach a patch
* [14:43] Merov Linden: that's the best
* [14:43] JB Kraft: k
* [14:43] Techwolf Lupindo: I still have access to my old internet connection, I could do real world network testing of bad data. That one way the communities can help. I think.
* [14:43] Rob Linden: https://jira.secondlife.com/browse/WEB-1028
* [14:43] Merov Linden: I (and soft and all committers) review those on a regular basis
* [14:43] Merov Linden: also, just testing the binaries does help too
* [14:43] Morgaine Dinova: The SL viewer is the most highly instrumented client I've ever seen for any kind of 3D experience. I think it's a great start. How can that be extended to support more testing from the community side, that's the question. What patches would help?
* [14:44] Soft Linden: That (WEB-1028) will really, really help. It's really tough to see where to take the first bite.
* [14:44] Merov Linden: Aimee reproed a bug that only Philip saw before while testing
* [14:44] Q Linden: Morgaine, if we build out-of-band (compile-time) unit tests, that has a nice side effect of reducing coupling between components and making it easier to do other kinds of testing, measurement, and refactoring
* [14:45] Techwolf Lupindo: I like to see a patch that removes all crashlogger code from the main client. This is so we linux users can get _real_ core dump to run gdb on and get meanfull backtraces.
* [14:45] Aimee Trescothick: oh yeah, the black hole bug :)
* [14:45] Merov Linden: nods
* [14:45] Q Linden: Hah, Rob is quick. I'm already assigned to the internal and external bugs. Nice.
* [14:45] Soft Linden: Removing crashlogger shouldn't be hard - that should really be a command line option, to not launch/initialize it.
* [14:45] Morgaine Dinova: Q: would be better if those test facilities were integrated though. Then *everyone* can test.
* [14:45] Robin Cornelius: Techwolf i tried that once the core was 800Mb ;-( had the bright iread of using gnome bug-buddy on omvviewer
* [14:46] Robin Cornelius: s/iread/idea/
* [14:46] Soft Linden: I'd catch that ask in JIRA if you haven't already
* [14:46] Techwolf Lupindo: The crashlogger.bin can be remove, but the SL code still calls it. One get a "file not found" error on the consule output.
* [14:46] Robin Cornelius: yea, it can be removed but takes a little surgery to actualy core correctly
* [14:47] Techwolf Lupindo: Robin, I have 8G RAM on my box. 2G core dumps are not a problem for me.
* [14:47] Robin Cornelius: bug-buddy emails them to the developer if set up though ;-p that would hav ebeen fun
* [14:48] Rob Linden: so, I realized mid discussion here that I skipped over Robin's first item.
* [14:48] Rob Linden: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
* [14:48] Rob Linden: VWR-12656[c
* [14:48] Techwolf Lupindo: Soft, command line to dis-able crasshlogger so as not to interfer with crash singles would be a great thing too add. Is there an existing pjira for that?
* [14:49] Soft Linden: Techwolf - I just asked -you- that. :) I'd capture it in pjira if you don't know of it.
* [14:49] Robin Cornelius: yea i think 80% of linux 64 packages are done and in install.xml can we just add the remaining few?
* [14:49] Rob Linden: Techwolf: I don't think there is....and a duplicate isn't going to kill us
* [14:50] Rob Linden: you might have seen I assigned to myself. one big issue is that there's some automation we need to do in this area
* [14:50] Robin Cornelius: i worked around them being missing and basicly it all builds and works, so not much can be done from the comminuty side
* [14:50] Techwolf Lupindo: Soft, LOL, ok. I'll look into it. I did create VWR-12678 yesterday. I'll think about updateing that one to feature request.
* [14:51] Rob Linden: it'd be a pretty tedious and time consuming task to add libraries right now, to the poitn that getting some general automation may make sense as a prerequisite task
* [14:51] Robin Cornelius: ok, you probably saw we have a potential fallback for the time discussed on the pJIRA
* [14:51] Soft Linden: Yar. A worthy goal internally would be getting an automated process in place that can replicate our current 32-bit set, then repeat that for the 64-.
* [14:52] Rob Linden: if the goal is "64 bit LInux supprot", it's hard to get a lot of people excited about that at Linden
* [14:52] Robin Cornelius: 64bit build out of the box would be a *bug* plus
* [14:52] Techwolf Lupindo: Buiding 64 solves a lot of issues. One of witch is gstreamer crashing the client on music play.
* [14:52] Robin Cornelius: *big*
* [14:52] Rob Linden: if the goal is "better build reproducability for all platforms", that's much easier to get folks behind
* [14:53] Q Linden: robin, lol: that is the worry. :)
* [14:53] Soft Linden: 64-bit viewer support - hard to get folks excited just because of usage numbers. But we need to pay more attention to 64-bit on sims. So if we can use the same processes...
* [14:53] Robin Cornelius: 64bit users don't seem to be afraid of a compile if there are not too many hoops, but that fact its such a pain to build is an issue for many
* [14:54] Rob Linden: one thing that we discussed at Linden just this morning was the fact that we really need to do a better job of getting people excited about mainstream problems for the central project
* [14:54] Robin Cornelius: Techwolf, you going to update VWR-12678 to a feature request for the optional crash logger?
* [14:54] Techwolf Lupindo: Soft, are those usage number from the interniela stats? Everyone but those that build there own client will be 32. Those usage stats will be hightly skewed.
* [14:55] Dale Glass: I'm going to try to start releasing 64 bit builds
* [14:55] Rob Linden: Robin: having two 64-bit Linux boxes at home myself, I definitely am personally motivated to solve the problems
* [14:55] Dale Glass: as soon as I get my processes going
* [14:55] Rob Linden: but....
* [14:55] Robin Cornelius: Soft, i know you can't make them public but have a look at the distribution between 32/64 for my viewer
* [14:55] Techwolf Lupindo: Robin, I can. Sence it would make a better pjira sence there is currently no way to disable crashlogger.
* [14:55] Dale Glass: btw, does 64 bit work on windows?
* [14:55] Rob Linden: Robin: I've been meaning to dig up your numbers...what are they?
* [14:55] Rob Linden: I know I have them in email somewhere
* [14:56] Robin Cornelius: i only know the debian, not ubuntu or arch and they are 40/60 -- 64/32 bit
* [14:56] Soft Linden: Robin - I think a lot of people go to your viewer -because- of the 64-bitness. The ratio wouldn't apply the same way.
* [14:56] Techwolf Lupindo: Uh-oh..I can't change from a bug to feature request on the pjira. I'll have to made a new entry.
* [14:56] Rob Linden: Soft: I wouldn't be surprised if Robin's numbers are in the ballpark, though
* [14:57] Rob Linden: (and we don't have any numbers that are more accurate)
* [14:57] Robin Cornelius: well you might be able to get the entire omvviewer login pattern, i can only see debian downloads
* [14:58] Morgaine Dinova: It's chicken and egg. I have a 64-bit machine but I don't use with SL except for testing because 32-bit emul doesn't support gstreamer. The number of 64-bit users would undoubtedly rise if it worked :P
* [14:58] Rob Linden: anyway Robin, I think there's a path forward here, which is the automation task
* [14:58] Robin Cornelius: Techwolf, moved to a new feature
* [14:58] Robin Cornelius: Rob, sounds good
* [14:58] Rob Linden: the only other agenda item was from Seg, who isn't here, and I don't think we have an update for anyway
* [14:59] Techwolf Lupindo: Robin, I see it now. Will edit it after this meeting.
* [14:59] Rob Linden: (I personally haven't nagged on that front to find out the latest on the TopCoder thing)
* [14:59] Robin Cornelius: i know why seg is asking
* [14:59] Robin Cornelius: the top coder used a specific version of gcc for the tests
* [15:00] Robin Cornelius: openjpeg-dev know that *significant* improvments are made using a newer gcc
* [15:00] Robin Cornelius: the code that won may not be the best on the latest gcc
* [15:00] Robin Cornelius: and other entries may all touch different parts of the code or be mergable
* [15:00] Rob Linden: hmmm....good to know
* [15:01] Robin Cornelius: plus to merge to openjpeg you need to get through Seg and Dzontaz
* [15:01] Techwolf Lupindo: In the next few days, I hope to get running the IBM e-server pSeries 690 that has 256 cores and see how long it takes for the SL code to compile. :-)
* [15:02] Soft Linden: sneaks - other meeting
* [15:02] Morgaine Dinova: LOL Techwolf :P
* [15:02] Rob Linden: yeah, we're running a little over already
* [15:02] Rob Linden: unless there's anything particularly urgent, I should get going
* [15:02] Q Linden: thanks, all
* [15:02] Robin Cornelius: Thanks
* [15:03] Thickbrick Sleaford: about the 32/64 stats, you might look at how common is amd64 in general linux usage, for example: 
* [15:03] Merov Linden: great conversation today
* [15:03] Otaku Thor: thank you
* [15:03] Tegg Bode: It's ok it's only virtual time we're using 
* [15:03] Morgaine Dinova: Thanks everyone
* [15:03] Techwolf Lupindo: My vote for longer meetings, too may topics to cover in one hour. hehe
* [15:03] Aimee Trescothick: waves
* [15:03] Atashi Toshihiko: Take care everyone :)
* [15:03] Twisted Laws: bye, thanks
* [15:03] Morgaine Dinova: Oh, amd64 even more popular than I thought.
* [15:03] Morgaine Dinova: waves bye
* [15:04] Rob Linden: thanks everyone for coming!
* [15:04] Thickbrick Sleaford: see you
* [15:04] Home: Going: to home
* [15:04] Rob Linden: cya
Category:Open Source Meeting