https://bugzilla.redhat.com/show_bug.cgi?id=1594313 --- Comment #32 from jiri vanek <jvanek@xxxxxxxxxx> --- > 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. Are they really out? I'm really afraid of leaving (again) behind. Can we keep it in untill the review is finished, so all is done with it in mind? If the shenandoah repo is still not accptable at that time, Then I will bow and remove it. Hmm? > > > > > 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 ++ prit a bit of what is ahppening > > HUGE +1 Thanx for adding courage :) > > > + generate also systemtap (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..., zzzz. I can survive comment saying what envrionmet variable to set to what :( > > > 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). ok. It should not be my workflow (although it grown into it), it should be genereic helper. If it do not serve that, then it should be removed. Still I like it *much more* then comment with "VERSION=..." > > 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 The monolitic repo have huge performance problems when cloned. If this will be faster I will swithc to it. Thanx for reminding this approach. btw - you highligh the reproducible sources - you mean after unpack, right? Or do you wont to tkae similar approach as https://src.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/repackReproduciblePolycies.sh?h=f28 did? Is it even possible with tar.xz? Thanx for review! -- 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/JR74J7OFCWYYILF3FWQW5UEOOT7ZZ6P6/
