| pboro | grantc, bad news... cache_dynamic is still broken | 00:07 |
|---|---|---|
| grantc | morning pboro - doh | 00:08 |
| pboro | I'll file a bug report about it | 00:08 |
| pboro | I guess it might work in low concurrency environment, but we're having 100s or 1000s or queries per second, so... | 00:09 |
| grantc | which should be the scenario where it helps... | 00:11 |
| *** Alex| has joined #ingres | 00:12 | |
| *** ChanServ sets mode: +o Alex| | 00:12 | |
| pboro | the errors are E_DM0039_BAD_TABLE_NAME, E_DM9B09_DMPE_TEMP, E_AD7013_ADP_CPN_TO_LOCATOR, E_SC0216_QEF_ERROR, E_SC0206_CANNOT_PROCESS, E_SC0024_INTERNAL_ERROR, E_QS000F_BAD_HANDLE and E_SC0210_SCS_SQNCR_ERROR | 00:13 |
| pboro | grantc, btw it's funny that the JDBC driver is not distributed through ESD but forums | 00:16 |
| pboro | I would expect to find all the drivers in the same place, i.e. ESD | 00:17 |
| grantc | pboro, can you post the link? | 00:18 |
| pboro | http://community.ingres.com/forum/database-drivers-apis/2656-updated-jdbc-driver-posted-version-3-4-8-9-2-a.html | 00:18 |
| grantc | i would expect it too - perhaps my colleague does not know how it's done or it was done to resolve a question | 00:18 |
| pboro | aaahhh... it's in the ESD too, sorry! | 00:18 |
| pboro | but it's only under community projects, not under Drivers | 00:19 |
| * grantc ducks this one | 00:19 | |
| pboro | ahaha :) | 00:19 |
| grantc | i don't know the thinking behind ESD's "structure" | 00:19 |
| pboro | skynet is probably taking care of it | 00:20 |
| grantc | :) | 00:20 |
| pboro | "BUG 121437 - Reduce DateFormat syncronization overhead"... I hope they are not reintroducing the concurrency problem in old drivers where dates between different resultsets got mixed :D | 00:23 |
| pboro | (poking around the changes in the JDBC driver) | 00:23 |
| grantc | no idea - a part from the whole INGRESDATE vs ANSIDATE is a can o' worms | 00:27 |
| pboro | damn, the source code for Ingres JDBC driver 3.4.7 or 3.4.8 is not available in SVN | 00:31 |
| pboro | I was about to try helping in http://community.ingres.com/forum/database-drivers-apis/11364-9-2-ingres-jdbc-driver-spring-throwing-illegalaccesserror.html | 00:31 |
| pboro | by compiling a modified version of the driver for him to try, but I guess he'll manage | 00:31 |
| grantc | pboro, the code should be in svn once it gets sync'd into the internal main codeline | 00:42 |
| pboro | yeah, but the code was published to svn when 9.3 was created | 00:43 |
| pboro | drivers 3.4.7 and 3.4.8 belong to 9.2 | 00:43 |
| pboro | so the history is not available in the svn | 00:43 |
| grantc | sure but a fix in 9.2 will be crossed into main | 00:44 |
| pboro | the fix won't come up there since I was going to try to make the change by myself and put the jar in the forums for the person in trouble :) | 00:44 |
| pboro | well, maybe he'll ask support for it... | 00:45 |
| grantc | ah i see | 00:46 |
| pboro | it would have been five minutes job if I just had the source :) | 00:47 |
| *** Gerhard has joined #ingres | 00:47 | |
| Gerhard | Morning all | 00:47 |
| pboro | hi Gerhard | 00:47 |
| *** paulm05 has joined #ingres | 00:55 | |
| pboro | hmmh the bug with cache_dynamic may actually relate to LOB handling with JDBC | 00:55 |
| Gerhard | It seems that a modify table ... takes significantly longer when used with the concurrent_updates option | 00:59 |
| Gerhard | found that out when testing usermod's -online flag | 00:59 |
| *** Gerhard has quit IRC | 01:32 | |
| Alex| | anyone uses compressed checkpoints with Windows? | 01:33 |
| paulm05 | I have in the past | 01:33 |
| Alex| | is there a knowlegde base article or something... I know how to do it with Linux, just add z or j to the tar command | 01:35 |
| grantc | Alex|, i guess you can use the same commands? | 01:35 |
| Alex| | do we use tar under windows? | 01:36 |
| paulm05 | no | 01:36 |
| grantc | no but you can install gtar | 01:36 |
| Alex| | I would have thought I had to add zip or something to the template file | 01:36 |
| paulm05 | yes - you'll need a zip type program with a command line interface | 01:36 |
| grantc | that's another option or rar | 01:37 |
| Alex| | ckxcopy is the command under windows, right? | 01:38 |
| paulm05 | yes - I'll see if I can find the details I had for when I did - I was doing a comparison of different compression programs | 01:38 |
| *** Dejan has joined #ingres | 01:43 | |
| Alex| | customer's checkpoints grow and he has no space left soon :) | 01:43 |
| Dejan | meep | 01:44 |
| Dejan | hi guys | 01:44 |
| paulm05 | hi | 01:44 |
| *** Mud has joined #ingres | 01:59 | |
| paulm05 | not having much luck finding the files I was looking for Alex | 02:02 |
| Alex| | ok no problem.. we'll suggest it to the customer, he will have to decide.. gives me some time to search :) | 02:02 |
| paulm05 | it was a while ago and my email doesn't go back far enough :( | 02:03 |
| paulm05 | and now outlook has hung :(( | 02:06 |
| Alex| | because you used it... happens often ;) | 02:06 |
| paulm05 | yes well that was the first mistake | 02:09 |
| *** Gerhard has joined #ingres | 02:14 | |
| *** grantc has quit IRC | 02:28 | |
| *** grantc has joined #ingres | 02:33 | |
| *** ChanServ sets mode: +o grantc | 02:33 | |
| *** Gerhard has quit IRC | 02:34 | |
| *** Alex| has quit IRC | 02:53 | |
| *** Gerhard has joined #ingres | 04:17 | |
| *** atrofast has quit IRC | 04:23 | |
| *** atrofast has joined #ingres | 04:24 | |
| *** atrofast has quit IRC | 04:25 | |
| *** atrofast has joined #ingres | 04:25 | |
| *** atrofast has joined #ingres | 04:26 | |
| atrofast | Gah Empathy crashes if you try to put two message windows into one, after you combine then it explodes | 04:27 |
| *** cthibert has joined #ingres | 04:30 | |
| paulm05 | Empathy is the new gnome IM client? | 04:32 |
| grantc | yup and it's playing havoc with our IM server | 04:33 |
| paulm05 | so my next question "any good?" probably a bit redundant ;) | 04:37 |
| grantc | that depends - from an Ingres point of view you cannot use it with our IM server since it's blocked | 04:40 |
| grantc | http://croker.net/~grant/linegraph.png is the problem we are seeing with the only resolution right now is to reboot the im server process | 04:42 |
| grantc | from a user point of view it supports video/voice .... | 04:42 |
| pboro | looks like a leak :) | 04:43 |
| grantc | however compared to pidgin it's not as feature rich (if you exclude the video/voice feature) | 04:43 |
| grantc | indeed ;) | 04:43 |
| *** cthibert has quit IRC | 04:49 | |
| *** paulm05 is now known as PaulM05_afk | 05:03 | |
| atrofast | Wow grantc that's pretty bad | 05:07 |
| grantc | err yeah | 05:08 |
| grantc | the memory problems started at the end of summer when someone started using, we guess an alpha/beta of ubuntu 9.10 or some distro that shipped with empathy | 05:09 |
| atrofast | Yeah I see more and more evidence of Empathy not being ready for consumption | 05:09 |
| atrofast | Hopefully they will make good use of all the bug reports :P | 05:10 |
| grantc | perhaps but openfire should not leak memory | 05:10 |
| atrofast | Heh my crash bug was reported back in June! | 05:13 |
| atrofast | Status: UNCONFIRMED | 05:13 |
| * Dejan is on Fedora 12 | 05:21 | |
| Dejan | i upgraded 2h ago | 05:21 |
| Dejan | Ingres 10 works well on it, if SELinux is disabled | 05:22 |
| Dejan | i did not bother to configure SELinux for Ingres... | 05:22 |
| atrofast | Dejan: same here, I just set SELinux to disabled | 05:23 |
| Dejan | but it would be great if future ingres installer setup selinux properly | 05:23 |
| atrofast | I couldn't find the GUI for it though so I used the command line | 05:23 |
| *** toumi01 has joined #ingres | 05:35 | |
| *** cthibert has joined #ingres | 05:44 | |
| *** Alex| has joined #ingres | 05:50 | |
| *** ChanServ sets mode: +o Alex| | 05:50 | |
| *** Alex| has quit IRC | 05:51 | |
| grantc | there are notes out there on ingres with selinux | 05:54 |
| *** PaulM05_afk is now known as PaulM05 | 05:57 | |
| *** rossand has joined #ingres | 06:03 | |
| *** ChanServ sets mode: +o rossand | 06:03 | |
| Dejan | guys | 06:09 |
| Dejan | is it possible to have something like: | 06:09 |
| Dejan | insert into... values(2, "soemthing", (SELECT... FROM ...)) | 06:09 |
| *** dyki has joined #ingres | 06:09 | |
| Dejan | ie. to mix values with selects | 06:09 |
| Dejan | forget the question | 06:10 |
| Dejan | it was stupid | 06:10 |
| Dejan | :D | 06:10 |
| Dejan | i needed select 2, "something", * ... | 06:10 |
| *** zxiiro has joined #ingres | 06:13 | |
| *** ChanServ sets mode: +v zxiiro | 06:13 | |
| *** thoda04 has left #ingres | 06:17 | |
| *** mull has joined #ingres | 06:37 | |
| *** zxiiro has quit IRC | 06:43 | |
| *** zxiiro has joined #ingres | 06:45 | |
| *** ChanServ sets mode: +v zxiiro | 06:45 | |
| *** Dejan has quit IRC | 07:15 | |
| *** ccsidiot has joined #ingres | 07:25 | |
| *** dyki has quit IRC | 07:29 | |
| *** zxiiro has quit IRC | 07:48 | |
| *** zxiiro has joined #ingres | 07:49 | |
| *** ChanServ sets mode: +v zxiiro | 07:49 | |
| *** hanje04 has joined #ingres | 08:00 | |
| *** Gerhard has quit IRC | 08:03 | |
| *** FrankW has joined #ingres | 08:04 | |
| *** Mud has quit IRC | 08:07 | |
| *** atrofast has quit IRC | 08:14 | |
| *** atrofast has joined #ingres | 08:16 | |
| *** Alex| has joined #ingres | 08:45 | |
| *** ChanServ sets mode: +o Alex| | 08:45 | |
| *** Alex| has quit IRC | 08:57 | |
| ccsidiot | Hum, is this normal for runbuild.sh to be taking > 20 minutes at the same file? I'm "tail -f"ing my build log and it's stucked at ingres/install/vt220.map | 08:58 |
| grantc | it's probably finished | 08:59 |
| grantc | or perhaps not.. | 08:59 |
| ccsidiot | I don't think it's done, since if the build is successful, then it should print o "The build succeeded." | 09:00 |
| ccsidiot | without the o, the o is a typo | 09:00 |
| PaulM05 | try hitting enter - I did see a problem where runbuild was waiting for a user response but didn't indicate it | 09:02 |
| ccsidiot | Hum, I hit, nothing happening | 09:03 |
| PaulM05 | probably not that then :| | 09:04 |
| ccsidiot | Hummm... | 09:04 |
| PaulM05 | any errors or warnings in the build log? | 09:05 |
| ccsidiot | I'm finding @@ | 09:06 |
| *** Mud has joined #ingres | 09:07 | |
| PaulM05 | here's what I was thinking of - http://bugs.ingres.com/ticket/412 | 09:07 |
| PaulM05 | try entering 'y' on the session running runbuild | 09:08 |
| ccsidiot | Thanks PaulM05! | 09:11 |
| ccsidiot | Progress, the build failed | 09:11 |
| ccsidiot | lol | 09:11 |
| ccsidiot | Actually I got the message "All compile targets were successful","Some compile targets were skipped", how is this possible? | 09:19 |
| ccsidiot | Hum, finally spotted those lines | 09:21 |
| ccsidiot | Not found: geospatial/build/lib/libxerces-c.so.27.0 | 09:21 |
| PaulM05 | check for "skipped" in the log and it should say what was skipped and why | 09:21 |
| PaulM05 | ah I was just about to say it's usually xerces | 09:22 |
| ccsidiot | Oh right, I know why | 09:22 |
| PaulM05 | I have to go about now - hope you get it working :) | 09:23 |
| ccsidiot | :) Thanks Paul05 | 09:23 |
| *** PaulM05 has quit IRC | 09:23 | |
| cthibert | hanje04 - Another build related question if you don't mind. There are a few community members trying to compile Ingres in 64bit. One of the issues seen was a lack of lp32 directories. These are created during the build? I expect they are 32 bit related so are not being created in the 64 bit path. | 09:55 |
| cthibert | However, compiling in 64 bit seems to require the use of a few 32bit compatible libraries. So, lp32 is being looked for. Is it possible to create the lp32 directories even during the 64 bit compile? | 09:57 |
| hanje04 | cthibert: The lp32/lp64 directories should be automatically created as part of the hybrid build process | 09:57 |
| hanje04 | Are they doing a 64bit compile or a hybrid compile? | 09:57 |
| hanje04 | The default for x86_64 is hybrid | 09:57 |
| hanje04 | but you can turn it off in the VERS.a64_lnx file in tools/port/conf | 09:58 |
| cthibert | Okay. So both sets of dirs should be created in the hybrid compile? | 09:59 |
| hanje04 | sorry, wasn't clear. There are two types of hybrid, regular and reverse | 10:00 |
| hanje04 | regular is used when the compiler generates 32bit code by default but can generate 64bit, e.g Solaris | 10:00 |
| hanje04 | In this case lp64 directories are generated during the build process | 10:00 |
| hanje04 | reverse, is when the compiler generates 64bit code by default but can also generate 32bit, e.g. x86_64 Linux | 10:01 |
| hanje04 | In this case the lp32 directories get created by the build process | 10:01 |
| cthibert | Hmm, okay. Maybe regular is getting used when it should be reverse. | 10:02 |
| cthibert | I'll double check with the interested parties. | 10:02 |
| hanje04 | If you're just building PURE 64bit (i.e. no hybrid at all) you don't get either of the lpxx | 10:02 |
| hanje04 | I think I say the mail you sent | 10:03 |
| hanje04 | He's running on x86_64 from what I can tell, I'm not sure what could cause the dirs not to be created | 10:03 |
| cthibert | Yeah, Frank's leading the charge there. He's made some changes to get compatible libraries used as well. Maybe there's something there that's causing it to think it's running pure 64 bit. I'm sending an email now to ask for the specific changes again so I get a better idea of what's going on. Thanks. | 10:05 |
| ccsidiot | Hey, how do I unapply a patch? | 10:27 |
| *** grantc has quit IRC | 10:36 | |
| atrofast | ccsidiot: patch -p0 -R < patch_file | 10:44 |
| atrofast | It essentially does the opposite :) | 10:44 |
| ccsidiot | Yea, I tried that and I was silly and -R for some but not the others, now messed things up, I'll try a bit more later | 10:46 |
| atrofast | ccsidiot: You can always revert changes made if you do svn revert file | 10:47 |
| atrofast | run svn revert -R . on the root and it'll revert all files | 10:48 |
| atrofast | Just make sure you don't have changes you want to keep before running that :) | 10:48 |
| *** clach04 has joined #ingres | 10:51 | |
| hanje04 | cthibert: Get Frank to mail me directly if you want, I'll see if I can help him out | 10:54 |
| cthibert | hanje04 - Will do when I hear back from him. Thanks. | 10:56 |
| * FrankW is now available. | 11:07 | |
| *** Mud has quit IRC | 11:09 | |
| FrankW | hanje04, cthibert: the diff on my entire tree is very minimal: | 11:09 |
| FrankW | http://osgeo.pastebin.ca/1676834 | 11:09 |
| FrankW | What in the build is responsible for creating the lp32 directories? | 11:09 |
| FrankW | Should their creation show up in the log file? | 11:10 |
| hanje04 | FrankW: Those changes certainly wouldn't affect the creation of the lp32 dirs | 11:14 |
| FrankW | no, I wouldn't think so. | 11:15 |
| hanje04 | Most of them are created by the build rules in Jamrules | 11:15 |
| hanje04 | ... | 11:15 |
| *** cthibert1 has joined #ingres | 11:16 | |
| cthibert1 | Also, I think the changes to specifiy GEOS_LOC and GEOS_INC would help with the above changes as well. You could specify the 32bit location in the GEOS_LOC env var. | 11:17 |
| FrankW | cthibert1: I should svn update for those changes, right? | 11:18 |
| hanje04 | if you look for 'VERSHB' in Jamrules you'll see the hybrid specific actions | 11:18 |
| hanje04 | FrankW: Which Linux are you building on? | 11:18 |
| FrankW | Ubuntu 7.10 | 11:18 |
| cthibert1 | Not quite yet. Soon. Was just getting to submitting them actually. Give me 10-15mins and they'll be there. | 11:18 |
| FrankW | cthibert1: ok | 11:19 |
| hanje04 | FrankW: x86 | 11:19 |
| hanje04 | x86_64 (sorry) | 11:19 |
| FrankW | x86_64 | 11:19 |
| hanje04 | FrankW: OK, try the following | 11:20 |
| hanje04 | cd $ING_SRC ; jam clean | 11:20 |
| hanje04 | rm bin lib man1 | 11:21 |
| hanje04 | cd $ING_ROOT | 11:21 |
| FrankW | I've just rerun my build so I was going to let that finish. Is "runbuild.sh -c" equivelent to the cleanup you suggest? | 11:21 |
| hanje04 | rm -rf build install release tools | 11:22 |
| hanje04 | I don't know exactly what runbuild.sh -c does. It may be missing something | 11:22 |
| FrankW | ok | 11:22 |
| *** SaraDanaher has joined #ingres | 11:23 | |
| hanje04 | Clear out the stuff I mentioned above, re-run the build and send me the log if it fails. I just want to be sure it's not something left in the build causing the issie | 11:23 |
| hanje04 | issue | 11:23 |
| FrankW | ok, will do. | 11:23 |
| atrofast | Yes runbuild.sh -c does miss some things I believe | 11:24 |
| *** Mud has joined #ingres | 11:34 | |
| cthibert1 | buildtools/cleandbuild.sh does remove everything mentioned above if you're looking for a one command solution. The only thing cleanbuild leaves behind is the logs directory and the handful of generated files that jam clean leaves behind. It tries to bring it back as close to a bare svn checkout as possible. | 11:34 |
| cthibert1 | Also, the Jam changes to allow GEOS_LOC and GEOS_INC are submitted to the geospatial branch. | 11:35 |
| *** cthibert has quit IRC | 11:35 | |
| FrankW | clean build running now... | 11:38 |
| FrankW | does all that cleaning erase the lp32 directories I manually created? | 11:38 |
| hanje04 | not sure | 11:55 |
| hanje04 | looking at Jamrules, I don't think so | 12:07 |
| FrankW | I do not seem to be having the lp32 problems any more. | 12:12 |
| FrankW | I am getting some stuff like: | 12:13 |
| FrankW | Link /wrk/home/warmerda/ingres/server/build/bin/lp32/icesvr | 12:14 |
| FrankW | /usr/local/32bit/lib/libgeos_c.a(libgeos_c_la-geos_ts_c.o): In function `__static_initialization_and_destruction_0(int, int)': | 12:14 |
| FrankW | geos_ts_c.cpp:(.text+0x16f): undefined reference to `std::ios_base::Init::Init()' | 12:14 |
| FrankW | But I think I can work on that. | 12:14 |
| hanje04 | I'm going to pull the source and run a build just to see if I it any problems | 12:15 |
| hanje04 | I'll let you know what happens | 12:15 |
| FrankW | Is it possible that things got screwed up for me because on the first build geos wasn't found and various build utilities could not be linked? It seems the ingres build does not restart cleanly in some circumstances and needs a "hard clean". | 12:16 |
| FrankW | cthibert1: I've svn updated. What is the procedure for GEOS_LOC and GEOS_INC? | 12:19 |
| FrankW | Do I set these outside the build in my environment? What do they point to exactly? | 12:19 |
| cthibert1 | Yes, they are environment variables you set before the build. GEOS_LOC is expected to be the path to the geos libraries. And GEOS_INC the path to the GEOS headers. | 12:20 |
| FrankW | What about distinguishing 32bit and 64bit libraries? | 12:21 |
| cthibert1 | You may not need to set GEOS_INC if you have your headers in a standard location (/usr/local/include for example) But you could use GEOS_LOC to point to the 32 bit location. | 12:21 |
| FrankW | And it points to a directory? | 12:21 |
| cthibert1 | It doesn't stop it from looking in the standard defined locations. Basically GEOS_LOC is used in a -L arg for the linker. | 12:22 |
| cthibert1 | And GEOS_INC is a -I arg for the compiler. | 12:22 |
| FrankW | OK, in my case I was in the past forcing use of the geos .a files to avoid some additional complexities but I gather that isn't supported by the env. variables. | 12:23 |
| FrankW | I'll try it "straight" for now. | 12:23 |
| cthibert1 | Ah, I see. No, the env var is mostly there to allow non standard locations of GEOS installs, since there are users who don't have root access to install geos. After a quick view of your changes I thought this might be an alternative solution, but it looks like you're doing more than just pointing at a library location. | 12:24 |
| FrankW | Well, it may not be necessary for me to do this. | 12:25 |
| FrankW | is this something that would eventually be documented as part of src/tools/port/jam/bldenv? | 12:26 |
| FrankW | I see some notes in there about XERCES and, GTK, etc. | 12:26 |
| cthibert1 | Yes. I'd like to add some stuff in there, including default values that can be overridden. | 12:28 |
| *** SaraDanaher has quit IRC | 12:34 | |
| *** zxiiro has quit IRC | 12:56 | |
| *** cthibert1 has left #ingres | 13:01 | |
| hanje04 | FrankW: There are some situations where the build failing can cause the need for a hard clean but they're fairly rare. Stuff failing during the linking stage shouldn't be a problem. There are links and a few directories which get created by a script. If some get created and not others, the script sometimes doesn't re-run and that causes problems. | 13:27 |
| FrankW | I guess I'm just unlucky. | 13:28 |
| hanje04 | FrankW: Ah, just found tools/port/conf hbdirs.ccpp, this is a fairly new addition | 13:28 |
| hanje04 | it lists all the dirs which have an lp32 dir created in them | 13:28 |
| hanje04 | Is the directory you were having trouble with listed in that file? | 13:29 |
| FrankW | hanje04: I didn't keep close track, but there were lots. | 13:30 |
| FrankW | At first I tried manually creating them and rerunning but that didn't work well since there were so many. | 13:30 |
| FrankW | In any event, I'm past that but there may be a way of making the build more resilient in the face of this sort of thing, or better advertising "hard clean" mechanisms. | 13:31 |
| hanje04 | yeah, I'll take a look at runbuild -c and see if I can improve it | 13:32 |
| hanje04 | I think I know what caused your issue now | 13:32 |
| *** Mud has quit IRC | 13:48 | |
| *** mull has quit IRC | 14:24 | |
| *** DarylM has quit IRC | 15:27 | |
| *** toumi01 has left #ingres | 16:08 | |
| *** rossand has quit IRC | 16:14 | |
| *** mull has joined #ingres | 16:17 | |
| FrankW | The build succeeded! | 17:28 |
| FrankW | ccsidiot: Have you made good progress on your build? | 17:28 |
| ccsidiot | FrankW: Congrads! Mine doesn't go well, old errors are popping up | 17:29 |
| ccsidiot | I screwed up something playing around with the patch | 17:29 |
| ccsidiot | I can see in the repo that the patch's already been committed right? | 17:30 |
| *** mull has quit IRC | 17:30 | |
| ccsidiot | about the non-standard location thingy | 17:30 |
| FrankW | Chucks env variable patch is in the repository, yes. | 17:30 |
| FrankW | The other issue I ran into was the need to do a hard clean. | 17:31 |
| ccsidiot | Yea, I checked out from repo, and export the proper variables, old error are finding me back | 17:31 |
| ccsidiot | Like finding the geos_c.h | 17:35 |
| ccsidiot | It worked before when I first applied the patch, but not anymore after I checked out the updated code from repo after I messed up my own local copy | 17:36 |
| FrankW | Would you like me to take a look? | 17:42 |
| ccsidiot | Thanks, http://ingres.pastebin.com/d3f10244. I was trying to see if I can sort this out | 17:43 |
| ccsidiot | I guess I'm not knowledgable enough | 17:43 |
| ccsidiot | Line 272, geos_c.h not such file... | 17:44 |
| FrankW | I don't see anything obvious on line 347 which is the -I for your geos. | 17:45 |
| FrankW | Am I missing it? I presume that is the actual compile line that was used? | 17:45 |
| FrankW | This either implies Chuck's include directive stuff didn't work, or you didn't set the environment up appropriately. | 17:46 |
| FrankW | I didn't have this particular issue since my include files were in a standard location. | 17:46 |
| ccsidiot | export GEOS_LOC="/path/to/geos/libs" | 17:46 |
| ccsidiot | export GEOS_ING="/path/to/geos/headers" | 17:46 |
| ccsidiot | export LD_LIBRARY_PATH="$GEOS_LOC:$LD_LIBRARY_PATH" | 17:46 |
| FrankW | GEOS_ING? Or GEOS_INC? | 17:46 |
| ccsidiot | export XERCVERS=28 | 17:47 |
| ccsidiot | Hum, let me try INC, since that's what I got from email | 17:47 |
| ccsidiot | Hum, still building | 18:00 |
| ccsidiot | OMG!!!!!!!!!!!!!!!!!! | 18:07 |
| ccsidiot | The build succeeded! | 18:07 |
| ccsidiot | Thanks FrankW! | 18:07 |
| FrankW | ccsidiot: great news, sometimes it is the little things. | 18:28 |
| *** cytrinox_ has joined #ingres | 19:20 | |
| *** cytrinox has quit IRC | 19:37 | |
| *** cytrinox_ is now known as cytrinox | 19:37 | |
| ccsidiot | atrofast: I applied the diff but is says "can't find file to patch at input line 5", and at line 17 and so on, those are lines with "@@", why is that? | 19:51 |
| hanje04 | cssidiot: FrankW: Congrats both | 20:27 |
| *** hanje04 has quit IRC | 20:30 | |
| ccsidiot | FrankW: Thanks! | 20:56 |
| FrankW | ccsidiot: Were you able to get ingres running, create a db, etc? | 20:57 |
| ccsidiot | Oh, yea, I can see from the build messages that I need to create the dbms and stuffs. I also got an email from Andrew and Alex with a sth.diff attached to step me through this | 20:58 |
| FrankW | I haven't quite nerved myself up to do that art again. I vaguely recall it being somewhat difficult. | 20:59 |
| ccsidiot | I've worked with C and svn before, but not with such a large code base and with patchs and diffs, so currently stuck on applying the sth.diff | 20:59 |
| FrankW | patches are a hassle, and ingres is a very large source tree. | 20:59 |
| FrankW | If you want to make the patch available as a paste, I could try it here. | 21:00 |
| ccsidiot | FrankW: Thanks so much! Here is the patch Alex emailed me: http://ingres.pastebin.com/d5ad9cc97 | 21:02 |
| ccsidiot | It's stucked on every line that has @@ | 21:02 |
| FrankW | What patch command did you issue? | 21:05 |
| ccsidiot | patch -p0 < sth.diff | 21:05 |
| FrankW | I'm getting: | 21:05 |
| FrankW | warmerda@gdal64[199]% patch -p0 < ~/ingres.patch | 21:05 |
| FrankW | patch: **** Only garbage was found in the patch input. | 21:05 |
| ccsidiot | :O | 21:06 |
| ccsidiot | I got something like this | 21:07 |
| ccsidiot | http://ingres.pastebin.com/d7aeadd26 | 21:07 |
| FrankW | It looks like you are just having path problems. | 21:08 |
| FrankW | Hmm, I take that back, it doesn't seem to be picking up much properly. | 21:08 |
| FrankW | i just generated a small svn diff patch and the diff lines look more like: | 21:09 |
| ccsidiot | For every line in the sth.diff file that has @@ | 21:09 |
| FrankW | --- README.txt (revision 2240) | 21:09 |
| FrankW | +++ README.txt (working copy) | 21:09 |
| FrankW | @@ -1,5 +1,7 @@ | 21:09 |
| FrankW | + | 21:09 |
| ii_log` | FrankW: Error: "@" is not a valid command. | 21:09 |
| ccsidiot | then there's error | 21:09 |
| FrankW | I wonder if your email client is stripping some of the "@" signs or something. | 21:09 |
| ccsidiot | Even the file is sent as attachment? | 21:10 |
| FrankW | It does seem odd. | 21:10 |
| FrankW | I add "@@" at the beginning of each line ending with "@@" and it applied ok. | 21:10 |
| ccsidiot | Wow, never know about that | 21:11 |
| ccsidiot | Let me try too | 21:11 |
| ccsidiot | :) | 21:11 |
| ccsidiot | So for every line that looks like this " -729,6 +729,7 @@", should change it to "@@ -729,6 +729,7 @@" | 21:13 |
| FrankW | That's what I did. | 21:13 |
| FrankW | Though I must confess the second part of the adupoint.c change did not apply properly for some reason. | 21:13 |
| * FrankW hates patching. | 21:16 | |
| FrankW | ok, it's working right now. | 21:17 |
| FrankW | I was getting messed up by some sort of active diff editing mode in emacs. | 21:17 |
| FrankW | http://osgeo.pastebin.ca/1677448 is my slight variation. | 21:18 |
| ccsidiot | Hum, how come same error :( | 21:18 |
| ccsidiot | I added @@ for every single line that ends with @@ | 21:18 |
| FrankW | warmerda@gdal64[229]% patch -p0 < ~/ingres.patch | 21:18 |
| FrankW | patching file src/common/adf/adu/aduerror.c | 21:18 |
| FrankW | patching file src/common/adf/adu/adupoint.c | 21:18 |
| FrankW | patching file src/common/hdr/hdr/adf.h | 21:18 |
| FrankW | patching file src/common/hdr/hdr/eradf.msg | 21:18 |
| ccsidiot | Since that file has name sth.diff, so I need to rename that into sth.patch before I can apply? | 21:19 |
| FrankW | I do not believe the extension matters. | 21:20 |
| FrankW | Particularly since we are redirecting it so patch can't even tell what the filename was. | 21:20 |
| ccsidiot | Okay, patch -p0 < sth.diff gives me those errors | 21:21 |
| ccsidiot | same, complaining about those @@ | 21:21 |
| FrankW | Using http://osgeo.pastebin.ca/1677448 ? | 21:21 |
| FrankW | You are doing this from the directory above "src"? | 21:22 |
| ccsidiot | Yes | 21:22 |
| ccsidiot | No | 21:22 |
| ccsidiot | I'm doing that under src with the code that you've pasted | 21:22 |
| FrankW | since the paths refer to src/... I think you need to run patch one directory above "src". | 21:23 |
| FrankW | At least that is what I did. | 21:23 |
| ccsidiot | Oh I see | 21:24 |
| ccsidiot | :) | 21:24 |
| ccsidiot | Yay | 21:25 |
| ccsidiot | ! | 21:25 |
| ccsidiot | So end up in the end don't you guys have all those patches flying around in the local source tree copy? | 21:28 |
| FrankW | I often have several patches sitting around in my tree, but seldom send them to folks as diffs. | 21:29 |
| FrankW | I normally just apply and review them with svn commands. | 21:29 |
| FrankW | But there are definately open source developers who sling patches around left and right. | 21:30 |
| ccsidiot | I see :) | 21:30 |
| ccsidiot | Next: Createdbms and createdb | 21:32 |
| ccsidiot | Wow, it's already 12.32 ! | 21:32 |
| *** Alex| has joined #ingres | 22:39 | |
| *** ChanServ sets mode: +o Alex| | 22:39 | |
| *** grantc has joined #ingres | 22:55 | |
| *** ChanServ sets mode: +o grantc | 22:55 | |
| *** Alex| has quit IRC | 23:15 | |
| *** ccsidiot has left #ingres | 23:39 | |
| *** Alex| has joined #ingres | 23:43 | |
| *** ChanServ sets mode: +o Alex| | 23:43 | |
| *** Mud has joined #ingres | 23:55 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
