| 00:07.00 | echelon | copyfree licenses aren't weaker |
| 00:08.40 | blast007 | echelon: care to elaborate? |
| 00:09.30 | echelon | http://copyfree.org/standard/licenses |
| 00:09.48 | blast007 | yes, I can google. :) I mean on your "aren't weaker" comment |
| 00:11.15 | echelon | if the purpose is to ensure that a project's derivatives get credited back to the source, copyfree licenses are the way to go |
| 00:11.42 | blast007 | nope, that's incorrect |
| 00:12.28 | echelon | otherwise, people will either just not credit the original source, or not use your project to begin with |
| 00:13.12 | blast007 | some of those don't have any sort of attribution clause, and most of them let you relicense the work (including making it fully closed source) |
| 00:13.44 | blast007 | that's what I would consider 'weaker' because it has fewer guaranteed freedoms for downstream users |
| 00:13.45 | echelon | i don't see the problem |
| 00:14.05 | blast007 | as in, a third party can take away rights from their version |
| 00:14.06 | echelon | it certainly doesn't affect me if someone finds my work useful |
| 00:14.32 | blast007 | as it stand, BZFlag can even be sold commercially without violating the license - they'd just have to provide the source code |
| 00:18.31 | blast007 | I use MIT when I don't really care about the who and how of derivative works |
| 00:18.51 | blast007 | I prefer GPL/LGPL/AGPL when I care |
| 00:28.12 | blast007 | Constitution: so much for Apple being less evil: https://www.mikeash.com/pyblog/i-do-not-agree-to-your-terms.html |
| 00:44.38 | Constitution | I already agreed that their licensing approach is not ideal... what I care about is reaching their users |
| 00:45.44 | TimRiker | if I decide to modify the license, it would be if I can find something that still allows the apple store while still requiring source release for the binary in the store. the apple store license prevents the redistribution of the binary, but if people have the source, they could rebuild it. that's my thought process anyway. |
| 00:46.26 | blast007 | does it really matter? aren't mobile platforms already crapped up with tons of games? |
| 00:46.41 | TimRiker | anyhow. thx for the comments. feel free to email me directly if you have more feedback. |
| 00:47.13 | TimRiker | blast007, true. but if someone wants to do the work, others would benefit from it. :) |
| 00:47.21 | Constitution | sounds fair enough... thanks |
| 00:47.29 | TimRiker | anyhow. gotta run. thx! |
| 01:00.49 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 01:28.11 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 01:28.12 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 01:53.14 | *** join/#bzflag Pimpi (~frank@p4FF420E7.dip0.t-ipconnect.de) |
| 03:30.14 | *** join/#bzflag rob1n (rob1n@unaffiliated/rob1n) |
| 03:52.53 | *** join/#bzflag meeba (~lamer@c-73-14-146-7.hsd1.co.comcast.net) |
| 05:32.32 | Constitution | well now that I've spent a few nights trying to figure out why the client was downsampling my higher resolution font texture files, I will update the maxTextureSize BZDB variable *headdesk* |
| 07:10.19 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 08:30.39 | *** join/#bzflag the_map (~the_map@ip72-208-177-194.ph.ph.cox.net) |
| 09:08.56 | *** join/#bzflag the_map (~the_map@unaffiliated/the-map/x-1795707) |
| 09:37.50 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 09:50.44 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 10:18.04 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 10:57.41 | *** join/#bzflag the_map (~the_map@ip72-208-177-194.ph.ph.cox.net) |
| 11:20.51 | *** join/#bzflag the_map (~the_map@ip72-208-177-194.ph.ph.cox.net) |
| 11:46.13 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 12:08.32 | *** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional) |
| 14:10.23 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 14:15.42 | *** join/#bzflag the_map (~the_map@unaffiliated/the-map/x-1795707) |
| 14:41.11 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 14:53.32 | *** join/#bzflag the_map (~the_map@unaffiliated/the-map/x-1795707) |
| 15:32.27 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 16:48.56 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.34) |
| 16:48.56 | BZnotify | [13bzflag] 15macsforme pushed 1 new commit to 062.4: 02http://git.io/vLsB3 |
| 16:48.56 | BZnotify | 13bzflag/062.4 1487cb6d3 15Joshua Bodine: Created new TextTool2 program. It uses FreeType 2 and libPNG to render and write textures. Should build on most *nix, but there's only a Mac OS X project file for now.... |
| 16:48.56 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.34) |
| 16:59.23 | blast007 | ~Constitution++ |
| 17:00.12 | *** join/#bzflag meeba_ (~lamer@c-73-14-146-7.hsd1.co.comcast.net) |
| 17:01.09 | blast007 | Constitution: am I thinking right that if someone hasn't modified their maxTextureSize that it should automatically get the new default value? I'd assume that the vast majority of people have not touched that, so we can probably do without any config upgrade if so. |
| 17:02.36 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 17:03.41 | Constitution | correct... if they have the default value, it should be commented out in the config, so it will update automatically |
| 17:03.47 | blast007 | yay |
| 17:04.33 | *** join/#bzflag dngor (~abuse@p3m/dngor) |
| 17:07.21 | blast007 | So what do we all feel is left for a 2.4.4 release? Finishing up CIDR ban support is one. Maybe fixing the unit tests to build correctly on Debian Jessie (gcc 4.9.2). I might also see about improving support for changing tank/team colors with some sort of menu (and proper BZDB storage/retrival of values), but I'd do that in a fork in my account so I'm not slowing down a release. |
| 17:08.00 | blast007 | Possibly some more floating point validity checks on the server for data coming from the clients. |
| 17:08.39 | Constitution | there is one more issue with SDL 2 on mac where vsync stops working when the window is fully occluded... I am looking into that |
| 17:08.55 | blast007 | okay |
| 17:09.47 | blast007 | Want to add it to the issue tracker with a milestone of 2.4.4 so we can keep track of it? |
| 17:10.27 | blast007 | I'll add some the ones I mentioned when I'm done with work. |
| 17:10.36 | Constitution | I also want to backport the autoteam fix from master, refactor the mouse grabbing functionality (so we don't need that newer SDL 2 function), fix the problem where typing a list server search term while the list is loading will lock it up, and then fix one issue with HUD stuff being drawn over the pause menu |
| 17:11.03 | Constitution | that should be it for me... I can create issues for those if it would help |
| 17:11.47 | blast007 | Yeah, that'd be great if you would create issues for those. |
| 17:12.15 | blast007 | Few other things mentioned here that we should evaluate: http://wiki.bzflag.org/DevelopmentPlans/2.4.4 |
| 17:24.59 | Constitution | I don't know how the windows project file works... do we need to update the list of texture files there so they all get included in the build? |
| 17:35.29 | blast007 | the installer script currently grabs *.png, *.fmt, *.License, and README from the data/fonts/ directory |
| 17:35.45 | Constitution | cool |
| 17:36.26 | blast007 | the script is at ./package/win32/nsis/BZFlag.nsi if you're further interested in what it pulls |
| 17:36.57 | Constitution | do we want to implement something like this, so it will be easier to customize fonts? http://trepan.bzflag.bz/fontopts.png |
| 17:39.32 | BulletCatcher | Do we want 2.4 to build with older compilers (e.g, gcc-4.4 on CentOS 6) that have limited shared_ptr support? |
| 17:40.42 | BulletCatcher | I am willing to require c++11 for 2.5. |
| 17:41.34 | blast007 | BulletCatcher: How much work would be necessary to make it work for older compilers? |
| 17:42.12 | BulletCatcher | I have a 95-line (including context lines) patch to provide that. |
| 17:43.11 | BulletCatcher | It makes 8 changes. |
| 17:43.24 | blast007 | Any downside to it? |
| 17:44.42 | BulletCatcher | None that I am aware of. It simply changes "std::shared_ptr<AresHandler> ares" in NetHandler.h back to "AresHandler *ares". |
| 17:46.13 | blast007 | go for it then |
| 17:46.23 | BulletCatcher | k |
| 17:47.00 | blast007 | do we want to purge our src/other/ contents in this release? |
| 17:48.21 | BulletCatcher | Can we build on Windows and the Mac without src/other? |
| 17:49.06 | blast007 | Windows I could make work without too much effort as I have the majority of the bzflag-dependencies build script done. |
| 17:49.40 | blast007 | it sounded like Mac OSX only used a couple of the things from src/other/ |
| 17:50.26 | blast007 | < Constitution> blast007: right now the OS X SDK already has all of those (well, ncurses instead of PDCurses) except GLEW and c-ares, which are the two currently built by the Xcode project |
| 17:51.47 | Constitution | did we make any modifications to those libraries? it doesn't seem too much to ask to make people compile those |
| 17:51.54 | blast007 | basically for Windows it would be running a batch script and setting a handful of environment variables in order to make the normal Visual C++ project files build okay |
| 17:52.36 | BulletCatcher | As I recall, the only changes we made under src/other are to make them build in our source tree. |
| 17:53.23 | blast007 | <+DTRemenak> our copy of libcurl was specifically modified to work correctly on windows in our environment. there were problems with the standard project files too (relatively subtle ones iirc) |
| 17:53.54 | blast007 | <+DTRemenak> I think we ended up configuring it to use c-ares for dns resolution, and there's some other fix that I'm not remembering |
| 17:53.59 | BulletCatcher | Yup. Fixes to make it build. |
| 17:54.49 | blast007 | but currently I can't figure out how to update our in-tree libcurl and have it actually work correctly. I got it to build, but it fails to make POST requests correctly (because it sets the Content-Length to 6 Petabytes in the request headers) |
| 17:55.15 | blast007 | I got it to work correctly when using the .dll from a stock build of libcurl though. |
| 17:55.41 | BulletCatcher | Same curl version? |
| 17:55.45 | blast007 | yep |
| 17:55.55 | BulletCatcher | huh |
| 17:56.07 | blast007 | there's some memory wackyness going on |
| 17:56.53 | BulletCatcher | If we're going to continue to include src/other we should update ares and curl, at least. |
| 17:57.00 | BulletCatcher | That may help fix that bug. |
| 17:57.53 | blast007 | oh, no, I mean, that was with the latest version of libcurl :) |
| 17:58.14 | blast007 | the current version in there work |
| 17:58.31 | blast007 | so something with our custom project file doesn't work with the updated curl files |
| 17:58.41 | BulletCatcher | got it |
| 17:59.04 | blast007 | (I did try to add any new files to the project file - could have missed one, but it's more likely some build option that I'd need to change) |
| 17:59.23 | blast007 | I got reproducable values like this: "Content-Length: 6944085944303678" |
| 18:03.02 | BulletCatcher | My guess is that a narrow variable is incorrectly put into a wider one (e.g., a 2-byte signed short into an 8-byte size_t). |
| 18:03.46 | blast007 | Dunno. Like I said, it works if I build the exact same libcurl source using their project files and just copy over that resulting .dll file. |
| 18:03.58 | blast007 | and only happens for POST requests |
| 18:06.52 | BulletCatcher | It sounds like an incentive to stop using src/other on Windows. |
| 18:07.02 | blast007 | yup :) |
| 18:08.03 | blast007 | makes packaging on linux easier to, because Debian, for instance, has to modify our source for every release to remove src/other/ and modify our build scripts. |
| 18:08.09 | Constitution | removing src/other will streamline the process for getting the new version into the linux repos, right? |
| 18:08.20 | Constitution | I guess that's a yes |
| 18:08.25 | blast007 | reads minds |
| 18:08.40 | BulletCatcher | Debian seems to be the only distro that cares about that. |
| 18:08.51 | blast007 | perhaps.. |
| 18:09.26 | BulletCatcher | Fedora is happy as long as the executables use system libraries. |
| 18:10.10 | blast007 | we've had some people in the past have issues when they installed system libraries after running ./configure and having it build with a mixture of in-tree and system versions of a library |
| 18:18.16 | *** join/#bzflag Snake12534 (uid87978@gateway/web/irccloud.com/x-vpfxrzjqnhfqopji) |
| 18:23.00 | Constitution | BulletCatcher: you said backporting stuff from master should be done as a separate commit rather than any kind of merge, right? |
| 18:25.33 | BulletCatcher | yes |
| 18:25.54 | blast007 | and kinda on that same subject, what about a change we make in 2.4 that we don't want to bring forward to master? |
| 18:26.03 | BulletCatcher | We can still merge from 2.4->master, but master has changes that we don't want to merge into 2.4. |
| 18:26.21 | blast007 | (such as that change to make us build on older gcc) |
| 18:27.34 | BulletCatcher | I'll do the shared_ptr change with a carefully crafted merge. |
| 18:27.56 | BulletCatcher | Git lets you edit a merge before commiting it. |
| 18:29.48 | BulletCatcher | The shared_ptr change on 2.4 will be an undo, so future merges won't carry it to master (which will keep the undone change). |
| 18:30.53 | BulletCatcher | 7b0e056 is an example of a similar merge. |
| 18:35.46 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 18:35.46 | BZnotify | [13bzflag] 15macsforme pushed 1 new commit to 062.4: 02http://git.io/vLGZ1 |
| 18:35.46 | BZnotify | 13bzflag/062.4 1451fb1a4 15Joshua Bodine: Also ignore files created by the TextTool2 Xcode project file. |
| 18:35.46 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 20:47.46 | *** join/#bzflag L4m3r_ (~l4m3r@bzflag/developer/L4m3r) |
| 20:47.46 | *** mode/#bzflag [+v L4m3r_] by ChanServ |
| 21:51.14 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 23:41.47 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 23:46.19 | Delusional | my mac build still crashes on taking a screenshot⦠2.4.2 2014-1024 MAINT darwin 10.8.0 SDL (0221) |
| 23:46.27 | Delusional | donât know if thatâs important |
| 23:46.50 | Delusional | OSX 10.2.2 |
