Postings by Mikolaj Izdebski

Orphaning/retiring 3 Java packages

Soon after Fedora 31 branching I intend to retire java-packaging-howto
package and orphan byaccj and javapackages-tools packages. The reason
is that I intend to maintain these packages as part of modules.

I will continue to maintain non-modular packages through lifecycles of
Fedora 29-31, but starting from Fedora 32 I will maintain modular
versions only.

Orphaned some Java packages

I've just orphaned 259 packages listed below.

Orphaned fedora-review-plugin-java

I've just orphaned rpms/fedora-review-plugin-java.
This package was recently assigned to me in mass ownership reassignment
and I did not realize I was the owner, until now.
I never intended to maintain this package.

Orphaning some Java packages

TL;DR I am planning to orphan Java packages listed below soon after
Fedora 29 GA. Let me know if you want to adopt any of them.

I'm in the process of transitioning maintenance of all software to
modules only. The reason is that module maintenance is much easier
compared to maintenance of non-modular, "ursine" packages.

Maintenance of arbitrary branches of orphaned package

Suppose I am main admin of a package which I would like to orphan in
release branches, but keep maintaining the package in arbitrary [1]
branches, which are used for building modules. Would this considered
as a valid approach?

How should I handle orphaning the package in this case? I can think
of at least two possibilities:
1. Keep myself as admin and set bugzilla_contact for product Fedora to

Buildroot-only modules

Some modules are built in MBS/Koji but are never released to users.
Currently such modules can only be used as build dependencies of other
modules. In future, if solution like "ursa-major" [1] is implemented,
such modules could also be used as build dependencies for non-modular

An example of buildroot-only module is javapackages-tools. This
module is used as build dependency for 4 modules, but it is not
included in any compose and it's not shipped to users.

Should such modules be considered as allowed in Fedora?

Java auto-requires generator change

FPC decided [1] that Java packages must require javapckages-filesystem
instead of javapackages-tools. I've just updated [2] upstream code
generator code to comply with updated packaging guidelines and
backported [3] the patch to rawhide.

[1] <a href="" title=""></a>
[2] <a href="" title=""></a>
[3] <a href="" title=""></a>

glassfish-el-javadoc license change

License of glassfish-el-javadoc package was changed

<a href="" title=""></a>

sisu-mojos license change

License of rpms/sisu-mojos was updated from EPL to EPL-1.0

sisu license change

License of rpms/sisu was changed from EPL to EPL-1.0

junit5 license change

On Wed Jun 27 2018 License tag of rpms/junit5 was changed
from "EPL" to "EPL-2.0"

junit license change

License tag of rpms/junit was changed
from "EPL" to "EPL-1.0"

hawtjni license change

License tag of rpms/hawtjni was changed

base64coder license change

License tag of rpms/base64coder was changed

antlr license change

antlr license was changed from "Public Domain" to "ANTLR-PD"

For justification, see
<a href=" ... at lists dot" title=" ... at lists dot"> ... at lists dot fedoraproject....</a>

maven-archetype license tag change

maven-archetype license tag was corrected
from "ASL 2.0"
to "ASL 2.0 and ASL 1.1"

jeromq license change

Starting with version 0.3.6, jeromq package changes license from
"LGPLv3" to "MPLv2.0".

As far as I can tell, GPL compatibility is retained because
"Incompatible With Secondary Licenses" is not used.

See also: <a href="" title=""></a>

Orphaning xmlrpc-c (critpath)

I don't have time to maintain xmlrpc-c, so I'm going to orphan it within
next few weeks, unless someone volunteers to take it.

Note that as a transitive dependency of Anaconda, xmlrpc-c is a
"critical path package".

Koschei update

TL;DR Koschei now supports targets other than rawhide (not enabled
yet) and should correctly handle weak and rich deps.

Full version:

Last week Koschei [1] was updated to latest upstream release (1.6.1).
The new version comes with one particularly interesting feature -
Koschei is now able to track more than one package collection at time,
which means that it could be possible to use it for Fedora branches
other than just rawhide, for EPEL, or even for side tags in Koji.
Currently only rawhide is enabled, but if there's enough interest then
it should be possible to enable other targets too.

Insim - service for optimizing dependencies

I would like to announce Insim, which is a new web service for
monitoring package installation sizes and other numbers.

Insim checks installation sizes of defined modules (groups of
packages) and presents this information to user. It's main goal is to
help developers to optimize package dependencies, which aligns with
some objectives of modularization effort.

More information about Insim can be found at [1]. A running Insim
instance hosted at Fedora infrastructure cloud is available at [2].

Note that Insim is still in early development. There are many bugs
and missing features.

Koschei update

I would like to announce that Koschei [1], a continous intagration
system for Fedora packages, has just been updated to a new version,
which includes several new features and fixes multiple bugs.
Summary of most important user-visible changes follows.

Group management has been improved. Users can now create personal
package groups, visible only for them and for people that know group
URL. Groups can have multiple maintainers - people that can edit
group content.

Koschei - new Fedora infrastructure service

I'm glad to announce that as of yesterday Koschei production instance
has been moved Fedora infrastructure and now it can be considered as
officially-supported Fedora service.

Koschei is a continuous integration service for Fedora packages.
Koschei is aimed at helping Fedora developers by detecting problems as
soon as they appear in rawhide - it tries to detect package FTBFS in
rawhide by scratch-building them in Koji. More information can be
found at Fedora Wiki [1].

Interested parties can be automatically notified when Koschei detects
change in package FTBFS status.

Koschei migration (outage)

For your information: In the next few days we'll be migrating Koschei
server and database to different machines. During that time you may
experience ocassional Koschei unavailability. Additionally, Koschei will
be working in read-only mode (no new builds will be submitted) and any
changes made in the web interface (such as adding new packages) may be
lost after the migration.

jna license fixed

License field of "jna" package in rawhide has been corrected from
"LGPLv2+" to "LGPLv2 or ASL 2.0" to match upstream licensing terms.

Differences between Koji and mock buildroots

For your information:

Yesterday gdb package introduced "Remommends: dnf-plugins-core" in
rawhide [1]. gdb is required by rpm-build, which is a default package in
Koji f23 build group.

As a consequence minimal f23-build buildroot installed with DNF (default
mock config for rawhide) contains 22 additional packages compared to
buildroot installed with YUM (mock config used by Fedora Koji).

Orphaning maven-changes-plugin

I'm orphaning maven-changes-plugin in Fedora 23.

The reason is that I've been unable to update the package to newer
upstream version for over 2 years (bug #919544) due to Apache CXF being
outdated (bug #1007206).

Packages that build-require maven-changes-plugin:

Package maintainers

Removing Maven depmap support in F23

stop being resolved with Maven, one of Java build systems. It should
be enough to rebuild affected packages in order to fix them.

More details:

Next week after branching I will update XMvn in rawhide (F23) to new
upstream version. Among other things, this version removes support
for legacy "depmap" files, which were used by Maven to resolve
dependencies and which were obsoleted by new metadata format.

httpcomponents-client license change

License of httpcomponents-client was changed from "ASL 2.0" to
"ASL 2.0 and MPL", starting with version 4.4.

This is because httpclient 4.4 includes "public suffix list" from
Mozilla: <a href="" title=""></a>

junit license change

License of JUnit was changed from CPL to EPL starting with version 4.12

<a href="" title=""></a>

Orphaning plotutils

I took plotutils by mistake a few months ago as part of large package
reassignment. I am orphaning it now as I never intended to maintain the
package. Feel free to adopt it if you wish.