Created attachment 1714426 [details]
[patch] Update to 9.53.0 (#1877781)

Latest upstream release: 9.53.1
Current version/release in rawhide: 9.52-8.fc33
URL: http://www.ghostscript.com/

Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.


Based on the information from anitya: https://release-monitoring.org/project/1157/

Created attachment 1714819 [details]
[patch] Update to 9.53.1 (#1877781)

Blocked on jbig2dec update (PR: https://src.fedoraproject.org/rpms/jbig2dec/pull-request/3)

jbig2dec 0.19 is in a side tag now. Please build gs 9.53.1 for rawhide with:

fedpkg build --target=f34-build-side-30401

This gives an interesting dependency chain:

jbig2dec in side tag
gs in side tag
gs+jbig2dec(+others) update (tag merge)

So, I'm not sure which bug should block which in bz any more, but mapping that to bz dependencies might be overkill anyways.

I assume that this is good for f33 and f32 once it is in rawhide, right?

(In reply to Michael J Gruber from comment #5)

> So, I'm not sure which bug should block which in bz any more, but mapping
> that to bz dependencies might be overkill anyways.
+1

> I assume that this is good for f33 and f32 once it is in rawhide, right?
Not sure if I understood your question correctly, but I feel like for f33 and f32 the process should be similar - you create a side tag with fedpkg request-side-tag --base-tag f33-build, build jbig2dec 0.19 with it, I build gs 9.53.1, tag merge. Please correct me if I'm wrong

Updated gs to 9.53.1:

https://src.fedoraproject.org/rpms/ghostscript/c/1f50b8733044fcc7f46ab4fe82c7f26ab8c94312?branch=master
https://src.fedoraproject.org/rpms/ghostscript/c/37d6ad620072bcca397ce24f4dc53930a584be6f?branch=master

(In reply to Anna Khaitovich from comment #6)
> (In reply to Michael J Gruber from comment #5)
> 
> > So, I'm not sure which bug should block which in bz any more, but mapping
> > that to bz dependencies might be overkill anyways.
> +1
> 
> > I assume that this is good for f33 and f32 once it is in rawhide, right?
> Not sure if I understood your question correctly, but I feel like for f33
> and f32 the process should be similar - you create a side tag with fedpkg
> request-side-tag --base-tag f33-build, build jbig2dec 0.19 with it, I build
> gs 9.53.1, tag merge. Please correct me if I'm wrong

Sorry for being so terse. I meant to ask which branches you intend gs 9.53 to push to since gs is the main user of jbig2dec, and I feel mupdf and dependencies should follow your lead here. So we have:

f34-build-side-30401
f33-build-side-30597
f32-build-side-30599

All of them have jbig2dec-0.19-2 now.

The f34 target is "complete" except for zathura-pdf-mupdf (PR submitted), which I should wait for for a few days (before submitting the bodhi update for the side-tag builds), I guess. Or "push to push" ;)

f34 target is complete, and as per bodhi's error message, I would need commit access for gs and zathura-pdf-mupdf to submit the update.
I find that somehow strange as submitting another packager's build (which the packager put into the tag) should not need the same access level as committing to the dist-git repo and building into release or side tags.

So, if you have the nevessary access level, feel free to submit the update for f34.

f33 and f32 are missing gs only, so all lights are green for you :)

FEDORA-2020-9c3074c5d3 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-6d5bd33964 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6d5bd33964

FEDORA-2020-020dea71ed has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-020dea71ed

FEDORA-2020-6d5bd33964 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6d5bd33964`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6d5bd33964

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-020dea71ed has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-020dea71ed`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-020dea71ed

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-020dea71ed has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-6d5bd33964 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.