FESCo election nominations are now open
by Ben Cotton
Now through 17 November, you may nominate candidates for the open seat on
the Fedora Engineering Steering Committee.
To nominate yourself (or others, if you check with them first), visit:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
FESCo is currently selecting the questions for the
interview questionnaire, which will be finalized before the beginning
of the interview period.
For more information, see the Community Blog post:
https://communityblog.fedoraproject.org/f35-elections-nominations-now-open/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
- 1
- 0
Fedora Linux 35 is available now!
by Matthew Miller
Here we go! Fedora Linux 35 is now officially released. I know I say it
every time, but: this is a good one! You'll want to get it (or upgrade)
right away.
Read the details in our Fedora Magazine article at:
* https://fedoramagazine.org/announcing-fedora-35
or just go ahead and upgrade your system, or download install media from:
* https://getfedora.org/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2 years, 5 months
- 1
- 0
F36 Change: java-17-openjdk as system JDK in F36 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Java17
== Summary ==
Update the system JDK in Fedora from java-11-openjdk to java-17-openjdk.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: <jvanek(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/10364 10364]
=== Expected schedule ===
* During November, create new package, java-17-openjdk literally
cloned from java-latest-openjdk (which currently packages JDK 17, and
will move to package JDK 18 in February)
* December 2021 mass rebuild in copr
** all maintainers will be informed of results
* January 2022 second mass rebuild in copr
** all maintainers will be informed of results
* February 2022 mass rebuilds in rawhide - side tag
** FTBFS bugs will be filed
* 22.2, the sidetag will be merged
* Change Checkpoint: 100% Code Complete Deadline Tue 2022-02-22 -
https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
** hard deadline for feature completed
== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* java-latest-openjdk (on jdk16,jdk18, STS, jdk17, although LTS, only
untill jdk18 is released).
where the version-less '''java''' and '''javac''' (and friends) are
provided by java-11-openjdk.
* java-17-openjdk will be cloned from java-latest-openjdk to harbor next LTS JDK
So every package honoring the packaging rules and requiring java ,
java-headless or java-devel is built in koji by java-11-openjdk-devel
and pulls java-11-openjdk(-headless) in 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_...
changes])
We were intentionally delaying jdk11 on-boarding for stability
reasons. But there is no such reason with 17 (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.
=== "Political disclaimer" ===
In old bumps, 6->7, 7-8 we, Red Hat's openjdk team, were a driving
force to bump the system JDK. In case, of jdk11 were a bit reluctant
for stability reasons, so we updated as late as possible. In case of
jdk17, there are no known stability issues, and we hear fedora people
to to ask for jdk17 as system jdk as soon as possible. So targeting
f36, nearly year after jdk17 release. If it is not a wish of Fedora
community, we can postpond to F37 or even later
== Benefit to Fedora ==
JDK17 is out just shortly, but its compatibility with 11 is quite good
and its stability is promissing. Although we can expect some family of
packages to remain on jdk8 for ever, and some other (much smaller)
family of packages will remain on jdk11 for a while, the javastack
should be ok to go. Both jdk8 and jdk11 will remain part of Fedora
while they are supported usptream, and there is a target audience in
our OS.
== Scope ==
=== keep java-11-openjdk (+JDK8 of course) but remove its java/javac
versionless provides, make java-17-openjdk providing java, javac and
other versionless provides (+ keep java-latest-opendjk as rolling
bleeding edge of STS JDKs) ===
* will guarantee fedora to be pure JDK17 distro.
* will allow maintainers of JDK17 or up incompatible packages to keep
using JDK11 (and JDK8), however this is just false hope.
** if such an package depends on package build by JDK17, JDK11 and
JDK8 may not be able to pick up that dependency.
** this may lead to quite a lot of bundling or compat packages, but
may be acceptable
** people developing JDK8 and JDK11 applications will very likely stay
with fedora:)
** those was not so bad when JDK11 was moved to system JDK.
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 build by jdk8, while
works fine with jdk11
* it lead to manual work on align 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#comm...
==== Workflow ====
* announce as by
https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_...
* tune java-latest-openjdk package (for all live Fedoras)
* clone java-17-openjdk package (for all live Fedoras)
* several rounds of mass rebuilds ( see
https://fedoraproject.org/w/index.php?title=Changes/Java17#Expected_schedule)
** from coper
** over side tag
** to koji
==== Change owners ====
* Feature will be implemented in
[https://fedoraproject.org/wiki/Changes/Java17#side_tag side tag]
** --target '''f36-java17''' is tag of choice
** In its mass rebuild, aprox XYZ packages were built, and ABC failed.
FTBFS bugs filled, most of them needs manual fix later
* the jdk 11 and 17 will be changed for this side tag
* the mass rebuild of javastack will be then launched
** 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/Java17#Contingency_Plan
contingency] plan will be activated
==== Other developers ====
* should fix their packages
** this usually means to update to newer version, which supports jdk17
* 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: https://pagure.io/releng/issue/10364 (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 JRE17 should remain the only system JDK after installing base
javastack on clean system
* Both jdk8 and jdk11 and jdk17 and java-latest-openjd can live
together on system
* jdk17 will be selected by default and will run most of the base java stack
* todo, add few java-package to install examples, hopefully for jdk17 only
== 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 (that is aprox 1/3 of time
of jdk11 bump, but It seems, that 1100 packages remained on jdk8)
$ repoquery -q --whatrequires java-headless |wc -l
1007
$ repoquery -q --whatrequires java | wc -l
53
$ repoquery -q --whatrequires java-devel | wc -l
28
$ repoquery -q --whatrequires java-1.8.0-openjdk-headless |wc -l
1003
$ repoquery -q --whatrequires java-1.8.0-openjdk | wc -l
80
$ repoquery -q --whatrequires java-1.8.0-openjdk-devel | wc -l
42
$ repoquery -q --whatrequires java-11-openjdk-headless |wc -l
1030
$ repoquery -q --whatrequires java-11-openjdk | wc -l
78
$ repoquery -q --whatrequires java-11-openjdk-devel | wc -l
36
Packages needing major work will be
* java-11-openjdk
* java-17-openjdk
* javapackages-tools
== Contingency Plan ==
* If the mass rebuild, after the change application, breaks to much
packages, or some important will be unfixable, jdk11 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: beta freeze
* Blocks release? Yes
* Blocks product? N/A
* Generally going back will be imho impossible. Once the decision is
taken, javastack should be fixed, and where it can not be fixed, it
had to migrate to compat packages, or bundled-dependencies pacages or
be orphaned.
=== side tag ===
https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag
* for this fedora have technology known as side tag
* I do not have experience with it, but is making the contingency plan
much smoother
* it is a way, which will be done first
=== copr preliminary rebuild ===
We run an preliminary mass rebuild of javastack in copr repo
https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ on
packages requiring java,javac, java-devel, maven-local, ant, ivy &
comp for build. The first result will be: todo
* If there is "failed" but contains "- -" then it is probably orphan.
If you wish to resurrect it, please ensure it runs against JDK17 (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 lower then 1.8 JDK17 supports
1.7 and up. We recommend to bump the source/target to 1.8, to allow
existence of compat 1.8 packages alongside main javastack
* 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. JDK 17 is shortly. Please, try to fix the
package. Don't hesitate to ask,. If you fix the fail, feel free to
share your fix, it may help others.
==== Debugging failures wiht help of this copr ====
The copr repo we maintain, contains builds of java-17-openjdk as
system JDK, javapackages-tools 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
yours 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
rawhide chroot (we have jdk in rawhide broken a bit currently)
** It is the best approach. If you can fix your package in rawhide
directly, without breaking the rawhide to 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://jvanek.fedorapeople.org/java17/jvanek-java17-fedora-rawhide-x86_6...
. Eg:
sudo cp jvanek-java17-fedora-rawhide-x86_64.cfg
/etc/mock/jvanek-java17-fedora-rawhide-x86_64.cfg
#or
cp jvanek-java17-fedora-rawhide-x86_64.cfg
~/.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.
== Documentation ==
* oracle17 release notes:
https://www.oracle.com/java/technologies/javase/17-relnotes.html
* openjdk17 jeps: https://openjdk.java.net/projects/jdk/17/
https://openjdk.java.net/projects/jdk/16/
https://openjdk.java.net/projects/jdk/15/
https://openjdk.java.net/projects/jdk/14/
https://openjdk.java.net/projects/jdk/13/
https://openjdk.java.net/projects/jdk/12/
* oracle migration guide
https://docs.oracle.com/en/java/javase/17/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 jvanek(a)redhat.com
Threads of "F36 system wide change, java-17-openjdk as 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 jdk17 ====
Generally it is not true. Generally, no program can say, that it do
not support jdk17, because any javac/java application can be *hacked*
to work with java17 - see
https://jvanek.fedorapeople.org/devconf/2017/portingjavaInternalToJdk9/po...
(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 jdk17, and not
much excuses are around to support to not to do so. If you package is
really bound to jdk11, you can move to the version-full requires:
BuildRequires: java-11-openjdk(-devel)
and
Requires: java-11-openjdk(-headless).
In addition, '''if you work with maven/ant or simialr, you must set
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk before calling it.'''
japckage tools and comp are made to accept it.
However there is an trap - packages you depends 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 in dependency hell.
Please, try to avoid this as much as possible!
===== Intermediate step build with java-11-openjdk-devel and run with
java (that means any sytem java, eg java-17-openjdk) =====
Some projects support JDK17 for runtime, but not for compile time.
Buildrequires: java-11-openjdk-devel
...
Requires: java(-headless)
...
%build
...
export JAVA_HOME=/usr/lib/jvm/java-11-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 (jvanek(a)redhat.com) or ping me (jvanek), 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/2d6e0f1e3d23d864c1ed0...
example patch for netbeans generated ant]
==== usage of sun.misc.Unsafe.defineClass ====
==== direct usage ====
* use public replacement, java.lang.invoke.MethodHandles.Lookup.defineClass
* eg https://src.fedoraproject.org/rpms/procyon/blob/master/f/lookupPatch.patch
* Note taht it is not 100% replacement, and you should consult upstream first
* Note that it is JDK8 incompatible change
==== library usage ====
java.lang.NoSuchMethodException:
sun.misc.Unsafe.defineClass(java.lang.String
[B,int,int,java.lang.ClassLoader,java.security.ProtectionDomain)
at java.base/java.lang.Class.getMethod(Class.java:2227)
at com.sun.xml.bind.v2.runtime.reflect.opt.Injector$3.run(Injector.java:201)
at com.sun.xml.bind.v2.runtime.reflect.opt.Injector$3.run(Injector.java:197)
In this case, jaxb was old. Get new version of library
==== package XYZ does not exists ... in javadoc generation! ====
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:aggregate
(default-cli) on project classloader-leak-test-framework: An error
has occurred in Javadoc report generation:
[ERROR] Exit code: 1 -
/builddir/build/BUILD/classloader-leak-prevention-classloader-leak-test-framework-1.1.1/src/main/java/se/jiderhamn/classloader/leak/JUnitClassloaderRunner.java:9:
error: package org.junit does not exist
[ERROR] import org.junit.Assert;
* '''solution''' is be to replace javadoc plugin by xmvn --javadoc:
** https://src.fedoraproject.org/rpms/byteman/c/d145b9e4af8952b1a63432ec67d7...
** it is bug in fedora mavenjavadocplugin
* '''see this thread:
https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproj...'''
==== javah: No such file or directory ====
The '''javah''' command was retired and is no longer available in
jdk11; you should switch the package to use '''javac -h''' instead.
The new '''javac -h''' syntax works just fine with jdk8, so you can
switch to this now without worrying about backwards compatibility.
For example: https://src.fedoraproject.org/rpms/snappy-java/blob/2981aaa5b8a597129ad2f...
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
- 1
- 0
F36 Change: Remove .la files from buildroot (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RemoveLaFiles
== Summary ==
Autools/libtool-based projects frequently install files ending in
`.la` in their `make install`. These files are usually unwanted. Many
projects therefore end up with a variation of `find $RPM_BUILD_ROOT
-name "*.la" -delete` in their `%install section`.
`*.la` files are "libtool archives" and provide additional metadata
for library files and come from a time before the introduction of the
ELF format. Today, they are only consumed by libtool itself. Refer to
https://autotools.io/libtool/lafiles.html.
This changes proposes to instead use the `%__brp_remove_la_files`
macro in `redhat-rpm-config`'s `%__os_install_post` to remove the
`*.la` files automatically. This has been added to RPM 4.17.
== Owner ==
* Name: [[User:FASAcountName| Timm Bäder]]
* Email: tbaeder(a)redhat.com
== Detailed Description ==
(not provided)
== Benefit to Fedora ==
This change removes a widely used line of shell script from many spec
files. The advantage is cleaner and easier to maintain spec files as
well as more sensible defaults for rpm package builds.
While looking at what packages will be affected by this change, I
already found several packages that ship and install `.la` files by
accident. These packages will be fixed to not ship them.
== Scope ==
* Proposal owners:
** Update packaging guidelines to mention the automatic removal of
`*.la` files and mention the mechanism for opting out of this
behavior.
* Other developers:
** For the packages already removing their `*.la` files manually,
there should be no change. For packages that want to install such
packages, the package maintainers need to opt out of the automatic
removal.
* Release engineering: [https://pagure.io/releng/issue/10353 #10353]
* Policies and guidelines: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The following packages ship `.la` files currently (queried via `$
repoquery --repo=rawhide -f '*.la' --source | pkgname | sort | uniq`):
<!--
* apr
* apr-util
* aqbanking
* arts
* avr-gcc
* binutils
* calf
* cross-gcc
* djview4
* filezilla
* flatpak
* gambas3
* gforth
* gnome-do
* gnome-subtitles
* google-authenticator
* GraphicsMagick
* gretl
* gstreamer1-doc
* gutenprint
* gwenhywfar
* chafa
* ImageMagick
* jpilot
* kdebase3
* kdegames3
* kdelibs3
* kdepim3
* kdewebdev
* kdissert
* kguitar
* koffice-kivio
* libmodsecurity
* libsecp256k1
* liferea
* mcabber
* mingw-sane-backends
* mingw-speexdsp
* mousepad
* neon
* octave
* opencryptoki
* OpenIPMI
* openldap
* owfs
* pinball
* pragha
* qt5-qtbase
* qt5-qtfeedback
* qt5-qtremoteobjects
* qt5-qttools
* subversion
* taxipilot
* unicornscan
* util-linux
* xfce4-calculator-plugin
* xfce4-timer-plugin
-->
`*.la` files explicitly listed in `%files` (this includes packages
that modify the `*.la` file(s) but don't list them in `%files`
explicitly):
* arts
* gambas3
* chafa
* ImageMagick
* kdebase3
* kdegames3
* kdelibs3
* kdewebdev
* kdissert
* libmodsecurity
* libsecp256k1
* mingw-sane-backends
* mingw-speexdsp
* neon
* openldap
* pinball
* qt5-qtbase
* qt5-qtfeedback
* qt5-qtremoteobjects
* qt5-qttools
* subversion
* unicornscan
* xfce4-calculator-plugin
No mention of `*.la` files in the spec file:
* gcc-avr
* calf
* cross-gcc
* djview4
* filezilla
* gforth
* gnome-do
* gnome-subtitles
* google-authenticator
* GraphicsMagick - But probably needs them just like ImageMagick
* gstreamer1-doc
* jpilot
* kguitar
* liferea
* mcabber
* mousepad
* octave
* opencryptoki
* pragha
* taxipilot
* xfce4-timer-plugin
Tries to delete them but fails:
* aqbanking
* binutils (fixed)
* flatpak
* gretl
* gutenprint
* gwenhywfar
* kdepim3
* koffice-kivio
* OpenIPMI
* owfs
* util-linux
== How To Test ==
Whether a RPM package ships `.la` files can be checked either via the
`repoquery` command from above or via querying a local `.rpm` file
directly: `rpm -q --files ./my-package.rpm | grep '\.la$'`. The latter
command can be used for local testing.
If a package currently ships any `*.la` files but only does so
accidentally, nothing needs to be done and the package will
automatically stop shipping those files after it is rebuilt with this
change in effect.
If a package whishes to keep shipping `*.la` files, the package
maintainer can opt out of the automatic removal by setting
`%__brp_remove_la_files` to `%nil`: `%global __brp_remove_la_files
%nil`
If the package currently removes all `*.la` files manually via some
form of `find $RPM_BUILD_ROOT -name "*.la" -delete` or similar, it is
recommended (but not required) to remove that line.
== User Experience ==
Users should not notice any change.
== Dependencies ==
There are no dependencies. Only `redhat-rpm-config` needs to adapt to
the change.
== Contingency Plan ==
* Contingency mechanism: The change can simply be reverted in the
`redhat-rpm-config` package. Packages that have already removed the
manual deletion of `*.la` files need to revert this change too.
Packages that have opted out of the automatic `*.la` file removal
don't need to do anything.
* Contingency deadline: beta freeze
* Blocks release? Yes
== Documentation ==
Pull request implementing `%__brp_remove_la_files` in the upstream rpm
repository: https://github.com/rpm-software-management/rpm/pull/1674
== Release Notes ==
The [https://rpm.org/wiki/Releases/4.17.0 RPM 4.17 release notes]
simply state "Add policy for removing .la files from buildroot by
default".
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
- 1
- 0