Hi,
I'm starting to hit more and more challenges in the OpenVPN 3 Linux
project with the RHEL-7 GCC version (which is 4.8.5), especially when it
comes to C++ building. I've tried to keep the project compatible with
RHEL-7 as the oldest supported distro, but it is getting harder and
harder. In addition to newer C++ standards making the development of
the project easier.
I do see that RHEL/CentOS 7 has the needed compiler versions in the
devtoolset. I also stumbled across this blog post:
<https://smoogespace.blogspot.com/2018/03/using-red-hat-developer-toolset-dt…>
But ...
a) Is that blog post still relevant? I couldn't find anything in the
Fedora packaging guidelines giving any further advice.
b) By adding the devtoolset as a build dependency, is that enough?
Will the final .rpm need anything else installed to function? Like a
newer libstdc++?
c) Which other traps may I be facing using a devtoolset for EPEL-7 builds?
--
kin
d regards,
David Sommerseth
I've been talking with the awesome people at Sourcegraph, and they're
interested in indexing our packages. Still working out what that'l look like
exactly, but I'm pretty excited about it. (They're an open-source company
with a SaaS product. Also at least some of their folks run Fedora Linux, so
that's extra cool.)
In our conversation, they mentioned that it'd be nice to have their
command-line tool packaged. Anyone interested in taking that on? Looks
pretty straightforward, although I'm not sure of any Go lang pitfalls that
might await.
https://github.com/sourcegraph/src-cli
(Also, we already have a package named `src`, which is a apparently and RCS
(!!!!?!?!?!) wrapper. So we'll need to figure out a different comand name;
maybe src-cli, maybe 'sourcegraph', dunno.)
They'd also be interested in having the actual search engine tool itself
packaged (https://github.com/sourcegraph/sourcegraph) -- but that's a bigger
project. (Still, volunteers welcome!)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
Hello fellow java package maintainers!
We are planning to bump the JDK from java-11-openjdk to java-17-openjdk for f36. Please see https://fedoraproject.org/wiki/Changes/Java17
Short Story:
* if you have some java package, be aware that we are bumping JDK in rawhide
* Ensure your package builds and runs fine with java-17-openjdk (see the https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ )
* there is special tooling ready for this, before mass rebuild is launched
** See https://fedoraproject.org/wiki/Changes/Java17#copr_preliminary_rebuild
* If you do not want Fedora rotten with java-11-openjdk for ever, continue reading
Long Story:
We ran a preliminary mass rebuild of javastack in copr repo https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ (select "all" instead of "25" at the bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy &
comp. for build. You can see, the result was quite :
497 total; attempted to rebuild
107 failed; from those 75 are trivial failures (but if you fix it, there is no guarantee real troubles are not hidden behind that)
390 succeeded
2 not even srpm rebuilt - orphan? dead? (but orpahns and dead ones should be already excluded)
I would kindly ask you to search yourself in this list: https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/fillCopr/…
If you are here, please check status of your package in https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer/e… (pain text of
https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/)
* If all your packages are "succeeded", congratulations nothing to do, and just keep en eye on JDK bump
* If there is "failed" but contains "- -" then even srpm built failes. If you wish to resurrect it, please ensure it runs against java-17-openjdk (see lower)
* If there is "failed" but failed in "seconds", then those packages failed so quickly, that the build was in initial phases. That usually mean that you build with source/target/release lower then 1.7. java-17-openjdk supports 1.7 and up.
We recommend to bump the source/target to 1.8, to allow existence of compact 1.8 packages alongside main javastack. See https://fedoraproject.org/wiki/Changes/Java17#Wrong_source.2Ftarget_version. Don't forget to upstream the patch, or
maybe it is enough to update to more fresh upstream release which supports java-17-openjdk? it may happen, that after the fix, your build will fail in more terrible way (see below)
* If there is "failed", and its none of above, then your package simply failed. Very often the scary error may be fixed by bump to latest upstream version. java-17-openjdk is out shortly, but changes against java-11-openjdk are minimal,
and upstreams keep an track. Please, try to fix the package. Don't hesitate to ask on devel(a)fedoraproject.org or java-devel(a)fedoraproject.org or directly to me jvanek(a)redhat.com. If you fix the fail, feel free to share your fix, it may help
others.
We are trying to gather the most common issues at https://fedoraproject.org/wiki/Changes/Java17#common_issues_packagers_can_f… . Feel free to enhance the page, or write us your case (possibly both with solution and
without) so we can add it here.
If your package is missing, and you wish it here, I will gladly add it! Just let me know - jvanek(a)redhat.com
Debugging Your failures.
The copr repo we maintain, contains builds of java-17-openjdk as system JDK, javapackages-tools, maven & comp. honoring that, and java-11-openjdk as non system JDK. Also it contains successfully rebuilt packages. You can directly use this
copr repo in several ways.
* first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ find your build (select "all" instead of "25" at the bottom),
** Click its number, select chroot (currently fedora-rawhide-x86_64 ) and check the logs. Main log is build.log.gz.
* anything you push to rawhide, will automatically rebuild here in fedora-rawhide-x86_64 chroot.
** It is the best approach. If you can fix your package in rawhide directly, without breaking the rawhide too much, go for it
** If yo need to experiment, I have a mock config for you (generated from copr-cli mock-config jvanek/java17 fedora-rawhide-x86_64) which you can copy to your /etc/mock and use -
https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer/e… . Eg:
# as root, globally
sudo wget https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scritps… -O /etc/mock/jvanek-java17-fedora-rawhide-x86_64.cfg
# or as user, locally (after creating ~/.config/mock/)
wget https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scritps… -O ~/.config/mock/jvanek-java17-fedora-rawhide-x86_64.cfg
# change spec, bump sources, apply patches
fedpkg srpm
mock -r jvanek-java17-fedora-rawhide-x86_64 *.src.rpm
Or any other packaging workflow you use, and you can use against the copr repo.
Thank you very much for your help, there are 107 failures, and 270 java packagers, but only 2 active members of java sig. Without your help, the JDK bump will be very hard.
Thank You!
J.
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-34-20211130.0):
ID: 1074830 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1074830
ID: 1074838 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1074838
Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-35-20211130.0):
ID: 1074814 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1074814
ID: 1074822 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1074822
Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose