| 00:00.21 | brlcad | mafm: installing into /usr is usually very *bad* |
| 00:00.43 | brlcad | that may result in installed system libraries getting overwritten |
| 00:00.55 | brlcad | rendering your system unusable |
| 00:09.23 | mafm | hmm |
| 00:09.39 | mafm | well, no hope to get it in Debian repositories then :| |
| 00:11.59 | ``Erik | yeah, was a long fight with gentoo, iirc |
| 00:12.20 | ``Erik | like the ray trace library is librt.so, but sometimes there's a /usr/lib/librt.so for realtime stuff on leenewx |
| 00:12.40 | ``Erik | and I think libbn has a conflict with openssl? |
| 00:13.16 | ``Erik | the fbsd maintainers were pretty easy to go with /usr/local/brlcad/ I think... pedro did that work |
| 00:13.42 | *** join/#brlcad Nohla (~Nohla@201.255.251.208) | |
| 00:16.00 | mafm | well |
| 00:16.19 | mafm | it is nice to have it in the official repositories (and Debian means Ubuntu...) |
| 00:16.26 | mafm | but if it cannot be, cannot be |
| 00:19.05 | ``Erik | debian has a bit of a crusade going, is ubuntu more flexible? |
| 00:21.27 | ``Erik | (debian was my favored linux before I switched to fbsd, I like it... but if they're unwilling to give a little to solve a conflict like what we have...) |
| 00:24.37 | mafm | debian follows linux filesystem hiearchy standard, I think |
| 00:24.37 | ``Erik | if this cat keeps going after my phone wire, imma take her around the corner to the chinese restaurant O.o |
| 00:24.45 | mafm | that's problably the cause of the problems? |
| 00:25.22 | ``Erik | um, I vagually recall LSB having contingencies for this |
| 00:26.36 | mafm | and Ubuntu imports most packages directly from Debian (the ones not very important for the desktop, at least, in the "universe" repository) |
| 00:27.42 | ``Erik | hm, from the LSB FHS stuff, /opt/brlcad looks 'optimal' |
| 00:28.04 | ``Erik | http://www.pathname.com/fhs/pub/fhs-2.3.html |
| 00:28.33 | ``Erik | and it doesn't seem to say that /usr/brlcad is wrong |
| 00:32.00 | ``Erik | having bloodied myself up on more *nix than you can shake a stick at, the notion of putting verydamnthing in /usr/bin seems horrible to me, so'z ya won't find me trying to make that ok for any software I work on... :) |
| 00:32.44 | ``Erik | everydamnthing even |
| 00:46.35 | mafm | mmm |
| 00:47.40 | mafm | dunno, I think that /opt is reserved for other installed software not coming from the OS/distribution (e.g., the same software that goes to /usr/local) |
| 00:48.36 | mafm | all the packages in the repositories are installed under /usr with no separation except for /usr/share/brlcad, /usr/lib/brlcad and so on |
| 00:49.50 | mafm | in fact, all the tools checking the package quality blackmail you threatening to rape your bicicle and crash your dog, or something to that effect... |
| 00:50.47 | mafm | when you use strange directories, when the non-arch-dependent data files are shipped in arch-dependent binary packages, etc |
| 00:51.05 | mafm | so in the case of Debian, it is more than clashing with existing libraries |
| 00:52.27 | mafm | actually, what I (or another person packaging for official Debian repos) should do is to create many different packages from brl-cad source package, e.g. for opennurbs or any other of the 3rd party software not present in Debian |
| 00:53.12 | mafm | and split brl-cad itself in data, libs, -dev, bins... |
| 00:54.13 | mafm | openoffice, for instance, is splitted in different packages for each of the tools, plus some common packages (core, doc?, one for every l10n and help manual translated, etc) |
| 00:55.38 | *** join/#brlcad Nohla_ (~Nohla@201.255.246.119) | |
| 01:27.47 | mafm | well, time to sleep |
| 01:43.42 | brlcad | mafm: see what was done for gentoo, it was a reasonable compromise |
| 01:44.32 | mafm | ops, still here |
| 01:44.52 | brlcad | http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sci-misc/brlcad/brlcad-7.16.6-r1.ebuild?view=markup |
| 01:45.08 | mafm | brlcad: it's not about *my* compromise, the people in charge of approving packages to the repositories wouldn't admit the package having those "problems" |
| 01:45.25 | brlcad | mm, actually looks like they actually let us live in /usr/brlcad in that latest ebuild |
| 01:46.01 | brlcad | but at the time, the idea was to install in some place like /usr/share/brlcad then create symlinks in /usr/bin, /usr/lib etc |
| 01:46.36 | brlcad | mafm: is there a clobber-detection mechanism in debian for .deb packages? |
| 01:47.28 | brlcad | if there is, then you might actually get away with it -- do you already have a /usr/lib/librt.so or /usr/lib/libbu.so or /usr/lib/libbn.so ? those are the usual conflict suspects |
| 01:49.11 | mafm | there are such mechanisms in place |
| 01:49.58 | mafm | but more than that, the ftp masters carefully check the contents of the packages, specially the new ones |
| 01:50.17 | mafm | that includes licensing, directories, 3rd party software shipped inside... |
| 01:50.54 | brlcad | so you can go for broke -- try /usr but I'd be shocked if you didn't encounter a conflict with something by installing there even on your system |
| 01:51.01 | mafm | anyway, I can create the package and give it to you, the users can then install it easily |
| 01:51.15 | brlcad | just don't want that deb to hose their system :) |
| 01:51.28 | brlcad | mafm: there is sh/make_deb.sh .. you should update it :) |
| 01:51.51 | mafm | then, with time and after feedback from usrs, we can work towards that |
| 01:52.02 | brlcad | have you seen the other guy's efforts? |
| 01:52.14 | mafm | the last time that I tried there were problems with Jama and other things, as far as I can remember we even sent patches to upstream |
| 01:52.16 | brlcad | two other guys actually |
| 01:52.30 | mafm | nope, is that in the repository? |
| 01:53.04 | mafm | ah, I see it |
| 01:53.33 | brlcad | Giuseppe Iuculano |
| 01:53.38 | brlcad | http://git.debian.org/?p=debian-science/packages/brlcad.git |
| 01:53.50 | brlcad | the guy recently active on the lists |
| 01:54.02 | brlcad | alas, he slapped gpl on his files, so can't add them |
| 01:54.25 | mafm | mmm |
| 01:54.48 | brlcad | more specifically, added a debian dir (which should have been in misc/ )http://git.debian.org/?p=debian-science/packages/brlcad.git;a=tree;f=debian;h=95c1ef639d51ce10a6979231dfe97ad7d9d5d38a;hb=cfe02b5bfc8b33745e3431216cb4872302ac3cff |
| 01:54.51 | mafm | that script only creates the commands, but the control-files are not in your repository |
| 01:55.41 | brlcad | ah, yeah, .. the control files were removed a LONG time ago because they fell out of maintenance |
| 01:55.50 | mafm | 18 months ago Move to debian-science team master Giuseppe Iuculano [Sun, 22 Feb 2009 18:24:44 +0000] |
| 01:56.18 | mafm | I saw other guys trying to package this for Debian since a few years ago, nobody succeeded :D |
| 01:57.35 | mafm | I was more inexperienced the first time that I tried, I'm much more experienced now, let's see what I can get :) |
| 01:57.46 | mafm | I'll let you know in the following days... |
| 01:57.52 | mafm | now of to bed, for real! |
| 01:57.53 | mafm | bye |
| 02:01.45 | *** join/#brlcad velociostrich (~nsd@c-68-37-119-2.hsd1.nj.comcast.net) | |
| 03:13.20 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 03:35.39 | *** join/#brlcad _yukonbob (~svs@S010600235a187d92.ok.shawcable.net) | |
| 04:46.55 | *** join/#brlcad IriX64 (~MarioDUli@bas2-sudbury98-1128565033.dsl.bell.ca) | |
| 06:47.11 | *** join/#brlcad merzo (~merzo@smartbussiness.mobicom.net.ua) | |
| 07:09.12 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 08:21.32 | *** join/#brlcad mafm (~mafm@83.50.133.37) | |
| 09:39.40 | mafm | would people installing the deb want the files in /usr/brlcad/include ? |
| 11:20.12 | ``Erik | some probably would, there're a few programs that use the libs |
| 11:20.37 | mafm | all right |
| 11:20.56 | mafm | I can't find any other packages being called librt or things like that |
| 11:21.11 | mafm | so probably there would not be any conflicts |
| 11:21.50 | d-lo | I get linker warnings when compiling with Qt 4.6.2 on my system. there is some librt.somethin.somethin in Qt somewhere :/ |
| 11:25.23 | mafm | dunno, but at least libbu, librt, libbn do no exist |
| 11:25.43 | mafm | maybe with soversions appended it happens |
| 11:25.51 | d-lo | Probably not an issue, just mentioning it :) |
| 11:26.20 | mafm | W: brlcad-dev: non-standard-dir-in-usr usr/brlcad/ |
| 11:26.21 | mafm | W: brlcad-dev: file-in-unusual-dir usr/brlcad/include/brlcad/RtServerImpl.h |
| 11:26.23 | mafm | W: brlcad-dev: file-in-unusual-dir usr/brlcad/include/brlcad/analyze.h |
| 11:26.24 | mafm | ... :D |
| 11:26.33 | mafm | do you use debian-based systems, d-lo? |
| 11:26.44 | d-lo | no, I don't. |
| 11:26.51 | d-lo | I still a *nix newbie |
| 11:27.00 | d-lo | so I am sticking with RHEL at work and Ubuntu at home. |
| 11:28.48 | mafm | Ubuntu is debian-based :þþþþþþ |
| 11:35.08 | mafm | E: brlcad-data: shell-script-fails-syntax-check ./usr/brlcad/share/brlcad/7.16.10/tclscripts/ami.tcl |
| 11:35.09 | mafm | E: brlcad-data: shell-script-fails-syntax-check ./usr/brlcad/share/brlcad/7.16.10/tclscripts/ampi.tcl |
| 11:35.54 | mafm | and there are a lot of... W: brlcad-data: executable-not-elf-or-script ./usr/brlcad/share/brlcad/7.16.10/tclscripts/mged/plot.tcl |
| 11:39.22 | ``Erik | probably debhelper being... stupid. Looking for a shebang on an 'include' file |
| 11:39.22 | ``Erik | are the files +x? |
| 11:39.31 | ``Erik | (the C equivalent would be complaining about not finding main() in a library) |
| 11:42.58 | ``Erik | can't remember if he added a debian/ thingie to BRL-CAD... pretty sure he did an rpm spec file |
| 11:46.09 | ``Erik | I'd actually be curious to see a modern deb thingie, it's been many years since I've logged into a debain based machine :) |
| 12:06.13 | starseeker | mafm: what do other packages with .tcl files do? |
| 12:08.10 | starseeker | ponders - I know brlcad won't like this suggestion, but is there some autotools magic that could produce libraries named libbrlcad* instead of lib*? CMake appears to provide such a hook, but I don't know about autotools. Would break naming convention expectations I know, if if that's the ONLY way to get the thing into the repositories... |
| 12:09.01 | ``Erik | probably... but the people who give us money care a whole lot about conventions and don't give a flying eff about linux repos |
| 12:09.24 | starseeker | ``Erik: I know - I'm not suggesting WE do that, but perhaps mafm could figure it out for Debian |
| 12:09.45 | starseeker | Debian isn't likely to give a flying eff about not obeying our lib naming expectations |
| 12:10.30 | starseeker | Gentoo fought it for five years before they gave up, and generally they're more flexible than Debian |
| 12:10.39 | ``Erik | heh |
| 12:10.49 | ``Erik | debian is a religious movement, gentoo is for ricers :D |
| 12:11.09 | ``Erik | if the hook isn't there to generate names, libtool could be tweaked to force it, methinks |
| 12:11.20 | starseeker | Debian is the distro that took out some of the original dictionary content for one of the spellcheckers when they couldn't verify it was open, IIRC... |
| 12:12.18 | ``Erik | yes, which is why you see a LOT of apt repos for stuff that isn't guaranteed friendly to the gpl... |
| 12:12.54 | starseeker | nods - even on ubuntu I think I had to set up four or five repositories other than the standard ones to get what I wanted |
| 12:13.10 | ``Erik | had some of his software in, uhhh, sam hocevar's repo awaiting "blessing"... dev repo's are common |
| 12:13.55 | starseeker | I do have to admire Ubuntu's mechanisms for that stuff - they are making good use of signing mechanisms |
| 12:14.33 | starseeker | bit of a pain, but less so than many I've seen and probably about as simple as it can be without missing the point |
| 12:15.33 | ``Erik | pkg_add -r |
| 12:15.35 | ``Erik | ftw. |
| 12:15.36 | ``Erik | :D |
| 12:15.57 | mafm | ``Erik: the files (executables) are +x, yes |
| 12:16.50 | ``Erik | mafm: that's probably what's triggering it, and that actually might be our bad, using tcl_SCRIPTS instead of tcldir_DATA... can you sed/awk down a list and dump it on a pastebin? |
| 12:17.03 | mafm | starseeker: you can only execute a file if you can do "./file" and works, because it's an elf binary executable, or an script. Probably those .tcl files are none, so they can't be executed, so being +x is not needed (it's just a Warning). |
| 12:17.33 | starseeker | mafm: we DO have some .tcl files that can be run that way, IIRC |
| 12:18.05 | starseeker | not completely sure, and it's more likely some of them have exe set incorrectly, but don't dismiss it out of hand |
| 12:18.09 | ``Erik | is going to guess that the deb checker sees +x and does not see the shebang... that'd be malformed |
| 12:19.10 | mafm | ``Erik: look for "executable-not-elf-or-script" https://devel.adenu.ia.uned.es/~mafm/lintian.log (being produced in real time, it might take a few seconds more to finish) |
| 12:19.21 | ``Erik | mged/plot.tcl, for example, is an inclusion file and should not be +x |
| 12:19.55 | mafm | probably all the cases are similar to that, yes |
| 12:19.58 | ``Erik | well, I'm about to put on some pants and drive tot he office, so I'm not exactly in a rush :D |
| 12:20.21 | mafm | (just reading the backlog and have to go to lunch in a minute, I'll reply you later) |
| 12:20.35 | starseeker | yeah, most of those probably shouldn't be exe |
| 12:21.35 | starseeker | not so sure about /usr/brlcad/bin/ssampview.tcl |
| 12:21.45 | starseeker | the location suggests it is intended to be run... |
| 12:24.54 | starseeker | as for the man pages, it's a fairly good bet that some of those will stomp over other man pages... I know some of the mged command ones would (ending in .nged if I recall, although I don't see those in the log - are you building with or without Docbook based docs?) |
| 12:25.33 | starseeker | heads to the office too... |
| 13:26.19 | mafm | starseeker: without docbook, I think |
| 13:27.14 | mafm | I didn't require any dependencies outside bison, flex and X-windows stuff... you should tell me which ones are needed to generate a package that it's generally useful |
| 13:51.00 | starseeker | mafm: that's fine, it just means the documentation system in mged won't be active |
| 13:51.04 | starseeker | the software will work find |
| 13:51.07 | starseeker | fine even |
| 13:52.16 | mafm | well, yes, but the point of creating the package is to be useful for people :) |
| 13:52.41 | mafm | it's you, devels and users of the software, who have to say me which stuff would be useful |
| 13:53.02 | starseeker | well, hopefully the extra docs would be useful... |
| 13:53.07 | mafm | I'm trying to help brl-cad, but I don't known which things are useful and which are not :) |
| 13:53.24 | starseeker | mafm: you only need the docbook stuff to build the files |
| 13:53.34 | mafm | also, the warnings about the package that I posted, are warnings and do not in general prevent it from including it in Debian |
| 13:53.34 | starseeker | it's not required at run-time |
| 13:53.55 | mafm | I can easily create an script to set -x on those files |
| 13:54.15 | mafm | but I just thought that it would be useful to report it, so you can inspect them (even if it's a minor error) |
| 13:54.35 | starseeker | generates a bunch of html and man pages (and pdf if you happen to have FOP, but that's probably n ot as useful) |
| 13:54.42 | starseeker | mafm: sure :-) |
| 13:55.10 | mafm | mmm, let's see, I will tell you the packages (dependencies) that I declare for the package |
| 13:55.36 | starseeker | mafm: build time dependencies or run-time dependencies? |
| 13:55.45 | mafm | Build-Depends: debhelper (>= 7.0.0), make (>= 3.8.0), ccache, bison, flex, xserver-xorg-dev, libx11-dev, libxi-dev, libpng-dev, zlib1g-dev, tcl8.5-dev (>= 8.5), tk8.5-dev (>= 8.5), itcl3-dev, itk3-dev, iwidgets4, blt-dev |
| 13:56.09 | mafm | debhelper is a debian thing, ccache for fast compilation in the developer or build farm Debian machines |
| 13:56.20 | starseeker | ah. OK. If you also have xsltproc you can build the docbook stuff |
| 13:56.30 | starseeker | dunno which package that is in Debian |
| 13:56.43 | starseeker | libxml something or other probably |
| 13:56.47 | mafm | I run ./configure directly, I hope that there's no problem with this, so I don't declare autotools as dependencies |
| 13:57.03 | starseeker | mafm: should be fine for the tarball |
| 13:58.56 | mafm | I see that there are lots of checks for opengl libs headers... would be useful to include those? |
| 14:01.41 | mafm | also, is libncurses5 a substitute of termlib in src/other? |
| 14:50.20 | starseeker | um |
| 14:50.58 | starseeker | mafm: not sure about those two - opengl is probably something we would want on, but I don't know if it's "stable enough" to advise turning it on |
| 14:55.11 | mafm | starseeker: that's what my configure lines look like http://paste.debian.net/85979/ |
| 14:55.44 | mafm | I'd like to use the system packages, e.g. with --with-tcl=/usr/include/tcl8.5/ and the like |
| 14:55.49 | mafm | but it does not seem to work |
| 14:55.52 | mafm | the questions are: |
| 14:56.23 | mafm | 1) do I need to enable anything else, for the regular functionality that you want to support? |
| 14:56.54 | mafm | 2) the --with-tcl thing doesn't seem to work, could anybody help me with that? |
| 14:57.43 | mafm | I'd like to use the system packages at least for all the Tcl/Tk-related stuff |
| 15:17.30 | CIA-88 | BRL-CAD: 03davidloman * r40329 10/rt^3/trunk/ (3 files in 2 dirs): Stub in a wrapper class for QThread. Will enable us to track the creation and status of threads much easier. |
| 15:19.20 | CIA-88 | BRL-CAD: 03davidloman * r40330 10/rt^3/trunk/tests/libNetwork/CMakeLists.txt: Modified cmake for libNetwork tests to reflect new lib name. |
| 15:34.26 | starseeker | mafm: try adding --enable-docs and see if that works |
| 15:38.34 | brlcad | mafm: what are your current configure flags? |
| 15:39.11 | brlcad | enable-docs implies adding a dep for xsltproc and fop |
| 15:39.26 | brlcad | ideally configurable, especially the latter.. fop is a beast of a dep |
| 15:42.19 | brlcad | mafm: ncurses should suffice for termlib |
| 15:46.18 | mafm | brlcad: http://paste.debian.net/85979/ |
| 15:47.05 | mafm | the ones commented out are the ones trying to use the system installed software |
| 15:47.56 | mafm | and the package exists: http://packages.debian.org/sid/amd64/tcl8.5-dev/filelist |
| 15:48.20 | brlcad | building regex? that might be in base |
| 15:48.21 | mafm | sorry, I mean "the path provided with --with-tcl exists" |
| 15:49.34 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 15:49.34 | brlcad | shouldn't need --enable-tcl --enable-tk --enable-itcl --enable-iwidgets |
| 15:49.56 | brlcad | if you list them as deps, they should be disabled |
| 15:50.11 | brlcad | (which you got by --disable-all) |
| 15:51.37 | brlcad | suggest adding xsltproc but not fop as dep, so html and embedded docs will get built and enabled, but avoids a java dependency for fop |
| 15:51.47 | brlcad | (so just no pdf) |
| 16:08.46 | brlcad | mafm: reading back through the log .. there wouldn't be packages for librt.so -- it's a really old "real-time" posix extensions library that would be in base/core |
| 16:09.03 | brlcad | it was deprecated for like 10 years, so might have finally removed it |
| 16:11.00 | brlcad | the syntax failures on ami.tcl, ampi.tcl, and friends are a failure of shell-script-fails-syntax-check .. the scripts are fine -- they're dual-syntax tcl AND shell scripts |
| 16:12.21 | brlcad | and yeah, I don't think it's a good idea to change our name, especially when we can change our install location and avoid conflicts just as easily, putting things into subdirs |
| 16:14.32 | brlcad | those tcl files can be directly executed (try running "ami.tcl", it works) |
| 16:14.56 | brlcad | that's why they're +x, that's right |
| 16:15.36 | brlcad | is done |
| 16:17.25 | CIA-88 | BRL-CAD: 03brlcad * r40331 10/brlcad/trunk/doc/README.Linux: include a list of the required and optional Debian package requirements |
| 16:18.20 | brlcad | mafm: feel free to install your debian package files into misc/debian or misc/apt if they're not gpl |
| 16:46.18 | mafm | doens't it need image libraries other than libpng, e.g. libtiff? |
| 16:46.43 | mafm | re: misc/debian, do you mean in the official brlcad repo? |
| 16:49.21 | mafm | re: the enable-tcl and the like, I need them because it doesn't detect when I have the system tcl and use --with-tcl=/usr/include/tcl8.5 (same error as yesterday, as if it couldn't include the tcl) |
| 16:49.46 | mafm | I think that it's missing the -I/usr/include/tcl8.5 when trying to compile the conftest.c |
| 17:01.00 | brlcad | mafm: nope, just libpng .. and yes, misc/debian in the repo |
| 17:01.34 | brlcad | it is missing the include dir -- try specifying it manually: --with-cppflags=-I/usr/include/tcl8.5 |
| 17:03.21 | brlcad | alternatively, you could do something like --with-cppflags="`sh tclConfig.sh && echo $TCL_INCLUDE_SPEC`" |
| 17:03.51 | brlcad | make sure "sh tclConfig.sh && echo $TCL_INCLUDE_SPEC" works, of course |
| 17:05.13 | mafm | but would I have to do the same for tk8.5, iwidgets, etc? |
| 17:05.25 | mafm | maybe the cppflags is better in this case |
| 17:05.27 | brlcad | in theory, that's how tcl's set themselves up |
| 17:06.18 | brlcad | the config script "knows" where the include files are, even for whacky builds. putting /usr/include assumes that never changes |
| 17:14.45 | mafm | I see |
| 17:15.42 | mafm | $(sh tkConfig.sh && echo $TK_INCLUDE_SPEC) |
| 17:15.51 | mafm | that's the one for TK, right? |
| 17:15.57 | mafm | or is not needed? |
| 17:16.32 | brlcad | trun running it |
| 17:16.42 | brlcad | *try |
| 17:17.01 | brlcad | in theory, you need it for all of them |
| 17:17.48 | brlcad | basically a custom pkgconfig |
| 17:18.36 | mafm | <PROTECTED> |
| 17:18.48 | mafm | these ones are in really akward directories |
| 17:19.51 | brlcad | grep "/usr/share" `which tclConfig.sh` |
| 17:19.54 | brlcad | does it show up? |
| 17:20.44 | brlcad | there might be a standard location for tcl/tk "packages", which could lead you to that dir without hard-coding it |
| 17:23.58 | mafm | the thing is that if I have to hardcode the path to them, I can as well hardcode th path with --with-cppflags |
| 17:24.38 | mafm | currently the "standard" version shipped is 8.4, so there's a link tcl->tcl4.4 and so on for this version |
| 17:24.42 | mafm | but not for 8.5 :D |
| 17:26.59 | mafm | well, this seems to be starting to work |
| 17:27.40 | mafm | and other than the possible clashes with other software installed in the system, is there a compelling reason for have it running under /usr/brlcad ? |
| 17:29.00 | brlcad | clashes with system software is by far the dominant problem, I've simply yet to hear of a single system successfully installed into /usr |
| 17:29.54 | mafm | even when using the system provided tcl and so on? |
| 17:30.18 | brlcad | iirc, openssh has/had a libbn.so, there was librt.so in core for many linux and irix systems |
| 17:36.59 | starseeker | mafm: yeah, the conflict is our own libraries |
| 17:37.41 | starseeker | we predate all the others, but since BRL-CAD wasn't open source until 2005 we weren't in the "ecosystem" early enough to have people name around us |
| 17:40.23 | mafm | I see |
| 17:44.03 | CIA-88 | BRL-CAD: 03bob1961 * r40332 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Added routines for reconciling the tree view with the database. |
| 17:46.01 | mafm | new error :( https://devel.adenu.ia.uned.es/~mafm/config.log |
| 17:46.17 | mafm | checking for Tcl configuration... configure: WARNING: Can't find Tcl configuration definitions |
| 17:53.53 | starseeker | bemusedly reads the slashdot article about someone shooting a server - that's like that story on CNN about how the flight attendant announced he had had enough and was quitting over the intercome before bailing out of the plane |
| 17:54.23 | mafm | these are the commands http://paste.debian.net/86007/ |
| 17:54.23 | starseeker | although I suppose this sounds a tad less sane... |
| 17:54.24 | brlcad | half-rhetorically notes that while Intel 64-bit is 'x86_64', their 32-bit architecture is officially 'i386' or 'ia32' .. does it matter? |
| 17:54.35 | brlcad | (and not x86) |
| 17:54.45 | starseeker | checks HACKING |
| 17:55.31 | brlcad | hacking says uname -a |
| 17:55.41 | starseeker | ah yeah - hacking lists x86 and x86_64 - though that implied x86 was used for the 32 bit case, but maybe not... |
| 17:55.52 | starseeker | (line 1015) |
| 17:56.01 | brlcad | yeah, I listed x86, but that was just for usability consistency |
| 17:56.24 | brlcad | I probably had the same internal debate back then to, deciding for simplicity |
| 17:56.31 | brlcad | *too |
| 18:00.11 | starseeker | brlcad: ah, here's that link flag thing I was talking about yesterday: "-flat_namespace -undefined suppress" |
| 18:00.12 | brlcad | mafm: that Tcl configuration failure is from Tcl itself .. it probably is expecting tclConfig.sh to be in a known location (--with-tcl=/path/to/tclconfigshdir/.)) |
| 18:00.22 | brlcad | starseeker: yep |
| 18:00.43 | brlcad | even our libs do that, libtool magic |
| 18:00.52 | starseeker | that's on the stepcore library - only one so far that seems to need it |
| 18:02.25 | starseeker | seems like we need a two-fold test for that - does the compiler support those flags, and are they actually needed on the platform in question |
| 18:02.59 | mafm | actually, it seems to need --with-tcl*config* and --with-tk*include* |
| 18:03.21 | brlcad | (gnu) libtool achieves that with our libs by using gcc -dynamiclib instead of -dynamic .. that tells (apple's) libtool to link in -noall_load mode, which is the same as -undefined suppress |
| 18:03.22 | mafm | (I searched for it in configure script) |
| 18:04.42 | starseeker | brlcad: that's find for libtool, but CMake will need another approach |
| 18:04.45 | brlcad | starseeker: I'd question why stepcore is different -- maybe other linker flags on it are wrong or non-optimal causing -dynamic to be used instead of -dynamiclib or -module or some other linkage flag |
| 18:05.47 | brlcad | cmake is supposed to encompass how to build libraries, so what does their documentation say about linking libraries? |
| 18:05.55 | starseeker | checks |
| 18:06.09 | brlcad | this is guaranteed to be a problem for other projects |
| 18:06.12 | starseeker | normally add_library and target_link_libraries are all that's needed |
| 18:07.32 | brlcad | mafm: OUT configure has a --with-tcl and --with-tk options that can help point out the tclconfig -- tcl adds more specific flags for their build system -- either should work |
| 18:07.40 | starseeker | http://www.cmake.org/pipermail/cmake/2005-March/006255.html |
| 18:08.17 | mafm | hmm, well, --with-tcl didn't work, I tested several times since yesterday :-? |
| 18:09.30 | starseeker | hmm, doesn't mention this but a good page to remember: http://cmake.org/Wiki/CMake_Platform_Dependent_Issues |
| 18:09.45 | brlcad | starseeker: that's a way around it, I suppose, but not a great way in the least |
| 18:10.01 | starseeker | is still looking |
| 18:10.04 | brlcad | that's basicaly what we'd do if we were an autoconf+automake project without libtool |
| 18:10.41 | brlcad | what is your CMAKE_SHARED_MODULE_CREATE_C_FLAGS set to? |
| 18:11.02 | brlcad | sounds like that's where there's a mistake |
| 18:11.03 | starseeker | uh - probably the default, let me print it out |
| 18:11.35 | brlcad | bets it's -dynamic or -bundle |
| 18:12.08 | starseeker | -bundle |
| 18:12.17 | starseeker | CMAKE_SHARED_MODULE_CREATE_C_FLAGS: -bundle -headerpad_max_install_names |
| 18:18.12 | CIA-88 | BRL-CAD: 03davidloman * r40333 10/rt^3/trunk/tests/ (5 files in 3 dirs): Rename test directory for libNet to reflect new lib name. |
| 18:19.23 | mafm | is this stuff needed, or can I disable some of them? --enable-libregex --enable-urt --enable-opennurbs --enable-tnt --enable-tkhtml3 --enable-tkimg |
| 18:21.22 | starseeker | even replacing bundle with dynamiclib doesn't work though |
| 18:35.10 | starseeker | sighs - can't find much more on the issue |
| 18:35.44 | starseeker | well, still a lot of basic hookups to accomplish before things like flag tuning begin |
| 18:57.51 | brlcad | you sure it's using dynamiclib when you replace it? |
| 18:58.20 | starseeker | I did a make VERBOSE=1 |
| 18:58.25 | starseeker | looked at the actual line |
| 18:58.35 | brlcad | fresh build object files? |
| 18:58.49 | starseeker | pretty sure - I'll try again if you like |
| 18:59.35 | brlcad | mafm: be sure to read the INSTALL file ... those enable/disable flags enable or disable our *compilation* of them, not whether they are used |
| 18:59.44 | mafm | yay, packages created again, this time without tcl, tk and a few others |
| 19:00.23 | brlcad | they are technically aliases for much longer option names, e.g. --enable-libregex is technically --enable-libregex-build |
| 19:01.34 | brlcad | so if you --disable-all (which is really an alias for --disable-almost-everything), it will attempt to use system libraries for everything and is equivalent to adding --disable-regex --disable-opennurbs --disable-tcl, etc... |
| 19:03.02 | mafm | brlcad: yep, I understood that, but I'm not sure to understand what is your point? |
| 19:03.50 | mafm | reading the INSTALL file, it seems that the options that I enable are "auto" -- enabled if not present in the system |
| 19:04.18 | mafm | and are enabled if not present in the system, because they are really needed for some brl-cad programs |
| 19:05.02 | mafm | now, my question was if some of them are not needed really, or at least is not important that the users of this package |
| 19:05.45 | mafm | e.g., they are only used for experimental programs (like the opengl thing), or by core developers which won't use the deb (they compile from source and update almost everyday) |
| 19:05.57 | mafm | (finished my exposition :) ) |
| 19:07.27 | starseeker | brlcad: http://paste.lisp.org/display/113925 |
| 19:29.35 | mafm | the debian tools create the following warning (it's not a problem for the package itself, but you might want to take a look) -- http://paste.lisp.org/display/113926 |
| 19:30.18 | mafm | I have a question though... where do the files create by xsltproc go? they're just man files or what? |
| 19:32.45 | starseeker | the man output is, but they also create html files |
| 19:35.05 | CIA-88 | BRL-CAD: 03starseeker * r40334 10/brlcad/branches/cmake/CMakeLists.txt: Commented out line tweaking CMAKE_SHARED_MODULE_CREATE_C_FLAGS - just there for convenience at the moment |
| 19:39.16 | CIA-88 | BRL-CAD: 03starseeker * r40335 10/brlcad/branches/cmake/ (11 files in 11 dirs): Add FindREGEX.cmake. Also, it's time to stop hard-linking to ../other/tcl/generic for tcl includes. |
| 19:39.35 | mafm | oh thanks starseeker, I see that they are in a different directory |
| 19:42.49 | mafm | another bunch of warnings, this about man pages: http://paste.debian.net/86031/ |
| 19:46.14 | starseeker | I'm not surprised about the mann stuff - there are mged commands that conflict with system names, hence the .nged name to try and ensure a unique man page naming |
| 19:46.27 | starseeker | mann was the closest match |
| 19:46.48 | starseeker | we're kinda abusing the man page system in a way, making documentation about internal application commands available as man pages... |
| 19:50.15 | starseeker | I suppose debian wants /usr/man/mannged with that extension or some such? |
| 19:50.28 | starseeker | (which I doubt is a legal man directory...) |
| 20:15.17 | mafm | no idea what that should be |
| 20:15.52 | mafm | http://lintian.debian.org/tags/manpage-in-wrong-directory.html |
| 20:37.42 | *** join/#brlcad merzo (~merzo@66-28-133-95.pool.ukrtel.net) | |
| 20:48.40 | *** join/#brlcad IriX64 (~MarioDUli@bas2-sudbury98-1178014852.dsl.bell.ca) | |
| 20:57.59 | CIA-88 | BRL-CAD: 03starseeker * r40336 10/brlcad/branches/cmake/CMakeLists.txt: This should be TERMLIB |
| 20:59.51 | CIA-88 | BRL-CAD: 03starseeker * r40337 10/brlcad/branches/cmake/misc/CMake/FindTERMLIB.cmake: Not ready yet - just working out the TRY_RUN test approach |
| 21:12.29 | CIA-88 | BRL-CAD: 03bob1961 * r40338 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: A few minor tweaks. |
| 21:13.25 | CIA-88 | BRL-CAD: 03bob1961 * r40339 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added updateCombEditView. |
| 21:19.19 | brlcad | mafm: my point was in response to your question ( "is this stuff needed, or can I disable some of them" ) |
| 21:19.33 | brlcad | you can disable all of them and yes they are all needed :) |
| 21:21.42 | brlcad | the only optional components that come to mind are ones we do not bundle including X11, lex, yacc, xsltproc, fop, and java .. along with external plugins with cubit, unigraphics, and protoolkit |
| 21:27.08 | brlcad | starseeker: yeah... |
| 21:27.37 | brlcad | undefined suppress is needed for that library in particular (for now at least) due to the stupid sdai binding |
| 21:28.04 | brlcad | that is a hard case where the library calls symbols that it never defines, expecting the front-end application to provide those hooks |
| 21:28.33 | brlcad | keith talked a bit about reworking step to remove that stupidity iirc, even if they were just simple empty stubs |
| 21:37.28 | brlcad | somehow, libtool figures out that libstepcore has undefined symbols and automatically adds the undefined suppress |
| 21:38.34 | brlcad | the build can be forced to fail with LDFLAGS=-no-undefined, sure enough I can reproduce |
| 21:44.13 | mafm | is java needed? |
| 21:49.36 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 21:51.02 | brlcad | mafm: er.... |
| 21:51.16 | brlcad | "the only OPTIONAL components that come to mind are ones we do not bundle including ...." |
| 21:53.07 | mafm | yeah well, was a rethorical question, in astonishment |
| 21:54.00 | mafm | also, it seems to compile fine without java |
| 22:18.58 | brlcad | ``Erik: scheme bindings for ftgl and iphone: http://jlongster.com/blog/2010/02/08/fonts-ugh/ |
| 22:19.07 | brlcad | (see video at the bottom) |
| 22:19.47 | brlcad | mafm: it should compile fine without any of those optional components.. otherwise, they wouldn't be optional now would they? :) |
| 22:21.00 | mafm | brlcad: the thing is, as I have said a few hours ago in the channel, that I'm not an user of brl-cad per se |
| 22:21.11 | mafm | I don't know what would be useful and what would be not |
| 22:21.28 | brlcad | x11 gets you a gui for about a half-dozen apps, lex and yacc are used by a converter and point-acquisition interface in mged, xsltproc is used to generate html/manpage documentation, fop gives pdf documentation, java is for a jnilib binding to librt (and for fop) |
| 22:21.57 | mafm | so if I'm not compiling the package for myself, and I don't know what the users would expect, I'm not in position what is optional-but-desirable, and things like that |
| 22:22.20 | brlcad | so you compile it, see who complains about what .. :) |
| 22:22.43 | brlcad | better to have it in debian than not at all in any form |
| 22:23.27 | mafm | well, if there's no 3rd party package shipped and it's not in /usr/brlcad, certainly it would be easier to have it approved for official debian repositories |
| 22:23.57 | mafm | but I don't know if having a package with opennurbs disabled, for example, would be useful at all |
| 22:25.18 | mafm | and the first idea was to put the package in sourceforge and not (yet) in debian official repos, I think |
| 22:27.14 | mafm | if I leave only the "disable-build-all" and don't enable anything in "--disable-build-all --enable-libregex --enable-urt --enable-opennurbs --enable-tnt --enable-tkhtml3 --enable-tkimg", would the package still be mostly useful? |
| 22:34.16 | brlcad | mafm: again, you're misunderstanding the --enable/--disable flags .. you cannot disable opennurbs, you can only disable *building* opennurbs |
| 22:35.17 | mafm | hmm |
| 22:35.18 | brlcad | the things that are optional have no enable/disable flags, except indirectly for --disable-documentation |
| 22:35.56 | mafm | I understand that, the thing is that the system doesn't have any of those packages |
| 22:36.16 | brlcad | which is why we bundle and auto-detect by default ;) |
| 22:36.53 | mafm | so in those cases, no external package installed (nor available in any way other than compiling from source) in the system, it's not that optional |
| 22:36.55 | mafm | :) |
| 22:37.29 | brlcad | we've also become the effective maintainers for some of them (urtoolkit, libutahrle, step, jove, and tkhtml) |
| 22:37.53 | brlcad | I agree -- I never said the items in src/other are optional |
| 22:37.56 | brlcad | they're required |
| 22:38.05 | brlcad | "the only optional components that come to mind are ones we do not bundle including X11, lex, yacc, xsltproc, fop, and java" |
| 22:38.28 | brlcad | the only "option" you're given is whether to let us build it for you or not |
| 22:38.46 | brlcad | download convenience |
| 22:40.29 | mafm | tkhtml is also required? |
| 22:40.53 | brlcad | if it's in src/other, consider it required |
| 22:42.09 | mafm | I do not enable step nor jove, are they built unconditionally? |
| 22:43.41 | brlcad | step, yes; jove, no -- it's deprecated, soon to be removed (but was required) |
| 22:44.05 | brlcad | the configure summary says what is enabled/disabled for compilation |
| 22:53.52 | mafm | hmm |
| 22:53.59 | mafm | well then |
| 22:54.39 | mafm | svn: Failed to add directory 'src/librt/comb': a non-directory object of the same name already exists |
| 22:54.44 | mafm | funny |
| 22:54.52 | brlcad | you have an old build in the way |
| 22:55.11 | brlcad | rm -rf src/librt/comb* && svn up src/librt |
| 22:55.32 | brlcad | (or get a fresh checkout) |
| 22:55.41 | mafm | yep, I did |
| 22:55.51 | mafm | can I commit the directory at any time? |
| 22:56.06 | brlcad | which directory? |
| 22:56.29 | brlcad | "a non-directory object of the same name already exists" says that nope, you didn't |
| 22:57.17 | mafm | misc/debian |
| 22:57.17 | brlcad | there used to be a binary called "comb" .. now there's a directory called "comb" |
| 22:57.18 | brlcad | sure, you can commit misc/debian whenever |
| 22:57.28 | mafm | I mean that I had already figured out how to solve the error by having done already the same that you said later |
| 22:57.32 | brlcad | just make sure to keep misc/Makefile.am up-to-date with EXTRA_DIST so it's included in the source tarball |
| 23:00.37 | mafm | I'm trying to use the system's TNT library but I expect that it fails, as the last time |
| 23:01.11 | brlcad | TNT is just a bunch of headers, so just add the corresponding --with-cppflags=-I/path/to/tnt |
| 23:02.11 | mafm | anyway, I got to narrow down the 3rd party libraries to "--disable-build-all --enable-urt --enable-opennurbs --enable-tkhtml3" plus maybe tnt, and the rest one which are compiled unconditionally |
| 23:02.39 | mafm | mm, the problem with TNT was some clashing of namespaces or something, don't you remember that we even sent a patch upstream? |
| 23:02.56 | brlcad | mmm, vaguely remember that |
| 23:03.05 | brlcad | std:: collisions |
| 23:03.18 | brlcad | min/max |
| 23:08.53 | mafm | yep, something like that |
| 23:09.14 | mafm | is ./usr/share/scl/3.2.0/data/ needed in the binaries that I ship? |
| 23:09.25 | mafm | binary packages |
| 23:11.33 | mafm | -> W: brlcad-doc: zero-byte-file-in-doc-directory usr/share/doc/brlcad/html/manuals/mged/mug.jpg |
| 23:15.49 | mafm | brlcad: the extra_dist files, can I just add the dir or each file has to be added individually? |
| 23:21.41 | CIA-88 | BRL-CAD: 03brlcad * r40340 10/brlcad/trunk/HACKING: talk briefly about code smells, sacred code, and perfection under the refactoring section. |
| 23:24.53 | brlcad | mafm: i'm not sure if scl's data dir is needed |
| 23:25.04 | brlcad | it'd be used by our step-g converter |
| 23:25.10 | brlcad | don't think it's used |
| 23:25.28 | brlcad | each file has to be listed individually |
| 23:26.18 | mafm | good, then I nuke it and let's see if somebody complains :þ |
| 23:26.33 | mafm | rudimentary smoke testing |
| 23:28.17 | CIA-88 | BRL-CAD: 03brlcad * r40341 10/brlcad/trunk/doc/html/manuals/mged/ (Makefile.am mug.jpg): remove the unused zero-length mug.jpg image file. thx mafm |
| 23:32.27 | mafm | brlcad: *misc*/Makefile.am is the one that I have to edit? |
| 23:37.39 | mafm | ok, done! |
| 23:40.24 | CIA-88 | BRL-CAD: 03mafm * r40342 10/brlcad/trunk/misc/ (17 files in 3 dirs): Adding Debian dir, for creating Debian packages |
| 23:54.47 | brlcad | cool |
| 23:54.55 | brlcad | (and yes, it is/was) |