https://bugzilla.redhat.com/show_bug.cgi?id=1594313 --- Comment #27 from jiri vanek <jvanek@xxxxxxxxxx> --- (In reply to Severin Gehwolf from comment #17) > # to regenerate source0 and source1(shenandaoh hotspot) run update_package.sh > # update_package.sh contains hardcoded repos, revisions, tags, and projects > to regenerate the source archives > # at the end it sed specfile and sources to match those new names > # FIXME adapt the script to work better on shenandoah hotspot (After the > jdk10 and removal of forest). Current source1 was done by manual delete > # FIXME: adapt the sed to new specfile and sources or drop those parts > # next update will be used to tweek those two files > Source0: jdk-jdk-jdk-%{majorver}+%{buildver}.tar.xz > > I'm missing a short and concise: > > # Use this to generate the source tarball: > # $ VERSION="jdk-11+19" PROJECT_NAME=jdk REPO_NAME=jdk \ > # bash generate_source_tarball.sh Yes because I disagree with that approach. Those flags do not have sense without wider context. Thats why I wont to tune update_package.sh to be more straightforward and not doing redundant things. > > # Shenandoah HotSpot > # current name used with tip and bleading edge may be incorrect > Source1: jdk-shenandoah-jdk-ac148db384ee.tar.xz > > With JDK 11 I'm doubtful we should continue with the different hotspot for > shenandoah arches approach. One single tarball for all arches would be > better. We'll discuss this elsewhere. I'd suggest to leave shenandoah out > for now and add it back in when the upstream repos are ready. Yup. I have noticed your conversation. It would be really nice to have only one source tarball. Still we agreed to have shenndaoh in LTS versions. What is the purpose of not having it on since start? What is the moment to add it? Forking? Will Shenandoah team be her i time? I would match rather keep Shenandoah hotspot for 64b intel and arm, even on tip, rather then waiting for some moment i future to add it. By having it in will allow me to track it, and to ping Shenandoah team in time. > > # Systemtap tapsets. Zipped up to keep it small > # Use 'generate_tarballs.sh' to generate the following tarballs > # They are based on code contained in the IcedTea7 project > # The script have hardcoded url and revision > # FIXME discover what exactly is current systemtap from or > # FIXME current systemtap is not working, new version is necessary > Source8: systemtap-tapset-3.6.0pre02.tar.xz > > All of those comments above suggest we don't have a good way to regenerate Nope, the regeneration of tapset is deterministic, but was not done properly in one moment. IIRC, there was issue found and several chaotic pulls without updating the clonning file. > each tarball. I have a feeling that update_package.sh has too many > responsibilities. Ideally there would be one script or one command per > tarball doing just that: producing one source tarball in a reproducible way! So the steps I wont t do: - rename generate_tarballs.sh to regenerate_systemtap.sh + tune the script to point to current valid locations + get rid of the icon and desktop file as ithave nothing common now + we need to agree on systemtap versioning and releaseing (see stalled thread on java-team) - rename generate_source_tarball.sh to generate_openjdk_tarball.sh + keep it as it is - modidy update_package.sh + maybe rename it to generate-sources.sh + simplyfy its logic. ++ stop touching specfile ++ stop touching sources + generate also ystemtap (if necessary) and so on - its reason really si to replace comment you suggest, by pushed, right-away for use script. Changes to update_package I would like to keep for next update of sources -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx/message/UQYP3QFF77UQGXAPTCZ7EYJMV3WYSTJM/
