I've just orphaned packages:
perl-Debug-Client (https://src.fedoraproject.org/rpms/perl-Debug-Client)
perl-Padre (https://src.fedoraproject.org/rpms/perl-padre)
perl-Debug-Client is not possible to build with Perl 5.34. It is
required only
by perl-Padre. Upstreams of the packages have been inactive for a few
years and
it probably won't be fixed early.
Jitka
--
Jitka Plesnikova
Software Engineer
Red Hat
I took the recently orphaned rubygem-term-ansicolor. It was behind on
releases, so I updated it from 1.4.0 to 1.7.1, the latest. In the
meantime, upstream has changed the license from GPLv2 to ASL 2.0.
Hi,
I have orphaned python-invoke, whose test suite requires
pytest-relaxed, which requires pytest < 5 and fails to build with
Python 3.10.
I believe this only impacts python-jsonmodels; not sure how big an
impact it is.
Paul.
I've just been looking through my packager-dashboard page. A
depressingly large chunk of my packages are going to become
unbuildable on Monday when a bunch of orphaned Java packages are
retired. I think a lot of us are going to be affected. In my case,
there are quite a few non-Java packages involved (due to the parser
generators antlr3 and antlr4-project), primarily OCaml and python
packages. Mikolaj has a huge pile of work on his shoulders, so don't
take this as criticism of him.
Here are some of the pain points:
- log4j will be retired, which will break ant.
- hamcrest2 will be retired, which will break apache-commons-lang3,
which will break bcel, which will also break ant.
- google-gson and javassist will be retired, which will break
reflections, which will break jna, which is used by about a dozen
packages, including bcel.
- maven-install-plugin will be retired, which will break tycho, which
will break eclipse.
- args4j will be retired, which will break jacoco and jgit.
- maven-invoker-plugin and several of its dependencies
(maven-doxia-sitetools, plexus-velocity, maven-reporting-api,
maven-script-interpreter, and maven-reporting-impl) will be retired,
which will break xml-maven-plugin, which is used by eclipse.
- jakarta-el and jakarta-server-pages will be retired, which will break eclipse.
- aopalliance will be retired, which will break maven-native.
- jdependency will be retired, which will break maven-shade-plugin,
which is used by openjfx8, a dependency of java-1.8.0-openjdk.
- apache-ivy will be retired, which will break javapackages-tools.
I have packages that depend directly on the following, so I am willing
to adopt them if nobody more competent shows up (although there is no
point in taking ant-contrib if ant is going to be broken anyway):
- ant-contrib
- jakarta-common-httpclient
- jakarta-ws-rs
- maven-invoker-plugin
- spec-version-maven-plugin
I introduced the jansi1 and jline2 packages so that jansi could be
moved to 2.x and jline to 3.x, but I don't actually maintain any
packages that need the old versions. I would like to give them away
to someone who needs them, but note that you will need to grab
jansi-native as well, before Monday!
Has anybody already done something about any of these packages (and my
packager-dashboard page just hasn't caught up yet)? Is anybody
planning to do something about any of these packages before they are
retired on Monday?
--
Jerry James
http://www.jamezone.org/
https://fedoraproject.org/wiki/Changes/Replace_Anaconda_product_configurati…
== Summary ==
In Anaconda, we would like to introduce profile configuration files
and remove the support for product configuration files.
== Owner ==
* Name: [[User:vponcova| Vendula Poncova]]
* Email: <vponcova(a)redhat.com>
== Detailed Description ==
Anaconda allows to change its configuration based on a detected
product using [https://anaconda-installer.readthedocs.io/en/latest/configuration-files.htm…
the product configuration files]. The configuration is chosen based on
the <code>inst.product</code> and <code>inst.variant</code> boot
options, or the <code>Product</code> and <code>Variant</code> options
of the <code>.buildstamp</code> file, or the <code>NAME</code> option
in the <code>os-release</code> files.
This solution has several flaws:
* The detection based on the <code>os-release</code> files will no
longer work because of
[https://fedoraproject.org/wiki/Changes/Fedora_Linux_in_os-release a
Fedora 35 change].
* The <code>.buildstamp</code> file is generated by <code>lorax</code>
when it creates is a boot.iso. Therefore, we have to rely on other
solutions during the live, dir and image installations.
* The <code>inst.product</code> and <code>inst.variant</code> boot
options are misleading. Anaconda will run with a different
configuration. That doesn't mean it will install a different product.
* The configuration has to use a fake product name for its
identification if it is not tied to a real product.
We would like to redesign the product configuration files to solve
these issues. The idea is to replace them with more general profile
configuration files:
* The profile will be identified by a unique id.
* The profile can specify additional options for the automated profile
detection.
* The profile will be chosen based on the <code>inst.profile</code>
boot option, or based on the <code>ID</code> and
<code>VARIANT_ID</code> options of the <code>os-release</code> files.
For example, Fedora Server uses a configuration from
<code>/etc/anaconda/product.d/fedora-server.conf</code>.
The configuration can be enforced with the <code>inst.product=Fedora
inst.variant=Server</code> boot options.
The file contains the following sections:
<pre>
[Product]
product_name = Fedora
variant_name = Server
[Base Product]
product_name = Fedora
</pre>
After this change, Fedora Server will use a configuration from
<code>/etc/anaconda/profile.d/fedora-server.conf</code>.
The configuration can be enforced with the
<code>inst.profile=fedora-server</code> boot option.
The file will contain the following sections:
<pre>
[Profile]
# Define the profile.
profile_id = fedora-server
base_profile = fedora
[Profile Detection]
# Match os-release values.
os_id = fedora
variant_id = server
</pre>
The full draft of the profile configuration files is provided at:
https://github.com/rhinstaller/anaconda/pull/3388
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
* The installer will use ids instead of names. That will solve the
problem with [https://fedoraproject.org/wiki/Changes/Fedora_Linux_in_os-release
the Fedora 35 change] and prevent similar issues in the future.
* All types of installation will use <code>os-release</code> values to
identify the product. We can remove workarounds for boot.iso and Live
ISO.
* The <code>inst.profile</code> option makes more sense, because it
allows to choose a different installation profile.
* A configuration, that is not tied to a product, doesn't have to
provide a fake product name or id.
== Scope ==
* Proposal owners: Will submit a pull request for the
<code>anaconda</code> package.
* Other developers: Should be no impact. Anaconda provides
configuration files for all Fedora products and the products rely on
the automated detection of configuration files.
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: None.
== Upgrade/compatibility impact ==
Test the automated profile detection:
# Download and boot the Fedora Server ISO.
# The installation is started with the Fedora Server configuration.
Test the <code>inst.profile</code> boot option:
# Download and boot the Fedora Everything ISO.
# Add the <code>inst.profile=fedora-server</code> boot option.
# The installation is started with the Fedora Server configuration.
== User Experience ==
* Users will have to use the <code>inst.profile</code> boot option
instead of <code>inst.product</code> and <code>inst.variant</code>.
* Maintainers of custom product configuration files will have to
change their files.
== Dependencies ==
None.
== 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), Yes/No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis