-
Notifications
You must be signed in to change notification settings - Fork 12
/
2012-06-04.txt
173 lines (173 loc) · 23.5 KB
/
2012-06-04.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
{"nick":"madewokherd","reason":"Remote host closed the connection","date":"2012-06-04T04:11:48.314Z","type":"quit"}
{"nick":"ender`","date":"2012-06-04T06:36:04.393Z","type":"join"}
{"nick":"jgmdev","reason":"Quit: Thanks and take care everyone, lets make the world a better place to live :)","date":"2012-06-04T07:47:55.496Z","type":"quit"}
{"nick":"ender","date":"2012-06-04T07:49:24.889Z","type":"join"}
{"nick":"ender`","reason":"Read error: Operation timed out","date":"2012-06-04T07:49:39.612Z","type":"quit"}
{"nick":"ender|","reason":"Ping timeout: 244 seconds","date":"2012-06-04T07:50:45.636Z","type":"quit"}
{"nick":"ender|","date":"2012-06-04T08:04:00.281Z","type":"join"}
{"nick":"FearTheCowboy","date":"2012-06-04T10:41:19.129Z","type":"quit"}
{"nick":"piscisaureus_","date":"2012-06-04T10:48:58.168Z","type":"join"}
{"nick":"gix","reason":"Ping timeout: 248 seconds","date":"2012-06-04T11:40:48.318Z","type":"quit"}
{"nick":"gix","date":"2012-06-04T11:46:16.999Z","type":"join"}
{"nick":"auroraeosrose","date":"2012-06-04T12:44:36.129Z","type":"join"}
{"nick":"[[zz]]","reason":"Ping timeout: 244 seconds","date":"2012-06-04T12:46:10.849Z","type":"quit"}
{"nick":"[[zz]]","date":"2012-06-04T12:58:37.329Z","type":"join"}
{"nick":"vpovirk","date":"2012-06-04T13:55:18.115Z","type":"join"}
{"nick":"FearTheCowboy","date":"2012-06-04T13:59:18.412Z","type":"join"}
{"nick":"FearTheCowboy","reason":"Changing host","date":"2012-06-04T13:59:28.620Z","type":"quit"}
{"nick":"FearTheCowboy","date":"2012-06-04T13:59:28.855Z","type":"join"}
{"nick":"virmitio","date":"2012-06-04T14:23:42.601Z","type":"join"}
{"nick":"virmitio","message":"vpovirk: on the forks you've been working on, does your package target also auto-increment the version file?","date":"2012-06-04T14:59:03.746Z","type":"message"}
{"nick":"vpovirk","message":"no","date":"2012-06-04T14:59:11.536Z","type":"message"}
{"nick":"virmitio","message":"hmm","date":"2012-06-04T14:59:50.854Z","type":"message"}
{"nick":"virmitio","message":"I need a reasonable and consistent method by which to always increment the versioning of a package, either before or after building it.","date":"2012-06-04T15:00:48.284Z","type":"message"}
{"nick":"vpovirk","message":"they all use the same sort of define for the package version in version.inc","date":"2012-06-04T15:01:20.445Z","type":"message"}
{"nick":"virmitio","message":"because I don't want the automation to have even the possibility of constructing the same package+version twice","date":"2012-06-04T15:01:31.402Z","type":"message"}
{"nick":"vpovirk","message":"I think it's best if you automatically increment, tag, and build","date":"2012-06-04T15:02:26.169Z","type":"message"}
{"nick":"vpovirk","message":"then it's also clear exactly what git revision was used for every build you do","date":"2012-06-04T15:02:41.866Z","type":"message"}
{"nick":"virmitio","message":"ok, so do you provide a target in your forks to increment the version?","date":"2012-06-04T15:03:09.332Z","type":"message"}
{"nick":"vpovirk","message":"no","date":"2012-06-04T15:03:13.284Z","type":"message"}
{"nick":"auroraeosrose","message":"in order to do that virmitio","date":"2012-06-04T15:04:16.453Z","type":"message"}
{"nick":"vpovirk","message":"but as I said it all uses the same package-version define in version.inc, so the target would have exactly the same code in every fork","date":"2012-06-04T15:04:29.650Z","type":"message"}
{"nick":"auroraeosrose","message":"we need a \"package version\" and a \"code version\" - do we have that and I\"m stupid?","date":"2012-06-04T15:04:30.024Z","type":"message"}
{"nick":"auroraeosrose","message":"cause it might be the 5th package of openssl - but it's all the same version (if the package got screwed)","date":"2012-06-04T15:04:50.157Z","type":"message"}
{"nick":"vpovirk","message":"which means it doesn't make sense to me to put it in every fork","date":"2012-06-04T15:04:55.678Z","type":"message"}
{"nick":"vpovirk","message":"well, my thought was that every automated build would automatically produce a commit and a tag","date":"2012-06-04T15:05:42.829Z","type":"message"}
{"nick":"vpovirk","message":"so you can get the exact source revision from any build out of git","date":"2012-06-04T15:06:05.584Z","type":"message"}
{"nick":"vpovirk","message":"which also means it has to successfully push the commit and tag before it even starts the build, since the push could fail..","date":"2012-06-04T15:06:39.406Z","type":"message"}
{"nick":"vpovirk","message":"also, we have an upstream version","date":"2012-06-04T15:07:37.040Z","type":"message"}
{"nick":"virmitio","message":"true","date":"2012-06-04T15:08:13.634Z","type":"message"}
{"nick":"virmitio","message":"ok, with all of that in mind, another procedural question:","date":"2012-06-04T15:08:33.808Z","type":"message"}
{"nick":"virmitio","message":"when should the automated builds happen? every push to the desired branch(s)? on a static timer? something else?","date":"2012-06-04T15:09:33.767Z","type":"message"}
{"nick":"vpovirk","message":"good question","date":"2012-06-04T15:10:06.973Z","type":"message"}
{"nick":"virmitio","message":"a static timer alone should be out of the question, as that could easily result in multiple versions of a package that are completely identical except their version numbers","date":"2012-06-04T15:10:33.633Z","type":"message"}
{"nick":"vpovirk","message":"one could argue that you should only push to coapp-packages things you intend to be published..","date":"2012-06-04T15:10:44.669Z","type":"message"}
{"nick":"vpovirk","message":"which would mean every push","date":"2012-06-04T15:10:53.239Z","type":"message"}
{"nick":"vpovirk","message":"(except those made by the build system itself)","date":"2012-06-04T15:11:27.004Z","type":"message"}
{"nick":"virmitio","message":"I can easily filter those out","date":"2012-06-04T15:11:47.953Z","type":"message"}
{"nick":"wwahammy","date":"2012-06-04T15:12:03.752Z","type":"join"}
{"nick":"vpovirk","message":"the only other option I can think of is that a packager would have to explicitly say that a branch is ready for packaging and trigger the build somehow..","date":"2012-06-04T15:12:45.976Z","type":"message"}
{"nick":"vpovirk","message":"which doesn't have to be out of band, it could just be some special string in the commit message","date":"2012-06-04T15:13:27.030Z","type":"message"}
{"nick":"vpovirk","message":"so the question is whether packagers should be pushing things we don't want immediately packaged (which is something I've been doing but would be happy to change)","date":"2012-06-04T15:14:23.347Z","type":"message"}
{"nick":"virmitio","message":"I can see the merits to both sides on that point. Anyone else want to weigh in on this?","date":"2012-06-04T15:15:38.337Z","type":"message"}
{"nick":"FearTheCowboy","message":"o_O","date":"2012-06-04T15:16:18.360Z","type":"message"}
{"nick":"virmitio","message":"auroraeosrose: to your earlier comment, I don't know that we do outside of the \"author version\" in the package info","date":"2012-06-04T15:16:52.510Z","type":"message"}
{"nick":"FearTheCowboy","message":"I like the \"only push what you wnat published\"","date":"2012-06-04T15:16:56.949Z","type":"message"}
{"nick":"auroraeosrose","message":"hmmmm","date":"2012-06-04T15:16:59.685Z","type":"message"}
{"nick":"auroraeosrose","message":"I'm thinking of \"OMG I SCREWED UP THE PACKAGE\" cause you know that never happens...","date":"2012-06-04T15:17:17.743Z","type":"message"}
{"nick":"auroraeosrose","message":"easy way would be to have a new package version but","date":"2012-06-04T15:17:27.404Z","type":"message"}
{"nick":"auroraeosrose","action":"shrugs","date":"2012-06-04T15:17:28.860Z","type":"action"}
{"nick":"vpovirk","message":"we'll need another way to let people know we're working on things so we don't duplicate work","date":"2012-06-04T15:17:33.819Z","type":"message"}
{"nick":"auroraeosrose","message":"I have a better idea","date":"2012-06-04T15:18:33.162Z","type":"message"}
{"nick":"virmitio","action":"is all ears","date":"2012-06-04T15:18:40.436Z","type":"action"}
{"nick":"auroraeosrose","message":"why dont' we have a branch to use","date":"2012-06-04T15:18:41.519Z","type":"message"}
{"nick":"auroraeosrose","message":"that is \"publish this\"","date":"2012-06-04T15:18:46.597Z","type":"message"}
{"nick":"auroraeosrose","message":"otherwise people can't collaborate on packaging if it's \"push to package\"","date":"2012-06-04T15:18:59.460Z","type":"message"}
{"nick":"virmitio","message":"fair","date":"2012-06-04T15:19:16.937Z","type":"message"}
{"nick":"vpovirk","message":"I think I like that idea","date":"2012-06-04T15:19:18.618Z","type":"message"}
{"nick":"virmitio","message":"but do we declare the (existing in most places) \"CoApp\" branch to be push-to-publish, or some other (not yet named) branch?","date":"2012-06-04T15:20:12.502Z","type":"message"}
{"nick":"auroraeosrose","message":"because we don't want all local dev because some of thes (oh god, php with a million extensions) are going to have collaborators on the packaging code","date":"2012-06-04T15:20:14.705Z","type":"message"}
{"nick":"auroraeosrose","message":"virmitio: I think at this point you can decide ;)","date":"2012-06-04T15:20:28.782Z","type":"message"}
{"nick":"auroraeosrose","message":"I like Coapp to keep the coapp stuff","date":"2012-06-04T15:20:35.211Z","type":"message"}
{"nick":"vpovirk","message":"we'll want to be able to have more than one branch to publish","date":"2012-06-04T15:20:37.134Z","type":"message"}
{"nick":"auroraeosrose","message":"anything prefixed with publish?","date":"2012-06-04T15:20:55.544Z","type":"message"}
{"nick":"virmitio","message":"vpovirk: that's not an issue on a per-package basis","date":"2012-06-04T15:21:01.695Z","type":"message"}
{"nick":"auroraeosrose","message":"publish-coapp publish-php3","date":"2012-06-04T15:21:03.122Z","type":"message"}
{"nick":"auroraeosrose","message":"whatever?","date":"2012-06-04T15:21:09.631Z","type":"message"}
{"nick":"auroraeosrose","action":"is throwing out ideas","date":"2012-06-04T15:21:14.154Z","type":"action"}
{"nick":"auroraeosrose","message":"I think at this point virmitio gets to pick - then document it ;)","date":"2012-06-04T15:21:23.507Z","type":"message"}
{"nick":"virmitio","message":"I'm looking for a basic standard that can be the default on forks that the automation is initially notified about by getting a post-receive notice","date":"2012-06-04T15:21:46.457Z","type":"message"}
{"nick":"virmitio","message":"auroraeosrose: thanks, I think","date":"2012-06-04T15:22:21.677Z","type":"message"}
{"nick":"ender","message":"ouch: http://news.slashdot.org/story/12/06/04/1211206/microsoft-certificate-was-used-to-sign-flame-malware","date":"2012-06-04T15:37:21.002Z","type":"message"}
{"nick":"FearTheCowboy","message":"Yeah, I saw that.","date":"2012-06-04T15:38:20.557Z","type":"message"}
{"nick":"FearTheCowboy","message":"it seems to implicate an older, exploitable crypto algorithm","date":"2012-06-04T15:39:13.860Z","type":"message"}
{"nick":"FearTheCowboy","message":"I've wondered when that sort of thing would eventually happen.","date":"2012-06-04T15:39:31.967Z","type":"message"}
{"nick":"FearTheCowboy","message":"If I was trying to exploit crypto, I'd seek out older cert chains like that too.","date":"2012-06-04T15:39:58.840Z","type":"message"}
{"nick":"ender","message":"oh","date":"2012-06-04T15:40:08.658Z","type":"message"}
{"nick":"ender","message":"i haven't read that far yet","date":"2012-06-04T15:40:14.984Z","type":"message"}
{"nick":"ender","message":"but i was wondering the same thing a few months ago when i was checking the signatures in older MS products","date":"2012-06-04T15:40:39.267Z","type":"message"}
{"nick":"FearTheCowboy","message":"Hmm.","date":"2012-06-04T15:41:08.638Z","type":"message"}
{"nick":"FearTheCowboy","message":"we should think about a way to rapidly push certificates into the untrusted cert store.","date":"2012-06-04T15:41:30.467Z","type":"message"}
{"nick":"virmitio","message":"\"I changed my mind, and now I don't really trust that guy\"?","date":"2012-06-04T15:42:30.602Z","type":"message"}
{"nick":"FearTheCowboy","message":"Yeah","date":"2012-06-04T15:43:16.564Z","type":"message"}
{"nick":"FearTheCowboy","message":"Perhaps we should come up with a way of adding in 'blacklisted/revoked' certificates in feeds.","date":"2012-06-04T15:45:41.918Z","type":"message"}
{"nick":"FearTheCowboy","message":"that would simplify the 'fetching","date":"2012-06-04T15:46:17.444Z","type":"message"}
{"nick":"FearTheCowboy","message":"and then we just need to process those entries.","date":"2012-06-04T15:46:28.199Z","type":"message"}
{"nick":"ender","message":"i wish i requested activation of my terminal server earlier :)","date":"2012-06-04T15:46:33.879Z","type":"message"}
{"nick":"wwahammy","reason":"*.net *.split","date":"2012-06-04T16:21:49.142Z","type":"quit"}
{"nick":"gix","reason":"*.net *.split","date":"2012-06-04T16:21:49.358Z","type":"quit"}
{"nick":"piscisaureus_","reason":"*.net *.split","date":"2012-06-04T16:21:49.358Z","type":"quit"}
{"nick":"sungami","reason":"*.net *.split","date":"2012-06-04T16:21:49.732Z","type":"quit"}
{"nick":"wwahammy","date":"2012-06-04T16:31:30.106Z","type":"join"}
{"nick":"gix","date":"2012-06-04T16:31:30.341Z","type":"join"}
{"nick":"piscisaureus_","date":"2012-06-04T16:31:30.342Z","type":"join"}
{"nick":"sungami","date":"2012-06-04T16:31:30.342Z","type":"join"}
{"nick":"wwahammy","reason":"Quit: If you think nobody cares, try missing a few payments","date":"2012-06-04T16:33:02.567Z","type":"quit"}
{"nick":"auroraeosrose","reason":"Read error: Connection reset by peer","date":"2012-06-04T16:38:09.041Z","type":"quit"}
{"nick":"cH40z-Lord","date":"2012-06-04T17:14:14.526Z","type":"join"}
{"nick":"jgmdev","date":"2012-06-04T17:19:59.937Z","type":"join"}
{"nick":"wwahammy","date":"2012-06-04T17:34:19.985Z","type":"join"}
{"nick":"virmitio","message":"I don't recall. Is the only thing in the version.inc files the package version? or did we decide to put other info in there as well?","date":"2012-06-04T17:55:34.129Z","type":"message"}
{"nick":"vpovirk","message":"I've been putting other stuff in there","date":"2012-06-04T17:57:30.012Z","type":"message"}
{"nick":"virmitio","message":"k","date":"2012-06-04T17:58:03.204Z","type":"message"}
{"nick":"virmitio","message":"means I won't be able to alter the file directly from a command prompt","date":"2012-06-04T18:00:09.145Z","type":"message"}
{"nick":"virmitio","message":"at least, not without a great deal of extra effort","date":"2012-06-04T18:00:31.588Z","type":"message"}
{"nick":"FearTheCowboy","message":"I was using the version.inc for just the version","date":"2012-06-04T18:03:10.735Z","type":"message"}
{"nick":"FearTheCowboy","message":"everything else could go in the .autopkg file itself.","date":"2012-06-04T18:03:24.041Z","type":"message"}
{"nick":"virmitio","message":"FearTheCowboy: vpovirk and I had a conversation a while back about what else might be reasonable to keep in the same place as the version info, such as dependency informaiton. I just couldn't remember the outcome of the conversation.","date":"2012-06-04T18:04:54.755Z","type":"message"}
{"nick":"vpovirk","message":"I think we wanted the compatibility policy in there but not the dependencies","date":"2012-06-04T18:05:18.833Z","type":"message"}
{"nick":"virmitio","message":"that could be","date":"2012-06-04T18:05:38.478Z","type":"message"}
{"nick":"vpovirk","message":"we can't just put dependency information in the .autopkg because then it would be duplicated with .buildinfo, and between different autopkg files","date":"2012-06-04T18:05:51.291Z","type":"message"}
{"nick":"virmitio","action":"is starting to wonder if it would be smarter to go back to only the version in that file and use another include file for the additional information...","date":"2012-06-04T18:07:07.201Z","type":"action"}
{"nick":"FearTheCowboy","message":"probably","date":"2012-06-04T18:07:42.950Z","type":"message"}
{"nick":"FearTheCowboy","message":"wwahammy","date":"2012-06-04T18:34:09.668Z","type":"message"}
{"nick":"Jonny5","date":"2012-06-04T18:40:25.077Z","type":"join"}
{"nick":"Jonny5","reason":"Changing host","date":"2012-06-04T18:40:25.397Z","type":"quit"}
{"nick":"Jonny5","date":"2012-06-04T18:40:25.626Z","type":"join"}
{"nick":"virmitio","message":"ok, we have a plan for the versioning","date":"2012-06-04T19:06:50.458Z","type":"message"}
{"nick":"virmitio","message":"vpovirk, you probably won't like it","date":"2012-06-04T19:06:59.751Z","type":"message"}
{"nick":"ender","reason":"Quit: To get as fewest unhappy people as possible, always bully the same ones.\u000f","date":"2012-06-04T19:07:10.574Z","type":"quit"}
{"nick":"virmitio","message":"all packages fall into one of three categories:","date":"2012-06-04T19:09:49.642Z","type":"message"}
{"nick":"virmitio","message":"1) package version is determined by a version.inc file in the COPKG directory","date":"2012-06-04T19:10:37.417Z","type":"message"}
{"nick":"virmitio","message":"2) package version is recorded/handled elsewhere","date":"2012-06-04T19:11:03.188Z","type":"message"}
{"nick":"virmitio","message":"3) package version is unmanaged (as in the case of some limited redistributables that we'll be packaging)","date":"2012-06-04T19:11:36.182Z","type":"message"}
{"nick":"ender`","date":"2012-06-04T19:11:53.095Z","type":"join"}
{"nick":"virmitio","message":"for cases 1 and 2, it is assumed that the version is updated sometime during the run of 'ptk package'. The details of how this happens do not matter, nor do we care. If a maintainer wishes to be able to produce .msi files without increasing the version number, they may implement a variable to be passed via the command-line which will skip the version update, but the default action of the","date":"2012-06-04T19:14:14.127Z","type":"message"}
{"nick":"virmitio","message":"'package' target should always be to update the version information","date":"2012-06-04T19:14:26.250Z","type":"message"}
{"nick":"virmitio","message":"in case 2, an additional target named 'commit-version' must be included in the .buildinfo file which will generate a git commit containing all necessary updated version information. This target is expected to add any necessary files and perform the commit, including any appropriate message, but is not to perform a push.","date":"2012-06-04T19:16:32.482Z","type":"message"}
{"nick":"virmitio","message":"questions?","date":"2012-06-04T19:16:49.453Z","type":"message"}
{"nick":"wwahammy","message":"TL;DR","date":"2012-06-04T19:24:26.293Z","type":"message"}
{"nick":"vpovirk","message":"in case 1, is the version updated before or after creating the package?","date":"2012-06-04T19:32:20.429Z","type":"message"}
{"nick":"virmitio","message":"either. However, if the push fails, the packages that are built will not be published to the feed.","date":"2012-06-04T19:34:10.422Z","type":"message"}
{"nick":"vpovirk","message":"if it's before, I would worry that the versions in git won't match up with the versions built by the automation, unless the change is also pushed and tagged before the build","date":"2012-06-04T19:43:27.534Z","type":"message"}
{"nick":"vpovirk","message":"my understanding was that as soon as you build the same version twice, things can be messed up, and not pushing before the build could lead to that","date":"2012-06-04T19:44:05.643Z","type":"message"}
{"nick":"vpovirk","message":"if it's after, that would also be confusing because whenever the build automation pushes a version update, that revision will be BEFORE the revision that will eventually be used to build that new version, if a package with that number is ever published at all","date":"2012-06-04T19:45:58.468Z","type":"message"}
{"nick":"virmitio","message":"the current expectation of the lifecycle is similar to thus, where each step only occurs if the previous step succeeded: pull --> build --> local archive --> push version --> publish to feed","date":"2012-06-04T19:48:37.805Z","type":"message"}
{"nick":"vpovirk","message":"I'm ok as long as the version you build is the same as the version you push, and as long as you won't run into problems because you built the same version twice","date":"2012-06-04T19:49:48.740Z","type":"message"}
{"nick":"virmitio","message":"the early forks were designed to update the version file at the start of the 'package' target, so the resulting package built would have the same version as that being pushed back to the repo","date":"2012-06-04T19:50:11.254Z","type":"message"}
{"nick":"virmitio","message":"I can keep the local archive isolated from observation, which will keep the automation from going nuts if it builds the same version more than once. My biggest concern is preventing multiple builds of the same version from making it out into the wild","date":"2012-06-04T19:51:24.853Z","type":"message"}
{"nick":"vpovirk","message":"also: this essentially means you have a self-modifying ptk script","date":"2012-06-04T19:53:24.222Z","type":"message"}
{"nick":"virmitio","message":"I'm ok with that","date":"2012-06-04T19:53:49.024Z","type":"message"}
{"nick":"vpovirk","message":"it means my targets in package will be foo-1.0.0.1-x86.msi","date":"2012-06-04T19:53:54.818Z","type":"message"}
{"nick":"vpovirk","message":"while foo-1.0.0.2-x86.msi will be built","date":"2012-06-04T19:54:04.205Z","type":"message"}
{"nick":"vpovirk","message":"so the target will fail","date":"2012-06-04T19:54:11.129Z","type":"message"}
{"nick":"virmitio","message":"hmm...","date":"2012-06-04T19:54:41.498Z","type":"message"}
{"nick":"virmitio","message":"need to ask FearTheCowboy about that, as it worked fine in the past","date":"2012-06-04T19:55:48.721Z","type":"message"}
{"nick":"virmitio","message":"for the moment, however, I need to eat something","date":"2012-06-04T19:56:02.142Z","type":"message"}
{"nick":"vpovirk","message":"maybe you didn't have targets in your package","date":"2012-06-04T19:56:04.365Z","type":"message"}
{"nick":"virmitio","message":"that could be","date":"2012-06-04T19:56:21.328Z","type":"message"}
{"nick":"vpovirk","message":"or maybe it incremented after building","date":"2012-06-04T19:56:21.592Z","type":"message"}
{"nick":"virmitio","action":"is grabbing lunch quick, and will return shortly...","date":"2012-06-04T19:56:36.972Z","type":"action"}
{"nick":"virmitio","message":"and I'm back","date":"2012-06-04T20:09:03.160Z","type":"message"}
{"nick":"ender`","message":"does anybody know of a program that would make automatic backups of my USB pendrives?","date":"2012-06-04T20:09:32.976Z","type":"message"}
{"nick":"Jonny5","reason":"Read error: Connection reset by peer","date":"2012-06-04T20:09:38.784Z","type":"quit"}
{"nick":"piscisaureus_","reason":"Quit: ~ Trillian Astra - www.trillian.im ~","date":"2012-06-04T20:15:35.351Z","type":"quit"}
{"nick":"vpovirk","reason":"Remote host closed the connection","date":"2012-06-04T21:20:47.287Z","type":"quit"}
{"nick":"piscisaureus_","date":"2012-06-04T21:59:46.286Z","type":"join"}
{"nick":"madewokherd","date":"2012-06-04T21:59:55.897Z","type":"join"}
{"nick":"ender`","reason":"Quit: What if there were no hypothetical questions?\u000f","date":"2012-06-04T22:09:26.927Z","type":"quit"}
{"nick":"jgmdev","reason":"Quit: Thanks and take care everyone, lets make the world a better place to live :)","date":"2012-06-04T22:15:12.204Z","type":"quit"}
{"nick":"FearTheCowboy","message":"yo","date":"2012-06-04T22:49:35.674Z","type":"message"}
{"nick":"cH40z-Lord","reason":"Quit: Wenn 2 im Raum sind, 3 raus gehen, dann muss einer zurückkommen, dass keiner mehr da ist.","date":"2012-06-04T23:04:20.268Z","type":"quit"}
{"nick":"virmitio","reason":"Quit: So long and thanks for all the fish.","date":"2012-06-04T23:26:26.963Z","type":"quit"}
{"nick":"piscisaureus_","reason":"Quit: ~ Trillian Astra - www.trillian.im ~","date":"2012-06-04T23:49:43.241Z","type":"quit"}