| 00:15.50 | *** join/#bzflag trepan (~trepan@s72-38-252-50.static.datacom.cgocable.net) |
| 00:16.53 | *** join/#bzflag cods (~fred@tuxee.net) |
| 02:04.48 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 02:04.48 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 02:26.32 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 02:26.32 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 02:49.53 | the_map | why don't lagstats give jitter info on obs? |
| 02:55.39 | BulletCatcher | Jitter is calculated from position updates, which are sent by live tanks but not observers. |
| 02:56.18 | the_map | ah, thanks |
| 03:57.21 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 03:57.21 | BZnotify | [13bzflag] 15JMakey pushed 1 new commit to 062.4: 02http://git.io/vnEri |
| 03:57.21 | BZnotify | 13bzflag/062.4 14e5223eb 15Jeff Makey: Use new help file names in Makefiles.... |
| 03:57.21 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 04:07.55 | the_map | I've noticed that a lot of times when you guys commit, you have an ellipse on the end of the commit message |
| 04:08.13 | the_map | is there a reason for that, or is it just something that you guys do? |
| 04:08.34 | the_map | or is it truncated by bznotify? |
| 04:08.36 | BulletCatcher | The notifier does that to indicate that the message shown here in the channel is truncated. |
| 04:10.18 | the_map | how does it decide how much to keep? |
| 04:11.05 | BulletCatcher | It shows no more than the first line. |
| 04:11.06 | BulletCatcher | There is probably a limit on the length of that, too. |
| 04:13.02 | the_map | in one commit message, there was no truncation even though it hit 194 chars; in another, it truncated after 54 |
| 04:13.37 | BulletCatcher | Were there multiple lines in the other? |
| 04:15.16 | the_map | how do I find a commit by the 7-char ID? |
| 04:15.24 | the_map | I assume that's some sort of ID... |
| 04:15.57 | BulletCatcher | What tool are you using? |
| 04:16.06 | the_map | google chrome? |
| 04:17.43 | allejo | Github limits commit messages to 50 chars, everything else is truncated and gets added to the "extended" commit message or notes section or whatever it's called |
| 04:18.13 | allejo | https://github.com/BZFlag-Dev/bzflag/commits/2.4 shows the shortened hash of the commit on the right hand side |
| 04:19.22 | BulletCatcher | https://github.com/BZFlag-Dev/bzflag/commit/[hash here] will take you to a specific commit. |
| 04:20.04 | allejo | `git log --pretty=oneline --abbrev-commit` would be the command line equivalent of the short hashes |
| 04:20.26 | BulletCatcher | You can also just click on the git.io link provided by BZnotify. |
| 04:31.33 | the_map | these are the commits I was referencing: http://pastebin.com/b8inC1M2 |
| 04:34.32 | BulletCatcher | The first message was all one line. |
| 04:34.42 | BulletCatcher | The second was truncated at the end of the first line. |
| 04:34.47 | the_map | ok |
| 04:53.30 | alezakos | the_map: if you visit tje git.io link for the commits in that pastebin and examine each commit individually, Github will have URLs to every referenced commit |
| 04:59.47 | the_map | ? |
| 04:59.59 | the_map | like http://git.io/vYpiN ? |
| 05:00.18 | the_map | and http://git.io/vYJ5A |
| 06:27.43 | alezakos | the_map: yes |
| 07:32.05 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 09:00.33 | *** join/#bzflag rodgort (~rodgort@105.ip-167-114-152.net) |
| 11:07.17 | *** join/#bzflag cods (~fred@rsbac/developer/cods) |
| 13:45.00 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 13:48.05 | *** join/#bzflag JBdiGriz (~dbw@108-197-33-160.lightspeed.sndgca.sbcglobal.net) |
| 14:16.49 | *** join/#bzflag rodgort (~rodgort@2607:5300:100:200::160d) |
| 15:14.13 | *** join/#bzflag joevano_ (~joevano@bzflag/developer/JoeVano) |
| 15:14.13 | *** mode/#bzflag [+v joevano_] by ChanServ |
| 15:44.47 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 16:26.59 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 16:32.31 | *** join/#bzflag aimen1 (~aimen1@115.242.144.213) |
| 16:33.10 | aimen1 | hello |
| 16:33.29 | the_map | hey |
| 16:37.23 | blast007 | bye |
| 16:45.33 | *** join/#bzflag develCuy (~quassel@unaffiliated/develcuy) |
| 17:50.35 | BulletCatcher | The version of OpenSSL shipped with Solaris 10 does not implment SHA2, so it can't verify modern SSL certificates such as the one at bzflag.org. |
| 17:50.37 | BulletCatcher | grrr |
| 18:13.17 | blast007 | hrm |
| 18:13.38 | blast007 | is that something we can test for in configure.ac? |
| 18:20.12 | blast007 | hmm... probably not easily, since we don't specificially depend on OpenSSL (as curl can use a variety of SSL libraries) |
| 18:32.36 | blast007 | a super hackish way would be parsing the output of 'curl -V' to see if it mentions an old OpenSSL version |
| 18:33.17 | BulletCatcher | A successful "curl https://my.bzflag.org/" command should be sufficient. |
| 18:34.21 | BulletCatcher | My Solaris compilation environment would complicate that, though. |
| 18:34.28 | blast007 | can you determine the difference between 'does not support SHA-2' and 'your network cable is unplugged'? :) |
| 18:35.59 | blast007 | if our calls to curl in our code provide some unique error code for this situation, we could properly handle it at run-time without the hackish configure.ac stuff |
| 18:37.37 | BulletCatcher | bzfs reports "File transfer terminated with error from libcurl 35 : error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm" |
| 18:39.27 | blast007 | CURLE_SSL_CONNECT_ERROR, /* 35 - wrong when connecting with SSL */ |
| 18:43.03 | blast007 | The error for bzfs is at least descriptive, though a bit technically worded. The client would probably just write it's usual "Can't talk with list server" to the message panel. |
| 18:44.54 | BulletCatcher | Providing a SHA2-capable OpenSSL seems to be the only reasonable solution to this. |
| 18:45.51 | blast007 | well, right, but I'm thinking more about how to notify the user that that is the problem |
| 18:51.01 | BulletCatcher | It should be possible to emit some sort of "SSL failure: possible man in the middle" message at appropriate times. |
| 18:51.55 | BulletCatcher | How easy do we want it to be to fall back to non-SSL connections? |
| 18:52.47 | BulletCatcher | The server will have to support non-SSL HTTP as long as we support 2.4.0 and 2.4.2. |
| 18:53.54 | BulletCatcher | the *list* server |
| 18:55.12 | blast007 | I'd rather it not fall back from 2.4.4 onward since that would limit when we can force it |
| 18:55.49 | BulletCatcher | That is my preference, too. |
| 18:56.06 | blast007 | I'd want one release of 2.4 that will be able to use HTTPS so that at some point in the 2.6 release we can say "upgrade to 2.4.4 or move to 2.6" and force SSL on m.b.o |
| 22:20.36 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 22:25.03 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 22:28.57 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |