This is already caught upstream in the bug https://bugs.ghostscript.com/show_bug.cgi?id=703270.

The fix is here: http://www.ghostscript.com/cgi-bin/findgit.cgi?c6166768c6e963b0fe28ccdb266629443e521381

A fix with merged fix in ghostscript-9.53.3-2.3.mga8 has been uploaded to updates_testing.

Thank you for the report, and the work you have done on it.

It seems that you have done the correction. Can you please:
- say exactly what packages & SRPMs are updated
- with their full new version numbers
- and write a short advisory
TIA

Assignee: bugsquad => qa-bugs
CC: (none) => lewyssmith

Confirmed the error with a .ps file created with an earlier update test. "Purple07.ps" is a photo of part of the inflation of a hot air balloon, and is viewable in Okular with no errors.

With no response to the request from Comment 3, I used the 64-bit rpm list from http://madb.mageia.org/tools/listRpmsForQaBug/bugnum/30409/application/0 in qarepo:

ghostscript-9.53.3-2.3.mga8.x86_64.rpm
ghostscript-X-9.53.3-2.3.mga8.x86_64.rpm
ghostscript-common-9.53.3-2.3.mga8.x86_64.rpm
ghostscript-doc-9.53.3-2.3.mga8.noarch.rpm
ghostscript-dvipdf-9.53.3-2.3.mga8.x86_64.rpm
ghostscript-module-X-9.53.3-2.3.mga8.x86_64.rpm
lib64gs-devel-9.53.3-2.3.mga8.x86_64.rpm
lib64gs9-9.53.3-2.3.mga8.x86_64.rpm
lib64ijs-devel-0.35-162.3.mga8.x86_64.rpm
lib64ijs1-0.35-162.3.mga8.x86_64.rpm

No installation issues. However, when I ran the command again, I got this:

$ ps2epsi Purple07.ps
Error: /typecheck in --readstring--
Operand stack:
   --nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   %loop_continue   --nostringval--
Dictionary stack:
   --dict:734/1123(ro)(G)--   --dict:0/20(G)--   --dict:129/200(L)--
Current allocation mode is local
Current file position is 5987
GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1

"Purple07.epsi" was created, despite the error, though I don't know how to confirm that the file is usable. While the resulting file may be valid, I cannot OK this without investigating this "unrecoverable error."

CC: (none) => andrewsfarm

Thanks for the file list. If you get that error, then the original .ps file is corrupt, or you hit "another" gs bug.

When it works, the ps2epsi conversion shouldn't give any error, it simply produces the .epsi file.

If you don't have a PostScript or EPS file, you might try to generate one using imagemagick. Example suppose you have picture.jpg, you might use:

convert picture.jpg picture.ps
convert picture.jpg EPS:picture.eps

ps2epsi picture.ps picture.epsi
ps2epsi picture.eps picture_alt.epsi

Then .epsi files are visible in any postscript/pdf previewer (e.g. okular, evince, or gv).

There is also the ghostscript-9.53.3-2.3.mga8.src.rpm (and the debug rpms which I don't know whether are needed to the requested package list too); I think there is needed also the .i586 file list for 32bit platform (and I guess for arm and aarch64).

OT: I think that we need a tool to generate automatically the filelist from the build.log. At the end of any buildlog file there is appended a string with:

Wrote /home/iurt/rpmbuild/RPMS/x86_64/...*.rpm
Wrote ...

we could use this info to generate automatically the filelist for any built arch. We could add a little script that parse the build.log and saves the produced rpm filelist for all the platforms in a file named as <packagename>-<versiom>-<release>.<distrover>.lst, saved somewhere. Pterjan is that feasible?

CC: (none) => pterjan

The ps file I used was created in early 2020. I don't remember the circumstances now. I created another from another photo as instructed, and it converted to epsi with no problems, and the result was viewable in Okular. So it appears that this is working after all.

The link I gave contains the files for all the arches. A link to a similar page for each bug is available on the http://madb.mageia.org/tools/updates page in the "Lists" column. I believe it is generated from the source file(s) listed in the "Source RPM" field above. If more than one source is required for a particular update, and those extra sources aren't included in that field, they won't be on the list.

I believe you need more guidance on how to prepare an update for testing by QA. This update was not really ready for us. Like most of QA, I'm not a developer, and cannot give you that guidance.

Looks like an accurate package list:
http://madb.mageia.org/tools/listRpmsForQaBug/bugnum/30409/application/0

It sounds like the update fixes the issue in Comment 0.

What else is missing TJ?

Technically nothing, I suppose. A suggested advisory would have been appreciated, but then a lot of updates have been coming through over the last several months without them.

Giuseppe, the debug rpms are not needed in the package list if provided, and in fact get in the way of using the qarepo tool. 

OKing and validating.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: (none) => MGA8-64-OK

As for the short Advisory:

This update provides a fix in the ghostscript conversion tool ps2epsi. Due to a bug in internal LIBPATH, the ps2epsi script couldn't find the necessary ps2epsi.ps file, and thus was giving an error when ps2epsi was called.

--------------------------------

As for the requested package list, I always wonder why it's necessary to post the whole list every time if somewhere is automatically available the right list for all the archs (especially as one could made some typo in posting the right filelist pasting from somewhere, or miss some subpackage (also it's not said that all the archs have the same subpackages).

Wouldn't be necessary just to get the right version-release of the fixing .src.rpm? I thought it was due for someone for manually moving the packages from updates_testing to updates, but apparently this seems not the case.

I forgot the References in the advisory; here is:

- https://bugs.ghostscript.com/show_bug.cgi?id=703270
- http://git.ghostscript.com/?p=ghostpdl.git;h=c6166768c6e963b0fe28ccdb266629443e521381

(In reply to Giuseppe Ghibò from comment #5)
> we could use this info to generate automatically the filelist for any built
> arch. We could add a little script that parse the build.log and saves the
> produced rpm filelist for all the platforms in a file named as
> <packagename>-<versiom>-<release>.<distrover>.lst, saved somewhere. Pterjan
> is that feasible?

That information is already collected by genhdlist2/createrepo, I'd rather not extract it to an additional location.

http://ftp.free.fr/mirrors/mageia.org/distrib/cauldron/aarch64/media/core/release/media_info/20220517-175406-files.xml.lzma

http://ftp.free.fr/mirrors/mageia.org/distrib/cauldron/aarch64/media/core/release/repodata/949c41cbe113d3b52dacd95b74671a654c06d3b434808c67adf1fa12ffd45137-filelists.xml.gz

I don't know if tools support querying them for another architecture/version but I'd rather have that done

(In reply to Giuseppe Ghibò from comment #9)
> 
> As for the requested package list, I always wonder why it's necessary to
> post the whole list every time if somewhere is automatically available the
> right list for all the archs (especially as one could made some typo in
> posting the right filelist pasting from somewhere, or miss some subpackage
> (also it's not said that all the archs have the same subpackages).
> 
> Wouldn't be necessary just to get the right version-release of the fixing
> .src.rpm? I thought it was due for someone for manually moving the packages
> from updates_testing to updates, but apparently this seems not the case.

As I misunderstand it, the src rpm is used when the tested packages are moved from updates_testing to updates. The requested package list makes it easier for QA to avoid missing any packages when we do our testing. That lets us avoid coming back to the packager with a "missing" dependency that wasn't missing at all, just not obvious from the information we had.

The link I gave for the rpm list is sufficient for a bug like this one, where it's relatively simple and no changes or additions were needed after the first test. I don't know exactly how those lists are generated, or how often they are updated, but, if additions or changes ARE needed, there have been times when those rpm lists wern't updated for several days. I can remember one complicated Libreoffice update in particular where that happened, making it VERY difficult to accurately test the update in a timely manner.

We don't request lists for all arches, just i586 and x86_64. It is easiest for us if we have separate lists for each of those two arches, but we can, and often do, work with just one.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2022-0070.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED