| | <<<Back 1 day (to 2012/08/02) | 2012/08/03 |
| ray_laptop | mvrhel: I don't see any SEGV with bug 693185 (Signal.pdf) is run with 14 DeviceN component limit. True the error message is bogus (reports "Error reading a content stream. The page may be incomplete." then the "File has unbalanced q/Q operators (too many q's)" which doesn't really indicate the problem | 00:59.14 |
| | mvrhel: but it looks like it is "safely" avoiding an out of array bounds usage | 00:59.56 |
| | I'm going to open a bug and assign to Alex so that he can look into getting a better error message out when we get the limitcheck from trying to set a DeviceN space | 01:00.58 |
| | It is processing an image (or trying to) that has the colorspace with 17 components. | 01:11.39 |
| | This problem is wrapped up in the change to the PDF interp to not stop on errors. With -dPDFSTOPONERROR we get a MUCH more reasonable "Error: /limitcheck in --run--" | 01:18.42 |
| | so in trying to continue from the thing we can't handle, we proceed to get quite confused and give a confusing error message | 01:19.30 |
| | mvrhel: so I see no reason that we should have MAX_COMPONENTS_IN_DEVN set to less than GS_CLIENT_COLOR_MAX_COMPONENTS | 01:35.32 |
| mvrhel | ray_laptop: no one said there was a SEGV | 02:32.55 |
| | just that there were colors missing in the output | 02:33.03 |
| | I agree that the message we gave was essentially of no help | 02:33.52 |
| | ray_laptop: I think we should have this structure dynamically allocated myself rather than a hard limit | 02:34.27 |
| | ray_laptop: updated the documentation for tiffsep and added the little suggestion to use -dMaxSpots when we run into the limit (that is this is displayed when you run the code) | 03:40.43 |
| ray_laptop | mvrhel: I reopened bug 693185 (for alexcher) to address the confusing error message, and also am testing a fix for array bounds violation if GS_CLIENT_COLOR_MAX_COMPONENTS > MAX_COMPONENTS_IN_DEVN | 06:36.50 |
| | (basically use MAX_COMPONENTS_IN_DEVN in the limitcheck test and add strong comments about the invariant required) | 06:37.35 |
| | kens must be sleeping in ;-) (he's usually around by now) | 06:40.40 |
| NaHCo3 | hello | 06:50.43 |
| ghostbot | niihau | 06:50.43 |
| ray_laptop | hi, bicarb | 06:56.32 |
| | oops -- he left | 06:56.55 |
| | tkamppeter: I committed a patch to remove icclib (commit d8ca80d) -- please have a look and see if I missed anything. I'm not sure if all will agree to cherry picking this into 9.06, however | 06:58.24 |
| | if I feel particularly sour, I should change my nick to C2H4O2 ;-) | 07:00.41 |
| | OK, committed (minor) patch for MAX_COMPONENTS_IN_DEVN. Not verified, but I think that DeviceN with > 32 components would have accessed outside array bounds. | 07:05.47 |
| | mvrhel: I already, committed it, but please let me know if you see anything screwed up about it. | 07:06.25 |
| | chrisl is going to regret going on holiday just before release -- we now have a mess of patches to discuss cherry picking. :-/ | 07:07.49 |
| kens | I'm against including the icclib patch, its huge | 07:08.18 |
| | But I haven't finished reading the logs yet | 07:08.44 |
| ray_laptop | tkamppeter: please weigh in on the icclib removal if you feel strongly, but I tend to agree with kens that it is not important | 07:08.45 |
| | tkamppeter: but thanks for bringing it to our attention | 07:09.00 |
| kens | One day we will get rid of teh AFS font code too.... | 07:09.17 |
| ray_laptop | kens: the only one I think are important are 974ba5d, cfbd3fa and a884b57 (since those affect one of our more noisome customers) | 07:11.18 |
| | kens: I'd also like to get rd of jasper | 07:11.37 |
| kens | Is that still in there ? We should put it out of its misery | 07:12.12 |
| | IMO topics for the next release. | 07:12.26 |
| ray_laptop | kens: maybe I'll go ahead and rip out jasper (since we don't have to cherry pick it for this release) | 07:13.04 |
| kens | I think that's an excellent idea ray_laptop. May as well get rid of unused stuff while we remember its till there | 07:13.32 |
| sebras | Robin_Watts: I think ghostbot might have scared off NaHCo3... :) | 07:13.34 |
| tkamppeter | ray_laptop, generally, it is not so important as the presence or absence of the patch does not change the binary files resulting from the build, but it should be written both in the Release Notes/What's New in 9.06 and in the general installation documentation that icclib is not needed (any more) for building GS, so that distro packages know to drop any dependencies on libicc in their packages. | 07:31.23 |
| kens | I'm pretty sure chrisl will be happier with documenting the fact that it is not required than removing it in this release. | 07:32.03 |
| | I'll send him an email and ask him to make the documentation change if that is sufficient Till. | 07:32.23 |
| tkamppeter | ray_laptop, I also had a look into the patch. It is huge but it seems to be rather harmless regression-wise. Most of it is removal of the files in icclib and the rest is removal of variables in Makefiles. | 07:32.32 |
| kens | Note that he is on vacation today. | 07:32.32 |
| | tkamppeter : I agree with what you say completely. nevertheless, its a large change to apply after the rc1 candidate. While I don't believe thre will be any adverse side effects, I'm not confident about such a change. | 07:33.19 |
| | You cna try and persuade chrisl to adopt the change but I'm doubtfull he will want to at this stage | 07:33.48 |
| | Bear in mind that we are trying to hit the release date for Ubuntu's next release, and we have a number of people taking vacation time this month | 07:34.15 |
| ray_laptop | kens: I'm running a regression on my jasperrectomy | 07:35.49 |
| tkamppeter | kens, OK, let's go with my first message then. | 07:35.58 |
| kens | tkamppeter : Just writing mail to chrisl now, I'll direct him to the IRC logs as well, for his consideration. | 07:36.25 |
| ray_laptop | tkamppeter: a minor change to note that icclib.so is no longer needed seems reasonable | 07:36.31 |
| | tkamppeter: the same with jasper (is there a .so for that ?) | 07:36.51 |
| tkamppeter | ray_laptop, yes, as I suggested in my first message. | 07:37.05 |
| | ray_laptop, kens, I get | 07:38.57 |
| | till@till-desktop:~$ ldd /usr/lib/libgs.so.9.06 | grep jasp | 07:39.01 |
| | libjasper.so.1 => /usr/lib/x86_64-linux-gnu/libjasper.so.1 (0x00007f4f0a25a000) | 07:39.01 |
| | till@till-desktop:~$ | 07:39.01 |
| | What is wrong? Does Ghostscript's build system link Ghostscript with a lib which it does not actually use? | 07:39.47 |
| kens | That sounds 'odd'. | 07:39.58 |
| tkamppeter | ray_laptop, kens ^^ | 07:40.01 |
| kens | I'm fairly certain we don't use JasPer any more, maybe we still did in 9.05 ? | 07:40.16 |
| ray_laptop | tkamppeter: gs uses openjpeg now, so libjasper is (also) no longer needed | 07:40.17 |
| | tkamppeter: you are saying that it still shows up as used with 9.06 | 07:41.52 |
| tkamppeter | ray_laptop, it is not linked against openjpeg, does it mean that I have lost features and need to change the ./configure command line? | 07:41.59 |
| kens | I don't remember when the change to OpenJPEG was done, it may not have been in 9.05 | 07:42.31 |
| | But the use of OpenJPEG is certainly superior to using JasPer | 07:42.48 |
| ray_laptop | I thought the configure (not an expert on configure.ac) only used jasper if openjpeg wasn't available | 07:42.53 |
| | tkamppeter: the ./configure script is generated (AFAIK) from autoconf and the configure.ac -- maybe chrisl didn't regenerate it for the rc1 ??? | 07:44.12 |
| | makefiles are bad enough -- autoconf files are something that I consider obsolete enough to leave to those that have had to delve into it (at least until I have to git dirty) | 07:45.46 |
| tkamppeter | ray_laptop, on the system where I have built, openjpeg was not installed. So I have to build again. Is external openjpeg in GS 9.06 supported? | 07:46.04 |
| ray_laptop | tkamppeter: I hope not ;-) | 07:46.42 |
| kens | chrisl is the expert but.... I believe it is in teh same way as other third party libraries | 07:46.58 |
| ray_laptop | is NOT a fan of (who knows whatever) shared lib is installed | 07:47.18 |
| tkamppeter | ray_laptop, kens, so I will simply do a build test. | 07:47.34 |
| | ray_laptop, kens, is the jasper support still in the source? Or is the JPEG 2000 support dropped when ./configure falls back to Jasper? | 07:48.38 |
| ray_laptop | tkamppeter: as we've often pointed out, the shared libs often need fixes that WE find, that the upstream either won't take, or the user doesn't update when they get our release | 07:48.43 |
| | our regression testing and user/customer support is superior to that done by many shared lib packages | 07:49.30 |
| kens | tkamppeter : I don't know if JasPer support is still possible, I imagine it is but Alex did the change and he is not online for several hours | 07:49.34 |
| ray_laptop | tkamppeter: in the 9.06, jasper is still there -- I am testing a patch to rip out jasper (that and removing icclib probably won't make it into 9.06). | 07:50.38 |
| | tkamppeter: note, however, that jasper problems and performance were bad enough that we no longer support it and openjpeg SHOULD be the preference and be a precursor for ghostscript | 07:51.57 |
| | tkamppeter: I assume that when packaging gs, you can add openjpeg as a pre-requisite ? | 07:52.37 |
| | tkamppeter: and remove libjasper (if it is there). At the least, that should be done for 9.06 | 07:53.28 |
| | tkamppeter: also, lcms2 is preferred over lcms | 07:58.07 |
| tkamppeter | ray_laptop, I am test-building the package with switch to libopenjpeg now. | 08:01.05 |
| ray_laptop | tkamppeter: great ! | 08:01.14 |
| tkamppeter | ray_laptop, the transition from liblcms to liblcms2 I did already in Ubuntu Precise (12.04 LTS). | 08:01.36 |
| ray_laptop | tkamppeter: note that we won't REQUIRE openjpeg (vs. jasper) in 9.06, but the next release won't support it, nor need icclib, and _may_ REQUIRE lcms2 (that's up to mvrhel) | 08:02.26 |
| | tkamppeter: we generally 'bridge' over to new libs/tools so that the old lib is still usable for at least one version | 08:03.55 |
| tkamppeter | ray_laptop, do you document somewhere what fixes/patches/hacks you do on the copies of the libraries which you ship in your source tarball? | 08:05.20 |
| ray_laptop | tkamppeter: well, since we have our own copies of all of the lib sources, our git log will show what we've done | 08:06.20 |
| | tkamppeter: git log --name-only | less; then /openjpeg seems to work for me | 08:08.48 |
| | tkamppeter: but we don't have a document. We _do_ tend to send patches for things we need or improvements upstream (if there is one). That's one of the things that led us to dump jasper -- they wouldn't take a MAJOR performance improvement patch from us because "it didn't fit their design philosophy" | 08:12.16 |
| | IMHO, if you want to be a purist/philosopher, stay out of software | 08:12.54 |
| | sort of like some linux distros that insist on shared libs, despite a detrimental user experience and extra support load for software products that utilize the libs ;-) | 08:14.25 |
| tkamppeter | ray_laptop, it seems that the ./configure script does not support a shared openjpeg, it only checks local openjpeg. | 08:14.52 |
| ray_laptop | I've never heard a convincing (currently relevant) argument for shared libs | 08:15.20 |
| kens | Ah, that may be because we need some changes ot the standard OpenJPEG code | 08:15.34 |
| ray_laptop | tkamppeter: that may be because openjpeg does not yet have the patches we need. | 08:15.58 |
| | tkamppeter: as you can tell I am STRONGLY in favor of dropping ALL support for shared libs (except maybe the crtl) since we are so much more proactive with support/fixes | 08:17.22 |
| kens | I've just quickly reviewed what Alex said and I think we cannot use an OpenJPEG 'shared library'. | 08:18.23 |
| | We need some thiings from the version 2 which is not yet released as I undertand what Alex says | 08:18.51 |
| ray_laptop | maybe if we opened enough bugs against the other packages that use the same libs we do, we could get the upstream to pay attention. | 08:18.55 |
| kens | FreeType (werner) is very responsive | 08:19.25 |
| ray_laptop | kens: I agree | 08:19.32 |
| tkamppeter | ray_laptop, OK, so I will move to internal libopenjpeg as the external is not suitable. | 08:20.20 |
| ray_laptop | and he is also quite reasonable with some of the wierdos that come in on ft-devel | 08:20.25 |
| kens | Werner has far more patience than I do, that is certain | 08:20.42 |
| ray_laptop | tkamppeter: thank you. and the gs users will thank you -- performance is > 200% and memory usage can be 10% or less compared to jasper | 08:21.27 |
| kens | Yes indeed, openjpeg is *way* better than JasPer | 08:21.49 |
| tkamppeter | ray_laptop, kens, currently available libopenjpeg is suffering CVE-2012-3358. Is this fixed in your libopenjpeg? | 08:21.58 |
| kens | tkamppeter : I don't know, can you give me a URL ? | 08:22.19 |
| | Looking at the bug, I doubt it is fixed in our version, no. | 08:23.25 |
| tkamppeter | kens, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3358 | 08:24.04 |
| ray_laptop | kens: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3358 | 08:24.26 |
| kens | Yes, I have t Till thanks. As I said, looking at the report I very much doubt this is fixed in our code. | 08:24.28 |
| | Duh, I'm looking at the RedHat oe :-) | 08:24.46 |
| | My comments still apply, I doubt this is fixed in our code, no. | 08:26.01 |
| tkamppeter | ray_laptop, about the performance, are there many files containing images which are treated by openjpeg? So will the average printing user often see advantages? And can you give me a sample file? | 08:26.16 |
| ray_laptop | the trouble with these (AFAICT) is that they don't tell (the hackers or the fixers) how to reproduce the issue :-( | 08:26.21 |
| kens | tkamppeter : jpeg2000 images aren't that common, but if you get one you will see the difference. | 08:26.50 |
| ray_laptop | tkamppeter: JPXDecode is becoming more prevalent, but since most of your (problem) files seem to come from Cairo, I don't know how much they are impacted. I recommend running a test with timing (as we do) | 08:27.35 |
| kens | http://bugs.ghostscript.com/show_bug.cgi?id=692002 | 08:27.54 |
| | THere's a public file attached there | 08:28.01 |
| ray_laptop | kens: thanks' | 08:28.09 |
| | oh, that's for performance ? | 08:28.37 |
| kens | Yes. | 08:28.47 |
| ray_laptop | (not the CVE report) | 08:28.48 |
| kens | Sorry I thought Till was asking for a JPEG2000 image in a PDF file | 08:29.09 |
| | which exhibits a performance problem | 08:29.23 |
| | According to the comments that one goes from 3.5s to 2s | 08:29.50 |
| | More importantly it uses less than half the memory | 08:30.19 |
| ray_laptop | kens: tkamppeter was asking bout the performance, but also was concerned that an openjpeg vulnerability was in our source that we hadn't picked up (I don't think so) | 08:30.21 |
| kens | ray_laptop : yes, I don't believe we have a fix fot the vulnerability | 08:30.39 |
| ray_laptop | kens: nor do the openjpeg maintainers (if there are some) AFAIK | 08:31.05 |
| kens | No, it seems a ver recent report | 08:31.29 |
| | very * | 08:31.34 |
| ray_laptop | time for sleep ... | 08:33.47 |
| kens | I would think so ray_laptop yes, goodnight | 08:34.02 |
| ray_laptop | the Olympics coverage just ended :-) | 08:34.27 |
| tkamppeter | ray_laptop, thank you very much for all. | 08:34.32 |
| ray_laptop | g'nite -- back in the AM | 08:34.44 |
| kens | Really ray ? Its just starting here in an hour | 08:34.45 |
| tkamppeter | kens, ray_laptop, there are two other CVEs which are solved upstream: | 08:35.15 |
| kens | tkamppeter : I'd suggest opening a bug in GS for these and assigning it to Alex. | 08:35.40 |
| tkamppeter | CVE-2009-5030, CVE-2012-1499, please check whether they are also solved in your code. | 08:35.53 |
| kens | Iseally we would like to use a released version of OpenJPEG but I think that may be some time away | 08:36.04 |
| | tkamppeter : Not my area of the code, it would take me a very long time to figure out if we have these vulnerabilities. | 08:36.40 |
| tkamppeter | kens, test build with internal libopenjpeg done, performs great now. | 09:02.14 |
| kens | That's good, thanks for the update tkamppeter | 09:02.38 |
| Robin_Watts | paulgardiner: Am I supposed to be looking at those reviews? | 09:39.08 |
| paulgardiner | Yeah, if you have a moment. | 09:39.37 |
| tkamppeter | kens, gs with internal libopenjpeg is uploaded now. | 09:40.18 |
| Robin_Watts | paulgardiner: All look good to me now. | 09:40.52 |
| paulgardiner | great ta | 09:40.59 |
| kens | great, thanks Till. For what its worth, shelly just told me that the openjpeg developers are hoping to have a release out later this year, probably around October. Hoperully we can move to a standard release at that point | 09:41.12 |
| Robin_Watts | paulgardiner: pushed | 09:42.26 |
| paulgardiner | ta | 09:42.31 |
| tkamppeter | kens, CVE bug reported as http://bugs.ghostscript.com/show_bug.cgi?id=693250 | 09:49.15 |
| | alexcher, hi | 09:49.20 |
| kens | Thanks tkamppeter | 09:49.34 |
| | Oh wow, how many MuPDF commits ? :-) | 09:51.23 |
| Robin_Watts | kens: only 6. | 10:04.31 |
| kens | Loads in my email, 31 | 10:05.51 |
| Robin_Watts | kens: Ah. Paul merged master into forms. | 10:06.22 |
| | so for some reason that causes loads of the merged ones to be spewed into the email too. | 10:06.44 |
| | paulgardiner: So, stupid question, but does the saving of filled out forms work? | 11:03.12 |
| paulgardiner | Robin_Watts: strangely it does seem to. | 11:03.33 |
| Robin_Watts | (More specifically, I guess, I'm asking if we can save PDF files from the viewer and still have the viewer work afterwards :) ) | 11:03.39 |
| | Well, I never doubted it for a second! :) | 11:03.53 |
| paulgardiner | Ah. I've added two ways to save. Save on close and the 'S' button. I have to admit I've mostly tested the former and then messed witht the saved file. | 11:06.36 |
| | I guess, if we do find that the viewer behaves strangely after the latter method of saving then we could force a reload of the saved file. | 11:06.39 |
| Robin_Watts | paulgardiner: Right. Would be worth trying saving the file, then following some internal links, or changing pages etc. | 11:06.39 |
| | or I could fix it :) | 11:06.39 |
| paulgardiner | Oh I hadn't thought of that. Radical! :-) | 11:06.39 |
| | I'll see if I can do some more testing later. | 11:06.50 |
| Robin_Watts | tor8: ping | 13:12.43 |
| | Are there any mupdf bugs that are blocking a release? If so, do you want me to handle any of them ? | 13:13.32 |
| | (I'm still busy with windows 8, so I'm not actually looking for work yet, but probably getting the mupdf release out should be a higher priority) | 13:14.06 |
| | Morning marcosw | 13:43.27 |
| marcosw | morning Robin_Watts | 13:43.37 |
| Robin_Watts | Camera finally shipped this morning. | 13:43.45 |
| kens2 | Shuld be in time for meeting then :-) | 13:43.58 |
| marcosw | four packages have already arrived for you | 13:44.29 |
| Robin_Watts | Lets see... Camera/Lens, Lens, Batteries, Battery grip, screen protectors, strap | 13:45.25 |
| marcosw | one is definitely the screen protector, it's just an envelope. | 13:45.58 |
| Robin_Watts | That's not counting the polarisers, memory cards etc I have here :) | 13:46.18 |
| pipitas1 | When is the 9.06 release scheduled? | 14:02.34 |
| | because I'm seeing segfaults on Linux on some of my files with today's Git checkout which didn't occur before | 14:03.34 |
| Robin_Watts | pipitas1: Very soon. Can you tell us what command line you are using ? | 14:05.51 |
| halfie_ | mupdf developers, sumatrapdf supports the new Revision 6 encryption algorithm. | 14:06.49 |
| | http://code.google.com/p/sumatrapdf/source/browse/trunk/mupdf/pdf/pdf_crypt.c?spec=svn6520&r=6520 | 14:06.50 |
| Robin_Watts | halfie_: Indeed, we spotted that, thanks. | 14:07.02 |
| halfie_ | Robin_Watts, mupdf is too big a tool for writing my tool (for extracting encrypt information from pdf files for brute-forcing) , I am searching for alternatives. Any tips? | 14:08.05 |
| tor8 | Robin_Watts: I'd like the build issues sorted, and the ios bug I entered today should be fixed. I'm working on the latter, have been upgrading my mac all day. yet again... | 14:08.23 |
| Robin_Watts | tor8: build issues? | 14:08.41 |
| tor8 | Robin_Watts: .incbin for clang and some other makefile related bugs | 14:09.03 |
| | I think the incbin is the only serious one | 14:09.13 |
| | but it's not a blocker by any means | 14:09.27 |
| pipitas1 | Robin_Watts: Basically, I'm first using GS to process an input PDF so that it outputs single pages (which are shifted a bit with /PageOffset) using the %03d syntax for output file names. That works, but when I then try to re-merge these pages with GS, it segfaultâ¦. | 14:14.43 |
| | Robin_Watts: Gimme some time to come up with a testcase you can reproduce... | 14:15.05 |
| Robin_Watts | halfie_: Sorry, no. | 14:15.18 |
| | It's perfectly possible to build small tools with mupdf - mupdfextract etc for example. | 14:15.39 |
| | pipitas1: I guess I'm mainly interested in what devices you are using. | 14:15.59 |
| | We've made changes to the psdcmyk and tiffsep devices over the last couple of days | 14:16.13 |
| | I guess the ideal thing would be for you to git bisect it and tell us what commit broke it - if you're in a position to do that. | 14:17.03 |
| pipitas1 | Robin_Watts: pdfwrite is the device | 14:19.20 |
| Robin_Watts | kens2: ping ? | 14:19.30 |
| kens2 | Yes ? | 14:19.40 |
| Robin_Watts | pipitas1 has just been talking about a new SEGV he's seeing with pdfwrite. | 14:20.07 |
| kens2 | I saw, yes | 14:20.13 |
| Robin_Watts | pipitas1: How recently has it occurred? | 14:20.17 |
| | kens2: OK, sorry. | 14:20.27 |
| kens2 | But he said he would concoct a test case | 14:20.28 |
| kens2 | will wait for bug report :-) | 14:21.03 |
| pipitas1 | Robin_Watts: Oh, it happens with another command as well: gs -o out_p%03d.pdf -sDEVICE=pdfwrite -dLastPage=1 PDF32000_2008.pdf (where PDF3200_2008.pdf comes from http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf ) | 14:21.35 |
| pipitas1 | will look how the OSX build behaves... | 14:22.30 |
| kens2 | pipitas1 : please raise a bug (and attach the file) | 14:23.08 |
| pipitas1 | kens2: will do | 14:25.39 |
| kens2 | OK back to my personal salt mine then | 14:25.52 |
| Robin_Watts | Well, I have ghostscript compiling on windows 8 using the metro only VS 2012 express edition. | 15:21.50 |
| | Basically, the windows message loop has gone under metro, and all the window handling calls are different, so I've stripped out all that. It's now got no display device. | 15:22.37 |
| | The tiff devices use libtiff which manages to be incompatible with metro, so they are out. | 15:23.18 |
| | The printer/spool handling stuff is all changed, so that's gone. | 15:23.31 |
| | but that's it. Otherwise it seems to be OK. | 15:23.44 |
| henrys | what is incompatible in libtiff? | 15:23.48 |
| Robin_Watts | I'm not entirely sure. | 15:24.01 |
| | It has some windows specifics in (#include <windows.h> etc in tif_win32.c IIRC) | 15:24.24 |
| | it's probably nothing major, but the path of least resistance was to remove those devices. | 15:24.41 |
| | I'm guessing that if people are planning to use gs in a metro app, they will either be going to file, or will be handling display themselves - so I don't think we've lost anything hugely important. | 15:25.28 |
| | Oh, no registry access for metro either. | 15:25.48 |
| henrys | would you report the lib tiff problem? http://www.libtiff.org/bugs.html | 15:29.19 |
| kens2 | wot, the registry is dead ? | 15:29.24 |
| | for apps ? | 15:29.27 |
| henrys | wow a muslim woman in head dress and almost her entire body covered in the 100 meter run event at the olympics. | 15:31.59 |
| kens2 | AH, that'll be a 'sports' niqab | 15:32.37 |
| | or possibly hijab | 15:32.59 |
| Robin_Watts | henrys: Sure. I'm just tidying it all up now for a commit. | 15:34.00 |
| | The P/invoke thing; most apps under metro are going to be in 'managed' code (C#, .net etc) | 15:34.45 |
| | So to call C/C++ code, they need to go through some hoops. I think they can call into dlls etc, but obviously those dlls need to be compliant. | 15:35.52 |
| | The ability for metro tiles to just 'invoke' desktop apps isn't there. | 15:36.07 |
| kens2 | The more I hear, the less I like ..... | 15:37.23 |
| Robin_Watts | It kinda makes sense; metro is a new environment (new APIs, some shared, but basically a new system built on the windows kernel). If you go into the 'desktop' sandbox then you get access to all the old APIs that are built on top of the windows kernel. | 15:39.00 |
| | The restriction is that you can't talk from a metro app into another metro apps sandbox (i.e. the desktop) | 15:39.50 |
| | Oh, great. So now apparently Microsoft are having to change the Metro name to something else. | 16:05.21 |
| kens2 | Yes I saw that too | 16:08.31 |
| | maximal confusion | 16:08.39 |
| henrys | I think xps was originally called metro wasn't it? | 16:10.09 |
| kens2 | Possibly. Microsoft certainly used teh name before | 16:10.29 |
| Robin_Watts | OK, the tiff win32 dependency comes from it's warning/error stuff, which I don't think we use. | 16:11.17 |
| | I suspect if we define TIF_PLATFORM_CONSOLE we should be fine. | 16:11.35 |
| | Has anyone ever seen the tif device pop up a warning/error box on windows ? | 16:11.50 |
| kens2 | not me. | 16:12.17 |
| pipitas1 | kens2: bug report is #693251. (My segfault happens on Linux, but not on OSX. Also, I now think the faulty component may be the PDF Interpreter, not the Writer: because it also happens with jpeg output deviceâ¦) | 16:31.10 |
| Robin_Watts | pipitas1: Thanks. | 16:33.09 |
| | If it's not pdfwrite, then that changes the complexion of the problem a lot. I'll try a windows build here. | 16:33.37 |
| | How recently has this occurred, do you know? | 16:33.53 |
| kens2 | pipitas1 : if its a crah outside pdfwrite devie then its not mine :-) | 16:41.18 |
| marcosw | henrys: sorry I'm late for the support meeting (again). Do we need one this week? (I haven't checked the report) | 16:46.42 |
| henrys | I don't think so | 16:47.17 |
| | this problem being discussed now should probably be entered. | 16:47.43 |
| kens2 | Robin_Watts : pipitas1 I still can't reproduce the seg fault, I think it must be memory dependent | 16:48.30 |
| henrys | or rather prioritized and assigned | 16:48.32 |
| kens2 | Possibly 64-bit related | 16:48.35 |
| Robin_Watts | pipitas1, kens: I've just build on peeves, and I can't reproduce it either. | 16:48.48 |
| kens2 | Robin_Watts : pipitas's original report is a non-standard build | 16:49.05 |
| | But I have to be off, its getting late for me | 16:49.33 |
| | I'll check the logs tomorrow | 16:49.42 |
| Robin_Watts | pipitas1: Can you tell us please: 1) Are you building on a 32 or 64bit version of Ubuntu? 2) Are you using any shared libs? | 16:49.43 |
| | sorry, I see from the bug that you aren't using shared libs. | 16:51.14 |
| pipitas1 | Robin_Watts: "How recently did it occur?" â Can't say exactly⦠Last I tested on Linux was about 5 weeks ago. But it doesn't happen with ALL files. | 17:06.15 |
| Robin_Watts | pipitas1: I assume you're on a 64bit linux box? | 17:06.49 |
| pipitas1 | Kens: should I rebuild with just "./configure" (no options)? | 17:07.21 |
| Robin_Watts | pipitas1: Kens has gone for the night. | 17:07.33 |
| | pipitas1: That would be a test worth doing. | 17:07.58 |
| pipitas1 | Robin_Watts: it's 32bit Ubuntu â not using any shared libs AFAICT... | 17:08.10 |
| Robin_Watts | Ah, ok, I have a 32bit ubuntu vmware thing here I can try. | 17:08.29 |
| pipitas1 | Robin_Watts: how can I test for shared libs? ldd `which gs`? | 17:08.32 |
| Robin_Watts | pipitas1: Just do: ./autogen.sh && make | 17:09.00 |
| alexcher | pipitas1: The file works for me on an AMD64 box with or without special connfiguration, debug or release, 1st page or all pages. | 17:10.02 |
| pipitas1 | Robin_Watts: should I build the one level above (ghostpdl) too? Or just the gs subdirectory? | 17:10.08 |
| Robin_Watts | pipitas1: Just in the gs directory | 17:11.29 |
| marcosw | henrys: I just read the irc logs and am not sure what problem you say should "probably be entered". One is an issue reported by pipitas1 but I believe he's entered it and the other is a discussion of building for windows metro. | 17:11.38 |
| alexcher | marcosw: how difficult it is to make a packaged regression test? I want to upload a bundle to a clean system, run a single command, download the results, and compare them with the current cluster results. | 17:20.17 |
| henrys | I was talking about pipitas1 problem Robin_Watts is trying to reproduce. | 17:20.59 |
| Robin_Watts | henrys: That's already entered as bug 693251 | 17:21.22 |
| | pipitas1: And exactly what git SHA are you on please? | 17:22.04 |
| henrys | right I said it might need prioritization or assignment | 17:22.05 |
| pipitas1 | Robin_Watts: I rebuilt, but problem persists. Also updated info in 693251. | 17:22.20 |
| marcosw | alexcher: sorry, I'm not sure what you mean. Can you clarify what you need? | 17:22.39 |
| ray_laptop | alexcher: sorry to have dumped a minor bug on you (bug 693185). Now it's just down to a confusing (and unlikely) error message. If you want to close it as WONTFIX, I won't lose any sleep over it. | 17:23.00 |
| | alexcher: also it isn't a customer issue, but I left the customer # there for history. | 17:23.34 |
| alexcher | marcosw: ray_laptop: Can I just suppress the message about q/Q cleanup? | 17:23.53 |
| pipitas1 | Robin_Watts: How do I look for the SHA in git? (I'm only used to see what it prints towards the end of 'git pull'. But when I'm current, I don't see...) | 17:24.34 |
| Robin_Watts | git log -1 | 17:24.48 |
| ray_laptop | alexcher: that would probably help and it highlights the other part of the error message | 17:24.53 |
| pipitas1 | commit 14ab2a0c68eed10ea665f00cb77c728ffbd5c1ba | 17:25.30 |
| alexcher | marcosw: It is desirable to regression test gs on various odd systems, but thre's no convenient way to do it. | 17:25.59 |
| Robin_Watts | That's interesting. I haven't got a 14ab2 here... | 17:26.53 |
| | What does the rest of git log -1 say ? | 17:27.05 |
| | yeah, that commit hash is not one of ours. | 17:28.10 |
| marcosw | alexcher: I understand now. This would be pretty easy to do. The system I set up some time ago to compare multiple command lines (i.e. page mode vs. clist) could be trivially modified to just run once and produce a list of m5sums (and it could take an list of current md5sums and preserve bitmaps of those files that differ). Can you open a bug and assign it to me? | 17:30.47 |
| henrys | marcosw:we talked about this some time back: the regression test should be able to run standalone on any machine, I thought you did that, did it break? | 17:31.41 |
| alexcher | marcosw: Yes. | 17:32.17 |
| marcosw | alexcher: I think the q/Q cleanup messages should be suppressed (along with a lot of other warnings about bad PDF files, they only confuse users and no one ever fixes their pdf writers based on our complaints). | 17:32.22 |
| henrys | I'd like them left on in a debug build is that possible alexcher? | 17:32.51 |
| alexcher | marcosw: Q/q message is just wrong. Others are correct. | 17:33.36 |
| Robin_Watts | Am I right in thinking that the Q/q messages 'spew' ? | 17:33.50 |
| marcosw | henrys: The regression test can run standalone, it's the basis for the comparison code I mentioned. The only thing that has to be done are minor changes to shell script that calls the various bits and the documentation. | 17:33.50 |
| ray_laptop | henrys: I don't think the PDF interpreter knows if it is a DEBUG build, but I guess we could add a private operator to allow it to find out | 17:33.50 |
| pipitas1 | Robin_Watts: The full git log message is: | 17:34.13 |
| | commit 14ab2a0c68eed10ea665f00cb77c728ffbd5c1ba | 17:34.16 |
| | Merge: f414f22 7167ebc | 17:34.16 |
| | Author: My Name <my.name@gmail.com> | 17:34.16 |
| | Date: Fri Aug 3 15:18:37 2012 +0200 | 17:34.16 |
| | Merge branch 'master' of git://git.ghostscript.com/ghostpdl | 17:34.16 |
| marcosw | alexcher: I'm not saying the messages aren't correct, just not useful. | 17:34.25 |
| ray_laptop | Robin_Watts: no, AIUI we don't know about unbalanced q/Q until the end of the page | 17:34.27 |
| pipitas1 | I wonder how that happened?!? | 17:34.27 |
| Robin_Watts | pipitas1: Right. You've done a merge when pulling. | 17:34.39 |
| pipitas1 | I didn't "merge" anything. I always only do git pull | 17:34.46 |
| Robin_Watts | Right. And git pull can merge. | 17:35.01 |
| pipitas1 | Also I didn't modify anything (knowingly) | 17:35.08 |
| Robin_Watts | OK, so: git checkout master | 17:35.23 |
| | git reset --hard HEAD~ | 17:35.29 |
| | git reset --hard HEAD~1 | 17:35.32 |
| pipitas1 | Maybe I should try again with a completely fresh checkout.... | 17:35.40 |
| Robin_Watts | (sorry, hit return too early) | 17:35.40 |
| | That will move master back to before the merge. | 17:35.56 |
| pipitas1 | Ah.. You're guiding me through the shallow waters of Git. Robin_Watts :-) | 17:36.08 |
| Robin_Watts | what SHA is that on then ? | 17:36.08 |
| ray_laptop | OK, I psuhed the commit that removes jasper | 17:36.17 |
| pipitas1 | Robin_Watts: now it is 'commit f414f22c42c39e9996d2a7b4aa5369b3a006e362' | 17:37.12 |
| Robin_Watts | ok. Still not one of ours :) | 17:37.39 |
| | What's that one ? | 17:37.42 |
| pipitas1 | *Sigh* | 17:38.06 |
| | If ping was designed by the Git developers, you'd use: | 17:38.12 |
| | net-ping host | 17:38.12 |
| | --no=dns,bind | 17:38.12 |
| | --proto=TCP,rfc:492 | 17:38.12 |
| | eth0@ipv4::http://1.0.0.127.IN-ADDR.ARPA | 17:38.12 |
| | --stats -v | 17:38.12 |
| | Robin_Watts: I'll do a fresh Git checkout, OK? | 17:38.35 |
| Robin_Watts | If you want. | 17:38.50 |
| | But you don't mean a checkout. | 17:38.56 |
| | You mean a clone. | 17:39.00 |
| pipitas1 | Robin_Watts: What is the Git equivalent to SVN's "svn info" ? | 17:39.04 |
| | Yes, I meant a clone :-) | 17:39.19 |
| Robin_Watts | pipitas1: Hold on. We can fix it. | 17:39.25 |
| | Try: git log --graph --oneline --decorate --all -20 | 17:39.33 |
| henrys | ray_laptop is deprecator of the quarter. icclib and jasper... yeah! | 17:40.34 |
| pipitas1 | git log --graph --oneline --decorate --all -20 | 17:41.03 |
| | * 7167ebc (origin/master, origin/HEAD) pdfwrite - check annotation placement and Box sizes for PDF/X-3 validity | 17:41.03 |
| | * b40b8fd Bug 693185. The limitcheck in validatedevicenspace must match int_remap_color_info_s. | 17:41.03 |
| | * d8ca80d Get rid of 'icclib' since we now use lcms2 (or optionally lcms). | 17:41.03 |
| | * a884b57 Update documentation for tiffsep planar device | 17:41.03 |
| | * cfbd3fa Add -dMaxSpots for tiffsep and psd devices. | 17:41.03 |
| | * 974ba5d Add new 'const' compression method for clist bits. | 17:41.03 |
| | * fe9465d ps2write - don't leave our dictionary on the stack at temination of the output | 17:41.04 |
| | * 2d613c3 Fix the -disable-gtk "so" build option | 17:41.04 |
| | * 004aeab Fix lcms2 64-bit value decoding on big endian systems that lack 64-bit types or have these types missed by configuration. | 17:41.05 |
| | * c1532d4 Fix parenthesis typo that caused the return code from sscanf to be ignored. | 17:41.06 |
| | * 60028f8 Add common unix style scaling suffix support for -d____= parameters. | 17:41.06 |
| | Sorry, Robin_Watts, you asked for it :-) | 17:41.19 |
| Robin_Watts | Perfect. So: git reset --hard 7167ebc | 17:41.47 |
| | That should set master to the right place. | 17:42.07 |
| pipitas1 | Ah, now it's "commit 7167ebcceae78be8dcec24a059f936a861769cd5" <== same one I have on Mac OSX, I just checked that too | 17:43.11 |
| Robin_Watts | Perfect. Do a fresh: ./autogen.sh && make and test that. | 17:43.40 |
| pipitas1 | building... | 17:45.50 |
| marcosw | the last regression test failed because henrysx6 reported a build error. I believe it's running a different release of gcc, so presumably it's a legitimate issue and not a cluster bug. Unfortunately the email message that was sent out didn't contain the actual error. I'll fix the regression system so that the error is reported and re-run the job. | 17:51.13 |
| | never mind, the email did include the error message: | 17:53.56 |
| ray_laptop | time for coffee | 17:53.57 |
| marcosw | ./obj/gsromfs1.c:10434:79: error: invalid suffix "x" on integer constant | 17:53.57 |
| | it's hard kind of lost, so I'll try to fix that issue. | 17:54.17 |
| Robin_Watts | marcosw: That smells like an rsync issue. | 17:54.25 |
| | Ray saw something like the other day- not sure what host. | 17:54.37 |
| marcosw | rsync shouldn't be involved, it was a git commit regression test. | 17:54.54 |
| ray_laptop | marcosw: I had a funky build error on henrysx6 last week with a \26 in gsromfs | 17:54.56 |
| henrys | ray_laptop's problem seemed to happen when space ran out. | 17:55.05 |
| | the /tmp fill up | 17:55.25 |
| ray_laptop | henrys: I had wondered about that -- I asked on IRC but didn't notice if you replied. The next time I tried it, it was fine | 17:55.45 |
| marcosw | henrys: remind me what henrysx6's ip address is again. | 17:55.49 |
| henrys | 192.168.1.141 | 17:56.27 |
| marcosw | plenty of space this time. | 17:56.48 |
| mvrhel_laptop | I was taking a quick look at Bug 691814 to see if this was fixed with the xps soft mask changes and I am getting a segv with gxps on the fts_33xx.xps file at 72 and 300dpi in windows debug build. could I have someone else double check this? | 17:56.56 |
| ray_laptop | the gsromfs1.c is the big file we generate that has all of the compiled inits and apparently compiling it takes a fairly large /tmp space | 17:57.14 |
| mvrhel_laptop | ray_laptop: thanks for ripping out the icclib stuff | 17:57.59 |
| ray_laptop | mvrhel: I will _after_ I get back with my coffee | 17:58.12 |
| | bbiab | 17:58.20 |
| mvrhel_laptop | thanks ray_laptop | 17:58.22 |
| marcosw | there are 237 gigs free, is that what you mean by "fairly large"? | 17:58.52 |
| | I'm doing a make clean ; make pcl. Presuming it works this time we'll assume broken computer :-) | 17:59.25 |
| | or did I mean :-( | 17:59.31 |
| mvrhel_laptop | hmm I should do the same.... | 18:00.01 |
| marcosw | henrys: the compile worked the second time, so I'm guessing you have a hardware issue (memory?). I'll take henrysx6 out of the cluster list for now and run mprime on it; that's what all the over-clockers use for stress testing. | 18:01.52 |
| mvrhel_laptop | ray_laptop: ok never mind about checking out the segv. clean and rebuild fixed the issue | 18:02.08 |
| henrys | marcosw:odd because I have been doing stuff on it and haven't noticed anything. | 18:02.52 |
| marcosw | have you been running multiple threads? the compile happens in parallel and the generating of gsromfs1.c happens at the end, so presumably the machine is pretty hot at that point. | 18:04.25 |
| henrys | well I always compile with -j but I doubt it gets as hot as a cluster run. | 18:05.56 |
| pipitas1 | Robin_Watts: It works now, I closed 693251 again. | 18:07.59 |
| | Thanks for the awesome help, Robin_Watts :-) | 18:08.13 |
| marcosw | the cluster run hadn't started, it was just finishing the compile. I'm running a bunch of compile now, just to see what happens. I'll launch mprime as well, so you'll notice the fans spin up :-) | 18:08.48 |
| Robin_Watts | pipitas1: Ah, fab. | 18:11.38 |
| Robin_Watts | supposes he ought to make pcl and co build on win8 too. | 18:14.50 |
| henrys | Robin_Watts:that would be great | 18:15.31 |
| | off to lunch bbiaw | 18:16.28 |
| mvrhel_laptop | Robin_Watts: remember bug 693240 | 18:34.27 |
| | and I mentioned that there was some weirdness going on with the transfer function | 18:35.04 |
| | looking in the source PS file, it looks like it is randomly setting the transfer array | 18:35.34 |
| | which makes me think that this file is the issue | 18:36.03 |
| | ah there we go | 18:37.31 |
| | damn net split | 18:37.33 |
| | Robin_Watts: did you see my post to you? | 18:37.42 |
| Robin_Watts | Did I miss anything? | 18:37.42 |
| mvrhel_laptop | ha | 18:37.45 |
| Robin_Watts | I didn't. I went the other way :) | 18:37.50 |
| ray_laptop | mvrhel: yeah, it's pretty noisy. | 18:37.52 |
| mvrhel_laptop | so Robin_Watts do you remember bug 693240 | 18:38.16 |
| | which I found to be something funny going on with the transfer function | 18:38.31 |
| Robin_Watts | ah, right, yes. | 18:38.42 |
| mvrhel_laptop | I looked at the source file and it looks the the PS file is setting the transfer function randomly | 18:39.15 |
| Robin_Watts | or "Tuesday" as I like to call it :) | 18:39.16 |
| mvrhel_laptop | which makes me think the file is the issue | 18:39.25 |
| Robin_Watts | the PS file is setting the transfer function to something random ? | 18:39.48 |
| mvrhel_laptop | look for the comment %fill transfer array randomly | 18:40.15 |
| | in the source file | 18:40.21 |
| | I think it is picking a random id for one to use | 18:40.32 |
| | wife on phone brb | 18:41.08 |
| Robin_Watts | oh, gawd, yes, that does look like it's filling it full of random numbers. | 18:41.38 |
| | Are they at least pseudo random? I mean, do we get the same every time we run the file? If so, we still have a problem in that clist and non-clist should give the same results, right ? | 18:42.41 |
| mvrhel_laptop | Robin_Watts: I have no idea | 18:47.21 |
| | My PS understanding is not so good | 18:47.35 |
| | let me do multiple runs to see what is going on | 18:48.16 |
| | to me when looking in the graphics it seems that the transfer array is either identity or inverted | 18:49.11 |
| | I was thinking that the source file was randomly picking choices from a set of transfer functions | 18:49.56 |
| | need to go get my other vehicle right now from the shop. bbiab | 18:50.16 |
| Robin_Watts | Ah, right. It's pseudo random. | 18:51.51 |
| | They set the seed (by deffing rancid) to 12345. | 18:52.11 |
| | Then they call 'rnd' which makes a 'random' number from rancid and updates rancid. | 18:52.50 |
| | So every time it runs you should get the same values. I hope. | 18:53.13 |
| | Someone with more PSclue than me may want to double check it though. | 18:53.28 |
| Robin_Watts | heads out. Have a good weekend all. | 19:06.35 |
| ray_laptop | Robin_Watts: you, too | 19:10.45 |
| | Robin_Watts: mvrhel: I'm having a look into this screwy test as well. BTW, if you convert it using pdfwrite the colors are different yet | 19:11.57 |
| | not too surprising, but I'm looking at the banding/no banding issue... | 19:12.50 |
| pipitas1 | Robin_Watts: I just reported an OSX build bug #693252 for the default './autogen.sh && make' way (which can be worked around by running './autogen.sh âlibiconv=gnu' or 'âlibiconv=none')... | 19:44.41 |
| ray_laptop | OK, I see what's going on with the 09-40.PS.... | 20:09.19 |
| mvrhel_laptop | ok back | 20:10.47 |
| ray_laptop | mvrhel_laptop: just in time. | 20:11.01 |
| mvrhel_laptop | oh good you had a look at this ray_laptop | 20:11.16 |
| ray_laptop | on 09-40.PS the 'cmap_transfer_halftone' has a funky test in it that is _supposed_ to make us correspond to the PLRM 3rd p. 494 | 20:11.58 |
| | This is only using the transfer function for the 'K' component, which is inverting the input value of 0x01 and so K swamps the other colors when displayed | 20:12.47 |
| mvrhel_laptop | oh | 20:12.57 |
| | I thought that was only if the source space was gray | 20:13.04 |
| ray_laptop | mvrhel_laptop: please read the PLRM note on that page. | 20:13.19 |
| mvrhel_laptop | I am | 20:13.25 |
| | it says when the current color space is device gray | 20:13.37 |
| ray_laptop | mvrhel_laptop: that's how I read it, but if we applied the transfer function for ALL components, we'd still end up with black (AFAICT) | 20:14.22 |
| | mvrhel_laptop: also, I don't know how this can give us colors on the non-clist case. I haven't gotten that far | 20:15.00 |
| | but clearly the problem is with an inverted transfer function. So I need to run this with CPSI and see what happens ... | 20:15.47 |
| mvrhel_laptop | ray_laptop: what I am seeing is that in the graphics lib, the transfer functions for each CMYK channel are either inverting or they are identity | 20:15.49 |
| ray_laptop | I don't trust Acrobat with this since transfer functions may be ignored | 20:16.10 |
| mvrhel_laptop | yes. I was wondering about that ray_laptop | 20:16.23 |
| ray_laptop | mvrhel_laptop: I'll fire up CPSI now | 20:16.40 |
| mvrhel_laptop | ok thanks | 20:17.12 |
| ray_laptop | I forgot how slow this system is (my old XP box) | 20:23.16 |
| | mvrhel_laptop: I had the settings wrong -- trying again. | 20:31.41 |
| mvrhel_laptop | ok | 20:31.48 |
| ray_laptop | hopefully this time (fingers crossed) | 20:34.34 |
| | oops -- got a call have to run, but it still doesn't look like what I expect | 20:35.40 |
| | bbiab. | 20:35.44 |
| mvrhel_laptop | ok | 20:40.48 |
| | blue angels just flew overhead.... | 20:40.56 |
| | henrys: before the day gets away from me, good luck on the race this weekend | 20:50.15 |
| henrys | pipitas1:see the docs for setting LDFLAGS="-L/usr/lib" for the mac os x build problem. | 20:50.23 |
| | thanks mvrhel_laptop, I have humble goals: stay out of the medical tent. | 20:50.45 |
| mvrhel_laptop | I have a 4 day Mt. bike ride at the end of august that is 140 miles. first day is 6100 foot climb.... | 20:50.54 |
| | henrys: what are the temps supposed to be? | 20:51.38 |
| henrys | low 90's... that quite a ride, where is it? | 20:52.03 |
| mvrhel_laptop | it is a 4 day hut-to-hut ride that circumnavigates mt. hood. doing it with 3 friends of mine. I have been doing a lot of riding but not quite at the level that this is going to be... | 20:52.54 |
| | so the huts are supplied with food and water | 20:53.22 |
| | and you spend the night there | 20:53.30 |
| henrys | that sounds like fun. How will you fix bugs in these huts ;-? | 20:54.19 |
| mvrhel_laptop | here is the trip mapped out | 20:55.01 |
| | http://www.everytrail.com/view_trip.php?trip_id=1702210&code=4beeb61a10ce7a990810af38cd9531b0 | 20:55.03 |
| | henrys: laptop will not be on the bike.... too heavy | 20:55.22 |
| henrys | BTW I volunteered for the Chicago show this year but if anyone else really wants to go let me know. | 20:55.51 |
| mvrhel_laptop | I sort of like going since I usually head off to see my parents for a bit | 20:56.08 |
| | but what are the dates | 20:56.11 |
| henrys | 10/6 - 10/10 | 20:56.58 |
| mvrhel_laptop | ah parents visiting here at that time... | 20:57.59 |
| henrys | a airplane ticket does not seem worth 3 days of booth duty... | 20:58.20 |
| mvrhel_laptop | no | 20:58.25 |
| | that is a long show... | 20:58.43 |
| | ok. I am going to move on from this crazy ps file bug. | 21:00.52 |
| | maybe I should pass it along to ray | 21:00.56 |
| henrys | I think it is more productive to have postscript problems looked at by the experts first. | 21:02.29 |
| mvrhel_laptop | yes | 21:02.34 |
| Robin_Watts | I passed it to mvrhel_laptop originally, cos I thought it was a color issue rather than a PS one. | 21:04.27 |
| mvrhel_laptop | Robin_Watts: I thought so too | 21:04.46 |
| | Once I got to digging though something seemed really weird | 21:05.04 |
| | ok pushed it off to ray to enjoy | 21:07.42 |
| | henrys: I am going to get back to looking at 693015 | 21:09.15 |
| | would like to have that done before our meeting | 21:09.27 |
| henrys | yes that would be good. I'll test the customer files once you have it working. | 21:10.47 |
| | actually the show is 7-10, I like to come in the night before. | 21:11.52 |
| Robin_Watts | chicago marathon is the 7th... | 21:12.56 |
| henrys | global warming has really screwed up that race recently | 21:19.40 |
| | but I did really enjoy it last year... I don't know if you saw above but if you want to go it's fine by me (Robin_Watts) | 21:23.49 |
| | to the show that is. | 21:23.59 |
| Robin_Watts | I suspect I might be doing the show in November. | 21:24.59 |
| | the android one. | 21:25.22 |
| henrys | that would make sense, yes | 21:25.38 |
| | mvrhel_laptop:I'll be stepping out shortly but send me mail or update the bug if you have any questions about 693015, I'l be around this evening. | 21:34.35 |
| Robin_Watts | OK. Windows 8 stuff pushed. | 21:40.52 |
| | henrys: Have a good race! | 21:40.58 |
| | Forward 1 day (to 2012/08/04)>>> | |
IRC Logs