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 |