| 00:23.05 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 00:23.47 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 02:19.48 | *** join/#brlcad yqxublyynsbnzpge (~armin@dslb-088-065-178-111.088.065.pools.vodafone-ip.de) |
| 03:21.50 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 03:23.26 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) |
| 03:23.40 | *** join/#brlcad maths22 (~maths22@66-118-151-70.static.sagonet.net) |
| 03:23.40 | *** join/#brlcad maths22 (~maths22@unaffiliated/maths22) |
| 03:23.50 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 03:24.42 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) |
| 04:23.06 | andromeda-galaxy | brlcad: oops, sorry, my irc client disconnected and I didn't realize, so I missed you one more time... I've pm'd you the details of the plan I had set up, it would be great if you could take a look at it when you have a chance, and let me know what you think... I'll probably be able to discuss more tomorrow (sorry I missed you today!) |
| 05:20.51 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 05:22.27 | *** join/#brlcad maths22 (~maths22@66-118-151-70.static.sagonet.net) |
| 05:22.28 | *** join/#brlcad maths22 (~maths22@unaffiliated/maths22) |
| 05:22.42 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) |
| 05:22.50 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 05:23.10 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) |
| 05:42.26 | *** join/#brlcad greenapple (0e8b2997@gateway/web/freenode/ip.14.139.41.151) |
| 08:03.16 | *** join/#brlcad witness (uid10044@gateway/web/irccloud.com/x-msfjcyovzclkmzco) |
| 08:18.17 | *** join/#brlcad witness_ (uid10044@gateway/web/irccloud.com/x-gdyzhvjurhstkrgq) |
| 08:53.28 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) |
| 09:19.30 | *** join/#brlcad merzo (~merzo@92.60.189.225) |
| 10:46.55 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 10:53.49 | *** join/#brlcad greenapple (0e8b2997@gateway/web/freenode/ip.14.139.41.151) |
| 14:14.48 | Notify | 03BRL-CAD:starseeker * 66961 brlcad/trunk/src/libgcv/plugins/CMakeLists.txt: DIRECTORY -> PATH, ws |
| 14:23.58 | Notify | 03BRL-CAD:starseeker * 66962 brlcad/trunk/src/libgcv/plugins/CMakeLists.txt: See if a straight include_directories will work for older CMakes... problematic, but the alternative is to bump our required CMake version. Getting close to that point for a number of reasons, but for now give this a shot... |
| 14:42.58 | brlcad | starseeker: is it time to just bootstrap the version of cmake we want |
| 15:39.04 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) |
| 15:54.35 | brlcad | hmm |
| 16:07.09 | starseeker | brlcad: maybe - if we can bump our minimum to 3.0.2 or some such that would take care of most of it |
| 16:07.30 | starseeker | checks Debian stable... |
| 16:08.06 | starseeker | hah - https://packages.debian.org/jessie/cmake |
| 16:12.24 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:33.22 | Notify | 03BRL-CAD:starseeker * 66963 (brlcad/trunk/src/conv/CMakeLists.txt brlcad/trunk/src/libgcv/plugins/obj/CMakeLists.txt and 8 others): Make libwfobj into a stand-alone compile. |
| 17:05.54 | Notify | 03BRL-CAD:starseeker * 66964 (brlcad/trunk/src/libgcv/plugins/obj/wfobj/obj_grammar.yy brlcad/trunk/src/libgcv/plugins/obj/wfobj/obj_grammar_decls.h and 4 others): Rework |
| 17:22.13 | Notify | 03BRL-CAD:starseeker * 66965 brlcad/trunk/src/libgcv/plugins/obj/wfobj/obj_grammar.yy: cleanup |
| 17:24.08 | Notify | 03BRL-CAD:starseeker * 66966 brlcad/trunk/src/libgcv/plugins/obj/wfobj/obj_grammar.yy: GCC 4.2 is now very old, and snprintf needs a define for MSVC. |
| 17:43.40 | Notify | 03BRL-CAD:starseeker * 66967 brlcad/trunk/src/libgcv/plugins/obj/wfobj/obj_parser.cpp: For whatever reason, it currently wants both extern "C" and WFOBJ_EXPORT in the .cpp file to generate a .lib file in MSVC. Still not sure why - maybe something to do with the use of C++ namespaces? |
| 18:20.47 | *** join/#brlcad zenemij (~quassel@2a00:1508:1:f018:e009:72a4:cdcf:f560) |
| 18:23.25 | zenemij | hey! |
| 18:23.40 | zenemij | i Remember some forum discussion between brlcad and freecad people |
| 18:23.55 | zenemij | do some collaboration started ? |
| 19:20.16 | andromeda-galaxy | brlcad: I'm back, did I miss you? |
| 20:13.13 | brlcad | starseeker: sounds good to me either way (bumping or bundling) |
| 20:14.09 | brlcad | andromeda-galaxy: I missed you! |
| 20:26.56 | starseeker | will bump once distcheck passes again - just got Windows build fixed (isst apparently works on Windows now!) and need to tidy up |
| 20:29.42 | starseeker | wonders if isst warrants a desktop icon... probably needs more UI polish first... |
| 20:30.25 | Notify | 03BRL-CAD:starseeker * 66968 (brlcad/trunk/misc/doxygen/CMakeLists.txt brlcad/trunk/src/libgcv/plugins/obj/CMakeLists.txt brlcad/trunk/src/other/stepcode.dist): Update ignore file lists for CMake |
| 20:40.49 | Notify | 03BRL-CAD:starseeker * 66969 brlcad/trunk/src/libgcv/plugins/obj/wfobj/CMakeLists.txt: copy paste strikes again |
| 21:07.43 | andromeda-galaxy | brlcad: did you see writeup that I sent you earlier? |
| 21:13.09 | Notify | 03BRL-CAD:starseeker * 66970 brlcad/trunk/CMakeLists.txt: We apparently need some quoting here. |
| 21:43.34 | Notify | 03BRL-CAD:starseeker * 66971 brlcad/trunk/src/libgcv/plugins/vrml/vrml_read/string_util.cpp: Add common.h to string_util.cpp |
| 21:46.49 | Notify | 03BRL-CAD:starseeker * 66972 brlcad/trunk/regress/repository.sh: Update repository.sh script |
| 22:04.14 | brlcad | andromeda-galaxy: I did -- it sounds good -- but to understand, that's the external files that will get referenced in the repo? |
| 22:05.02 | andromeda-galaxy | brlcad: the repo --- which will go on github --- will be a git annex repository with a web special remote pointing at brlcad.org |
| 22:05.42 | brlcad | right, but the dump into /usr/web is the repo or the files that annex will reference? |
| 22:05.59 | andromeda-galaxy | I was planning that that |
| 22:06.05 | andromeda-galaxy | would be the files |
| 22:06.11 | andromeda-galaxy | 1,2s/\n// |
| 22:10.00 | andromeda-galaxy | brlcad: gci-backlog-data.tar.gz in ~peter is the data dump (the archive that I'd extract into /usr/web/brclad.org/gci/data), if you want I can move/copy that somewhere that you can take a look at it |
| 22:10.15 | brlcad | no, go ahead |
| 22:10.41 | andromeda-galaxy | did the .htaccess lines that I posted seem right to you? |
| 22:19.42 | andromeda-galaxy | brlcad: I just did a quick test to confirm that those actually do disable execution and came up with a small tweak (it looks like the SetHandler wasn't properly being applied); see /usr/web/brlcad.org/gci/data/.htaccess for the new version (test.php in that directory is a tiny php script that I used to make sure that it was correctly disabled, which it was...) |
| 22:23.45 | andromeda-galaxy | brlcad: if the .htaccess lines look good, I'll untar the datadump inside /data (using --strip-components to avoid data/data uris) |
| 22:28.32 | brlcad | sure, the .htaccess looked/looks fine |
| 22:29.57 | andromeda-galaxy | great! shall I do the untar now? |
| 22:30.49 | brlcad | yep! |
| 22:30.59 | brlcad | what's the untarred size? |
| 22:31.34 | brlcad | we need to do some filesystem cleanup soon.. half TB almost full... |
| 22:31.56 | brlcad | we can spill over onto another drive if we need to, but there's a lot of big data laying waste |
| 22:33.14 | andromeda-galaxy | brlcad: hold on a sec let me check what it islocally |
| 22:33.33 | andromeda-galaxy | brlcad: 3.0G |
| 22:33.39 | brlcad | cool |
| 22:34.07 | andromeda-galaxy | it's in the middle of untarring on the sever right now... |
| 22:36.03 | andromeda-galaxy | brlcad: http://brlcad.org/gci/data/2012-8123204-Mock_up_new_BRL-CAD_website_interface_design_5_-_BRL-CAD/file-2-2012-12-27T01:59-0800-homepage.png, for example |
| 22:36.12 | andromeda-galaxy | unexpected problem, though: http://brlcad.org/gci/data/2012-8123204-Mock_up_new_BRL-CAD_website_interface_design_5_-_BRL-CAD/task.html |
| 22:36.24 | andromeda-galaxy | the task pages all use a bunch of css with relative urls |
| 22:39.06 | andromeda-galaxy | brlcad: are there any xml manipulation tools on the server? I can probably rewrite the style link quickly enough, but I'd rather not spend another ~3 hours uploading a new data dump just for that... |
| 22:42.47 | brlcad | that looks awesome |
| 22:43.27 | andromeda-galaxy | great! what do you think we should do about the accidentally unstyled task description pages? |
| 22:44.21 | andromeda-galaxy | (the tar just finished, so it should all be up now) |
| 22:44.26 | Notify | 03BRL-CAD:starseeker * 66973 (brlcad/trunk/db/comgeom/CMakeLists.txt brlcad/trunk/db/faa/CMakeLists.txt and 4 others): Some distclean cleanup |
| 22:44.40 | Notify | 03BRL-CAD:starseeker * 66974 (brlcad/trunk/misc/CMake/FindLEMON.cmake brlcad/trunk/misc/CMake/FindPERPLEX.cmake and 21 others): Compact down the LEMON/RE2C/PERPLEX CMake pieces into three files instead of six. |
| 22:45.36 | brlcad | I think the pages can be fixed pretty trivially with a find sed replacement |
| 22:45.48 | brlcad | just needs a couple images and css files |
| 22:46.29 | andromeda-galaxy | oh, that's probably true actually, the melange pages are autogenerated + pretty regular |
| 22:46.45 | andromeda-galaxy | I tend to be paranoid about using sed on things that are context-free langauges |
| 22:48.32 | andromeda-galaxy | should we grab copies of the styles and put them on our server, and then rewrite to point to them? (so that we can keep going if melange goes down) |
| 22:49.16 | brlcad | yeah, should be fully self-contained |
| 22:50.10 | andromeda-galaxy | That makes sense. what do you think of leaving the links for user profiles & the melange menu broken (since there's not really anything sane we could do with them)? |
| 22:51.03 | brlcad | probably something like find . -name task.html -exec perl -pi -e 's/soc\/content\/2-1-20151016-1-g2aa4932\//gci/g' {} \; |
| 22:51.23 | andromeda-galaxy | also: the file listing on the task pages points to melange, which is annoying. Do you think that it's worth trying to rewrite all of the download links to relative pointers to the local files? |
| 22:51.44 | brlcad | then mkdir gci/images/... copy in the css and few images |
| 22:52.20 | andromeda-galaxy | that looks right to me, but that implies creating /gci/css and /gci/styles, should we do that or /gci/data/{css,styles}? (since there's other stuff in /gci right now) |
| 22:54.07 | brlcad | nah, it's fine .. there's not much in gci |
| 22:54.22 | andromeda-galaxy | okay, I'll wget the files & rewrite the uris now |
| 22:55.04 | andromeda-galaxy | the task links will be annoying to do now though, since they'd require parsing a bunch of xml (and dates in it!) stretched over multiple lines... |
| 23:00.06 | andromeda-galaxy | ha! the menu and task file links are all broken, but: http://brlcad.org/gci/data/2012-8123204-Mock_up_new_BRL-CAD_website_interface_design_5_-_BRL-CAD/task.html |
| 23:00.27 | *** join/#brlcad merzo (~merzo@185-47-133-95.pool.ukrtel.net) |
| 23:02.44 | starseeker | woo hoo! basic distcheck passes again |
| 23:03.22 | starseeker | fires distcheck-full |
| 23:03.58 | brlcad | andromeda-galaxy: "curl -O url" is simpler than wget ;) |
| 23:04.20 | andromeda-galaxy | really? |
| 23:04.25 | brlcad | don't have to fix all the a links, just want it to display readably |
| 23:04.49 | brlcad | I mean, if you can fix the links to point to the local files, that would be awesome, but not strictly necessary |
| 23:05.19 | andromeda-galaxy | I see. well, it displays readably now, so I'll work on the git annex repo now, hopefully that'll be ready soon s well |
| 23:05.32 | brlcad | awesome |
| 23:06.37 | andromeda-galaxy | if you'll be around for a little while, I'll let you know when I have something that looks right to me |
| 23:07.53 | andromeda-galaxy | hmm, actually one more question first: |
| 23:08.11 | Notify | 03BRL-CAD:starseeker * 66975 brlcad/trunk/src/libgcv/plugins/obj/CMakeLists.txt: Set target folder for libwfobj targets |
| 23:09.02 | andromeda-galaxy | do we want to use github, or should we stick the actual repository on our server? the git-annex workflow is apparently a bit more complicated when you have to use separate special remotes, but since we don't intend to actually *change* anything, that might be fine |
| 23:13.32 | andromeda-galaxy | brlcad: also git-annex seems inclined to track which checkouts of the main repository have which files, which may or may not actually be desirable |
| 23:13.54 | andromeda-galaxy | (probably not, since I can't think of any use we have for that information) |
| 23:19.42 | brlcad | I'm actually waffling on the value of a revpo looking at these files on the server now |
| 23:20.21 | andromeda-galaxy | brlcad: what's the alternative? |
| 23:24.36 | brlcad | well, just trying to think what it's bringing to the table |
| 23:25.07 | andromeda-galaxy | over in-place modifying the directories on the server? |
| 23:25.16 | brlcad | yep |
| 23:25.28 | brlcad | guess it depends who all is going to be involved in processing |
| 23:25.58 | brlcad | most devs have an account an a directory-based workflow could be set up |
| 23:26.05 | brlcad | what's the complication using github? |
| 23:26.30 | andromeda-galaxy | right, if we want anyone without access to be able to help with categorizing (which might be good for images, etc.) then the repository is nice, but otherwise the only thing that it adds is an assurance that we can't accidentally delete everything, and it's not at all hard to re-create, so that's not worth that much |
| 23:26.49 | brlcad | if there's a repo, it can be wherever, don't really care -- just think the activity will be far more visible and allow for discussion if it's on github |
| 23:27.14 | brlcad | that's true, accidental deletions |
| 23:27.39 | andromeda-galaxy | (the main thing that I worry about without the repo is the possibility of deleting something and not noticing it) |
| 23:28.09 | andromeda-galaxy | the complication about github according to git annex is just that github doesn't let them upload the files, which we don't want them to do. the complication with using git-annex overall is that it wants to keep track of every repo clone and which ones have the files in them |
| 23:28.38 | andromeda-galaxy | which is awesome if you're one person using it to sync up stuff across a bunch of computers, but doesn't work that well with our planned workflow |
| 23:29.30 | andromeda-galaxy | since contributors might not want the world knowing their hostname and directory paths... |
