| | <<<Back 1 day (to 2015/08/26) | 20150827 |
| Robin_Watts | chrisl: Did you see pipitas comments from yesterday? | 08:11.26 |
| kens | Robin_Watts : chrisl gave the answer too | 08:11.38 |
| | and pipitas was OK with it | 08:11.44 |
| Robin_Watts | kens: Fab. | 08:12.01 |
| | One possible slight niggle... when he built with --with-libiconv=gnu, it gave pipitas warnings that it was excluding the devices due to iconv not being found - but didn't exclude the devices. | 08:12.55 |
| kens | I didn't notice that one# | 08:13.09 |
| Robin_Watts | (if I'm understanding it correctly) | 08:13.10 |
| | I guess that could be fixed either by really excluding the devices, or by changing the messages to "your build will fail due to iconv being missing" | 08:13.43 |
| chrisl | Robin_Watts: he said he used --with-libiconv=none - I didn't see any mention of --with-libiconv=gnu | 08:54.46 |
| Robin_Watts | chrisl: His pastebin showed libiconv=gnu | 08:55.23 |
| chrisl | Well, that won't work anyway | 08:55.58 |
| Robin_Watts | In what way will it not work? | 08:57.22 |
| chrisl | Does OS X use glibc? | 08:57.35 |
| Robin_Watts | I dunno. | 08:57.45 |
| | Regardless, there does seem to be a problem. | 08:57.58 |
| chrisl | No, there isn't | 08:58.05 |
| Robin_Watts | However he runs configure, it then says: | 08:58.09 |
| | configure: WARNING: Unable to include opvp/oprp driver due to missing or disabled prerequisites... | 08:58.25 |
| | configure: WARNING: Unable to include opvp/oprp driver due to missing iconv/libiconv... | 08:58.27 |
| | which seem like perfectly reasonable warnings. | 08:58.36 |
| | *BUT* the link stage tries to include opvp anyway. | 08:59.02 |
| | So the warning is lying. | 08:59.16 |
| chrisl | Not for me..... | 08:59.20 |
| Robin_Watts | Would him not 'make clean'ing between configures explain what he saw? | 09:00.29 |
| chrisl | Likely. yes. It probably left "stale" .dev files lying around | 09:01.06 |
| | I've noticed that kind of issue, which baffles me because *everything* should depend on the top makefile | 09:02.01 |
| Robin_Watts | Windows makes .ldt files or something like that that have the link line in. | 09:02.26 |
| chrisl | The linker scripts do get remade, it's the .dev files that *seem* to show the problem | 09:03.17 |
| Robin_Watts | hm. It's the linker scripts I've had problems with before, IIRC. | 09:03.45 |
| | but then the reliability of my memory is well documented, so... | 09:04.16 |
| chrisl | I *think* I fixed those - the reason I haven't sorted the .dev files problem is that I don't know what the problem is.... | 09:04.31 |
| | But, in general, rerunning configure and *not* doing a make clean is a bad idea | 09:05.23 |
| | Actually, we do have *lots* of targets that don't depend on their own makefiles, nevermind the top level makefile :-( | 09:08.21 |
| | I'll look at that properly - *after* the next release...... | 09:09.55 |
| | Apple appears to use a BSD derived libc, not glibc | 09:14.35 |
| kens | Hmm teh cluster isn't very happy today | 09:33.02 |
| | and it died again | 09:55.39 |
| sebras | tor8: was the thirdparty/jpegxr repo I prepared to your satisfaction? | 09:56.13 |
| Robin_Watts | kens: AWS claims to be fine... | 09:57.14 |
| kens | connections keep droping | 09:57.33 |
| Robin_Watts | And the load average on casper is fine. | 09:57.39 |
| | kens: yeah, just checking possible reasons, and I can't see anything obvious :( | 09:57.55 |
| | Does a vanilla run have the same problems ? | 09:58.03 |
| kens | yes, its all the same | 09:58.09 |
| Robin_Watts | The clustermaster.pl process dates from 12 minutes ago... | 10:00.01 |
| | so that might suggest that something crashed and reran ? | 10:00.16 |
| kens | It does seem to be genuine connectivity problems | 10:00.19 |
| | sometimes one noce, sometiems lots | 10:00.27 |
| | and someteimes, it works | 10:00.33 |
| | Robin_Watts : it reruns when it gives up yes | 10:00.49 |
| Robin_Watts | Maybe it's an emerging amazon problem and they haven't logged it yet. | 10:00.52 |
| kens | Tat is possible, I guess | 10:01.01 |
| Robin_Watts | kens: The job reruns, certainly. I'm not sure the clustermaster.pl process should do though. | 10:01.13 |
| kens | no idea, to be honest | 10:01.29 |
| | 12 minutes ago is roughtly when I submitted ths test | 10:01.55 |
| | 09:47 UTC | 10:02.12 |
| Robin_Watts | I think the clustermaster.pl thing may run on an cron job; it starts up, sees if there is one already running (and if so dies), and if not, checks to see if there is anything to do. | 10:03.26 |
| | So, it's possible clustermaster dies when the cluster is idle. | 10:03.39 |
| | Or it's possible it doesn't :) | 10:03.45 |
| kens | Err perhaps :-) | 10:03.54 |
| Robin_Watts | There are bits of the cluster that are still a mystery to me. | 10:03.56 |
| kens | Its all a black box to me | 10:04.06 |
| | I wouldn't worry about it, unless it gets worse | 10:04.34 |
| | Its just typical that it happens when I need the cluster :-) | 10:05.02 |
| tor8 | sebras: I haven't received any patches from you for jpegxr. where is the repo you prepared? | 10:48.15 |
| | sebras: nvm, found it. looks good, I've pushed that to the main thirdparty repository. | 13:03.37 |
| henrys | chrisl: I should have something that will work for COMPILE_INITS = 0 today. | 13:21.54 |
| paulgardiner | I believe I've fixed MuPDF's bug #696123, but I have no recollection how to cluster test | 14:22.29 |
| Robin_Watts | git cluster | 14:22.39 |
| | If you've set the appropriate git alias. | 14:22.51 |
| paulgardiner | I have it split amongst several commits. Does that matter? | 14:24.08 |
| Robin_Watts | nope. | 14:24.24 |
| | casper has a load average of 8.4. Ouch. | 14:28.21 |
| | 10.6. | 14:28.25 |
| henrys | Robin_Watts: I'd like gslibctx.c better if we passed the gs_lib_ctx_t instead of gs_memory_t so folks will never use the latter when changing the code, but gs_lib_ctx_get_default_device_list() indicates the context may not exist. Do you recall the circumstances of why we need that check for "mem" in that procedure? | 14:29.07 |
| | Robin_Watts: I guess it's really not a necessary changs, just seems confusing to have 2 memory pointers to choose from | 14:29.50 |
| Robin_Watts | I agree it would be nicer to use gs_lib_ctx. Let me look. | 14:30.11 |
| | I'm going to refer you to chrisl for an answer on that one though, I think. | 14:30.51 |
| henrys | right, I didn't check that ;-) | 14:31.39 |
| Robin_Watts | henrys: I can only see gsapi_get_default_device_list called from one place, and that gets the context, and then gets the memory from the context, so passing the context would be more direct. | 14:36.35 |
| | Presumably chrisl knows of other uses. | 14:36.46 |
| henrys | Robin_Watts: thanks, it might have also been a stopgap in his large change that isn't relevant anymore. We'll see. | 14:38.22 |
| chrisl | henrys: so, traditionally, it's been memory pointers that have been passed around in the graphics library, rather than the gs_lib_ctx | 14:43.59 |
| henrys | chrisl: so you don't agree with what we said above? I think it's going to be error prone the way it is now. | 14:46.38 |
| | but not a big deal | 14:46.45 |
| chrisl | henrys: I wasn't disagreeing, just pointing out. I really have only hammered Robin's stuff so it will build and run (gs anyway), I haven't made any progress on twisting it to my own preferences | 14:48.23 |
| Robin_Watts | chrisl: I believe this is about golden/master, not language_switch. | 14:49.05 |
| henrys | chrisl:sorry yes this is in the current code. Running pcl with a new profile directory does crash the code. Not sure when that regressed. | 14:50.06 |
| chrisl | Oh, okay, sorry..... well, as I said, everywhere else in the graphics library we pass around a memory pointer - I don't agree with that original decision, but I think adding inconsistency is not going to make it *less* error prone..... | 14:50.46 |
| henrys | chrisl: the issue is the context library must use it's own allocator and not use the one that is passed in. | 14:51.34 |
| Robin_Watts | I think that the graphics lib should continue to pass gx_memory_t's. | 14:53.17 |
| | But when we call gs_lib_ctx_.... we should be finding the lib_ctx from the memory_t and passing that in. | 14:53.55 |
| chrisl | henrys: I still think consistency trumps logic in terms of avoiding confusion | 14:54.24 |
| henrys | chrisl: okay well I have a simple fix for my crash that doesn't change the parameters so I'll use that for now. | 14:56.04 |
| | I'm not even looking at the language switch yet. I'm going to get the current PCL acting more like gs at startup (I'll do that incrementally) then we'll look at LS. | 14:56.48 |
| Robin_Watts | Paul: Your deep copy doesn't copy strings. | 14:59.24 |
| | henrys: You might want to just check what I've done in case when you arrive where gs is, you find that language_switch has moved the goalposts :) | 15:00.06 |
| paulgardiner | It doesn't need to for the current use, but maybe it should | 15:00.15 |
| | We have functions that alter strings? | 15:00.41 |
| henrys | Robin_Watts: I did I have them running side by side. | 15:00.42 |
| chrisl | henrys: ah, I see your original question was to Robin: I can't remember why I have gs_lib_ctx_get_default_device_list() checking the mem pointer existing - possibly just belts and braces | 15:01.24 |
| Robin_Watts | paulgardiner: I don't know. | 15:04.00 |
| | Possibly not. | 15:04.11 |
| | I suspect not actually, you're probably fine. | 15:04.46 |
| henrys | chrisl: seems like that is more "assertion like" than a test but no big deal if we aren't changing the parameter | 15:04.56 |
| chrisl | henrys: so, what was causing the crash? | 15:05.36 |
| | henrys: oh, and by the way, gs_lib_ctx_get(set)_default_device_list are really "internal API" calls. Normally, users of the GS API would call the gsapi version | 15:08.45 |
| henrys | chrisl: oh that's interesting: the lib context allocates space for the icc directory with gs's initial allocator as part of gs_malloc_init() then pcl wraps the allocator with the chunk allocator, when the icc profile directory is changed lib context frees the directory string with the chunk allocator's free, not the original allocators free. So we really do have a special case here in the allocator where it's important folks not use | 15:09.22 |
| | the input mem parameter within lib context. | 15:09.22 |
| | the last "allocator" should be replaced with "lib context" | 15:10.20 |
| | that is why I wanted to remove the parameter so there is no chance of it being used. | 15:11.32 |
| chrisl | henrys: I agree that makes sense, but are you going to do the same everywhere else the same confusion could arise? | 15:12.11 |
| henrys | not today | 15:12.24 |
| | we can leave it, no big deal for me. | 15:12.48 |
| chrisl | If we were starting from (near) scratch, I would rather pass the context around everywhere, but...... | 15:13.08 |
| | henrys: perhaps ctx->profiledir should be a structure with the string, length and allocator pointer in it | 15:15.25 |
| henrys | is worried about testing: 2 regression crashes - pcl with no device parameters and the iccdirectory should have been caught by automated testing. | 15:16.35 |
| | of course hindsight is 20/20 | 15:17.09 |
| chrisl | I doubt we regression test with a "custom" ICC directory | 15:17.37 |
| | Oh, I think maybe I do remember why gs_lib_ctx_get_default_device_list() checks for mem....... | 15:18.24 |
| | Passing in mem == NULL guarantees a way of getting back the graphics library's build time list | 15:20.34 |
| Robin_Watts | chrisl: passing in a NULL lib_ctx could still do the same. | 15:22.22 |
| henrys | is ray on vacation and I missed an email? | 15:23.47 |
| chrisl | Robin_Watts: Yes, I just meant I'd done it so there was a way to get it | 15:24.02 |
| Robin_Watts | henrys: Ray sent a mail around saying he'd be missing tuesdays meeting for a medical thing. | 15:24.38 |
| chrisl | I wasn't justifying using gs_memory_t - that was purely for consistency | 15:24.42 |
| Robin_Watts | I haven't seen him since. | 15:24.44 |
| | chrisl: sure. | 15:24.48 |
| henrys | Robin_Watts: yeah I got that, hope all is well. | 15:25.24 |
| Robin_Watts | I hope we shouldn't be reading anything bad into his absence. | 15:25.30 |
| | Morning rayjj. | 17:10.58 |
| sh4rm4^bnc | i'm crosscompiling ghostscript and there are 2 C files that are built with a wrong include path | 17:59.09 |
| | -I/include -o ./soobj/gsicc_lcms2_1.o -c ./base/gsicc_lcms2.c | 17:59.14 |
| | -I/include -o ./soobj/gsicc_create_1.o -c ./base/gsicc_create.c | 17:59.22 |
| | can someone point out the makefile rule that builds these 2 files with different CFLAGS, pulling in -I/include (which is the host's and wrong) ? | 18:00.03 |
| rayjj | Robin_Watts: morning (sorry I was in a debug session) | 18:00.20 |
| sh4rm4^bnc | (usually stuff like this is caused by bogus *-config scripts such as freetype-config) | 18:00.53 |
| Robin_Watts | sh4rm4^bnc: Looking now. | 18:01.00 |
| sh4rm4^bnc | thanks | 18:01.05 |
| Robin_Watts | rayjj: I hope tuesday went OK. | 18:01.15 |
| | sh4rm4^bnc: It's in base/lib.mak... | 18:02.10 |
| | It's probably the definition of GLLLCMS2CC that's incorrect. | 18:02.39 |
| sh4rm4^bnc | "GLLLCMS2CC" not found | 18:03.34 |
| Robin_Watts | GLLCMS2CC, sorry | 18:03.51 |
| | sh4rm4^bnc: The person who is best placed to handle this is chrisl, and he's gone for the night. | 18:04.35 |
| | It would help us immensely if you could do a clean, then reconfigure, the make, and drop the output from all of that into a pastebin. | 18:05.09 |
| | That would ensure that chrisl has the right information to be able to fix it when he returns tomorrow. | 18:05.28 |
| sh4rm4^bnc | build log http://sprunge.us/agAK | 18:07.34 |
| | recipe https://github.com/sabotage-linux/sabotage/blob/b6b2658a49ef4d20a2e385589e4a5d548ab93912/pkg/ghostscript | 18:07.57 |
| | the build of the above mentioned 2 files pulls in host's /include which contains 64bit headers | 18:09.27 |
| | so it likely produces horribly broken obj's | 18:09.52 |
| Robin_Watts | sh4rm4^bnc: I'm guessing that $(LCMS2SRCDIR) is not being set. | 18:11.11 |
| | hence $(II)$(LCMS2SRCDIR)$(D)include$(_I) is turning into -I/include | 18:11.32 |
| sh4rm4^bnc | that sounds plausible | 18:12.14 |
| Robin_Watts | Are you using code from our git repo? Or from a release from us? Or from a package you got from a distro? | 18:12.15 |
| rayjj | Robin_Watts: Tuesday was fine. Monday night wasn't fun. Results are good, just waiting for pathology on the parts they removed (polyps) | 18:12.34 |
| sh4rm4^bnc | i use the 9.16 release and trying to fix the x-compile of sabotage linux' recipe | 18:12.50 |
| Robin_Watts | rayjj: Glad to hear it's looking good. | 18:13.03 |
| rayjj | Robin_Watts: the doc that did it has done about 35,000 of these and he thinks they are fine. Two of the other doctors there said that he's the best in the department (UCI Medical Center) and they have him do their procedures | 18:13.49 |
| Robin_Watts | sh4rm4^bnc: If it was me, I'd nobble the line in lib.mak that sets GLLCMS2CC and change $(II)$(LCMS2SRCDIR)$(D)include$(_I) to $(II)FOO$(LCMS2SRCDIR)BAR$(D)include$(_I) | 18:14.23 |
| | and then rebuild, and see if the compile line comes out as -IFOOBAR/include | 18:14.42 |
| | If it does, then we know that we're in the right area. | 18:14.52 |
| sh4rm4^bnc | lcms2 is installed in the crosscompiler prefix | 18:14.57 |
| | how can i make it pick up the system one ? | 18:15.08 |
| Robin_Watts | sh4rm4^bnc: We don't recommend people using shared libs. | 18:15.30 |
| sh4rm4^bnc | why ? | 18:16.10 |
| Robin_Watts | because we test with our versions. | 18:16.28 |
| rayjj | Robin_Watts: I've removed the last vestiges of the compressed_color encoding. pdf14 had it sort of messily hooked in, and I wanted to clean up the pdf14 device before the hacking on it for SimulateOverprint usage | 18:16.31 |
| Robin_Watts | rayjj: Oh, is the simulated overprint stuff not done? | 18:16.55 |
| rayjj | Robin_Watts: I'm running a regression now, but you might be the best person to review since mvrhel is out | 18:17.07 |
| Robin_Watts | I thought the driving force for that was gproof. | 18:17.20 |
| | sh4rm4^bnc: I think I would expect LCMS2SRCDIR to be set in Makefile. | 18:18.00 |
| rayjj | Robin_Watts: no, the gproof is a real DeviceN device since we wanted to have the separations for the viewer side | 18:18.08 |
| Robin_Watts | If it's not being set, then that would explain what you're seeing I think. | 18:18.14 |
| rayjj | the simulation is for non-DeviceN devices to be able to see the overprint effects collapsed into the Gray, RGB or CMYK device | 18:18.53 |
| Robin_Watts | rayjj: Mvrhel forms the rgb data from the cmyk+spots, I think. | 18:19.05 |
| | Will that be correct w.r.t simulated overprint ? | 18:19.19 |
| rayjj | Robin_Watts: right, but the gproof device also emits the separation planes | 18:19.35 |
| Robin_Watts | Right. | 18:19.39 |
| | the gproof device needs BOTH an rgb version that is correct w.r.t overprint, AND the separation planes. | 18:20.05 |
| rayjj | The RGB from CMYK+spots will be correct w.r.t overprint | 18:20.08 |
| Robin_Watts | Great | 18:20.13 |
| | (apologies for asking newbie questions) | 18:20.20 |
| | rayjj: Sure, I'll look at the code. Is it on your repo? | 18:20.48 |
| rayjj | Robin_Watts: np. Effectively, the RGB should look just like the tiffsep CMYK converted to RGB | 18:20.51 |
| | Robin_Watts: not yet, I'll let you know. I wanted to run the cluster first to see if it blows up anything | 18:21.24 |
| Robin_Watts | sure. | 18:21.29 |
| rayjj | since it does touch some GC enumerated structures | 18:21.45 |
| | looks like no SEGV's that's good. but I got a bunch of diffs (I didn't have some of ken's recent changes) bmpcmp will probably discover lots of 'no differences' since I've now updated | 18:31.32 |
| sh4rm4^bnc | Robin_Watts, your suggested change does indeed yield -IFOOBAR/include | 18:37.46 |
| | and fixes the problem as -IFOOBAR not exists | 18:37.59 |
| Robin_Watts | sh4rm4^bnc: So... have a grep for GSLCMS2SRCDIR | 18:41.34 |
| | see if it's set in Makefile | 18:41.42 |
| | If not, then perhaps that is a bug with configure. | 18:41.54 |
| sh4rm4^bnc | ~/x-prefix/i486/src/build/ghostscript/ghostscript-9.16 $ cat Makefile | grep GSLCMS2SRCDIR | 18:44.02 |
| | ~/x-prefix/i486/src/build/ghostscript/ghostscript-9.16 $ | 18:44.02 |
| | it appears to be missing | 18:44.21 |
| Robin_Watts | ok, so add a line into Makefile now that sets it, and that should solve your problem for now. Then come back in about 16 hours time and talk to chrisl :) | 18:44.44 |
| sh4rm4^bnc | ok | 18:49.01 |
| | thanks so far, i think i'll commit my sed foobar fix for now | 18:49.50 |
| henrys | another crash if I set the pcl font path to a bad directory the enumeration stuff blows up ... ugh | 18:52.52 |
| sh4rm4^bnc | btw base/genarch base/genconf base/echogs need to be compiled with $HOSTCC rather than $CC | 18:54.59 |
| | because if compiled with the crosscompiler, the resulting binaries cannot be run on the host | 18:55.34 |
| rayjj | sh4rm4^bnc: yep, that makes sense | 18:56.11 |
| | sh4rm4^bnc: the cross compile build used to work, before all of the re-org | 18:56.41 |
| | I know because I did some for potential customers | 18:57.20 |
| sh4rm4^bnc | including all the third party libs in the source tree introduces a ton of complexity for little gain... | 18:58.15 |
| rayjj | sh4rm4^bnc: but genarch is problematic since running that on the host WON'T give the right arch.h for the target | 18:58.24 |
| sh4rm4^bnc | i understand that it is helpful for windows folks... | 18:58.29 |
| rayjj | sh4rm4^bnc: either arch.h should be hand built, or genarch needs to be built for the target and run there | 18:59.22 |
| sh4rm4^bnc | but on unix systems it's common practice to use (and require) the libs to be installed in the right version | 18:59.24 |
| | rayjj, oh | 18:59.44 |
| rayjj | sh4rm4^bnc: the problem with the third party libs is that distros don't always take needed fixes in a timely fashion and we test with our versions | 19:00.40 |
| sh4rm4^bnc | so the in-tree copies are patched ? | 19:01.02 |
| rayjj | sh4rm4^bnc: possibly. It depends. The git would tell you if we have patches | 19:01.38 |
| | openjpeg was particularly troublesome, iirc w.r.t getting the distro versions to have the patches we needed | 19:03.03 |
| sh4rm4^bnc | hmm in that case it may indeed make sense... but i doubt that all the included copies need patching | 19:04.10 |
| | like expat, freetype, lcms, libpng, libtiff... | 19:04.22 |
| | if all the libs are taken from the in-tree copies, we have a huge duplication of compiletime | 19:06.17 |
| | and later a huge waste of unsharable memory | 19:06.29 |
| rayjj | and some of our users don't have the permissions to update their systems, but still want to build our stuff. Then there are the Windows users (as you mentioned) where none of these are readily available | 19:06.51 |
| sh4rm4^bnc | rather than using the existing mmapped libpng.so, ghostscript has to load its own (static?) copy | 19:07.01 |
| rayjj | sh4rm4^bnc: shared libs are still OK, I thought. The distros insist on it. | 19:07.49 |
| | sh4rm4^bnc: AFAIK, if the configure script detects the third party libs and if the version is OK for our purposes, uses it (the Makefle has the SHARE_*=1 for those that will be shared) | 19:15.27 |
| sh4rm4^bnc | ah nice | 19:31.29 |
| | Forward 1 day (to 2015/08/28)>>> | |
IRC Logs