Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2019/09/23)Fwd 1 day (to 2019/09/25) >>>20190924 
rnissl Hi kens, I've got a further regression with 9.28rc3.14:10.22 
  gswin32c" -dBATCH -dNOPAUSE -q -c .setsafe pstack14:10.46 
  GPL Ghostscript RELEASE CANDIDATE 3 9.28: Unrecoverable error, exit code 25514:10.46 
kens Hmm, let me pass you to someone else, I'm up to my ears right now. chrisl ping ?14:11.21 
rnissl -c .setsafe fails without -dNOSAFER14:11.26 
kens Well you don't need .etsafe, since we are already safe in this case. But I guess it shoudl not throw an error14:11.50 
  OK seems chrisl is not about, I can confirm that calling .setsafe exits the interactive prompt, which it shouldn't do14:14.01 
rnissl I totally agree with you. In 9.28 -c .setsafe is not necessary as it is the default, and it should not throw an error14:14.05 
kens I'll try and find out why14:14.14 
  BTW, thanks for finding it14:14.48 
  testing is much appreaciated14:14.58 
rnissl well, I just wanted to start early this time -- last time I couldn't use official 9.27 due to some issues14:16.01 
kens We suspected there would be trouble this time, that's why we started the release so early14:16.23 
  Looks to me like .setsafe probably should check the current SAFER and exit without doing anything if its set. I htink its trying to change stuff its not allowed to14:17.51 
  Yes, its tryign to lock the file accesses and since tehy are already locked, that throws an error14:19.02 
chrisl Here now14:25.44 
kens wb14:26.24 
  If you run GS and then execute .setsafe, it exeits with an error14:26.40 
  unless you started with NOSAFER14:26.48 
chrisl Well, don't do that14:26.51 
kens Yeah but it really shouldn't exit I'd have thought ?14:27.02 
  TBH I'm not exactly sure where its exiting, I'm not hugely familiar with all this new code14:27.21 
  oh probably .addcontrolpath14:27.43 
chrisl Yes, probably14:27.54 
kens Yes, calling .addcontrolpath when we're already in safer mode calls gs_is_path_control_active, which returns true and we throw a fatal error14:29.23 
chrisl I suppose I can tweak .setsafe, but I'm rather surprised it didn't throw an error previously14:29.42 
kens I tried checking SAFETY /setsafe get in .setsafe and its not set14:30.18 
  mereting time, lets adjourn for 30 minutes14:30.41 
chrisl We don't set SAFETY any more14:30.48 
rnissl gs-9.26 doesn't exit if .setsafe is called multiple times14:30.53 
kens chrisl I didn't know any other way to test if we had locked safety14:31.12 
  And we can't (apparently) use stopped to get out of a fatal error14:31.24 
  chrisl could we add a PostScritp operator for gs_is_path_control_active() and use that to not try and set path control to active (with a warning, I would suggest)14:35.11 
chrisl No, we didn't14:35.24 
kens I know we didn't, but would that be a reasonable solution ?14:35.48 
chrisl I'm looking at it now14:35.58 
kens Then I'll shut up14:36.05 
chrisl kens: https://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=13344a38b1d0f9b882ffa3bb429603fec8237ac214:56.10 
kens chrisl I'd be inclined to emit a warnign if we execute .setsafe and we already haev the file paths locked. butotherise, yes that's exactly what I was thinking of14:57.39 
chrisl kens: I'm struggling with a wording that will mean anything sensible to an end user....15:00.19 
kens Something like 'PostScript program executed .setsafe while already in SAFER mode'15:00.41 
  Only savvy people should be using .setsafe (because it implies DELAYSAFER, or at least *some* knowledge of SAFER)15:01.11 
Robin_Watts chrisl: Did you have an opinion on the steak/steak/fish vs steak/chicken/fish question?15:01.33 
kens So ordinary users shouldn't see it, if they do it means their PostScript program was up to something suspicious15:01.37 
Robin_Watts Balls, wrong group.15:01.41 
kens chrisl its not so much end users I'm thinking of, but people like rnissl who might quite like to know that this has happened.15:02.25 
rnissl I do ;-)15:02.49 
chrisl kens: Yeh, I've been slightly trying to divorce "SAFER" from "file access controls"15:02.58 
kens Then say maybe 'while file access was already locked'15:03.13 
chrisl Which might confuse people who've called .setsafe.....15:03.38 
kens 'Attempt to lock file access, when file acces had previousl already been locked. Suspicious behaviour has been prevented to protect you'15:03.49 
  for your protection*15:04.02 
Robin_Watts mvrhel_laptop: come to #artifex... you know you want to...15:07.26 
chrisl kens: https://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=05e794d14a2853c45a08d5c49d50d1fa5cadaf6c15:08.47 
kens Looks fine to me15:09.10 
chrisl kens: I also have: https://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=5ca729649efc3b041237b8b45bd2d011b70143ff15:09.24 
kens Umm, maybe you should get Robin to look at that one ?15:10.05 
  I mean, it looks fine, but I'm not really up to speed with all that15:10.27 
chrisl At the moment if you give tiffsep(1) an output file like out.tiff, you end up with out.tiff(Sepname).tif for the separation files15:11.21 
kens Ah, I see, well that's certainly an improvement then15:11.44 
chrisl I found it confusing because the composite preview was still out.tiff15:12.17 
kens That would indeed confuse *me* !15:12.34 
chrisl Okay, I haven't been able to induce a problem with Robin's and my access control changes, so I'm going to push all that stuff - assuming this cluster run is clean15:14.17 
kens Great, needs to be done. Planning to wait until next week for RC4 ?15:14.51 
chrisl Yes, probably - on the off chance someone else on the team decides to do some testing.....15:15.43 
kens And time for replies from the distros15:15.59 
chrisl And also, after next week, nothing can really happen for nearly two weeks15:16.34 
kens Yeah.15:16.45 
kens hopes we're done now.....15:17.02 
chrisl Well, I'm also thinking, maybe do another release test run next week15:17.33 
kens Ugh, well I suppose there have been a few changes. Presumably test against the RC1 tagged code ?15:18.09 
chrisl RC2, that was the last set of release tests we did15:18.39 
kens Oh OK, my mistake15:18.48 
chrisl There's really only two commits that *might* influence rendering (and one of those is unlikely at worst).15:20.38 
kens So it should be a quick and easy test :-)15:20.55 
chrisl Truly, I've lost count of how often I've been wrong about that!15:21.45 
kens I knew I was tempting fate even saying it15:22.01 
chrisl rnissl: Thanks for spotting the .setsafe issue15:22.48 
rnissl chrisl, you're welcome15:23.02 
  ghostscript is and has been one of my favourite tools since the early nineties ;-)15:24.46 
chrisl rnissl: I just hope we're not putting you off! Unfortunately, the way things have gone has meant rethinking decisions made a long time ago, and the result is a certain level of upheaval for some users - for which we are sorry, but couldn't see an alternative15:27.45 
ray_laptop rnissl: sounds like you started with gs about the same time as me (version 2.5.1)15:35.11 
  I don't recall the exact date that was released -- I still have 3.33 laying around and that was Oct 199415:36.08 
  oh, google tells me 2.5.1 was 9/11/9215:37.56 
  version 1.0 was 8/11/8815:41.17 
  I should see if I can put together a git repository that goes way back (just for posterity) The Artifex git doesn't start until 199815:46.00 
rnissl chrisl, I don't mind the issues I had with rc1 to rc3. I just wanted to start testing erlier that with 9.27.16:02.17 
chrisl rnissl: That's good, and it is appreciated16:03.22 
rnissl ray_laptop, I think I have even used 2.4.x on my Amiga 3000T -- spent quite a while to compile it ;-)16:04.21 
  and around 1995 I reported a couple of issues with tiff g4 encoding to L. Peter Deutsch16:06.34 
  will leave for today -- thanks for your support, looking forward to rc4.16:28.55 
kens bb and thanks again for the testiong16:29.14 
 <<<Back 1 day (to 2019/09/23)Forward 1 day (to 2019/09/25)>>> 
ghostscript.com #mupdf
Search: