Should opencv require scala on runtime?
by Miro Hrončok
I've realized I have scala installed on my F33 developer machine and wanted to
remove it. But apparently, opencv-core pulls it in:
[~]$ repoquery --installed --whatrequires scala
jacop-0:4.8-2.fc33.noarch
[~]$ repoquery --installed --whatrequires jacop
mp-0:3.1.0-31.20200303git7fd4828.fc33.x86_64
[~]$ repoquery --installed --whatrequires mp
coin-or-Cbc-0:2.10.5-4.fc33.x86_64
[~]$ repoquery --installed --whatrequires coin-or-Cbc
coin-or-Clp-0:1.17.6-2.fc33.x86_64
[~]$ repoquery --installed --whatrequires coin-or-Clp
coin-or-Cbc-0:2.10.5-4.fc33.x86_64
coin-or-Cgl-0:0.60.3-2.fc33.x86_64
opencv-core-0:4.3.0-10.fc33.x86_64
Is this chain expected?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 3 months
dropping selinux-policy strict version requirement
by Ken Dreyer
Hi folks,
Many applications ship their own "-selinux" sub-package. These
subpackages usually set a minimal dependency on the exact
selinux-policy version in the buildroot.
In Ceph's case, we have:
Requires(post): selinux-policy-base >= %{_selinux_policy_version}
This version requirement causes problems in two scenarios:
1. If we build Ceph on CentOS Stream, the ceph-selinux package will be
uninstallable on RHEL.
2. If we build Ceph on the latest RHEL 8, the ceph-selinux package
package will be uninstallable on RHEL 8 EUS.
Is it safe to drop the exact version requirement here and just depend
on an unversioned "selinux-policy-base"?
I can't find any official Fedora Packaging Guideline on this. I opened
https://tracker.ceph.com/issues/49034 to track this in Ceph upstream.
- Ken
3 years, 3 months
Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
Note that this change was submitted after the deadline, but since it can be
shipped in an complete state, I am still processing it for Fedora 34.
== Summary ==
We want to add signatures to individual files that are part of shipped RPMs.
These signatures will use the Linux IMA (Integrity Measurement
Architecture) scheme, which means they can be used to enforce runtime
policies to ensure execution of only trusted files.
== Owner ==
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]
* Email: puiterwijk(a)redhat.com
* Name: [[User:Pbrobinson| Peter Robinson]]
* Email: pbrobinson(a)gmail.com
== Detailed Description ==
During signing builds, the files in it will be signed with IMA signatures..
These signatures will be made with a key that’s kept by the Fedora
Infrastructure team, and installed on the sign vaults.
== Benefit to Fedora ==
Having all files signed with a verifiable key means that system owners can
use the kernel Integrity and Measurement Architecture (IMA) to enforce only
verified files can be executed, or define other policies.
== Scope ==
* Proposal owners:
The proposal owners will write the code for sigul to pass the required
arguments, generate the keys in Infrastructure and get them deployed to the
sign vaults.
* Other developers:
Nothing needed from other developers
* Release engineering:
A mass rebuild would be nice (as it ensures all packages are signed), but
is not required to implement the change itself.
* Policies and guidelines:
No impact
* Trademark approval:
No impact
* Alignment with Objectives:
This aligns with the Internet of Things objective.
== Upgrade/compatibility impact ==
For standard Fedora users there will be no impact. If an advanced user was
already signing their own files (for the Fedora shipped RPMs) for IMA
functionality, they will just overwrite the existing signature.
== How To Test ==
The signatures can be tested “in vitro” by running `evmctl ima_verify
--sigfile --key publiccert.der -v myfile.txt`.
This should result in the system reporting “<filename>: verification is OK”.
The full system could be tested by enrolling the Fedora IMA key to the
kernel `_ima` keyring, and adding a policy that verifies (some) files to be
verified against the key. (instructions to follow).
== User Experience ==
If the user deploys an IMA policy to verify all or some files, they should
be able to trust the signatures made by the Fedora build system.
== Dependencies ==
No external package dependencies.
== Contingency Plan ==
* Contingency mechanism: If the change is not finished in time, we have
probably not yet started signing new files. Signing can easily be disabled
by updating the config file should issues arise.
If we did start signing, but haven’t signed everything, that is okay, since
then packages will get signed as they’re bumped by developers, and they’ll
be all signed in the next major release.
* Contingency deadline: We could ship with this feature in an unfinished
state.
* Blocks release? No
* Blocks product? N/A
== Documentation ==
Documentation to follow.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
What is the most time consuming task for you as packager?
by Miroslav Suchý
I am looking for challenges for upcoming year - what I and my team should enhance. I have some ideas, but I want to hear
yours.
What you - as Fedora packager - find most time consuming on packaging?
Where you will welcome more simplicity or automation?
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
3 years, 3 months
Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Scale_ZRAM_to_full_memory_size
== Summary ==
Fedora 33 [[Changes/SwapOnZRAM|enabled zram by default]]. The size of
the virtual swap devices was set so that the amount of memory used for
compressed swap pages was limited to a quarter of physical memory in
typical scenarios. That size is now increased to half of physical
memory (`zram-fraction` becomes 1.0, `max-zram-size` becomes 8 GiB).
This allows systems with small amounts to successfully launch the
[https://anaconda-installer.readthedocs.io/en/latest/ Anaconda
installer] and other programs.
== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek(a)in.waw.pl
* Name: [[User:jwrdegoede|Hans de Goede]]
* Email: hdegoede(a)redhat.com
== Detailed Description ==
When ZRAM was enabled by default in Fedora 33, the size of the device
(before compression) was limited to fraction 0.5 of RAM or 4 GiB,
whichever is less. The reason to limit the fraction to less than 1.0
is that with only incompressible data in memory, whole RAM would be
filled by the "compressed" pages, leaving no RAM for normal use. But
this concern seems to have been overblown, and there have been no
reports of compressed swap taking up too much memory. In real use, we
will have at least a few hundred MiB of code in memory, which
compresses quite well, so some compression will occur even when
working with incompressible data. In typical usage scenarios, we get
effective compression of 2:1 or 3:1, which means that the compressed
pages use at most between 1/4th and 1/6th of RAM. By increasing the
fraction to 1.0, we expect to consign up to half of RAM for compressed
pages.
Increasing the size of the device is important for small devices. For
devices with 1GB of RAM, sizing ZRAM to 1 GiB allows successful
installation with Anaconda. In general, it is expected that having
more compressed swap will make the device more functional after
installation too. This increase is the most important for devices with
small amounts of memory (< 1 GiB), but will be beneficial to systems
with slightly larger systems (1–8 GiB).
Technically, this change is completely trivial, amounting to two lines
of configuration. Nevertheless, there is some potential for problems
with incompressible workloads. The experience with ZRAM so far makes
the Change authors optimistic that no issues will be encountered, but
users and other developers should be aware of the change.
== Benefit to Fedora ==
Fedora works better on devices with low RAM. In particular, the
installer can function.
== Scope ==
* Proposal owners: change the defaults in `zram-generator-defaults`
package to `zram-fraction=1.0`, `max-zram-size=8096`.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Default configuration is changed. Systems with local configuration
will not be affected. Systems which had zram-generator disabled will
not be affected.
== How To Test ==
Install the new version of the `zram-generator-defaults` package,
execute `sudo systemctl daemon-reload && sudo systemctl restart
swap-create@zram0`, use `zramctl` to check that the device has the
expected size. After some use, check that pages are compressed at
least with ration 2:1:
<pre>
$ zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle 7.6G 4K 74B 12K 4 [SWAP]
^ ^ ^
| \____\_______ the ratio of those
values should be more than 2:1
|
`------ this should be approx the size of RAM
</pre>
(Note that the device is destroyed and recreated during restart. This
means that all pages will be "swapped in", i.e. decompressed. On
machines with low memory, rebooting might be a better option.)
== User Experience ==
Not user visible.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Revert default configuration to previous values.
* Contingency deadline: Final freeze, any time really.
* Blocks release? No
* Blocks product? No
== Documentation ==
None.
== Release Notes ==
The default size of compressed zram devices (`/dev/zram0`) has been
increased to 1.0 fraction of RAM, or 8 GiB, whichever is smaller.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months