https://bugzilla.redhat.com/show_bug.cgi?id=1594313 --- Comment #29 from Severin Gehwolf <sgehwolf@xxxxxxxxxx> --- (In reply to jiri vanek from comment #27) > (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. It seems too risky to keep this without by-in from Shenandoah folks. This has the potential to break x86_64 and aarch64 in strange ways. > > > > # 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 HUGE +1 > + generate also ystemtap (if necessary) > and so on > - its reason really si to replace comment you suggest, by pushed, > right-away for use script. OK. Those are reasonable steps. Just to be clear on the expectations, which I'll make a requirement for this review to pass: - For each source tarball there need to be clear instructions as to how to generate it. That includes all needed parameters to get the exact same tarball (reproducible tarballs) in a comment. I'll be testing it for each tarball individually. - There need to be switches to the script to just generate one tarball or alternatively document steps as mentioned above, VERSION="jdk-11+19"PROJECT_NAME=jdk REPO_NAME=jdk bash generate_source..., > Changes to update_package I would like to keep for next update of sources Like I said, if you are fond of update_package.sh, then this needs to get fixed immediately (or it'll never get fixed). FWIW, with mono-repository these would also be possible instructions for the main tarball: $ wget http://hg.openjdk.java.net/jdk/jdk/archive/jdk-11+19.tar.bz2 $ tar -xf jdk-jdk-11+19.tar.bz2 $ cd jdk-jdk-11+19 $ rm -rf src/jdk.crypto.ec/share/native/libsunec/impl $ patch -Np1 < %{SOURCEX} $ cd .. $ tar -cJf jdk-jdk-11+19.tar.xz jdk-jdk-11+19 -- 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/E5ISCGZHN2YA6TSFQ5JIJ5V7HWL2USNW/
