sysusers scriptlets: what to do if upstream includes the config
files?
by Adam Williamson
The guidelines for sysusers packaging:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/...
say:
"Create a <package-name>.sysusers file with the user definition and add
it to the specfile as a source...use the %sysusers_create_compat macro
to consume it in the %pre section:
%pre
%sysusers_create_compat %{SOURCE3}
"
but...what are you supposed to do if *upstream* ships the config files?
openQA recently added these to its upstream distribution, so it seems
wrong to replace the config files upstream ships with ones separately
packaged downstream. But if I don't package them as source files, how
can I set up the %pre macro? I tried this:
%pre
%sysusers_create_compat usr/lib/sysusers.d/geekotest.conf
where usr/lib/sysusers.d/geekotest.conf is the path to one of the
sysusers config file within the upstream source, but it doesn't seem to
work. The built package has no %pre script. However, that does work if
I eval it locally from an openQA source tree:
[adamw@xps13k openQA (master %)]$ rpm --eval "%sysusers_create_compat
usr/lib/sysusers.d/geekotest.conf"
# generated from geekotest.conf
getent group 'geekotest' >/dev/null || groupadd -r 'geekotest'
...etc...
so...help? Is there any way to make this work right? Thanks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 month, 3 weeks
What to do with Rust packaging in EPEL9?
by Igor Raits
Seems rust-srpm-macros and rust-packaging are in the RHEL9 which means it
is not possible to get them in EPEL9. That also means, they are already
outdated and do not support our latest greatest consistent packaging across
Fedora versions… Right now, I suppose it is still possible to get that
stuff updated in the Stream9, but later on it will be harder and harder I
suppose.
So what should one do if they want up2date stuff through the whole EPEL9
lifetime?
1 month, 3 weeks
Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed
by Nico Kadel-Garcia
@Miroslav Suchý asked me to sum up my suggestions for using internal
mirrors more clearly, So, adding to his published Google Doc:
5 - Use internal RHEL mirrors.
It's difficult to license multiple RHEL releases and enable multiple
yum dnf or yum channels and supported RHEL or CentOS releases and
architectures on a single server. Instead, support a local repository
with "reposync" used to mirror RHEL channels for designated
architectures and releases as needed. It is possible to mount DVD
images for local copies of specific releases to ease the mirroring
process.
Pros:
Provides multiple RHEL channels, architectures, and distributions
as desired.
Allows locking streams for scheduled updates of build environments
for compatibility inaccessible to streaming releases.
Allows aggregated, rather than directly mirrored, EPEL repos to
avoid regression failures.
Cons:
Requires local storage space and web server for registered clients
to load new content.
Requires individual tuning for distinct local environments
Adds RPM provenance concerns for local repos.
6. Use snapshotted CentOS 8 Stream mirrors
The CentOS 8 Stream uncertainties are described above. Creating a
local CentOS 8 mirror with locked snapshots can help stabilize the
stream, update the build components only if and when an update is
scheduled.
Pros:
Reduces burden of multiple build hosts on upstream mirrors.
Allows site specific scheduling of build repo updates.
Allows easy and efficient rsync internal mirrors.
Allows aggregated, rather than directly mirrored, EPEL repos to
avoid regression failures.
Cons:
Reposync based mirrors for RHEL require more work.
Includes inevitable phase lags between upstream changes and local
snapshotted repos..
Reduces, though does not completely eliminate risk of CentOS 8
Stream regression errors
1 month, 3 weeks
Mock/Copr default epel-8-* configuration to be changed
by Pavel Raiskup
Hello Fedora EPEL maintainers!
First I don't feel comfortable announcing this, I'm not happy about the
situation and so I don't want to be the lightning rod :-). But I believe
that we can come to acceptable Copr/Mock solution and this needs to be
discussed... so here we are.
By the end of the year 2021 we have to fix our default EPEL 8 Mock
configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8
goes EOL by then.
The same thing needs to happen in Fedora Copr, with the epel-8-* chroots
(side note, in Fedora Copr we use the mock-core-configs package for builds
without any deployment specific modifications).
I am proposing (as PR against mock upstream ATM [1]) to switch the default
epel-* configuration from CentOS+EPEL to RHEL+EPEL as soon as possible
(see the pull request [1]).
This would bring some consequences, namely newly with epel-8* chroots,
- builds will require a valid Red Hat subscription (the no-cost variant is
OK as well, though [2])
- we will miss some build-time packages that Red Hat is not shipping, at
least at the beginning till they are added (to RHEL CRB, or other
currently unknown place).
- cross-arch compilation can not be used, Red Hat subscriptions don't
allow that (using QEMU and rpm --forcearch), [3]
The positive thing is that the default configuration will be much closer
to the official EPEL builds (because Fedora Koji EPEL builds are actually done
also against RHEL).
For the Fedora Copr builders, we already have the necessary Red Hat
subscriptions in hand (will be deployed by the end of the year). So we will
only loose the opportunity to build on emulated epel-8-armhfp permanently, and
epel-8-s390x temporarily (as we already work on the native s390x support).
Any thoughts? Feedback is needed here.
[1] https://github.com/rpm-software-management/mock/pull/802
[2] https://rpm-software-management.github.io/mock/Feature-rhelchroots
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1912847
Pavel
1 month, 3 weeks
Unowned system directories
by Steve Grubb
Hello,
I am preparing to migate a F35 system to new hardware and was sanity checking
the whole system. One thing I found was that there are a number of system
directories that that are not owned by the package that uses them:
/var/cache/ibus
/var/cache/PackageKit
/var/cache/cups
/var/log/anaconda
/var/lib/tpm2-tss
/var/lib/machines
/var/lib/hsqldb
/var/lib/cs
/var/lib/rpcbind
/var/lib/portables
/etc/module-build-service
/etc/default
/etc/pesign
/etc/ipa
/etc/ndctl
/etc/flatpak
Should there be a gating or other test that catches this?
Thanks,
-Steve
1 month, 3 weeks
F36 Change: LXQt 1.0.0 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LXQt_1.0
== Summary ==
Update LXQt to 1.0.0 in Fedora.
== Owner ==
* Name: [[User:Zsun|Zamir SUN]]
* Email: zsun#AT#fedoraproject.org
== Detailed Description ==
LXQt 1.0.0 released with a bunch of bugfixes and new features. It's
always good to keep Fedora users running on most recent software.
Detailed LXQt release note is available
[https://lxqt-project.org/release/2021/11/06/lxqt-1-0-0/ here].
== Benefit to Fedora ==
This change brings bug fixes and enhancements to LXQt in Fedora.
== Scope ==
* Proposal owners: Update all the LXQt related packages in Fedora. And
fix the kickstart file if needed.
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/10405 #10405]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Install using the spin, netinstall or DVD. Or upgrade from older
release. Then users should be able to test by doing any daily work.
== User Experience ==
There will be a better user experience and many new features to explore.
== Dependencies ==
This update is pretty self contained.
== Contingency Plan ==
* Contingency mechanism: If I cannot make it happen, I'll just do not
merge side-tag into f36 branch.
* Contingency deadline: Fedora 36 Beta Freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 month, 3 weeks
