| | <<<Back 1 day (to 2011/08/16) | 2011/08/17 |
| robin_watts_mac | marcosw_: Hey. | 00:15.02 |
| | You asked about why we didn't fix the issues reported by check_deps.pl. | 00:15.23 |
| | I did, and then you unpicked a load of them that caused problems. | 00:15.39 |
| marcosw_ | robin_watts_mac: how's Vietnam? What do you mean I unpicked a load of them? | 00:40.42 |
| robin_watts_mac | marcosw_: Vietnam is fab(but hot) | 01:21.52 |
| | I believe that you reverted several of my dependency changes due to them causing build problems. | 01:22.26 |
| | (i.e. I wasn't complaining) | 01:22.37 |
| | tor8: (For the logs) Don't hold up a mupdf release based on the knockout/isolated problems. | 01:26.57 |
| | They are something that might take a long time to solve perfectly. | 01:27.10 |
| | I don't think we're in a worse state than previous releases now - at least now we have a stab at them. | 01:27.41 |
| kens | Off riding, back later. | 09:24.01 |
| chrisl | tkamppeter: I've made some further changes in gdevcups.c, but they are mainly about getting rid of compiler warnings, so they are not really required for your Ubuntu package. FWIW, gdevcups.c should now compiler "cleanly" - no warnings. | 09:37.02 |
| tkamppeter | chrisl, thanks. | 10:03.59 |
| robin_watts_mac | Hey tor8 | 10:28.05 |
| tor8 | hey robin | 10:28.16 |
| robin_watts_mac | see my earlier burblings about knockout groups etc. | 10:28.19 |
| | I wouldn't hold up a release of mupdf waiting for them to get fixed. | 10:28.31 |
| | That's something that's likely to take a long while to iron out all the creases. | 10:28.45 |
| | and we're better than previous releases, I suspect (at least we *try*). | 10:29.01 |
| tor8 | robin_watts_mac: alright, I was just a bit worried about the premultiplied alpha messups. we get dark edges where we didn't before. | 10:29.38 |
| | but if you think it'll take a while to figure out, I guess I'll roll a release soon | 10:30.05 |
| robin_watts_mac | tor8: Well, we could wrap the code in and ifdef to say whether we bother attempting it or not. | 10:30.17 |
| tor8 | nah, enjoy your vacation instead :) | 10:30.44 |
| robin_watts_mac | tor8: I burnt a week before I went getting as far as I did, and it was starting to feel like a bottomless pit. | 10:30.48 |
| tor8 | now you know why I've tried to stay as far away from it as possible :) | 10:31.18 |
| robin_watts_mac | I only started it because I thought it would be a quick hack :/ | 10:31.24 |
| tor8 | if you change your mind and want to back it all out and say WONTFIX!!! that's fine by me, though zeniko may gripe about regressions ;) | 10:32.08 |
| robin_watts_mac | tor8: No, if I did decide to back it out, then it would be by ifdeffing it, and disabling it by default. | 10:33.16 |
| | I think we're now doing the same kind of thing as gs does, so we shouldn't be a mile away from making it work. | 10:33.36 |
| | Of course, I did spot that gs renders l16.pdf incorrectly. | 10:33.52 |
| | (I don't think gs copes with isolated knockouts maybe) | 10:34.08 |
| tor8 | could be, I've seen some comments about that when I was studying the gs code last time I attempted transparency | 10:36.02 |
| robin_watts_mac | I was amazed to see gs 'uncompositing' things. | 10:36.47 |
| robin_watts_mac | reboots. | 10:42.15 |
| kens | OK who can tell me how to persuade Git to let me update my checkout ? | 12:33.02 |
| kens2 | OK I am screwed. Git won't let me update because opj_malloc is an 'unstaged change'. I can't run a cluster psuh for the same reason. git reset --hard doesn't do anything to help, I can't rebase because changes 'can't be applied to a dirty tree'. | 12:47.24 |
| | None of reset, pull, fetch rebase seem to help. Can anyone tell me how to sort this stupid file out ? | 12:47.48 |
| | tor8 ? | 12:48.04 |
| tor8 | kens2: what does git status say? | 12:48.33 |
| kens2 | one secnod while I check again | 12:48.43 |
| | Your branch is behind 'origin'master' by 14 commits, and can be fast-forwarded. | 12:49.17 |
| | no changes added to commit | 12:49.22 |
| | THis is the opj_malloc.h file whch had bad line endings applied | 12:49.39 |
| tor8 | hmm, I have a hunch | 12:49.59 |
| | it may be due to line ending mismatches | 12:50.12 |
| kens2 | Yes, exactly | 12:50.19 |
| tor8 | what if you do "git checkout -- path/to/opj_malloc.h" | 12:50.22 |
| kens2 | One moment | 12:50.29 |
| tor8 | git reset --hard won't touch files it thinks are up-to-date | 12:50.42 |
| | I've run into this before with line endings | 12:50.50 |
| sebras | tor8: and line-endings are not recognized as changes? | 12:50.58 |
| tor8 | actually, it was with git filters for whitespace cleanups, but it's close enough to the same issue | 12:51.22 |
| kens2 | weel checkout was silent, lets see whta I have now | 12:51.30 |
| | Still shows opj_malloc.h as 'changed but not updated' in git status | 12:51.58 |
| tor8 | git diff --cached say anything? | 12:52.12 |
| kens2 | Nothing. | 12:52.28 |
| tor8 | and git diff? | 12:52.34 |
| kens2 | Still can't pull with rebase | 12:52.36 |
| | all of opj_malloc.h shows up as a diff | 12:52.53 |
| tor8 | that'd be line endings for you :/ | 12:53.05 |
| kens2 | Possibly also trailing white space and tabs | 12:53.19 |
| sebras | wouldn't it be possible to remove the file and checkit out again and then be at a good starting point? | 12:53.21 |
| kens2 | Not sure I can do that. | 12:53.31 |
| tor8 | sebras: that's what "git checkout -- file" does | 12:53.33 |
| sebras | tor8: well, it tries to, yes. but what if it also thinks the file is up-to-date? | 12:53.57 |
| tor8 | checks out a clean pristine copy, similar to "git reset --hard" but only for the one file | 12:54.02 |
| kens2 | git reset --hard doesn't do anything either though... | 12:54.20 |
| tor8 | git reset --hard looks at time stamps, I think git checkout ignores that | 12:54.49 |
| | kens2: but just to be safe, try rm opj_malloc.h and git checkout -- opj_malloc.h | 12:55.07 |
| kens2 | OK | 12:55.12 |
| tor8 | if that still shows as a diff, you should record a "fix whitespace and line endings in opj_malloc.h" patch | 12:55.38 |
| | I've had similar troubles when importing third party sources that didn't conform to my "don't let whitespace accidents slip through" settings | 12:56.15 |
| kens2 | Still shows up complete file in diff. | 12:56.23 |
| tor8 | since git will be happy to pull in things from other people that the settings won't let you do, and then it kind of gets confused when you keep working on them | 12:56.50 |
| chrisl | kens2: can you try "git fetch", the git checkout master opj_malloc.h | 12:57.06 |
| kens2 | I did a git fetch before, it fails. | 12:57.18 |
| chrisl | git fetch fails, how? | 12:57.35 |
| kens2 | or rather, does nothing | 12:57.38 |
| | Tried it anyway, no difference. | 12:58.05 |
| | Whoel file is a diff in git diff. | 12:58.13 |
| | What does recording a patch do tor8 ? | 12:58.28 |
| tor8 | kens2: I meant you can create a new commit that fixes the whitespace problems in opj_malloc.h | 12:58.54 |
| kens2 | THey are already fixed, chrisl did it. | 12:59.07 |
| | Michael will have the same problem and possibly also henry, do we all haev to do this ? | 12:59.22 |
| tor8 | ah, but they're fixed in the "future" from where your master is sitting | 12:59.26 |
| | should have a ? at the end there | 12:59.44 |
| kens2 | Yes, true | 12:59.58 |
| | My code is a bit behind the times | 13:00.06 |
| tor8 | and the whitespace issues are preventing you from rebasing | 13:00.11 |
| kens2 | Yes... | 13:00.17 |
| tor8 | right. | 13:00.19 |
| kens2 | But if I commit the change, what does that do to master ? | 13:00.27 |
| tor8 | nothing unless you push :) | 13:00.39 |
| | trying to think of a smart way to solve this | 13:00.53 |
| kens2 | Yes, OK, but then I'll have a lingering staged commit, so I'll be unable to push.... | 13:01.06 |
| tor8 | does stashing work? probably not. | 13:01.07 |
| kens2 | Can't stash, that's part of the problem. | 13:01.15 |
| | I have changes I would prefer not to lose (not desperate though) | 13:01.30 |
| tor8 | yeah. you could try temporarily turning off the whitespace settings. | 13:01.33 |
| kens2 | I think its too late, the've been applied ot the local file already ? | 13:01.54 |
| tor8 | kens2: you can save your changes to a patch-set that you can later reapply | 13:01.54 |
| | with the "git format-patch" and "git am" commands | 13:02.04 |
| kens2 | Well I have a patch already, which is why its not desperate | 13:02.08 |
| tor8 | kens2: if you turn them off, and do a new "git checkout -- path/to/file", the new checkout should come out acceptably | 13:02.30 |
| kens2 | OK how do I turn it off ? | 13:02.50 |
| | Can't remember that far back... | 13:02.59 |
| tor8 | but I think doing the "format-patch" to get the commits saved, forcing your way to the front and reapplying the patches manually with "git am" is easier | 13:03.08 |
| | kens2: .git/config has a few settings, I'm not sure exactly which ones matter though | 13:03.25 |
| kens2 | OK forget that. What do you mean by hte 'format-pacth' ? | 13:03.39 |
| | I can redo the changes. | 13:03.52 |
| tor8 | git format-patch <commit> will create files containing the commits up to <commit> in a format you can reapply later | 13:04.35 |
| kens2 | Don't worry about that. | 13:04.48 |
| | How can I force to head ? | 13:04.56 |
| tor8 | it saves the commit messages etc | 13:04.59 |
| chrisl | tor8: what about cherry-picking the commit that converted line-endings? | 13:05.11 |
| tor8 | chrisl: won't that mess up history and/or merging? | 13:05.39 |
| kens2 | I'm now back at f369ae5, my UUID change. The only thing which is different is opj_malloc.h | 13:06.00 |
| | I need to get to the current head, if soemone can tell me how I'll be happy. | 13:06.26 |
| chrisl | I don't know, just thinking outload | 13:06.34 |
| tor8 | kens2: I'd make a backup of your branch first (git checkout -b my_backup_branch) | 13:06.35 |
| | kens2: then "git checkout master" followed by "git reset --hard origin/master" | 13:06.51 |
| | then you should be able to cherry-pick your patch from the backup-branch onto master | 13:07.25 |
| kens2 | switched to a new branch. Switched to branch 'master'.HEAD is now at 766df64 Suppress some warnings in gdevcups.c | 13:08.13 |
| | git status shows clean | 13:08.28 |
| | Seems to be OK. | 13:08.43 |
| | How can I get rid of the branch ? | 13:09.48 |
| sebras | git branch -D branch_name | 13:10.26 |
| kens2 | Thanks sebras, and thanks tor8 as well. | 13:10.38 |
| | Possilby prematurely, still waiting for my push to go through | 13:10.56 |
| | This time it worked, thanks tor8 | 13:11.14 |
| | You will probably have to do the same with Michael later. | 13:11.25 |
| | That was astonishingly quick. | 13:12.37 |
| tor8 | kens2: yeah, saving your work on a branch, resetting to head and cherry-picking is probably one of the easier and safer ways to recover when you're lost | 13:15.52 |
| kens2 | I meant the cluster push was quick :-) | 13:16.12 |
| | Hmm, looks like the reason it was quick is because my initial push *did* work, in as much as it copied the files and started the test. By the time I came to do the next one, the previous run was practically finished, and I thought it was the same run. | 13:19.56 |
| | This one looks like its going to take a more sensible amount of time. | 13:20.07 |
| | robin_watts_mac : working while on holiday ? | 14:14.38 |
| malc_ | tor8: i started getting "warning: pixmap memory exceeds soft limit 321M + 0M > 256M" messages on x86_64 machine any idea why? | 14:22.52 |
| kens2 | could be related to the memory leak bug ? | 14:23.11 |
| | bug #692436 | 14:23.34 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=692436 | 14:23.43 |
| robin_watts_mac | kens: had an idle hour, yeah. | 14:26.40 |
| kens2 | When do you get home Robin ? | 14:26.59 |
| malc_ | kens2: i wonder why i'm getting it on x86_64 and not on ppc | 14:27.08 |
| kens2 | malc_ it may not be the same as that bug then. | 14:27.26 |
| robin_watts_mac | kens2: a week. | 14:27.44 |
| malc_ | well. thing is i recycle pages (pdf_free_page) much faster on ppc32 since it only has 512M of RAM.. | 14:27.58 |
| robin_watts_mac | land next wednesday. | 14:27.59 |
| kens2 | Ah, just in time to get washed up and ehad for Chicago ;-) | 14:28.03 |
| | malc- No idea sorry, you probably need tor, just thought it might be related. | 14:28.28 |
| robin_watts_mac | just in time to go on a crash diet before chicago, yeah. | 14:28.47 |
| kens2 | :-O | 14:29.06 |
| malc_ | kens2: just verified - yeah i must free_pages more often... | 14:30.05 |
| kens | sorry, network died.... | 14:40.00 |
| henrys | we need a bugzilla banner that says "attach test file" | 14:42.51 |
| kens | :-) | 14:43.00 |
| henrys | another potential customer meeting today, 3rd this week... | 14:44.47 |
| kens | That's got to be good news though? | 14:45.00 |
| henrys | it might be a promising leading indicator or it's a coincidence. | 14:45.32 |
| kens | Its probably co-incidence, but as long as we keep on generating new potential customers, that's good. | 14:46.00 |
| henrys | chrisl:I wonder if the download page should just say: This page will help direct you to downloads and information about the open source and commercial releases for GhostScript, GhostPCL ... and not have 2 lines on for open and commercial the release are already separated on the actual download page. | 14:52.14 |
| chrisl | henrys: Ray wanted the full names there - I'd be happy to change it. | 14:55.03 |
| ray_laptop | morning all | 14:55.32 |
| henrys | oh okay well maybe he had some reason I'll check next I hear from him. | 14:55.40 |
| ray_laptop | chrisl: henrys: which URL are you talking about ? | 14:56.33 |
| henrys | ray_laptop:howdy, just had a question for you see above. I'm off to a meeting. | 14:56.37 |
| chrisl | henrys: as ray_laptop just appeared, he can answer for himself - but I think it was to try to catch searches for "GPL Ghostscript" or "Artifex Ghostscript" | 14:56.50 |
| ray_laptop | I'll check the logs ... | 14:57.24 |
| chrisl | just wants to state *once again* how much he hates Acrobat and all its works..... :-( | 14:58.33 |
| ray_laptop | chrisl: I see the question from 5 minutes ago, but don't understand it. Which 'download page' ? | 14:59.04 |
| chrisl | ray_laptop: our download page | 14:59.26 |
| ray_laptop | chrisl: URL please ??? | 14:59.33 |
| chrisl | http://www.ghostscript.com/download/ | 14:59.42 |
| ray_laptop | chrisl: OK. I was looking at the older http://downloads.ghostscript.com/public/ (which we should probably hide) | 15:00.29 |
| chrisl | ray_laptop: I don't know how to do a redirect, but I'll check with marcos when I remember. | 15:01.29 |
| ray_laptop | chrisl: what is that funky M with a magnifying glass doing on the page. Don't we want the Artifex logo instead ? | 15:02.54 |
| chrisl | ray_laptop: that is the MuPDF logo | 15:03.18 |
| malc_ | hmm.. i think i just hit a bug in, drum roll, ghostscript: http://www.valvesoftware.com/publications/2009/ai_systems_of_l4d_mike_booth.pdf page 7, the image has a nasty horizontal line.. | 15:04.12 |
| kens | Probably two images butted up. | 15:04.57 |
| ray_laptop | chrisl: how about we put the Artifex logo on the top left, and the mupdf logo down with the mupdf download on the right below the ghostscript 'g' (and maybe repeat the Artifex logo to the left there as well) | 15:05.07 |
| chrisl | ray_laptop: when I asked before, no one wanted the Artifex logo on that page | 15:05.48 |
| ray_laptop | Did someone object to it for some (religious) reason, or was it just not mentioned ? | 15:06.32 |
| chrisl | ray_laptop: I can't remember, but I think it revolved around no one really liking the Artifex "A" | 15:07.08 |
| ray_laptop | having the 'M' on the left when Ghostscript is mentioned first is (IMHO) confusing. | 15:07.21 |
| | chrisl: IMHO, Artifex needs more branding of the TM | 15:07.51 |
| chrisl | The problem is that the rest of the site has the "G" on the right | 15:08.01 |
| ray_laptop | then let's at least move the 'M' down to the mupdf section and have it off to the right as well | 15:09.26 |
| | chrisl: so the original question was about the phrasing and duplication in the top paragraph ? | 15:16.11 |
| | chrisl: I agree that it's a little clunky | 15:17.03 |
| | chrisl: plus the links for the 'Artifex Ghostscript' etc. don't take you to the Artifex downloads, but to the general downloads. | 15:18.31 |
| | I meant general Artifex info pages (which suck) | 15:18.59 |
| chrisl | ray_laptop: the links on the product pages take you to the commercial downloads page | 15:19.34 |
| | except MuPDF. I'm not sure how the commercial release gets distributed | 15:20.08 |
| ray_laptop | chrisl: no, they take you right back to the http://www.ghostscript.com/download/ page | 15:20.15 |
| chrisl | No they don't | 15:20.28 |
| ray_laptop | after going to "http://www.ghostscript.com/" | 15:20.43 |
| | chrisl: once you get to something like http://www.ghostscript.com/download/gsdnld.html it's OK | 15:21.38 |
| chrisl | Well that's what I was told was wanted - a "hand-holdy" set of links that gets to the product, and then you choose whether you want the GPL or commercial download. | 15:22.30 |
| ray_laptop | chrisl: but if you click on 'Artifex Ghostscript' from the http://www.ghostscript.com/download/ page, then click on the 'Download Ghostscript' there, it takes you to http://www.ghostscript.com/ | 15:22.53 |
| chrisl | ray_laptop: Well, I have no control or access to the Artifex pages | 15:23.51 |
| ray_laptop | chrisl: OK. I thought we wanted the 'which license is right for me' to be on the first page | 15:24.45 |
| | where we first mention the commercial release | 15:25.12 |
| chrisl | That wasn't what I understood | 15:25.32 |
| ray_laptop | chrisl: np. Let me test it with some uninformed people and see if they can make sense out of it, then I'll pull together an alternate 'flow' to propose. | 15:26.42 |
| | chrisl: for now, let's leave it alone | 15:27.21 |
| | the page still doesn't look very 'spiffy' | 15:27.38 |
| chrisl | ray_laptop: it still needed to fit in with the rest of the site, so it was always going to be simple | 15:34.10 |
| | ray_laptop: what about: http://www.ghostscript.com/~chrisl/binaries/ | 15:34.21 |
| henrys | I didn't know we were going to review the design of the page I just thought the extra line was redundant. | 15:40.08 |
| kens | design review next meeting ? | 15:40.23 |
| henrys | these things often take a long time since everyone has an opinion. Can't we just recommend things to chrisl and he strike them down. | 15:42.16 |
| chrisl | henrys: As I said, that full list of both GPL and AFX products wasn't in my first pass, but were added in the hope of catching searches - I was going to look into including them as meta-tags instead of visible text, but not as a priority. | 15:43.47 |
| henrys | sounds good to me. | 15:44.37 |
| | tor8:are you about? | 15:44.56 |
| tor8 | henrys: yes. | 15:45.06 |
| henrys | a new customer would like a way to invert the output of mupdf I assume that can be done somehow. | 15:45.54 |
| tor8 | invert how? colors? upside down? | 15:46.08 |
| henrys | colors | 15:46.24 |
| | swap black and white. | 15:46.34 |
| tor8 | well, they have the bitmap out, looping over that and doing 255-byte should do the trick. unless they want to preserve colors for images? | 15:47.10 |
| henrys | I was hoping for something like settransfer in postscript | 15:47.47 |
| tor8 | they could also make a custom colorspace, but that'll be slower | 15:47.58 |
| | there are no transfer functions in the mupdf renderer. post processing is the way we do things like it. | 15:49.00 |
| henrys | okay could you write a simple patch to do it with an option, and I'll send it to them, you don't have to integrate it if you don't want it. Seems like something you wouldn't want to do postprocess performance wise but anyway... | 15:51.01 |
| | this is something that concerns me with integrating mupdf generally, I think we might have a lot of user doing postscript customizations on the command line: like this could be done with {1 exch sub} settransfer - not clear how mupdf + gs is going to handle that stuff. | 15:52.44 |
| | but the good news it looks like we have a new mupdf customer if they can get everything working. | 15:55.44 |
| chrisl | I'm off to play squash...... | 16:01.20 |
| tor8 | henrys: right. I've had free users make their own patch for inverting the rendering before. | 16:01.25 |
| kens | Heading off for the night, see you all tomorrow | 16:45.50 |
| tor8 | henrys: I've pushed a patch that adds gamma correction and color inversion command line options to pdfdraw. | 17:28.00 |
| henrys | thanks tor8, I'll pass it along | 17:46.47 |
| ray_laptop | hi, mvrhel2 | 19:29.09 |
| mvrhel2 | hi ray_laptop | 19:29.22 |
| ray_laptop | I saw your email about the handle leakage issue | 19:29.23 |
| mvrhel2 | yes. I fooled around some more with that | 19:29.34 |
| ray_laptop | look like we never tear down the outermost graphics state or something | 19:29.47 |
| mvrhel2 | but it appears to me that our shut down of the graphic state is not really complete | 19:29.50 |
| | yes | 19:29.52 |
| | several objects remain | 19:29.59 |
| ray_laptop | from what I recall (working on something else right now) the graphics state is not getting freed. | 19:30.54 |
| mvrhel2 | the hafltone, the pattern cache, undercolor removal, black generation, icc_manager, link_cache, etc | 19:30.57 |
| ray_laptop | i.e. there is still a graphics state that 'owns' them laying around | 19:31.35 |
| mvrhel2 | all these these exist still in the graphic state when we are shutting down | 19:31.42 |
| | yes | 19:31.44 |
| | rc objects seem to have a ref count of 3 | 19:33.37 |
| | anyway, it appears that I screwed up my git checkout | 19:34.26 |
| | need to fix that now | 19:34.29 |
| | but first need to go grab lunch | 19:35.40 |
| | bbiab | 19:36.12 |
| ray_laptop | it's definitely not freeing the graphics state (I set a bp on gstate_free) | 19:46.04 |
| henrys | tor8:are you still up? | 20:16.12 |
| mvrhel2 | ray_laptop: ok so you are seeing the same thing that I am. You can see the member variables and their rc's | 20:27.07 |
| | it would seem like there should be a finalize for the graphic state to clean up everything when we are shutting down | 20:27.35 |
| henrys | I think he timed out ... using the other restore function didn't work? | 20:28.56 |
| mvrhel2 | henrys: I could not understand where I would do that | 20:30.52 |
| henrys | the base gstate is holding the references right? | 20:32.26 |
| | where is the bug again? | 20:33.07 |
| mvrhel2 | hold on | 20:33.41 |
| | 692372 | 20:34.54 |
| | so run tiger.eps | 20:35.07 |
| | with ppmraw | 20:35.09 |
| | and put a breakpoint in imainarg.c | 20:35.18 |
| | line 222 | 20:35.21 |
| | look at minst->i_ctx_p->pgs | 20:35.49 |
| | when we are all done | 20:36.36 |
| henrys | assign it to ray it all that stuff leaks, it isn't just you. | 20:36.37 |
| mvrhel2 | yes | 20:36.43 |
| henrys | a save restore will help but some stuff is allocated in stable memory | 20:37.17 |
| | or I'll work on it if he doesn't want to. | 20:38.09 |
| mvrhel2 | ok. Adding a comment and then I will reassign | 20:38.58 |
| henrys | you've got color stuff that only you can do so I don't think it should live with you. | 20:39.01 |
| mvrhel2 | henrys: do you want me to assign to you to have an initial look? Ray may be busy with customer 532 | 20:40.29 |
| henrys | sure | 20:40.40 |
| mvrhel2 | ok there you go | 20:45.54 |
| | weird. git resest hard followed by git up is complaining that I have unstaged changes | 20:48.47 |
| | ok it is this damn opj_malloc.h file | 20:50.11 |
| | henrys: am I the only one having issues with this file? | 20:50.23 |
| | this is on linux | 20:50.26 |
| henrys | no you are not. | 20:50.33 |
| mvrhel2 | it appears to be a CRLF issue | 20:50.42 |
| henrys | yes we fixed it yesterday. | 20:50.53 |
| mvrhel2 | ah. ok | 20:51.00 |
| | let me stash this then updape | 20:51.11 |
| | update | 20:51.13 |
| | grrr | 20:51.44 |
| henrys | that did not work for me I ended up recloning - something with auto handling of CRLF that I didn't feel like figuring out. | 20:51.53 |
| mvrhel2 | crap | 20:52.02 |
| | it does not seem to work for me either | 20:52.12 |
| | maybe if I delete the file | 20:52.17 |
| henrys | then you'll have an unstaged change ;-) | 20:53.35 |
| mvrhel2 | maybe I need to revert the file | 20:54.41 |
| | of course git reset should do that | 20:55.25 |
| henrys | I'm sure there is some way of doing it but a clone just takes a minute or so. | 20:55.33 |
| mvrhel2 | yes | 20:56.34 |
| | there. I backed up one commit and the did a git up | 20:59.02 |
| | hmm that did not work | 20:59.32 |
| | ok. time for a clone | 20:59.48 |
| | oh I see | 21:00.29 |
| | now I have it | 21:01.03 |
| | so backing up did work. just needed to delete the openjpeg stuff before doing the update | 21:01.22 |
| | rats 691800 has just gotten more complicated | 22:00.36 |
| | just realized pdf write does not do a | 22:01.36 |
| | \B command | 22:01.39 |
| | grumble grumble. for high level devices we should pass this one along | 22:02.49 |
| robin_watts_mac | mvrhel2: hi. I clusterpusheda possible fix for the rounding bug last night. | 22:58.31 |
| | but of course, no tiffsep testing in the cluster. | 22:58.42 |
| | Changing hotels/cities. back later | 23:06.08 |
| mvrhel2 | robin_watts_mac: great! | 23:07.38 |
| | Forward 1 day (to 2011/08/18)>>> | |
IRC Logs