Building custom kernels
by Julian Sikorski
Hi,
I am trying to test some Renoir s2idle patches [1]. It appears that
Fedora kernel source is now maintained on gitlab as kernel-ark [2]. What
I tried is adding the patches to the fedora-5.11 branch and running make
dist-srpm, but it failed due to config mismatch on CONFIG_INIT_STACK_NONE:
Processing
/home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config
... Error: Mismatches found in configuration files
Found CONFIG_INIT_STACK_NONE=y after generation, had
CONFIG_INIT_STACK_NONE=is not set in Source tree
make[1]: *** [Makefile:145: dist-configs-check] Błąd 1
Is this expected? Is there a better way of testing patches on Fedora
kernels? Thanks for the help in advance.
Best regards,
Julian
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230
[2] https://gitlab.com/cki-project/kernel-ark
3 years, 1 month
Fedora 35 Change: rpmautospec - removing release and changelog fields
from spec files (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/rpmautospec
== Summary ==
The goal of this change is to deploy in production the
[https://docs.pagure.org/fedora-infra.rpmautospec/ rpmautospec]
project.
With it, the content of the `Release` and `%changelog` fields in spec
files can be auto-generated, either locally or in the builder using
the information present in the git repo (in the form of git tags).
Note: This proposal is about changing the way the `Release` and
`%changelog` sections of the '''spec files''' are filled, not about
removing them from the SRPM or binary RPM.
== Owner ==
* Name: [[User:pingou| Pierre-Yves Chibon]]
* Email: pingou - at - pingoured.fr
* Name: [[User:nphilipp| Nils Philippsen]]
* Email: nphilipp - at - redhat.com
== Detailed Description ==
rpmautospec offers packagers who want to use it the possibility of
replacing the content of the `Release` of their spec file by `Release:
%autorel` and/or replace the content of the `%changelog` section of
their spec file by:
%changelog
%autochangelog
Both `%autorel` and `%autochangelog` are RPM macros that will be
expanded or replaced when the SRPM is built on the build system by
their corresponding values according to rpmautospec.
An overview of how rpmautospec works can be found at:
https://docs.pagure.org/fedora-infra.rpmautospec/principle.html.
We will describe below how each macro works.
=== The %autorel macro ===
To determine the next release information, rpmautospec relies on the
build history of the package.
This information is extracted from the buildsystem when running as a
koji plugin and from git tags when running outside of the buildsystem.
Using the build history of the package (ie a list of NEVRs) as well as
the information provided by the packager in the spec file, rpmautospec
then computes the next best release number for the package.
Once defined, it prepends a suitably defined %autorel macro to the top
of the spec file, freezing the computed value of the release number
and thus allowing reproducible builds of the SRPM.
The [https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html
documentation of the autorel macro] describes how packagers can use it
to provide extra information.
=== The %autochangelog macro ===
The %autochangelog macro is in fact more a placeholder that
rpmautospec fills in during the creation of the SRPM (or when ran
manually on a project).
rpmautospec uses two sources of information to automatically generate
the changelog:
* an optional `changelog` file that packagers can add to the repository
* the git history of the spec file
rpmautospec will include the `changelog` as is in the `%changelog`
section and will use all the commits made to the repository after the
last change of the `changelog` file to generate the changelog.
In other words, if the packager has a repository created on January
10th and works on it for 6 months, adds a `changelog` file on June
1st. All the commits made before that commit of June 1st will be
ignored in favor of the content of the `changelog` file.
Similarly, if the packager then edits the file on July 1st, all the
commits prior to that commit of July 1st will be ignored.
All the commits involving files ending with either ".spec" or ".patch"
(this list can be expended if desired) and made after July 1st will be
used to generate the changelog.
== Benefit to Fedora ==
In short: easier packaging in Fedora for the packagers who opt-in.
The `Release` and `%changelog` fields are the two most conflicting
fields in RPM spec files. They impact most pull requests if they
involve updating the package or if the package is updated/rebuilt
while pull-request are being reviewed.
We currently have three different change logs per package and while
they target different audiences (package maintainer: git, sysadmin:
%changelog and end-user: bodhi notes) they overlap a lot and in most
cases are redundant. With this proposal, package maintainers will only
have to cope with two changelogs: git and bodhi notes.
== Scope ==
* Proposal owners:
** Finish the work on the %autorel macro to support some of the use
cases not implemented currently
** Adjust the packaging so rpmautospec does not live in a specific,
versionized python environment (and thus could be use to bootstrap
python)
** Adjust rpmdev-bumpspec (used by releng for mass-rebuilds) so it
ignores spec files using %autorel/%autochangelog
** Adjust the mass-rebuild script so it only adds a suitable git
commit log message for spec files using %autorel/%autochangelog
** Adjust fedpkg to skip the NEVR check when using rpmautospec
** Add dependency on rpmautospec on redhat-rpm-config
* Other developers:
** Opt-in for those who want to use it
** Test changes in staging
** Provide feedback
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Packaging guidelines should be adjust to
explain how rpmautospec works and can be used. Documentation at:
https://docs.pagure.org/fedora-infra.rpmautospec/ should provide a
good basis for this
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Not applicable
== How To Test ==
In staging:
* Use `stg-koji` instead of `koji`
* Use `fedpkg-stage` instead of `fedpkg` (``dnf install fedpkg-stage``)
* Run `kinit <accountname>@STG.FEDORAPROJECT.ORG`
* Test with rawhide as rpmautospec is only available there in staging
at this point
* Install `rpmautospec-rpm-macros` to build packages locally.
* Edit the spec file to use either macro (or both)
* (Optional) Run `rpmautospec` on the git repository of your choice to
see what it does (you may have to run `rpmautospec tag-package` the
first time you run it).
* Build the package
* Check its release or changelog according to the macro set
In production:
* Edit the spec file to use either macro (or both)
* (Optional) Run `rpmautospec` on the git repository of your choice to
see what it does (you may have to run `rpmautospec tag-package` the
first time you run it).
* Build the package
* Check its release or changelog according to the macro set
Issues can be reported at: https://pagure.io/fedora-infra/rpmautospec/issues
Note that using this approach has some peculiarities, we've documented
the ones we've encountered at:
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html
== User Experience ==
Packagers not opting-in should not be affected in any way by this change.
Packagers opting-in should be able to stop worrying (or worry much
less) about the content of the Release/%changelog fields in their spec
file.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: rpmautospec is not deployed in koji
* Contingency deadline: N/A (this isn't tied to a Fedora release)
* Blocks release? No
== Documentation ==
All the upstream documentations can be
https://docs.pagure.org/fedora-infra.rpmautospec/
== Release Notes ==
N/A, this change will not affect end-users (except maybe for some
changes in the content of the rpm changelog).
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 1 month
systemd-resolved fallback DNS servers: usability vs. GDPR
by Tadej Janež
Hi,
I would like to question the decision that was made by systemd
maintainers to remove the fallback DNS server list:
https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c...
And then backported to F33:
https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e...
On F33, this actually breaks a working vanilla cloud instance by
removing the fallback DNS server list in a systemd upgrade, effectively
leaving the system with no DNS servers configured.
I described this in more detail here:
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.o...
Zbigniew Jędrzejewski-Szmek wrote the following in the commit message
accompanying the fallback DNS server list removal:
> So hopefully users will not see any effect from the change done in
> this patch. Right now I think it is better to avoid the legal and
> privacy risk. If it turns out this change causes noticable problems,
> we might want to reconsider. In particular we could use the fallback
> servers only in containers and such which are not "personal" machines
> and there is no particular person attached to them.
I would argue that the change causes noticeable problems and we want to
reconsider this change.
In particular, I think cloud image users would prefer to have their
cloud instances usable out of the box, i.e. have DNS working out-of-the
box.
Don't get me wrong, I understand the privacy concerns and I think
Fedora should strive to protect the privacy of its users as much as
possible, but at the same time, the circumstances of a cloud instance
are probably very different from a e.g. workstation instance.
Possible solutions that come to mind:
1) Use different defaults for different Fedora editions, e.g. container
and cloud images include the fallback DNS servers list while
workstation (and similar) images don't.
2) Pick a reputable DNS resolver that preserves users' privacy and
doesn't log anything and configure it as a fallback DNS server.
Here is a good summary of DNS resolvers and their privacy:
https://privacytools.io/providers/dns/#dns
Thoughts?
Regards,
Tadej
P.S. I'm subscribed, but please keep me in Cc so I'll notice replies
sooner.
3 years, 2 months
sssd: No %post/%preun/%postun?!?
by Richard Shaw
Per the packaging guidelines these don't seem to be optional:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_sy...
Additionally, at a minimum systemctl daemon-reload should be run. It looks
like there is some sort of default behavior but it's not correct.
Warning: The unit file, source configuration file or drop-ins of
sssd-kcm.socket changed on disk. Run 'systemctl daemon-reload' to reload
units.
Warning: The unit file, source configuration file or drop-ins of
sssd-kcm.service changed on disk. Run 'systemctl daemon-reload' to reload
units.
Even the base sssd service seems to be missing daemon-reload:
Warning: The unit file, source configuration file or drop-ins of
sssd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
For the other services provided the default behavior seems to be of the
try-restart variety but all (most?) of these are indirectly started by
socket activation so should be using %systemd_postun and not
%systemd_postun_with_restart:
Failed to try-restart sssd-autofs.service: Operation refused, unit
sssd-autofs.service may be requested by dependency only (it is configured
to refuse manual start/stop).
See system logs and 'systemctl status sssd-autofs.service' for details.
Failed to try-restart sssd-nss.service: Operation refused, unit
sssd-nss.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-nss.service' for details.
Failed to try-restart sssd-pac.service: Operation refused, unit
sssd-pac.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-pac.service' for details.
Failed to try-restart sssd-pam.service: Operation refused, unit
sssd-pam.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-pam.service' for details.
Failed to try-restart sssd-ssh.service: Operation refused, unit
sssd-ssh.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-ssh.service' for details.
Failed to try-restart sssd-sudo.service: Operation refused, unit
sssd-sudo.service may be requested by dependency only (it is configured to
refuse manual start/stop).
See system logs and 'systemctl status sssd-sudo.service' for details.
Looking at my dnf rpm log, this seems to have been going on for quite some
time and I can't believe I'm the first to notice...
Thanks,
Richard
3 years, 2 months
split-DNS, resolvconf on Fedora
by Petr Menšík
Hi,
I have submitted new package openresolv [1], which provides resolvconf
tool, similar to Debian's resolvconf package.
Why? I thought about common interface to various DNS cache
implementations for workstations and different VPN providers available.
While I think the best place to direct, which interface resolvers should
handle given domains. resolvconf handles conflicting requests from
different interfaces, when multiple DNS resolver providers are
configured by connection.
Current Fedora 33 already has /usr/sbin/resolvconf provided by
systemd-resolved. It provides split-DNS implementation in default Fedora
installation[2]. Problem is this is useful only in case systemd-resolved
service is running and used. When it is disabled, its resolvconf just
fails. But because systemd-resolved does not have its own subpackage,
the daemon can be only disabled, not uninstalled.
My question is, how should dhclient or vpn provider check resolvconf is
installed and enabled? It usually checks [ -x /usr/sbin/resolvconf ] in
Debian from shell, but because resolvconf is always present on Fedora,
it cannot work. Unlike Debian, where systemd does not provide
resolvconf. How could it therefore check, how should be /etc/resolv.conf
updated? How would dhclient know, when to rewrite /etc/resolv.conf
itself or when to use resolvconf for coordinated changes?
I think Network Manager should manage DNS domains list per connection
IMO. But in cases VPN provider is not configured via NM or NM is not
even used, I think resolvconf is good alternative to set and restore the
system's /etc/resolv.conf, when any VPN service is started. Only
systemd-resolved and dnsmasq can support split-DNS from NM.
openresolv is written only in shell, has no other dependencies. It could
support multiple DNS implementations as a local cache[3]. It currently
breaks systemd's symlink /usr/sbin/resolvconf, it uses alternatives
links. But systemd package does not use it, so after uninstallation of
openresolv, resolvconf remains broken. I think this has to be solved by
systemd package.
Do you have any opinion, how should resolvconf be supported on Fedora?
Any opinion against it?
1. https://src.fedoraproject.org/rpms/openresolv
2. https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS
3. https://roy.marples.name/projects/openresolv/configuration/
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
3 years, 2 months
Policy proposal (draft): Don't push knowingly broken or
work-in-progress work to dist git
by Miro Hrončok
Hello,
When we work on rebuilding Python packages with new Python version and when
other provenpackagers rebuild multiple packages at once, I've seen several
problems with packages failing to build from source and/or creating unexpected
breakage in rawhide when built. Usually, some of the following happens:
1. Untested changes
Packager pushes a "simple update" to dist git without checking if it even
builds. It doesn't. Packager has no time to fix this, so they move on for now.
Or they submit a build but never check if it actually built. Provenpackagers who
need to rebuild the package need to figure this out and fix the problem if it is
trivial, or revert the recent commit, when the failure blocks them.
IMHO Provenpackagers should not need to worry about this. Changes should be at
least smoke tested by a mock/scratch build and installation check before
shipping them.
2. Changes that work but are waiting on external factors
Packager pushes a breaking change to dist git (such as a soname bump) before
coordinating the change with the dependent packages, not intending to
immediately build it. A provenpackager rebuilds the package for a different
reason (such as a different soname bump), accidentally shipping the
not-yet-wanted upgrade to rawhide.
IMHO Provenpackagers should not need to worry about this. Commits should land in
dist git only when they are intended to be built (close to) immediately. The
only reasonable exception is when building the pushed changes in a side tag and
even then, packagers should communicate their intentions.
3. Work-in-progress changes
Packager works on a package. They have a work in progress solution to their
problem, but no time to finish. They push a "WIP" commit that either breaks the
build or produces a broken package. The symptoms are similar to (1) or (2). I've
heard packagers saying "but this is rawhide, this is where development happens,
so this is expected" - I disagree.
---
I'd like to explicitly say that neither of this is considered a good behavior.
I'd like to have a policy that more or less says:
1. Packagers MUST NOT push changes that are not considered ready to be built and
shipped at the time of the push. Using Pull Requests (clearly marked as not
ready to be merged) is a better place to present/save changes that are not ready
yet.
2. Packagers SHOULD preemptively check if the changes they intend to push work.
At least checking if the intended change builds and the package installs with it
is strongly recommended. In cases where the check is skipped for time reasons
(e.g. when a testing build takes several hours and the changes are urgent),
packagers SHOULD be ready to fix the build/installation failure in timely manner
after it is discovered by the actual build.
Before I try to word it more carefully I'd like to hear some feedback on this.
What do you think?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 2 months
Dilemma: -source repository data randomized by koji builder arch
by Fabio Valentini
Hello everybody,
There's a problem that's been puzzling me for months, since I started
writing the repochecker service (which provides the backend FTI/FTBFS
data for the new packager-dashboard):
There is no correct "source of truth" for BuildRequires / complete
package dependency graphs.
While SRPM *contents* are forbidden from being dependent on their
environment (e.g. Sources or Patches guarded by %ifarch / %if
%fedora), their metadata (RPM headers) will still potentially be
architecture-dependent.
For example: The most frequent case of this is packages disabling
support for Qt5WebEngine on ppc64le and s390x, because it's not
available on those architectures. That means %ifarch conditionals
wrapping the BuildRequires for Qt5WebEngine. But that leads to the
interesting problem of the SRPM file having architecture-dependent RPM
headers.
However, because koji only keeps *one* SRPM file from each build (even
though they have potentially different metadata on different
architectures), and the architecture that one SRPM is generated on is
basically random, the contents of the -source repositories are,
basically, randomized, and unreliable.
The architecture-dependent nature of SRPM files in -source
repositories affects at least those tools and Fedora services:
- dnf builddep (errors when encountering foreign-arch dependencies,
even if they are guarded by %ifarch in the .spec file)
- dnf repoquery and repoclosure produce wrong results
- koschei gets confused by architecture-dependent BuildRequires and
claims "failed dependency resolution" for foreign-arch dependencies
I file an issue with koji asking for a way to get correct metadata for SRPMs:
https://pagure.io/koji/issue/2726
However, I agree that keeping 6 SRPM files with identical *content*
and only different *metadata* is incredibly wasteful. But koji is the
only place in the build pipeline at which the entire and correct
dependency information is available, and it's lost afterwards, because
the rebuilt SRPM files produced by mock on each architecture are
discarded. I don't know if there could be a way to expose an
"srpmdiff" between the SRPM files on different architectures ...
But I'd argue that it's definitely not good that there's currently *no
way* to query BuildRequires *correctly* and *reproducibly* (other than
possibly rebuilding all fedora SRPM files for each target
architecture, but I do not have the resources - nor the desire - to do
that, just to get correct dependency information).
For the repository data that's processed by repochecker (for the
packager-dashboard data), I needed to add hard-coded overrides for
those "false positives", which is definitely not scalable for the
hundreds of different architecture-dependent BuildRequires that exist
in Fedora, but I also don't have a way to find them other than "look
at the .spec file":
https://pagure.io/ironthree/repochecker/blob/master/f/overrides.json
So, if anybody has an idea how we can solve this issue and actually
provide correct repository data, that would be great :(
Fabio
3 years, 2 months