The message about Ceph [1] reminded me that we should probably make the
same notification for Eclipse Platform.
The Eclipse Platform upstream is in the process of dropping all support for
32bit arches.
The current state is that upstream are no longer building for 32bit arches
upstream for 4.10 (release 2018-12) onwards. I expect them to start
actively removing 32bit specific code in future releases.
You can read more about the decision on the upstream bug [2]
In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now,
still builds for 32bit arches, but this will not last long. I expect in a
future release (4.11 or later) Eclipse will no longer build on x86/arm and
at that time I will no longer be able to support these architectures in
Fedora -- I expect to exclude those arches from Fedora builds.
If you depend on the ECJ batch compiler, this will continue to be available
on all arches as a noarch package. (It is packaged as a discrete SRPM and
has no build or runtime dependency on the Eclipse Platform itself.)
Regards,
Mat
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620
Hi All,
Fedora 30 has now been branched, please be sure to do a git pull
--rebase to pick up the new branch, as an additional reminder
rawhide/f31 has been completely isolated from previous releases, so
this means that anything you do for f30 you also have to do in the
master branch and do a build there. There will be a Fedora 30 compose
and it'll appear in
http://dl.fedoraproject.org/pub/fedora/linux/development/30/ once
complete. Please be sure to check it out. Bodhi is currently not
active for Fedora 30, it will be enabled in couple of weeks time when we hit
Beta change freeze point in the Fedora 30 schedule[1].
Mohan Boddu.
[1] https://fedoraproject.org/wiki/Releases/30/Schedule
According to the Fedora 30 schedule[1], today is the deadline for
changes to be in a testable state. If your change is ready to be
tested, please set the status in the tracker bug to MODIFIED. If you
know your change will not be ready for Fedora 30, you can set the
version to rawhide and notify me. For more information about this
milestone, see the Changes Policy[2].
As a reminder, the 100% code complete checkpoint is 2019-03-05. This
is the same day as the beginning of the Beta freeze. Change should be
fully complete and have tracking bugs set to ON_QA by that date.
[1] https://fedoraproject.org/wiki/Releases/30/Schedule
[2] https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_Completion…
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Hello All,
Fedora 30 will be branched from rawhide today as per the Fedora 30
schedule[1]. The process takes about a day and everything should be ready
by tomorrow. You can still be able to build packages normally until then,
but after the mass branching rawhide and F31 will be separated.
We will send another email once the branching is done.
Thanks,
Fedora Release Engineering.
[1] https://fedoraproject.org/wiki/Releases/30/Schedule
https://fedoraproject.org/wiki/Changes/BuildRequires_Generators
= BuildRequires Generators =
== Summary ==
Add possibility to generate build-time dependencies within RPM spec
file and teach RPM and mock how to handle this.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian
Festi]], [[User:msuchy|Miroslav Suchý]]
* Email: ignatenkobrain(a)fedoraproject.org, ffesti(a)redhat.com, miroslav(a)suchy.cz
== Detailed Description ==
For many languages (Rust, Golang, Node.Js, Ruby, Python),
BuildRequires can be automatically generated. All it takes, run some
special tool which will output dependencies in RPM format.
Q: How will it work under the hood?
A: When you build RPM, something like this will happen under the hood…
# rpm would perform %prep (which is supposed to abort if some
dependencies missing and print them)
# mock would install those dependencies and resume build
Q: Will src.rpm contain all generated dependencies?
A: This is not known yet, we'll update page once it is known.
Q: Does this mean that package builds won't be reproducible anymore?
A: No, as long as you have same buildroot and tool which is generating
BuildRequires is doing so in reproducible manner, it should not affect
reproducibility.
== Benefit to Fedora ==
Packagers won't have to pre-generate BuildRequires in the spec file
which means it will be always updated (and correct) :
* Packagers can focus of making their packages better instead of
spending all their packaging time copying BuildRequires from
documentation and third party tools.
* BuildRequires are dropped as soon as they're no longer necessary
* Packages can be easily bumped without requiring a manual BuildRequires refresh
* BuildRequires and Requires generation can use similar utilities,
making sure that the deps packages declare can also be used for
second-level building. Packages no longer need to declare the deps of
their second and n-th dependencies because someone forgot to declare
them in the correct package.
== Scope ==
* Proposal owners: Implement support for a feature in RPM and mock (if
implemented properly, Koji should just work). Make use of it in Rust
ecosystem.
* Other developers: Maintainers of language stacks are advised to use
this feature.
* Release engineering: [https://pagure.io/releng/issue/8129 #8129]
* Policies and guidelines: Packaging Guidelines need to be updated
with instructions how to use this feature.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Packagers and users who use repoquery might be affected (src.rpm might
not contain generated dependencies).
== How To Test ==
TBD.
== User Experience ==
Users won't notice differences.
== Dependencies ==
Required feature needs to be implemented in RPM and mock.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal
Owners might still ship feature disabled for Fedora buildsystem but
have it available for end-users, and move full completion to the next
release.
* Contingency deadline: Beta Freeze
* Blocks release? No.
* Blocks product? No.
== Documentation ==
TBD.
== Release Notes ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Automatic_strict_inter-package_depen…
= Automatic strict inter-package dependencies =
== Summary ==
Implement feature in RPM which will enforce strict dependencies
between subpackages automatically (right now packagers have to do it
themselves).
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]]
* Email: ignatenkobrain(a)fedoraproject.org
== Detailed Description ==
Let's take graphene as an example.
Spec file contains:
<pre>
%package devel
Requires: %{name}%{?_isa} = %{version}-%{release}
%package tests
Requires: %{name}%{?_isa} = %{version}-%{release}
</pre>
What we see when we build RPMs is:
* <code>graphene-devel</code> requires <code>graphene(x86-64) =
1.8.2-3.fc30</code> AND <code>libgraphene-1.0.so.0()(64bit)</code> AND
<code>pkgconfig(graphene-1.0)</code>
* <code>graphene-tests</code> requires <code>graphene(x86-64) =
1.8.2-3.fc30</code> AND <code>libgraphene-1.0.so.0()(64bit)</code>
What can we do?
* <code>Requires: libgraphene-1.0.so.0()(64bit)</code> is actually
provided by <code>graphene</code> (coming from same package), so it
can be dropped in favor of <code>Requires: graphene(x86-64) =
1.8.2-3.fc30</code>
* <code>Requires: pkgconfig(graphene-1.0)</code> is provided by
<code>graphene-devel</code> (coming from the same subpackage), so it
can be dropped entirely
== Benefit to Fedora ==
Package dependencies (between subpackages) will be more strict, more
automated ([https://docs.fedoraproject.org/en-US/packaging-guidelines/#_requiring_base_…
this section from guidelines] can be dropped entirely). Metadata size
will decrease as well.
== Scope ==
* Proposal owners: Implement required feature in RPM, backport it to Fedora.
* Other developers: Drop unneeded dependencies to keep spec file simpler.
* Release engineering: [https://pagure.io/releng/issue/8128 #8128]
* Policies and guidelines: Drop yet another Packaging Guidelines
section because it will be automated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Everything will keep working.
== How To Test ==
TBD.
== User Experience ==
User's won't see packaging errors (wrt. inter-package dependencies) anymore.
== Dependencies ==
RPM changes are needed. Will be handled by Proposal Owners.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal
Owners will try to fix problems ASAP or move Change to the next
release (and revert changes).
* Contingency deadline: Beta Freeze.
* Blocks release? No.
* Blocks product? No.
== Documentation ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis