Wiki -> https://fedoraproject.org/wiki/Changes/PytorchRelese
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This change will bring the first iteration of PyTorch to Fedora.
== Owner ==
This project is owned by the https://fedoraproject.org/wiki/SIGs/PyTorch.
* Name: [[User:trix| Tom Rix]]
* Email: trix(a)redhat.com
== Detailed Description ==
The goal of packaging PyTorch for Fedora is to make this open-source
machine learning framework easily accessible and seamlessly integrable
within the Fedora Linux ecosystem. By providing PyTorch as a packaged
software in the Fedora repositories, users gain simplified
installation and maintenance processes. This enhances the
accessibility of PyTorch for Fedora users, fostering a conducive
environment for developers, researchers, and enthusiasts to leverage
the capabilities of this powerful machine learning framework.
Additionally, packaging PyTorch for Fedora contributes to the broader
open-source community by promoting collaborative development and
innovation in the field of machine learning on the Fedora platform.
== Feedback ==
The PyTorch SIG meets bi weekly, contributing to the meeting is the
best way to engage with what is happening. TBD: Add how to join.
The feedback so far has been positive with some high level feature
requests.
GPU Acceleration
More packages that use PyTorch
Improving base PyTorch
== Benefit to Fedora ==
This change will introduce PyTorch, a high demand machine learning
framework, to Fedora. PyTorch is widely used for tasks such as image
and speech recognition, natural language processing, and other
artificial intelligence applications, providing a user-friendly
interface for building and experimenting with complex machine learning
models. This is for CPU (x86_64 and aarch64) only and is the first
release for Fedora. The current development effort is focused on AMD
GPU acceleration.
== Scope ==
* Proposal owners:
This change does not affect other parts of the distribution and is an
isolated change.
* Other developers:
To install use
> dnf install python-torch
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: Yes
== Upgrade/compatibility impact ==
This is the first time this package has been available.
== How To Test ==
The PyTorch code base is very large, start with the public examples
described here
https://pytorch.org/tutorials/beginner/pytorch_with_examples.html
== User Experience ==
How the user installs PyTorch changes from
> pip install torch
To
> dnf install python-torch
The pip install requires local building which may fail and will not be
consistent from machine to machine. Dnf will always succeed and be
consistent.
== Dependencies ==
PyTorch is available for Rawhide.
== Contingency Plan ==
* Contingency mechanism: PyTorch is available for Rawhide.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
There is a wealth of online and print documentation available. A good
place to start is the main project page https://pytorch.org/
== Release Notes ==
PyTorch 2.1.2 and some supporting packages are available in F40
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki -> https://fedoraproject.org/wiki/Changes/DefaultBpfman
This is a *proposed* Change for Fedora Linux.
This document represents a proposed Change. As part of the [Changes
process](https://docs.fedoraproject.org/en-US/program_management/changes_po…,
proposals are publicly announced in order to receive community
feedback. This proposal will only be implemented if approved by the
Fedora Engineering Steering Committee.
== Summary ==
bpfman: An eBPF Manager
bpfman operates as an eBPF manager, focusing on simplifying the
deployment and administration of eBPF programs. Its notable features
encompass:
* System Overview: Provides insights into how eBPF is utilized in your system.
* eBPF Program Loader: Includes a built-in program loader that
supports program cooperation for XDP and TC programs, as well as
deployment of eBPF programs from OCI images.
* eBPF Filesystem Management: Manages the eBPF filesystem,
facilitating the deployment of eBPF applications without requiring
additional privileges.
We do aim to have this included in Fedora so it becomes the de-facto
and easy way to load eBPF programs.
== Owner ==
* Name: [[User:dmellado| Daniel Mellado]]
* Email: dmellado(a)fedoraproject.org
* Name: [[davetucker| Dave Tucker]]
* Email: datucker(a)redhat.com
* Name: [[tohojo| Toke Høiland-Jørgensen]]
* Email: thoiland(a)redhat.com
== Detailed Description ==
bpfman operates as an eBPF manager, focusing on simplifying the
deployment and administration of eBPF programs. bpfman is a software
stack that aims to make it easy to load, unload, modify and monitor
eBPF programs whether on a single host, or in a Kubernetes cluster.
bpfman includes the following core components:
* bpfman: A system daemon that supports loading, unloading, modifying
and monitoring of eBPF programs exposed over a gRPC API.
* eBPF CRDS: bpfman provides a set of CRDs (XdpProgram, TcProgram,
etc.) that provide a way to express intent to load eBPF programs as
well as a bpfman generated CRD (BpfProgram) used to represent the
runtime state of loaded programs.
* bpfman-agent: The agent runs in a container in the bpfman daemonset
and ensures that the requested eBPF programs for a given node are in
the desired state.
* bpfman-operator: An operator, built using Operator SDK, that manages
the installation and lifecycle of bpfman-agent and the CRDs in a
Kubernetes cluster.
bpfman is developed in Rust and built on top of Aya, a Rust eBPF library.
== Feedback =
N/A
== Benefit to Fedora ==
bpfman is a software stack simplifying the management of eBPF programs
in Kubernetes clusters or on individual hosts. It comprises a system
daemon (bpfman), eBPF Custom Resource Definitions (CRDs), an agent
(bpfman-agent), and an operator (bpfman-operator). Developed in Rust
on the Aya library, bpfman offers improved security, visibility,
multi-program support, and enhanced productivity for developers.
For Fedora, integrating bpfman would streamline eBPF program loading.
It enhances security by restricting privileges to the controlled
bpfman daemon, simplifies deployment in Kubernetes clusters, and
offers improved visibility into running eBPF programs. This
integration aligns with Fedora's commitment to providing efficient and
secure solutions, making it easier for users to leverage the benefits
of eBPF in their systems.
== Scope ==
* Proposal owners:Submit / review pull-requests and packages to Fedora
* Other developers:
https://copr.fedorainfracloud.org/coprs/g/ebpf-sig/bpfman-next/
migrate these packages from copr to Fedora alongside proposal owners
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
N/A
== How To Test ==
N/A
== User Experience ==
Users would be able to easily load eBPF programs within Fedora in a
way more simpler way than currently using bpfman.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No
== Documentation ==
* https://bpfman.io/main/
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki -> https://fedoraproject.org/wiki/Changes/Anaconda_dir_and_image_installations…
== Summary ==
Anaconda will require a fully defined kickstart file for installations
into an image or a directory and these installations will run only in
a non-interactive text-based user interface.
== Owner ==
* Name: [[User:vponcova| Vendula Poncova]]
* Email: <vponcova(a)redhat.com>
* Package: anaconda
* Name: [[User:bcl| Brian C. Lane]]
* Email: <bcl(a)redhat.com>
* Package: lorax (livemedia-creator)
== Detailed Description ==
The Anaconda installer supports installations into a local image (via
the <code>--image</code> cmdline option) or a local directory (via the
<code>--dirinstall</code> cmdline option, the directory is usually a
mount point of a custom image). These types of installations are
supported by two user interfaces (text-based and GTK-based) in fully
interactive, partially interactive and non-interactive modes. We
believe that there is no strong reason for all these options, so we
would like to minimize the scope of this functionality and support
only the text-based non-interactive mode (specifically the
command-line mode). It means that Anaconda will require a fully
defined kickstart file and run only in the text-based user interface
(during dir and image installations).
== Feedback ==
== Benefit to Fedora ==
This is a preliminary step for an eventual deprecation and removal of
the Anaconda support for dir and image installations. This
functionality is being slowly taken over by [https://www.osbuild.org/
Image Builder] that is explicitly designed for building images and
provides a much broader and better support for all kinds of images.
Limiting the scope of dir and image installations in Anaconda will
allow its developers to focus their resources on more prospective
areas.
== Scope ==
* Proposal owners: Will submit a pull request for
<code>[https://anaconda-installer.readthedocs.io/en/latest/
anaconda]</code> to run dir and image installations only in the
non-interactive text mode and update
<code>[https://weldr.io/lorax/livemedia-creator.html
livemedia-creator]</code> to reflect these changes if necessary.
* Other developers: No impact.
* Release engineering: No impact. There should be zero impact on
building official Fedora images since these processes are fully
automated and use fully defined kickstart files.
[https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
== How To Test ==
== User Experience ==
It will be still possible to use <code>anaconda</code> and
<code>livemedia-creator</code> for installations into a local image or
a directory with a fully defined kickstart file. Users can notice the
following changes:
* If a user requests a dir or image installation, the installer runs
in the text mode.
* If the user doesn't specify a kickstart file, the installer will
report an error and abort.
* If the specified kickstart file is incomplete, the installer will
report an error and abort.
* All options for specifying the user interface will be ignored (for
example, <code>--graphical</code>)
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki ->https://fedoraproject.org/wiki/Changes/Java21
**This is a *proposed* Change for Fedora Linux.**
This document represents a *proposed* Change. As part of the [Changes
process](https://docs.fedoraproject.org/en-US/program_management/changes_po…,
proposals are publicly announced in order to receive community
feedback. This proposal will only be implemented if approved by the
Fedora Engineering Steering Committee.
== Summary ==
Update the system JDK in Fedora from java-17-openjdk to java-21-openjdk.
== Owner ==
* Name: [[User:pmikova| Petra Alice Mikova]]
* Email: <pmikova(a)redhat.com>
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)(which no longer exists)
* rcm ticket: https://pagure.io/releng/issue/11859
* named side tag ticket: TBD
=== Expected schedule ===
* During January 2024, we will create a new package, java-21-openjdk,
which will be a clone of java-latest-openjdk, which contains STS
versions of OpenJDK (currently 21) and will move to JDK 22 in
February/March.
* December 2023 I will do mass rebuild in copr
** all maintainers will be informed about the results
* January 2023 I will do second mass rebuild in copr
** all maintainers will be informed about the results
* February 2023 mass rebuild in rawhide - side tag
** FTBFS bugs will be filed
* February 2023 the sidetag will be merged
* Change Checkpoint: 100% Code Complete Deadline TBD
** hard deadline for feature completed
== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* java-17-openjdk (LTS), system JDK
* java-latest-openjdk (currently JDK21)
* java-21-openjdk will be cloned from java-latest-openjdk
Therefore, every package honoring the packaging rules and requiring
java via java-headless or java-devel is built in koji using
java-17-openjdk-devel and pulling java-17-openjdk during runtime (see
[https://fedoraproject.org/wiki/Java java] ). Also,
javapackaging-tools are using java-11-openjdk as hardcoded runtime
(see [https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_ja…
changes]).
We were intentionally delaying jdk11 on-boarding for stability
reasons. But there is reason for this approach with 21 (for recall,
see https://fedoraproject.org/wiki/Changes/Java11)
Major incompatibility is again (as we were bumping 8->11)
encapsulation. What was hidden is now even more hidden and few more
parts were hidden. Luckily, most of the projects, when shifted to 11,
did it properly. Still few projects may hit usage of some newly
restricted APIs.
== Feedback ==
== Benefit to Fedora ==
JDK21 was released a while ago, but compatibility with JDK 17 is good
enough and it is a stable release. Although we can expect some group
of packages to use jdk8 forever, and some other (much smaller) group
of packages stay on jdk11 for a while, the java stack should be able
to use the JDK 21. Both JDK 8 and JDK 11 will remain part of Fedora as
long as they are supported upstream, and there is a target audience in
our OS.
== Scope ==
=== To keep the java-17-openjdk (and lower versions of JDK), but to
remove its java/javac versionless provides, make java-21-openjdk the
provider of java, javac and other versionless provides, and keep
java-latest-openjdk as rolling package for STS JDKs) ===
* will guarantee fedora to be pure JDK21 distro.
* will allow maintainers of JDK21 (or higher) incompatible packages to
keep using JDK 17, JDK 11 and JDK 8
** if any package depends on a package built by JDK 21, JDK 17, JDK 11
and JDK 8 may not be able to pick up that dependency.
** this may lead to quite a lot of bundling or compat packages, but
that may be acceptable
** people developing JDK8 and JDK11 applications will very likely stay
with fedora
** we are bumping the system JDK every time a new JDK LTS comes up and
it proved itself as a good practice
While quite a lot of users will rejoice, there may be cases where
application is very hard to migrate to JDK11, so the contingency plan
should be taken very serious.
==== Bytecode version ====
* It appeared, that several applications have to be built by jdk8,
while they work fine with jdk11
* It lead to manual work on aligned libraries on 1.8 byte code
version. see https://pagure.io/java-maint-sig/issue/7
* Other approaches how to avoid this in next update (jdk17, aprox f36,
minimal bytecode 7) were mentioned here:
https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#commen…
==== Workflow ====
* announce as by
https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_es…
* tune java-latest-openjdk package (for all live Fedoras)
* clone java-21-openjdk package (for all live Fedoras)
* several rounds of mass rebuilds ( see
https://fedoraproject.org/w/index.php?title=Changes/Java21#Expected_schedule)
** from copr
** over side tag
** to koji
==== Change owners ====
* Feature will be implemented in
[https://fedoraproject.org/wiki/Changes/Java21#side_tag side tag]
** --target '''f40-java21''' is tag of choice
** In its mass rebuild, approximately XYZ packages were built, and ABC
failed. FTBFS bugs filled, most of them needs manual fix later
* the JDK 17 and JDK 21 packages will be changed for this side tag
* the mass rebuild of java stack will start
** if necessary, several rounds of them
* Failures will be gathered by me and few other volunteers
** Most common issues and theirs fixes will be published
** Package maintainers will be notified in case of failure via
[https://bugzilla.redhat.com/ bugzilla]
* Depending on the fail rate, importance of failed packages and effort
to fix them
** the side tag will be merged to Fedora
** or the [https://fedoraproject.org/wiki/Changes/Java21#Contingency_Plan
contingency] plan will be activated
==== Other developers ====
* should fix their packages
** this usually means to update to newer version, which supports jdk21
* or to retire them if they appear non-fixable
* or to base them on JDK11 without much warranty (as they will need to
compat most of dependency chain)
==== Other ====
* Proposal owners:
** based on above, adapt jdk11 and jdk17 package provides
** If necessary tune the build environment
* Other developers:
** based on selected approach to tune the main build tools
*** jpackage-tools and maven will affected
** based on selected approach to tune the rpmbuild/macros
** many java package maintainers will maybe need to adapt theirs packages
*** FTBFS bugs connected with this proposal, maybe with pagure ticket
to allow discussion.
*** Solutions to most common errors should be gathered and published
* Release engineering: TICKET_TBD (a check of an impact with Release
Engineering is needed)
** mass rebuild will be required for this change
* Policies and guidelines: how to deal with build failures, eventually
how to use some jdk17 specific build features will be provided
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Once the change is implemented properly, the update should be flawless
and seamless
== How To Test ==
* only JDK 21 should remain the only system JDK after installing base
javastack on clean system
* the JDK 8, JDK 11, JDK 17, JDK 21 and java-latest-openjd can
co-exist on one system
* JDK 21 will be selected by default and will run most of the base java stack
== User Experience ==
* Standard user should be still be able to use java stack without even
noticing the change.
* Standard developer should still be able develop any java application
comfortably
* Standard packager will not suffer to much, and should be able to
pack any java application for fedora
== Dependencies ==
Around 2000 packages will need attendance
$ repoquery -q --whatrequires java-headless |wc -l
736
$ repoquery -q --whatrequires java | wc -l
41
$ repoquery -q --whatrequires java-devel | wc -l
13
$ repoquery -q --whatrequires java-1.8.0-openjdk-headless |wc -l
653
$ repoquery -q --whatrequires java-1.8.0-openjdk | wc -l
8
$ repoquery -q --whatrequires java-1.8.0-openjdk-devel | wc -l
4
$ repoquery -q --whatrequires java-11-openjdk-headless |wc -l
663
$ repoquery -q --whatrequires java-11-openjdk | wc -l
8
$ repoquery -q --whatrequires java-11-openjdk-devel | wc -l
5
$ repoquery -q --whatrequires java-17-openjdk-headless |wc -l
757
$ repoquery -q --whatrequires java-17-openjdk |wc -l
55
$ repoquery -q --whatrequires java-17-openjdk-devel |wc -l
20
with src repos on, build time depndnecies:
set +x ;echo "dont forget to enable all (correct fedora,
fedotra-testing, fedora modules) SOURCE repos (sections in .repo
files)!" ; for x in ant maven-local maven mvn xmvn java-headless java
java-devel java-1.8.0-openjdk-headless java-1.8.0-openjdk
java-1.8.0-openjdk-devel java-11-openjdk-headless java-11-openjdk
java-11-openjdk-devel ; do for y in "" "--arch src" ;do set -x ;
repoquery $y -q --whatrequires $x |wc -l ; set +x ; done; done
dont forget to enable all (correct fedora, fedotra-testing, fedora
modules) SOURCE repos (sections in .repo files)
+ repoquery --arch src -q --whatrequires ant
152
+ repoquery --arch src -q --whatrequires maven-local
401
+ repoquery --arch src -q --whatrequires maven
4
+ repoquery --arch src -q --whatrequires mvn
0
+ repoquery --arch src -q --whatrequires xmvn
0
+ repoquery --arch src -q --whatrequires java-headless
5
+ repoquery --arch src -q --whatrequires java
0
+ repoquery --arch src -q --whatrequires java-devel
207
+ repoquery --arch src -q --whatrequires java-1.8.0-openjdk-headless
6
+ repoquery --arch src -q --whatrequires java-1.8.0-openjdk
0
+ repoquery --arch src -q --whatrequires java-1.8.0-openjdk-devel
19
+ repoquery --arch src -q --whatrequires java-11-openjdk-headless
0
+ repoquery --arch src -q --whatrequires java-11-openjdk
0
+ repoquery --arch src -q --whatrequires java-11-openjdk-devel
15
Packages needing major work will be
* java-17-openjdk
* java-21-openjdk
* javapackages-tools
* maybe maven base
== Contingency Plan ==
* If the mass rebuild, after the changes are applied, breaks too many
packages, or some crucial component will be unfixable, JDK 17 must be
restored back to the position of system JDK.
* Contingency mechanism: Return jdk8 as system jdk and mass rebuild
again. Note, that this may be very hard, because during build of
packages by jdk8, by jdk11 built dependencies will be picekd up, so
build will fail. Maybe several iterations of mass rebuild will be
needed.
* Contingency deadline: Announce release blocking deliverables Tue
2022-02-01 Tue 2022-02-01 0 (8days before branching, 22 before
beta freeze)
* Blocks release? Yes
* Blocks product? N/A
* In general, going back will be, in my opinion, impossible. Once the
decision is taken, java stack should be fixed, and where it can not be
fixed, it has to migrate to compat packages, or bundled-dependencies
packages, or be orphaned.
=== side tag ===
https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag
* for these changes, Fedora has technology known as side tag
* I do not have experience with it, but it is making the contingency
plan much smoother
* it is an approach, which will be used first
== Documentation ==
* oracle 21 release notes:
https://www.oracle.com/java/technologies/javase/21-relnote-issues.html
* openjdk21 jeps: https://openjdk.java.net/projects/jdk/21/https://openjdk.java.net/projects/jdk/20/https://openjdk.java.net/projects/jdk/19/https://openjdk.java.net/projects/jdk/18/
* oracle migration guide
https://docs.oracle.com/en/java/javase/21/migrate/index.html
=== common issues packagers can face and gathered solutions ===
Contacts: ask on devel(a)lists.fedoraproject.org or
java-devel(a)lists.fedoraproject.org or directly to me
pmikova(a)redhat.com
Threads of "F40 system wide change, java-21-openjdk as a system JDK"
Major database can be browsing of closed bugs of blockers of
https://bugzilla.redhat.com/show_bug.cgi?id=TODO ; unluckily, when it
was analysed, it was not summarised up (that would actually double the
work)
==== My package can not work with JDK 21 ====
No program can say, that it does not support JDK 21, because any
javac/java application can be remade to work with JDK 21 - see
https://jvanek.fedorapeople.org/devconf/2017/portingjavaInternalToJdk9/port…
(really all except package split over modules, which is impossible)
Now above mentioned approaches are indeed *hacked*, and I discourage
everybody to do so. The upstream should be moved to jdk21, and not
much excuses are around to support to not to do so. If you package is
really bound to JDK 17, you can move to the version-full requires:
BuildRequires: java-17-openjdk(-devel)
and
Requires: java-17-openjdk(-headless).
In addition, '''if you work with maven/ant or similar builders, you
must set export JAVA_HOME=/usr/lib/jvm/java-11
-openjdk before calling
it.''' javapackage-tools and comp are made to accept it.
However there is a trap - the packages you are depending on. Once
some of your dependencies will be compiled
with --target > 8, you are doomed, and you have to bundle it or create
its compat version. By doing
so you can easily end up in dependency hell.
Please, try to avoid this as much as possible!
===== Intermediate step build with java-17-openjdk-devel and run with
java (that means any sytem java, eg java-21-openjdk) =====
Some projects support JDK21 for runtime, but not for compile time.
Buildrequires: java-17-openjdk-devel
...
Requires: java(-headless)
...
%build
...
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
...
Should work for a while. See the "My package can not work with jdk11" section
==== My package is not in your copr! ====
If your package is not listed in the copr rebuild repo, I can see two causes
* You have very indirect BR on java.
** Solution
** Email me (pmikova(a)redhat.com) or ping me (pmikova), I will gladly
add you package(s)
* You have exact requires on java-11-openjdk(-devel)
** Solution
** Unless you have good reason, you are actually breaking packaging
guidelines. Switch to java-devel. Once done, again let me know and I
will gladly add your package
** If you can't, then you most likely can not bump to jdk17, and you
will live with jdk11 until it dies,
==== Wrong source/target version ====
maven
[ERROR] Source option 1.3 is no longer supported. Use 7 or later.
[ERROR] Target option 1.3 is no longer supported. Use 1.7 or later.
ant
-do-compile:
[mkdir] Created dir: /builddir/build/BUILD/jpanoramamaker-5/build/empty
[javac] Compiling 45 source files to
/builddir/build/BUILD/jpanoramamaker-5/build/classes
[javac] warning: [options] bootstrap class path not set in
conjunction with -source 5
[javac] error: Source option 5 is no longer supported. Use 7 or later.
[javac] error: Target option 1.5 is no longer supported. Use 1.7 or later.
BUILD FAILED
* Solution
** Your javac is run with wrong source/tag parameters.
[https://duckduckgo.com/?t=ffsb&q=javac+source+target&ia=web net
search will give you quick answer]
** Fixes are:
*** [https://src.fedoraproject.org/rpms/CardManager/blob/2d6e0f1e3d23d864c1ed0b2…
example patch for netbeans generated ant]
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney