As part of creating Fedora CoreOS (and derivatives like Red Hat Enterprise Linux CoreOS), we are making some fairly fundamental changes to how the operating system works - while OSTree isn't new to Fedora, Ignition is - and more broadly than that, using Ignition implies something much more similar to the Container Linux experience where installation is via "dd to disk".
We created https://github.com/coreos/coreos-assembler as a new, opinionated tool designed to bind together Ignition, rpm-ostree, while carrying forward a lot of the Container Linux tooling from the https://github.com/coreos/mantle/ project around uploading to IaaS clouds, running tests (kola) etc.
is the 0.6.0 release.
coreos-assembler comes as a container image (ready to run via "rootless" podman for example), not an RPM. We may try to add it to the Fedora container buildsystem at some point, but the reason I'd like to occasionally highlight releases here is because part of the intention is that coreos-assembler should be an easy onramp for people and projects that want a "custom" Fedora CoreOS style system.
For example, I'd like for in the future for Fedora Silverblue and Fedora IoT to be *derivatives* of Fedora CoreOS.
And today, RHEL CoreOS (part of OpenShift 4) is created via coreos-assembler, although it's RHEL content obviously.
There are obviously a *ton* of "build systems" out there - but I think so far coreos-assembler has been working well as a way to make "CoreOS style systems"; for anyone who is interested in that (or wants to contribute to Fedora CoreOS), please take a look!
== Summary ==
Update the Free Pascal Compiler used within Fedora to version 3.2.0,
once it is published, and enable building (previously unsupported)
AArch64 and ppc64le packages using the compiler.
== Owners ==
* Name: [[User:suve|Artur Iwicki]]
* Email: <fedora(a)svgames.pl>
* Name: [[User:joost|Joost van der Sluis]]
* Email: <joost(a)cnoc.nl>
== Detailed Description ==
The Free Pascal Compiler team plans to release a new release, 3.2.0,
somewhere until the end of this year (2019). This date falls within
the Fedora 32 release schedule, so the new compiler version could be
introduced into F32 once it's released.
== Benefit to Fedora ==
The Free Pascal Compiler will support new architectures, which in turn
will allow programs compiled using FPC to run on more architectures
supported by Fedora.
See also [https://wiki.freepascal.org/FPC_New_Features_3.2|FPC New
Features 3.2] for a list of other new compiler features.
== Scope ==
All packages depending on `fpc` should be rebuilt with the new `fpc`
once it hits F32, or, if there is not enough time for that, just all
packages built after the new `fpc` hits the buildroots.
* Proposal owners:
** Update the `fpc` package to version 3.2.0.
** Cross-compile the compiler for AArch64 and ppc64le (required for
** Add AArch64 and ppc64le to the `ExclusiveArch:` tag in the package spec.
** Build the compiler for the new architectures, using the
** Build the compiler once again, this time using the self-hosted binary.
** Update the `fpc-rpm-macros` package to accurately reflect the new,
expanded architecture list.
* Other developers: In the first few days or weeks, just voluntary
rebuilds using the new `fpc`. Should there be any build failures, look
at the [https://wiki.freepascal.org/User_Changes_3.2|User Changes 3.2]
page to see if the package is affected by any backwards-incompatible
change. If the packaged program/library does not support one of the
newly introduced architectures (AArch64/ppc64le), either resolve the
issue or add an `ExcludeArch:` tag to the spec.
* Release engineering: Mass rebuild requested for F32.
* Policies and guidelines: No changes needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
== How To Test ==
Since the main impact of this change is adding support for new
architectures, a mass-rebuild of dependent packages will also act as a
Users wanting to test this change may want to submit a scratch build
against rawhide. If needed, a [b]copr[/b] repo may also be created, so
anyone interested may install the compiler on F31 or F30.
== User Experience ==
FPC-dependent packages will become available on a larger number of
== Dependencies ==
Lazarus depends on FPC exact version, so it will need to be rebuilt.
== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in
preparing self-contained testcases to speed up analysis and fixing the
bugs. I do not expect the compiler to introduce any bugs for x86 /
x86_64 / ARM, so the main question will be whether the new AArch64 and
ppc64le targets work correctly.
* Contingency mechanism: If errors occur only for AArch64 / ppc64le
builds, keep the compiler at the new version (3.2.0), but disable
AArch64 and ppc64le (attempt to enable them again once F32 branches
from Rawhide). If errors are also spotted on x86 / x86_64 / ARM,
revert to the the older version (3.0.4). After choosing either option,
perform a mass rebuild of dependent packages.
* Contingency deadline: Before release
* Blocks release? No
* Blocks product? No
== Documentation ==
Free Pascal wiki pages:
* [https://wiki.freepascal.org/FPC_New_Features_3.2|FPC New Features 3.2]
* [https://wiki.freepascal.org/User_Changes_3.2|User Changes 3.2]
== Release Notes ==
Fedora 32 ships with Free Pascal Compiler 3.2.0, see the
[https://wiki.freepascal.org/FPC_New_Features_3.2|FPC New Features
3.2] page for a list of new features and consult the
[https://wiki.freepascal.org/User_Changes_3.2|User Changes 3.2] page
for a list of backwards-incompatible changes.
He / Him / His
Fedora Program Manager
Recently, a couple hundred packages were retired from rawhide (Fedora 31 at that
time) based on the Fedora Failed to Build From Source Policy . From various
reactions over several threads it seems this policy is not ideal. This is an
attempt to collect feedback and make the policy better serve Fedora's needs.
Fedora has a policy for a long time that can be simplified as:
1. Mass rebuild for Fedora N happens by releng
2. Packages that fail to build get open bugzillas by releng
3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly
reminders by releng
4. A week before Fedora N+1 branching any packages which still have open
Fedora N FTBFS bug are retired by releng
However, 3 or 4 haven't happened since Fedora ~26, because the automation was
not working any more for various reasons I don't understand.
The policy was then updated by FESCo to allow anybody to step up and do 3. manually.
However it needs 2 e-mails to devel directed at the package owners and that may
be understood as a personal attack by some.
So nobody ever did that but me (twice) IIRC (and I got my share of shame for that).
Currently, the FTBFS retirement is problematic due to various things:
1) Bugzilla spam: Maintainers are spammed weekly by releng, some of them find
that annoying and simply switch the bug to ASSIGNED to make it stop.
The problem is, how do we both keep notifying the maintainers that action is
needed and not spam them with stuff that will make them filter all Fedora
e-mails to /dev/null.
2) Retirement out of the blue. When releng executes 4., packagers that stopped
the bugzilla spam by setting the bug to ASSIGNED are suddenly surprised the
package was retired. OTOH arguably they made a deliberate action to stop the
notifications. However, most importantly, any dependent packages were not
notified at all, which is **not fair**.
This state is broken mostly because there is no automatic orphaning of packages
that have NEW bugzillas and there is no orphaning at all for packages where the
bugzillas are ASSIGNED for months. For the second bit, everything indicates that
packagers are aware of the problem and will fix the bug in time before 4., but
they don't and things blow up.
3) Questionable importance of the FTBFS bug.
Repeatedly, it has been stated by some, the FTBFS bug is not important and we
should not retire packages at all based on the fact that they "simply" fail to
build. I personally don't agree with this for various reasons, but I can imagine
a situation, where it is reasonable to say so and delay the problem. Obvious
argument is: Better to have 1 package nonbuildable than have 100 packages
nonisntallable. So we need a way to opt-out from the retirement, however simply
setting the bugzilla to ASSIGNED is not it, because we will end up with packages
last built 6 years ago (and I believe this is not what we want).
I'm starting this thread to collect the ideas about how to make this better.
If you see more problems, share them. I promise I'll do my best to make the
policy work better for both Fedora and the people who make Fedora.
I continue to run into strange (at least to me) issues with modules on
EL8. RHEL8 ships a 'rhn-tools' module that ships only the "koan"
package from the cobbler srpm . When this module is enabled, I
cannot install cobbler from my copr - dnf reports that 'cobbler' is
Can someone fill me in more on this.? Is this expected? I don't see
anything in the module file (assuming I have the right module file) that
specifically calls out cobbler for exclusion (such as a filter entry) -
so is it just automatically creating an exclusion for all unshipped
There is very little feedback from dnf - the cobbler package simply
# dnf list cobbler
cobbler.noarch 3.0.1-2.el8 copr:copr.fedorainfracloud.org:orion:cobbler
cobbler.src 3.0.1-2.el8 copr:copr.fedorainfracloud.org:orion:cobbler
# dnf module enable rhn-tools
# dnf list cobbler
cobbler.src 3.0.1-2.el8 copr:copr.fedorainfracloud.org:orion:cobbler
# dnf install cobbler
No match for argument: cobbler
What then does this imply for us being able to provide a cobbler module
(or just package) for EPEL?
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
Hey folks! Just to let folks know that the openQA job scheduling robot
(for the production instance) had a bad day and needed to go lie down
for a bit, so it didn't schedule any tests for any new composes or
critpath updates that appeared from about Oct 07 17:08:42 UTC until
about Oct 09 15:00:00 (about 20 minutes ago). Thanks to Christian
Heimes for alerting me to this. I just gave it a mug of tea and a
headache pill and some sympathetic conversation and it's back in top
form and scheduling tests again; it's scheduled all the things it
missed and the test system is catching up with the backlog, so results
will start appearing for updates and composes that were missed soon.
Sorry for any inconvenience.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
Per the https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers...
procedure here is a mail to let people know I have filed a request to
unretire tolua++: https://pagure.io/releng/issue/8895
tolua++ was retired as part of the recent semi-automated retiring of packages
which FTBFS, but I just found out that we still have several libraries depending
on it and then a bunch of packages depending on these libraries. So currently we
have a bunch of broken deps in the F31 repo.
Therefore I have requested to become the owner of the tolua++ package and to
unretire tolua++, I will take care of the FTBFS issue.
Note the depending packages were not listed in the orphan reports to the devel list,
likely due to this dnf bug: https://bugzilla.redhat.com/show_bug.cgi?id=1760772