Fedora EPEL 7 and enabling devtoolset
by David Sommerseth
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-...>
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
2 years, 4 months
packaging sourcegraph cli -- any volunteers?
by Matthew Miller
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
2 years, 4 months
java-17-openjdk mass-rebuild for f36 in copr I
by Jiri Vanek
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/fillCop...
If you are here, please check status of your package in https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer... (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... . 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... . Eg:
# as root, globally
sudo wget https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scrit... -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/scrit... -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.
2 years, 4 months
Trying to take an orphaned package
by Stephen Snow
Hello,
So I am back here to ask again if I can take a package on that is
currently orphaned as per
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
And I login with my FAS ID and cannot "Take" the package since I am not
a packager.
So I ask again what steps am I missing here? I want to take over
packaging something that is about to be removed from Fedora Linux since
it has been orphaned, I have signed the agreements, I have asked to
become a packager, and this is actually the second package I am trying
to take over.
The package I am interested in taking/sharing maintaining with is
https://src.fedoraproject.org/rpms/Java-WebSocket
I think it is likely a maven plugin issue just looking at the root log.
Thoughts?
Regards,
Stephen
2 years, 4 months
Onboarding package
by Vít Ondruch
Hi,
Recently, there have been a lot of discussions on this list as well as
we have internally about onboarding. During our internal brainstorming,
we were initially discussing that it could be useful to have some
package one can experiment with without being too much worried about the
result.
However, discussing this back and forth, we figured that it might also
be good idea to actually have something such as "onboarding" package,
where new coming package maintainer could gradually gain experience with
the packaging workflows. So the simplest tasks could be:
1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively this
could include change to "CONTRIBUTORS" file. I suspect that also some
current Fedora contributors might be interested to send such PR ;)
2) Second step could be something similar, but that would require the
packager to be already sponsored and they could go through the whole
process themeselves just with some light guidance if needed.
This could be extended in the future. E.g. next step could be:
3) Submit module update.
Apart from gaining experience, this could also help with the common
question "where should I start". And of course our sponsoring guidelines
could be refreshed suggesting/requesting to take these steps at some point.
Thoughts?
Vít
2 years, 4 months
Release 13.0.1-rc1 has been tagged
by Tom Stellard
Hi,
I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries.
There is still time to submit fixes for the final 13.0.1. I'll give more
details about timelines and how to do this once the bugzilla migration is
complete. Currently, bugzilla is read-only, so we can't submit any fixes
there.
-Tom
2 years, 4 months
F35 release retrospective
by Ben Cotton
Hi everyone,
Now that we've released F35, I'd like to share the first semi-annual
release retrospective survey:
https://fedoraproject.limequery.com/231354
I kept it intentionally short and open-ended. It should only take a
few moments of your time. If you have any questions, please let me
know. If you have suggestions for the next time around, there's a
field for that in the survey!
The survey is open through 4 December. I'll share results on the
Community Blog in late December or early January.
If you haven't seen, Adam is running a QA-specific retrospective as
well. If you only have QA feedback, you can record it on the wiki page
and I'll incorporate the responses into my final analysis.
https://fedoraproject.org/wiki/Fedora_35_QA_Retrospective
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
