Hi, I have a question for the FESCo and Council candidates: do you
support allowing Fedora src-git repositories to be hosted on
gitlab.com, which a proprietary software git forge?
Fedora Council has already effectively stated that dist-git
infrastructure must remain open source, but has no such promises for
src-git. I understand Council has previously stated that Fedora
infrastructure should depend on proprietary software only if no open
source alternative is suitable. Do you believe that there exist no open
source git forges that would be suitable for Fedora src-git?
The most obvious open source alternative would be the open source
version of GitLab. There is also Pagure. I think we're giving up on
open source infrastructure rather quickly here. I'd like to know what
the candidates think before voting.
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:
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
c) Which other traps may I be facing using a devtoolset for EPEL-7 builds?
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
(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!)
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
* 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
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)
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
* 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
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
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.
So I am back here to ask again if I can take a package on that is
currently orphaned as per
And I login with my FAS ID and cannot "Take" the package since I am not
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
I think it is likely a maven plugin issue just looking at the root log.
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
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.
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
Now that we've released F35, I'd like to share the first semi-annual
release retrospective survey:
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.
He / Him / His
Fedora Program Manager
Fedora 33 will go end of life for updates and support on 30th of
November 2021. No further updates, including security updates, will be
available for Fedora 33 after the said date. All the updates of Fedora
33 being pushed to stable will be stopped as well.
Fedora 34 will continue to receive updates until approximately one
month after the release of Fedora 36. The maintenance schedule of
Fedora releases is documented on the Fedora Project wiki . The
fedora Project wiki also contains instructions  on how to upgrade
from a previous release of Fedora to a version receiving updates.