IRC log for #brlcad on 20100202

00:18.12 starseeker has an "evil moment" contemplating cmakifying tcl/tk... http://wiki.tcl.tk/21227
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:42.24 yukonbob learned about marching squares in band class.
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.38 alex_joni was just pointing out it's 1-2 days of getting it done
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:18.46 starseeker is coming to the realization that the corefoundation stuff in tcl MUST be addressed before AquaTk can be used...
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

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.