| 00:19.40 | starseeker | not for later - issue with libtool and Tcl Stubs on Windows... http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/74cb58c3cdb7d252/cffcd1363cc2f684?lnk=gst&q=autotools#cffcd1363cc2f684 |
| 00:19.45 | starseeker | er note |
| 00:30.41 | *** join/#brlcad Tecan (~fsadf@unaffiliated/unit41) |
| 01:31.01 | *** join/#brlcad ibot (ibot@rikers.org) |
| 01:31.01 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs at http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.4 in prep, should be posted 20100114 |
| 01:42.45 | *** join/#brlcad ibot (ibot@rikers.org) |
| 01:42.46 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs at http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.4 in prep, should be posted 20100114 |
| 01:50.43 | *** join/#brlcad ibot (ibot@rikers.org) |
| 01:50.43 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs at http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.4 in prep, should be posted 20100114 |
| 01:59.57 | *** join/#brlcad ibot (ibot@rikers.org) |
| 01:59.58 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs at http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.4 in prep, should be posted 20100114 |
| 02:09.27 | *** join/#brlcad ibot (ibot@rikers.org) |
| 02:09.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs at http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.4 in prep, should be posted 20100114 |
| 02:14.47 | *** join/#brlcad ibot (ibot@rikers.org) |
| 02:14.48 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs at http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.4 in prep, should be posted 20100114 |
| 03:09.04 | *** join/#brlcad Nohla (~jesica@201.255.242.124) |
| 03:26.16 | *** join/#brlcad PrezKennedy (Matthew@whitecalf.net) |
| 03:30.02 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 04:06.35 | *** join/#brlcad Ralith (~ralith@69.90.48.97) |
| 06:42.38 | *** join/#brlcad ``Erik (~erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 08:03.32 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 08:30.46 | *** join/#brlcad Stattrav (~Stattrav@202.3.77.161) |
| 09:51.07 | *** join/#brlcad Tecan (~fsadf@unaffiliated/unit41) |
| 11:34.16 | Tecan | there be dragons |
| 11:40.11 | ``Erik | O.o |
| 11:40.36 | alex_joni | at least not here :) |
| 12:25.38 | Stattrav | and there be dragon hunters |
| 13:13.18 | brlcad | they are tasty with some BBQ sauce |
| 13:15.02 | CIA-43 | BRL-CAD: 03brlcad * r37520 10/brlcad/trunk/misc/win32-msvc8/Makefile.am: add the missing libanalyze to the dist |
| 13:18.09 | CIA-43 | BRL-CAD: 03brlcad * r37521 10/brlcad/trunk/src/other/tkhtml3/Makefile.am: add a couple files missing from the dist |
| 13:18.47 | Tecan | http://www.youtube.com/watch?v=qswm7lHp7oY << one tin soldier |
| 14:14.21 | ``Erik | bbq sauce for dragon hunters? interesting |
| 14:17.41 | *** join/#brlcad SWPadnos (~Me@emc/developer/SWPadnos) |
| 15:34.28 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) |
| 15:35.24 | CIA-43 | BRL-CAD: 03brlcad * r37522 10/brlcad/trunk/src/other/tkhtml3/Makefile.am: heh, backslash happy |
| 15:52.57 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) |
| 15:53.10 | poolio | ``Erik: I'm learning about marching squares in class :) |
| 17:24.33 | Stattrav | poolio: which class in which university ? my prof barely touched it just mentioned it arbitrarily once |
| 17:46.26 | CIA-43 | BRL-CAD: 03bob1961 * r37523 10/brlcad/trunk/include/opennurbs_ext.h: Quell some warnings when compiling 64-bit Windows. |
| 17:47.30 | CIA-43 | BRL-CAD: 03bob1961 * r37524 10/brlcad/trunk/src/librt/ (38 files in 25 dirs): Quell some warnings when compiling 64-bit Windows. |
| 18:14.13 | CIA-43 | BRL-CAD: 03starseeker * r37525 10/brlcad/branches/dmtogl/src/other/ (11 files in 5 dirs): Put back the ZLIB stuff in tcl/tk, but don't add it to the build system - need a way to pass in an external dir with the objects from the looks of it, based on manual tweaking of the gcc command used for tcl... |
| 18:52.30 | *** join/#brlcad mafm (~mafm@195.Red-83-37-177.dynamicIP.rima-tde.net) |
| 19:53.02 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 19:56.00 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 20:08.50 | CIA-43 | BRL-CAD: 03bob1961 * r37526 10/brlcad/trunk/src/librt/primitives/ (19 files in 19 dirs): The cast to long is now part of the bu_offsetof definition. |
| 20:09.30 | CIA-43 | BRL-CAD: 03bob1961 * r37527 10/brlcad/trunk/include/bu.h: The cast to long is now part of the bu_offsetof definition. |
| 20:44.08 | mafm | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632 |
| 20:44.17 | mafm | it seems tough to get brl-cad in Debian! |
| 20:48.38 | brlcad | hey mafm .. ltns! |
| 20:49.32 | brlcad | there are lots of things wrong with that RFP. |
| 20:50.18 | mafm | I'm a busy man, running all of my oil camp pumps and flying around with my bugatti veyron and stuff |
| 20:50.20 | brlcad | title should probably be "BRL-CAD", not BrlCAD or brlcad and not with the description in the title (unless there is no separate description section) |
| 20:50.35 | brlcad | mm.. that's a big car |
| 20:50.39 | brlcad | a big HEAVY car |
| 20:51.09 | mafm | :D |
| 20:51.46 | brlcad | there is absolutely no detail from "eugen" on his bad code quality assertion |
| 20:52.17 | mafm | yep, but after gsocing I'm very well paid... I can buy a veyron every month :PPPPP |
| 20:52.56 | mafm | the thing is, did you provide debian packages with some release? |
| 20:53.18 | mafm | maybe it's easy to provide a DD with it, and if it's a proper package, could upload it |
| 20:53.50 | mafm | with the added benefit that it would probably drop on ubuntu repos too, I think |
| 20:54.36 | mafm | the title is not important anyway, it's just some user asking to get it packaged |
| 20:54.46 | mafm | not the proper description that it would have |
| 20:57.57 | brlcad | we don't provide any distro-specific releases, that's up to a release maintainer for that platform subset |
| 20:58.13 | brlcad | we have enough to do managing source releases and major OS binaries |
| 20:59.16 | brlcad | "Linux (with a particular GLIB)" is where that line is drawn, binaries that'll run on any Linux of a given runtime |
| 20:59.39 | brlcad | there needs to be a debian dev to sort out the issues integrating with apt |
| 20:59.46 | brlcad | no diff than with portage, fink, ports, etc |
| 21:00.20 | brlcad | now if someone sorted out the build logic and make it a simple "make && make deb" which resulted in a .deb, that's something we could probably support |
| 21:00.23 | brlcad | there' |
| 21:00.38 | brlcad | there's hooks in the build system already for someone to fill in the logic, but to date nobody has stepped up |
| 21:03.31 | CIA-43 | BRL-CAD: 03bob1961 * r37528 10/brlcad/trunk/src/libbu/ (11 files): Quell some warnings when compiling 64-bit Windows. |
| 21:12.23 | *** join/#brlcad mafm_ (~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
| 21:12.43 | CIA-43 | BRL-CAD: 03bob1961 * r37529 10/brlcad/trunk/src/libbn/sphmap.c: Quell some warnings when compiling 64-bit Windows. |
| 21:13.04 | mafm_ | I thought by reading the RFP that you already provided that in the past |
| 21:16.43 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 21:17.05 | mafm_ | when brl-cad installs, all of include files, libs used by binaries and a lot of binaries themselves are installed, right? |
| 21:17.20 | mafm_ | is there any doc and data too, I guess? |
| 21:18.39 | brlcad | there has been one .deb posted, which was user-provided |
| 21:19.00 | brlcad | yes, it's the whole shebang, however it was configured |
| 21:19.27 | brlcad | if you compile it not use any provided libs, you have to have them all system-installed beforehand |
| 21:20.01 | brlcad | if you compile it to use all provided libs, it will be a completely stand-alone install with no additional dependencies (other than the C runtime) which is usually how binaries are built |
| 21:20.23 | brlcad | if you compile with auto-detection enabled, it'll run on systems matching the one you compiled |
| 21:22.07 | mafm_ | but I mean, regarding libs, that it also installs internal libs dynamically shared, like librt or libu, right? |
| 21:22.46 | brlcad | yes, all of the brl-cad libs, a few hundred binaries, some resource data, documentation files |
| 21:22.54 | brlcad | standard fare |
| 21:22.57 | mafm_ | that's how it should be done in debian anyway, and not use any statically compiled stuff if possible |
| 21:23.27 | brlcad | yes, on debian, it should be a ./configure --disable-all build and have a deb package file that describes all of the dependencies |
| 21:23.36 | brlcad | not rocket science, not even hard at all |
| 21:23.46 | brlcad | just nobody knowledgeable has tried |
| 21:23.58 | mafm_ | the problem is that you have to separate all of them into packages |
| 21:24.11 | mafm_ | it's similar with OpenSceneGraph that I updated recently |
| 21:24.27 | mafm_ | (but I didn't have to create from scratch) |
| 21:24.28 | brlcad | only a few hobbiest users that have *wanted* a deb, never made a deb before in their life, some that haven't even really compiled before |
| 21:25.08 | brlcad | none of the issues I've heard mentioned have been about separation |
| 21:25.15 | brlcad | it's been about competence |
| 21:25.24 | mafm_ | so there's libopenthreads (bin and dev), libosg (bin and dev) with many plugins, openscenegraph-doc, openscenegraph-data, openscenegraph-bin with samples and converter tools... |
| 21:25.27 | brlcad | they didn't really seem to know what they were doing |
| 21:26.02 | brlcad | isn't that up to the project to decide how to chop things up -- don't recall ever having seen anything about separation being a requirement |
| 21:26.19 | brlcad | and individual libs that are projects by themselves are already not an issue |
| 21:26.32 | mafm_ | it's part of the debian policy to separate it that way |
| 21:26.43 | mafm_ | AFAIK |
| 21:26.53 | mafm_ | of course, BRL-CAD as a project or anybody, can provide a .deb with everything |
| 21:26.58 | brlcad | it's more complex projects (like X11 or SVN or OpenSSH) that have multiple binaries and libraries |
| 21:27.14 | brlcad | svn isn't just "svn" |
| 21:27.18 | brlcad | they have about a dozen libraries |
| 21:27.25 | brlcad | they're certainly not separated last I saw |
| 21:27.36 | mafm_ | hmm |
| 21:27.41 | brlcad | similar with the X11 core (not even counting Xt, Xi, etc) |
| 21:28.11 | mafm_ | there's libsvn, subversion, and subversion-tools |
| 21:28.14 | brlcad | it's just a matter of size -- there are only so many "big" projects with code bases > 100k |
| 21:28.40 | mafm_ | and x.org is completely modular now in debian |
| 21:28.43 | brlcad | right, as I would expect, that's a reasonable breakout -- but svn has more libs than that |
| 21:29.04 | mafm_ | hmm |
| 21:29.19 | brlcad | the corrollary would be making a package for our libbrlcad |
| 21:29.26 | brlcad | (which needs to be renamed, ugh) |
| 21:29.51 | mafm_ | well, you don't have to provide a separate package for every library and binary |
| 21:30.10 | brlcad | I wouldn't even think to do that :) |
| 21:30.14 | mafm_ | just a sensible separation, specially non-binary data |
| 21:30.26 | mafm_ | by now Debian has around 11 architectures and several kernels (hurd and freebsd) |
| 21:30.43 | brlcad | that doesn't exactly solve the current problem |
| 21:31.25 | brlcad | sure a good thing to do, but the problem has been someone simply competent in making a .deb knowing how to set things up and deal with various configuration issues |
| 21:31.32 | mafm_ | the mirrors are very very huge, and they don't want to repeat data needlessly (non-binary packages are shared in a common pool for all architectures) |
| 21:32.07 | brlcad | our non-binary data is very miniscule at the moment |
| 21:32.16 | mafm_ | hmm, I might give it a try, but I don't promise anything |
| 21:32.18 | brlcad | docs are growing, but still tiny in comparison |
| 21:32.24 | mafm_ | just updating OSG was a bit PITA :D |
| 21:32.44 | brlcad | at the point we have all docs in docbook format and are generating pdf files, then docs will be huge |
| 21:32.53 | brlcad | but that's at least a year out |
| 21:33.12 | mafm_ | I agree that .configure && make is not rocket science, but somehow creating Debian packages is very cumbersome |
| 21:36.15 | brlcad | this is a great example: http://bugs.gentoo.org/show_bug.cgi?id=77197 |
| 21:36.22 | brlcad | the gentoo ebuild is in a similar boat |
| 21:36.53 | brlcad | it has been hit up by many many people over the years, and just today was looked at by someone knowledgable that whipped up an ebuild in very short order |
| 21:37.03 | brlcad | a completely new ebuild I might add |
| 21:37.10 | alex_joni | if you do make install then building a deb is not that hard |
| 21:37.39 | alex_joni | building a deb that gets accepted in the debian repos however is a bit trickier.. |
| 21:37.52 | mafm_ | biggest problem might be name clashes or something, librt or libu are not terribly "unique-like" :D |
| 21:38.38 | brlcad | we've sorted out most all of the name clashes I'm aware of, and made many insignificant by installing libs into a subdir |
| 21:40.44 | alex_joni | complying with the LFHS is another topic |
| 21:40.57 | mafm_ | how so? like /usr/lib/brlcad/libu.so? |
| 21:41.04 | brlcad | yeah, like that |
| 21:41.12 | mafm_ | debian adheres to FSH too :D |
| 21:41.22 | alex_joni | http://www.debian.org/doc/debian-policy/ch-opersys.html |
| 21:41.24 | brlcad | all just a configure flags |
| 21:41.47 | alex_joni | brlcad: then it's the point of debian/rules to just invoke the proper configure invocation |
| 21:41.55 | alex_joni | surely not a hard thing to do |
| 21:42.02 | brlcad | exactly my point |
| 21:42.41 | brlcad | nothing hard, just few knowledgeable have tried |
| 21:42.58 | alex_joni | well, it depends what you want to do with the packages |
| 21:43.04 | alex_joni | build a repo and maintain it? |
| 21:43.14 | mafm_ | are there any dependencies? kind of ogre in g3d? |
| 21:43.25 | alex_joni | push it to debian, and be done with it.. ubuntu maybe? etc |
| 21:43.47 | alex_joni | mafm_: what do you mean? |
| 21:43.49 | brlcad | alex_joni: I still believe that's not time we should waste |
| 21:44.07 | brlcad | by we, I mean an active developer capable of working on the code |
| 21:44.12 | alex_joni | brlcad: guess that's why there are no packages out there ;) |
| 21:44.14 | brlcad | it should be done by a user for that OS/distro |
| 21:44.19 | alex_joni | right |
| 21:44.25 | alex_joni | that's your call.. |
| 21:44.49 | brlcad | if there's nobody for that environment (yet), so be it .. in the meantime, we have PLENTY to work on (e.g. make things easier to use) |
| 21:45.11 | alex_joni | we did it for our software, as we planned to use debs as the primary way of distributing the software |
| 21:45.28 | alex_joni | and are still doing it 4? years later ;) |
| 21:45.39 | brlcad | that's 1-2 days for debian, 1-2 days for gentoo, .. fedora, fink, redhat rpms, etc... |
| 21:45.47 | brlcad | it's just not a productive use of time |
| 21:46.20 | alex_joni | you're certainly right about one thing, it's work that can be done by anyone with packaging skills |
| 21:46.24 | brlcad | there are a hundred "1-2 day" tasks that are perfectly justified in exactly the same way that can be performed by a non-developer |
| 21:46.38 | alex_joni | no need to know BRLCAD internals for that |
| 21:47.31 | brlcad | if there isn't someone willing or capable of doing it yet, that's fine -- it's not something that needs to be forced, it'll happen when we've made things "easy enough" for it to happen |
| 21:47.53 | brlcad | things are WAY better than they were 4 years ago |
| 21:48.10 | alex_joni | it'll bring more exposure (users).. but then again, it's up to you to decide if that's really needed ;) |
| 21:48.27 | alex_joni | or helpfull |
| 21:48.41 | brlcad | right |
| 21:48.50 | brlcad | I don't think it's helpful if we have to push to make it happen |
| 21:49.22 | alex_joni | or if you get a ton of users in here asking how to right click in mged |
| 21:50.24 | brlcad | right |
| 21:52.00 | mafm_ | alex_joni: src/other sometimes contains software that brl-cad need |
| 21:53.05 | mafm_ | like Ogre that it's needed for g3d |
| 21:53.31 | mafm_ | obviously you cannot put that into debian package |
| 21:55.39 | brlcad | or "simple" feature requests like "how can I get a shaded view of geometry" |
| 21:55.50 | alex_joni | right.. but you can make the brlcad package depend on the needed package |
| 22:04.13 | brlcad | src/other should contain ALL of our dependencies with the exception of the C runtime, curses (optional), X11 (optional), and OpenGL (optional) |
| 22:04.53 | brlcad | there are a couple of src/other items that are basically unmaintained or niche codes |
| 22:05.06 | brlcad | working out taking over maintainership of them for the fedora folks |
| 22:10.14 | mafm_ | all of those would have to be in debian or packaged separately |
| 22:14.47 | brlcad | or treated as private libs |
| 22:14.54 | brlcad | which is what most projects do |
| 22:15.26 | brlcad | we just make it explicitly clear that they're not code we wrote for maintainability and licensing purposes |
| 22:15.42 | brlcad | most projects would throw that in with the rest of the sources, link against it static and be done |
| 22:15.50 | brlcad | no problems because it really is that niche a code |
| 22:16.55 | brlcad | nobody would even know we use the TNT code if we didn't tell them .. nothing gets compiled, just a bunch of template headers |
| 22:17.07 | starseeker | the utahrle stuff and step we could probably move into src as our own libraries and nobody would blink - I don't know if I've ever heard of a system having those externally installed... |
| 22:18.05 | CIA-43 | BRL-CAD: 03bob1961 * r37530 10/brlcad/trunk/src/libdm/ (axes.c dm-Null.c dm-wgl.c dm_obj.c): Quell a few warnings when compiling 64-bit Windows. |
| 22:18.17 | brlcad | right, they're another good example |
| 22:18.29 | brlcad | the reason we can even take them over is because they're not maintained |
| 22:19.22 | brlcad | I used to see utahrle installed in places, but not in probably 5-10 years |
| 22:20.37 | brlcad | anyone care to place a bet on whether bob injects a bug with all of the 64-bit quelling? :) |
| 22:21.53 | CIA-43 | BRL-CAD: 03bob1961 * r37531 10/brlcad/trunk/src/libfb/if_remote.c: Quell a few warnings when compiling 64-bit Windows. |
| 22:23.20 | starseeker | heh - not a dime |
| 22:25.35 | starseeker | indianlarry: how did you compile step-g so that everything got included? |
| 22:37.09 | *** join/#brlcad PrezKennedy (Matthew@whitecalf.net) |
| 22:52.10 | mafm_ | I'm sure it's forbidden to include tcl version x.x for example, because brl-cad requires it and in thebian there's version x.z |
| 22:52.31 | mafm_ | which is one of the issues raised in the Request For Package item |
| 23:33.47 | ``Erik | "that show quit being funny after kristie alley ate shelly long" yow O.o :D |
| 23:34.16 | brlcad | mafm_: tcl is a managed external lib, we wouldn't even install it |
| 23:34.49 | brlcad | that issue in the RFP is bogus iirc |