| 00:10.31 | CIA-88 | BRL-CAD: 03mafm * r40394 10/brlcad/trunk/src/tclscripts/ (159 files in 12 dirs): Removed svn:executable property on the tclscripts which don't start with /bin/sh, as discussed in the mailing list |
| 00:16.14 | *** join/#brlcad Nohla (~Nohla@201.255.238.67) |
| 00:47.59 | ``Erik | http://brlcad.org/~erik/student.jpg |
| 01:19.34 | *** join/#brlcad Nohla (~Nohla@201.255.238.67) |
| 02:49.40 | *** join/#brlcad velociostrich (~nsd@c-68-37-119-2.hsd1.nj.comcast.net) |
| 03:02.52 | *** part/#brlcad velociostrich (~nsd@c-68-37-119-2.hsd1.nj.comcast.net) |
| 06:49.49 | *** join/#brlcad merzo (~merzo@smartbussiness.mobicom.net.ua) |
| 10:48.20 | *** join/#brlcad mafm (~mafm@202.Red-88-18-69.staticIP.rima-tde.net) |
| 11:28.12 | brlcad | *yawn* |
| 11:36.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 12:36.09 | *** join/#brlcad raininja (~raijin@unaffiliated/raijin) |
| 12:36.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 13:27.48 | mafm | brlcad: so I do my script magic when installing and leave man pages alone, right? |
| 13:31.10 | mafm | also, do you plan to make a new release soon? |
| 13:44.08 | CIA-88 | BRL-CAD: 03mafm * r40395 10/brlcad/trunk/src/vdeck/vdeck.1: Changing man page section to 1 instead of 1V |
| 13:50.47 | CIA-88 | BRL-CAD: 03mafm * r40396 10/brlcad/trunk/misc/debian/changelog: Adding closing Intent To Package (ITP) bug report |
| 13:59.42 | CIA-88 | BRL-CAD: 03mafm * r40397 10/brlcad/trunk/misc/debian/control: Preparing dependencies for when the packages are updated in Debian and so BRL-CAD can use the system's installed packages |
| 14:01.02 | CIA-88 | BRL-CAD: 03mafm * r40398 10/brlcad/trunk/misc/debian/rules: Move man pages section n to another directory, as discussed in the mailing list |
| 15:22.59 | CIA-88 | BRL-CAD: 03starseeker * r40399 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/incrTcl/CMakeLists.txt): |
| 15:22.59 | CIA-88 | BRL-CAD: Get itcl and itk building - some slight-of-hand needed to get information about |
| 15:22.59 | CIA-88 | BRL-CAD: private tcl/tk headers to incrtcl - we COULD use the compat directory (and do so |
| 15:22.59 | CIA-88 | BRL-CAD: if TCL_PRIVATE_HDRS isn't defined) but that may very well introduce trouble - |
| 15:22.59 | CIA-88 | BRL-CAD: perhaps compat needs an 8.5 directory as well. |
| 15:26.11 | brlcad | mafm: that wasn't what I was thinking, no -- manpage identify themselves |
| 15:26.24 | brlcad | if they're going to be installed into a 3cad dir, then need to be marked as such in the file |
| 15:27.19 | brlcad | what I was saying is that you should make someone on bsd and mac test the new sectioned manual page to make sure they still work on their (potentially non-subsectioned) man |
| 15:28.39 | brlcad | .bz and crit are bsd, ``Erik has another bsd, starseeker and ``Erik have a mac; also make sure brlman works post-install |
| 15:28.54 | CIA-88 | BRL-CAD: 03starseeker * r40400 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/incrTcl/CMakeLists.txt): eliminate stray debug message, enable the summary report for Itcl/Itk |
| 15:29.22 | starseeker | I have a feeling the man page organizational system was never intended for what we're doing with it |
| 15:30.01 | brlcad | we have a monthly iteration schedule just like during gsoc |
| 15:31.17 | brlcad | starseeker: it was meant to be expanded on, which folks have tried, but then you get numbnuts like debian and others than try to restrict it back |
| 15:32.02 | brlcad | the current state of affairs is just inconsistency between gnu and bsd and sysv man implementations |
| 15:32.10 | starseeker | ah |
| 15:32.14 | brlcad | how each expand |
| 15:32.59 | brlcad | and then groups like debian that are trying to simplify with further restrictions beyond the implementation |
| 15:33.51 | brlcad | 3cad is fine, it mirrors 3tcl for tcl commands and can be seen as "a library of commands" in that sub-context, making it fine for cat 3 |
| 15:38.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 16:03.07 | CIA-88 | BRL-CAD: 03starseeker * r40401 10/brlcad/branches/cmake/src/other/incrTcl/ (17 files in 6 dirs): Let's see if we can treat IncrTcl as a true external project - get rid of our directory, will check in just the vanilla sources and then add the one or two bug fix changes. |
| 16:22.26 | CIA-88 | BRL-CAD: 03starseeker * r40402 10/brlcad/branches/cmake/src/other/iwidgets/ (18 files in 8 dirs): Just to be sure, go with vanilla iwidgets too |
| 16:38.29 | mafm | brlcad: note that I didn't move the files in the repository, it's my installation script which does when building the debian packages |
| 16:39.45 | mafm | you can put it wherever you want, I can move it (and rename sections if needed) in my installation script for Debian |
| 16:45.28 | mafm | and actually I don't think that Debian people is numbnuts |
| 16:45.52 | mafm | they have several kernels (hurd, freebsd, netbsd, linux) working under the same basic system, which is not a small achievement |
| 16:46.20 | mafm | it's the better general distro for embedded systems and the most popular desktop distribution, Ubuntu, is based onit |
| 16:46.57 | starseeker | mafm: their policies are occasionally strict to the point of missing the point though... |
| 16:46.57 | mafm | if something, the numbnuts are all the people participating in unix wars beforehand, with decisions that don't make any sense even then, and much less today |
| 16:47.25 | mafm | they are following FHS and LSB, they are the only two prominent standards that Debian follows |
| 16:47.43 | starseeker | had some reservations about those even when they came out... |
| 16:48.21 | mafm | well, so what do you want, to repeat the unix wars all over again? isn't it enough with having gazillions of distributions, packaging systems and guidelines? |
| 16:48.43 | mafm | I don't think that looking at any other distro or OS, they don't have more whimsical rules than that |
| 16:49.15 | starseeker | I understand why they want standards, but things like the inflexibility of the man page setup are annoying |
| 16:49.57 | mafm | man is an obsolete documentation system for anything not related with simple command line programs |
| 16:50.10 | mafm | even GCC's manpages are a hell to follow |
| 16:50.22 | mafm | for other different that a very quick reference |
| 16:50.30 | mafm | or bash's |
| 16:52.13 | mafm | GNU tried to came up with texinfo documentation, which at least has hiperlinks and more than "one page per program" |
| 16:52.19 | mafm | but nobody follows |
| 16:53.30 | mafm | so if something is numbnuts, is the man documentations system itself |
| 16:54.05 | mafm | and its lack of standardization from within |
| 16:56.34 | *** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) |
| 17:03.50 | CIA-88 | BRL-CAD: 03starseeker * r40403 10/brlcad/branches/cmake/src/other/tkpng/ (Makefile.am README license.terms tkImgPNG.c tkImgPNGInit.c): Clear out old iwidgets and tkpng stuff - try tkpng with the original build logic too |
| 17:04.51 | CIA-88 | BRL-CAD: 03starseeker * r40404 10/brlcad/branches/cmake/src/other/iwidgets/: Hmm, go away iwidgets dir |
| 17:17.09 | CIA-88 | BRL-CAD: 03starseeker * r40405 10/brlcad/branches/cmake/src/other/ (116 files in 7 dirs): grab the move of tkhtml3 to tkhtml from trunk. |
| 17:44.26 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 17:54.45 | CIA-88 | BRL-CAD: 03starseeker * r40406 10/brlcad/branches/cmake/src/other/ (518 files in 40 dirs): Add in the vanilla incrTcl and tkpng sources - CMake appears to successfully build all of these with the external projects mechanism. |
| 18:04.19 | CIA-88 | BRL-CAD: 03starseeker * r40407 10/brlcad/branches/cmake/src/other/awf/: brlman doesn't use awf any more - not worth a CMake build |
| 18:05.33 | CIA-88 | BRL-CAD: 03starseeker * r40408 10/brlcad/branches/cmake/src/other/jove/: jove is also on its way out - only do a CMake build of it if we have to later. |
| 18:09.30 | brlcad | mafm: I know you didn't move the files, that's a problem :) |
| 18:11.24 | brlcad | you don't have to agree that they're desire for standards conformance makes them numbnuts or not, frankly I don't care much what they do (their influence is not nearly as far reaching as you suggest) |
| 18:12.16 | brlcad | it'd pedantic adherence to BAD or incomplete standard guidelines, which is also an important distinction -- they're almost entirely guidelines and ones that continually *change* |
| 18:12.38 | brlcad | the point was not blind acceptance, makes you a puppet |
| 18:12.43 | brlcad | or a parrot |
| 18:15.37 | brlcad | saying it's okay to impose arbitrary limitations (that other distros do not, which far predate FHS as a standard) because the man page system itself sucks is logical fallacy -- manpages serve enough of a purpose for them to declare rules, so those rules should be complete and consistent (which they're not) |
| 18:19.18 | brlcad | moreover, my comment about their 'brilliant' pedantry is not just based on manual pages -- I've directly worked with numerous debian devs on various issues, policies, and activities over the years |
| 18:20.45 | brlcad | their misdirected guidance is what made ubuntu the #1 distro (because they're not as pedantic and focus on the practical and usability) |
| 18:21.01 | CIA-88 | BRL-CAD: 03starseeker * r40409 10/brlcad/branches/cmake/CMakeLists.txt: OK, here we go - add in tktable and turn on building all of the tcl/tk packages in src/other |
| 18:21.21 | brlcad | certainly serve a purpose, regardless, there's room in the ecosystem for everyone |
| 18:23.49 | starseeker | brlcad: just to clarify - can we currently use a system TNT install even if it's there? If not, the "Build Template Numerical Toolkit" line in configure (which is a bit of a misnomer anyway since it's headers) should probably go - it's always on |
| 18:26.36 | brlcad | it was left as a tnt-build flag to be consistent with the other flags |
| 18:27.20 | brlcad | I don't know if we can -- I suspect it will give a build failure |
| 18:27.25 | starseeker | Hmm. OK. So when libpc goes live, we'll need something similar for Boost? |
| 18:27.37 | starseeker | brlcad: I was just thinking the summary line |
| 18:27.40 | brlcad | that along with the namespace usind 'std' caused our build to fail iirc |
| 18:29.45 | CIA-88 | BRL-CAD: 03erikgreenwald * r40410 10/brlcad/branches/bottie/ (487 files in 84 dirs): MFC 39973:40402 |
| 18:29.51 | CIA-88 | BRL-CAD: 03brlcad * r40411 10/brlcad/trunk/TODO: verify rt works on windows after the zappo re-enabling |
| 18:29.52 | brlcad | starseeker: ah, hm .. well to be consistent, the summary line should probably go away then :) |
| 18:30.58 | starseeker | I was just thinking how you had mentioned "summary space is limited, use it well" - seemed to me that if we're always using our local copies of the headers, we don't need to report it... |
| 18:33.41 | mafm | brlcad: well, I don't care about the limitations, in fact I don't see them as limitations |
| 18:33.53 | mafm | if that makes me a parrot, that's ok for me |
| 18:34.07 | starseeker | 'course, currently openNURBS and SCL also qualify but those two stand a better chance of gaining a life of their own in the future |
| 18:34.15 | mafm | however, if you don't want to help me fix things, the package won't enter Debian |
| 18:34.25 | mafm | so that's the end of the story |
| 18:34.49 | mafm | I don't want to hear remarks in every e-mail or IRC conversation about how stupid the standards and pedantic complaints are |
| 18:35.11 | mafm | when in fact they already served to identify some mistakes in brl-cad as the bad syntax for the manpages |
| 18:36.26 | mafm | including 3rd party software as Tcl is already stupid from many points of view, yet I don't make that remark every time that I have to deal with that |
| 18:36.42 | mafm | because you have reasons to include that software, right or wrong |
| 18:36.52 | brlcad | mafm: seriously? |
| 18:37.35 | mafm | so if you're going to complain for every thing needed to get the package in Debian, it won't go, and everybody happy |
| 18:37.36 | brlcad | you're the one that started the whole defensiveness posture, I have no problem addressing the issues that have been pointed out |
| 18:38.21 | brlcad | well I can't make you do anything, that's certainly your perrogative if it actually bothers you that much |
| 18:39.19 | brlcad | I haven't been the least bit emotional about it, I'm merely stating opinions based on years of experience working with them, you got defensive OF THEM, and I responded |
| 18:39.32 | brlcad | my comments were not an attack on them in the least, they serve a useful purpose |
| 18:39.45 | brlcad | more power to them for whatever rules they chose to adhere to |
| 18:41.15 | brlcad | you're entitled to feel that inclusion of 3rd party software (like Tcl) is stupid, that's certainly a similar decision (albeit based on user convenience and build guarantees) |
| 18:42.20 | mafm | <brlcad> my comments were not an attack on them in the least, they serve a useful purpose -- I can't see how there are useful |
| 18:42.25 | brlcad | I've said that I appreciate what you're doing, trying to get brl-cad into debian -- perhaps it needs to be said more often than my opinions of the debian devs? :) |
| 18:42.58 | brlcad | they == debian |
| 18:43.01 | mafm | they are not going to change the rules to which 10K+ packages abide just because of you, so complaining about them or calling Debian people retarded doesn't serve any useful purpose, as far as I can tell |
| 18:43.02 | brlcad | they serve a useful purpose |
| 18:43.28 | brlcad | that's a point that you apparently missed -- they DO change the rules, all the time |
| 18:43.58 | brlcad | there are plenty of exceptions to the rules depending on who pushes a package forward and what the situation is |
| 18:44.35 | *** join/#brlcad mafm (~mafm@202.Red-88-18-69.staticIP.rima-tde.net) |
| 18:44.36 | brlcad | X11 is a prime example, it's an exception to the rules in numerous places throughout the system due to the size and complexity of the system |
| 18:45.08 | brlcad | while in practice, they could be forced to conform to exactly the same rules for all the same reasons |
| 18:45.32 | brlcad | that's all really beside the point, though, and not one I'm interested in entertaining further if it gets you worked up |
| 18:45.39 | brlcad | my intention wasn't to irritate you |
| 18:46.06 | mafm | BRL-CAD is not nearly as important as X11, nobody is going to grant you any such privilege |
| 18:46.12 | brlcad | more to give you a perspective that things are NOT at all black and white, that the rules are not rules but guidelines and ones that often change |
| 18:46.42 | brlcad | what does importance have to do with it? |
| 18:47.18 | brlcad | so, it's okay to bend the rules if you're "important"? |
| 18:47.31 | brlcad | it's because they're not rules, they're guidelines |
| 18:48.29 | mafm | nope, it's because X11 has been like that for years and things are very difficult to change for many purposes |
| 18:48.38 | mafm | purposes->reasons |
| 18:48.48 | brlcad | when brl-cad was first pushed forward for debian integration, the integrator was actually willing to consider allowing brl-cad be installed into /usr/brlcad even though it went against the FSH guideline |
| 18:48.54 | brlcad | heh |
| 18:49.33 | brlcad | that exact same reasoning can be said of brl-cad, it's older than X11 and a larger codebase |
| 18:49.53 | mafm | well, I have no power to upload that myself, so it has to pass a first filter which is to be reviewed by somebody doing that |
| 18:50.31 | mafm | and I bet you that with the current problems and my previous experience about the matter, it's very unlikely to get past that filter |
| 18:50.42 | brlcad | well, we're no longer in that position of need, /usr/brlcad is just a preference now, no longer required |
| 18:51.08 | brlcad | but there's nothing wrong with that, too |
| 18:51.22 | mafm | and the thing about importance is -- X11 has been there since the beginning, since the distribution was created, probably, and everybody gives that for granted |
| 18:51.34 | brlcad | put it forward in whatever form works, however unlikely, and see what comes back that can't be justified |
| 18:51.43 | mafm | however brlcad and many other packages are not part of that yet, so it has to pass the initial resistence |
| 18:53.09 | brlcad | in our user community, the same can be said of brl-cad, only that it was long before that particular distribution was created, our community takes it for granted as well |
| 18:53.23 | brlcad | the point is still that they're an exception to this perception of a rule |
| 18:53.27 | brlcad | just one glaring one |
| 18:53.41 | brlcad | I could pull up dozens of other "unknown" exceptions to various guidelines |
| 18:54.08 | brlcad | most with good reasons, some just passing under the radar, others actively getting ignored |
| 18:55.34 | mafm | what's the exception with X11, actually? |
| 18:56.21 | brlcad | numerous, particularly with filesystem layout |
| 18:56.54 | brlcad | where are binaries supposed to be installed, then look where a core x11 binary is installed |
| 18:58.10 | mafm | http://packages.debian.org/sid/amd64/xserver-xorg/filelist |
| 18:58.18 | mafm | http://packages.debian.org/sid/amd64/xserver-xorg-video-ati/filelist |
| 18:58.25 | mafm | http://packages.debian.org/sid/amd64/libgl1-mesa-dri/filelist |
| 18:58.36 | mafm | http://packages.debian.org/sid/amd64/libx11-6/filelist |
| 18:58.43 | mafm | http://packages.debian.org/sid/amd64/libx11-dev/filelist |
| 18:58.49 | mafm | I can't see anything strange about that |
| 18:59.27 | brlcad | nope, not at all strange |
| 19:00.33 | mafm | if things were laid out in the old directories, probably that was with XFree86, and things were changed with X.org to follow the same practices as for the rest of the packages in the system |
| 19:01.23 | brlcad | yes, though X.orog did originally too, later updated |
| 19:02.32 | brlcad | not seeing your point, unless your point is that even large complex codes that are allowed exceptions to guidelines can slowly be changed to conform to those guidelines :) |
| 19:04.19 | brlcad | I'd still be a little surprised if there's not an /etc/X11 or /usr/X11 or similar oddity somewhere on a system even running the latest X.org |
| 19:04.32 | mafm | more like: they can be allowed and encouraged to do that when they are in, plainly rejected when they are out |
| 19:05.00 | brlcad | what's your point mafm? :) |
| 19:05.07 | mafm | $ ls /usr/ |
| 19:05.09 | mafm | bin/ games/ include/ lib/ lib64/ local/ sbin/ share/ src/ |
| 19:05.41 | mafm | the point is that if you don't abide to those rules, however idiotic they might seem to you, you probably don't get it |
| 19:05.43 | brlcad | /usr/games? .. my what a curious exception you have there |
| 19:05.49 | brlcad | what makes games special? |
| 19:06.11 | brlcad | now there is a throw-over from old layous days :) |
| 19:06.38 | ``Erik | yeah, back before GNU came and decided to screw up all the standards *cough* O:-) |
| 19:07.23 | mafm | <PROTECTED> |
| 19:07.39 | brlcad | mafm: if that's your point, then it's duly noted and nothing has changed from what we were already doing, has it? |
| 19:07.51 | ``Erik | FHS2.3 doesn't specify that /usr/games is allowed |
| 19:08.16 | ``Erik | so if you're arguing that all used dirs must exist in the FHS, that's an exception there... |
| 19:09.05 | mafm | ``Erik: http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS9 |
| 19:09.41 | mafm | I'm not interested in arguing anymore, actually |
| 19:09.43 | ``Erik | hm, grep evasive, that one |
| 19:10.13 | brlcad | mafm: could we agree that I can try to hold my debian policy resentment and you can try to hold your debian policy defensiveness? we don't have to agree to make progress |
| 19:10.18 | mafm | those are the rules, and I'm not going to try to change them or to persuade any Debian developer to accept a package with those conditions, that's all |
| 19:11.52 | brlcad | what exactly do you think you're going to have to persuade? |
| 19:12.16 | brlcad | i've not heard of a single issue that has been raised that cannot be addressed thus far |
| 19:12.22 | ``Erik | re-skimming it, looks like /opt/brlcad is a good spot for a debian package if the FHS is really being used. |
| 19:12.31 | mafm | all the points listed in the previous mails, already clarified, plus some of the most important lintian warnings remaining to be fixed |
| 19:12.55 | brlcad | mafm: no, which have been objected to? |
| 19:13.17 | brlcad | those were the issues raised, I didn't see any that cannot be addressed |
| 19:13.30 | brlcad | though addressing some of them amounted to "hey, your script is broken" |
| 19:14.32 | mafm | you've been continuously objecting to many of the complaints; and in particular objecting to the directories thing (which is not an issue anymore) is not going to achieve anything positive, that's all |
| 19:15.13 | brlcad | then you completely misunderstood my response |
| 19:15.31 | brlcad | there were no objections stated, i'm very clear with things I object to |
| 19:16.25 | brlcad | I pointed out that leaving out man[a-z] seems a bit silly to me and man3 without subcategories is inappropriate, man7 would work or man3 with subcategories |
| 19:16.29 | brlcad | how is that objecting? |
| 19:18.16 | brlcad | you don't like that I think (or at least that I voiced) leaving out man[a-z] is a bit silly, duly noted and I still think it's silly, .. so what? there are perfectly fine alternatives that were pointed out, which you even moved forward on and made useful productive progress |
| 19:19.06 | mafm | nevermind |
| 19:19.13 | mafm | sorry, but I have to go to dinner |
| 19:19.47 | brlcad | if you're going to get stressed out when developers voice opinions on policies and best practices, programming is going to be a veritable mine field :) |
| 19:20.11 | brlcad | no problem, enjoy .. and thanks again for your efforts |
| 19:20.13 | brlcad | seriously |
| 19:20.15 | mafm | I know, I'm thinking about growing crops |
| 19:20.18 | mafm | :P |
| 19:20.23 | mafm | see you later |
| 19:20.30 | ``Erik | hasta la pasta |
| 19:20.35 | brlcad | mm, pasta |
| 19:44.59 | CIA-88 | BRL-CAD: 03r_weiss * r40412 10/brlcad/trunk/src/librt/primitives/superell/superell.c: Within the superell primitive corrected tolerance tests to compare 'tol->dist_sq' instead of 'tol->dist', improved bu_log messages to correctly indicate function name. |
| 19:46.48 | CIA-88 | BRL-CAD: 03r_weiss * r40413 10/brlcad/trunk/src/librt/primitives/sph/sph.c: Within the sph primitive corrected tolerance tests to compare 'tol->dist_sq' instead of 'tol->dist', improved bu_log messages to correctly indicate function name. |
| 20:07.27 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 21:04.12 | *** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1178015256.dsl.bell.ca) |
| 21:07.52 | CIA-88 | BRL-CAD: 03starseeker * r40414 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/FindSCL.cmake): Write a quick and dirty FindSCL.cmake file and enable the summary reporting for NIST STEP class libraries. |
| 22:01.20 | _psilva | burp |
| 23:02.11 | *** join/#brlcad SWPadnos (~Me@dsl107.esjtvtli.sover.net) |
| 23:02.45 | *** join/#brlcad SWPadnos (~Me@emc/developer/SWPadnos) |
| 23:12.10 | ``Erik | hrm, now that I have all the parts to this r/c car, I have to figure out how to put it all together O.o |
