Any interest in ROCm packaging?
by Jeremy Newton
Full disclosure, I am both a Fedora packager and an employee at AMD.
To be clear, the following is not at all endorsed by my employer; my interest and use of Fedora is purely a personal hobby and I would like to keep it that way.
There has been a recent effort to step up Debian packaging of ROCm, and would like to see if anyone has some interest in expanding the Fedora ROCm packages.
I see there's a few packages already, and I'm hoping to help with some internal processes to make ROCm more distro friendly, such as better FHS compliance, clearer licensing, etc.
Anyone interested? I would be happy to try to help or review package requests :)
2 years, 2 months
F36 Change: Plocate as the default locate implementation
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Plocate_as_the_default_locate_impl...
== Summary ==
The venerable `mlocate` program is replaced by `plocate` — a
compatible reimplementation that is faster and uses less disk space.
== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl
* Name: [[User:Msekleta| Michal Sekletár]]
* Email: msekleta at redhat.com
== Detailed Description ==
Plocate is a newer implementation of `locate`/`mlocate` that using
`liburing` and `libzstd` for speed.
The database it creates on disk is also smaller.
Debian recently switched to `plocate` as the default implementation
(https://lwn.net/Articles/846405/).
It doesn't seem useful to maintain multiple locate implementations.
Thus the new package Conflicts with the old one, so they cannot be
installed in parallel.
The plan is:
# F35: `plocate` is made available for testing
# F36: `mlocate` is replaced by `plocate` in comps
# F37 or F38: `mlocate` will be retired (or given away, if somebody
wants to pick it up)
== Benefit to Fedora ==
We save some cpu cycles and disk sectors by using a more modern
implementation of a common tool.
== Scope ==
* Proposal owners:
** package `mlocate` (Review bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1931141, DONE)
** submit a pull request to comps with `s/mlocate/plocate/`
* Other developers: install plocate locally and test if it works as
expected on F35 and other versions
* Release engineering: n/a
* Policies and guidelines: n/a
* Trademark approval: n/a
* Alignment with Objectives: none
== Upgrade/compatibility impact ==
The upgrade should be mostly invisible. It is possible that somebody
might be relying on some very specific `mlocate` behaviour or parsing
the `mlocate` database directly, but no such cases are currently
known.
== How To Test ==
# Install `plocate` (`sudo dnf install plocate --allowerasing`)
# Wait for `plocate-updatedb.service` to finish (`sudo systemctl start
plocate-updatedb.service`)
# Use `plocate pattern` or `plocate -r <regexp>` to search for files.
== User Experience ==
Users should not notice the difference. Installing `plocate`
automatically removes `mlocate`. The new implementation is generally
compatible with the old one in all common cases, and provides some
additional options.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
`plocate` is now used as the default provider of `/usr/bin/locate`
instead of `mlocate`.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
Rawhide kernel crash
by edmond pilon
Has anyone tried the last kernel-5.15.0-60.fc36.
I have crashes at boot with this kernel since rc7 , with nvidia rpmfusion drivers .
I think it's because of this fedora patch : fedora: Disable fbdev drivers and use simpledrm instead .
I sent a bug report but still no answer .
2 years, 2 months
F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
== Summary ==
Currently, the RPM databases is located in `/var`. Let's move it to
`/usr`. The move is already under way in rpm-ostree-based
installations, and in (open)SUSE.
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel
Alexandre Salim]], [[User:Ngompa|Neal Gompa]]
* Email: bugzilla(a)colorremedies.com, michel(a)michel-slm.name, ngompa13(a)gmail.com
== Detailed Description ==
=== Current location ===
<pre>/var/lib/rpm</pre>
=== New location ===
<pre>/usr/lib/sysimage/rpm</pre>
<code>/var/lib/rpm</code> will be a symlink pointing to
<code>/usr/lib/sysimage/rpm</code>
Changing the file system layout to accommodate a snapshot+rollback
regime is implied, but not required by this proposal. For example,
Fedora has long placed `/home` on a separate subvolume (or file
system) so it can be isolated from system root. Likewise, it makes
sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so
these locations continue to carry forward in time, even if the system
root does a rollback.
== Feedback ==
There will be no change to DNF as part of this change proposal. DNF's
history will remain in `/var` until DNF 5. Discussion continues about
the effect of a snapshot+rollback regime on DNF history.
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html
Relocate DNF history to /usr.]
Upstream RPM accept the change, but institutionally don't like the
loss or weakening of a
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html
very well known location] for the database, and
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html
anticipate complaints].
== Benefit to Fedora ==
* The RPM database primarily describes the state of `/usr`. Storing
the databases in `/usr` will more easily facilitate OS rollback,
without affecting `/var`.
* Helps align Fedora variants with each other
** rpm-ostree based systems (including CoreOS, IoT, Silverblue,
Kinoite) already use `/usr/lib/sysimage` for rpmdb.
* Consistency with another RPM-based distro, (open)SUSE has made this change
* Accounts for various snapshot+rollback regimes, i.e. it's a
beneficial change whether Btrfs or device-mapper based regimes.
== Scope ==
* Proposal owners:
** changes in rpm package
*** create the new path
*** create a symlink for the old path pointing to new path
* Other developers:
** changes in SElinux policy
* Release engineering: [https://pagure.io/releng/issue/10441 #Releng
issue 10441]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Change will be applied to offline upgrades, similar to the RPM sqlite
database change. A systemd service will move the rpmdb from /var to
/usr, then create a symlink pointing to /usr from /var.
# Create `/usr/lib/sysimage/rpm` (rpm package will do this at preinst)
# Create symlinks in `/usr/lib/sysimage/rpm/` pointing to files in
`/var/lib/rpm/` (rpm package will do this at preinst)
# Change the dbpath in `/usr/lib/rpm/macros` to
`/usr/lib/sysimage/rpm` (rpm package will be patched to do this on
F36+)
# Request rpm rebuild the database (done via systemd service)
# Remove `/var/lib/rpm` and create a symlink `/var/lib/rpm` ->
`/usr/lib/sysimage/rpm` (done via systemd service)
== How To Test ==
# Perform a new clean install, or upgrade a system
# Check that `/var/lib/rpm` is a symlink to `/usr/lib/sysimage/rpm`
# Check that `/usr/lib/sysimage/rpm` is populated with at least
`rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and
`rpmdb.sqlite-wal`
# Confirm `rpm -q <package>` and/or `rpm -qa` still work
== User Experience ==
* symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm`
Otherwise, the change should be invisible to users.
== Dependencies ==
* `rpm-ostree` probably should make `/usr/share/rpm` a symlink to
`/usr/lib/sysimage/rpm`, rather than the reverse as it is currently.
* `PackageKit` might use inotify on `/var/lib/rpm` need to check if it
does and whether it should be changed or add the additional path
== Contingency Plan ==
* Contingency mechanism: Revert the change, try again the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? Yes
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
2 years, 2 months
Heads-up: trousers (TPM 1.2) silently orphaned
by Michel Alexandre Salim
Hi all,
`trousers` got silently orphaned around the time an EPEL9 branch for it
was requested: https://bugzilla.redhat.com/show_bug.cgi?id=2032258
Looks like we're slowly uncoupling ourselves from it, e.g.
- for ARM, uboot-tools no longer pulls in vboot-utils which pulls in
trousers: https://lists.fedoraproject.org/archives/list/scm-commits@lists.fedorapro...
- Neal disabled TPM/TSS 1.2 support in strongswan, dropping the trousers
dependency, in https://src.fedoraproject.org/rpms/strongswan/pull-request/13
but there are several dependencies still around (strongswan still shows
up here as the PR just got merged a few hours ago)
```
~
❯ sudo dnf repoquery --disablerepo=\* --enablerepo=rawhide-source --whatrequires trousers-devel
Last metadata expiration check: 0:00:10 ago on Thu 16 Dec 2021 10:08:04 AM PST.
ecryptfs-utils-0:111-25.fc36.src
gnutls-0:3.7.2-2.fc35.src
golang-github-google-tspi-0:0.2.0-6.fc35.src
openconnect-0:8.10-7.fc35.src
strongswan-0:5.9.4-3.fc36.src
tpm-quote-tools-0:1.0.4-8.fc35.src
tpm-tools-0:1.3.9-12.fc36.src
vboot-utils-0:20190823-8.git595108c0.fc36.src
```
Do we want to keep trousers in Fedora? If so someone who needs it should probably step up, if not, we should toggle it off in these packages. Maintainers BCC:ed.
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
2 years, 2 months
Self Introduction: Jan Baudisch
by Jan Baudisch
Hi,
I am a computer science student from Germany and have used Fedora for
at least 2 years by now.
Using COPR I gained some experience in buidling packages but recently I
wanted to try building packages conforming to the guidelines and
getting them into Fedora. My interest is mostly in Rust and that is why
I would like to contribute Rust packages. I already got started here:
https://copr.fedorainfracloud.org/coprs/janbaudisch/rust/packages
For now my main interest would be to get the Rocket framework packaged,
as many projects rely on it and on the way I discovered some key Rust
crates not packaged yet.
I feel like some of them are ready for submission and will file the
first review requests soon.
Looking forward to working on this!
Jan
2 years, 2 months
Rust Stack Spring Cleaning (in Winter)
by Fabio Valentini
Hello Rust packagers,
(I'm sending this email to the devel and rust lists, and I've added all directly
affected package maintainers in Bcc - because adding them all to the "To" or
"CC" fields would make the lists reject this message, I believe.)
I have been working on and preparing some more clean-ups in the Rust stack, and
I came across a large-ish number of Rust packages that were imported to Fedora,
but the recommended "initial setup" for them was never finished.
I have started by adding them all "rust-*" packages to koschei, which makes it
way easier for me to see at a glance whether there are any broken packages in
our Rust stack at any point in time.
I will also make sure all those packages are correctly set up with anitya /
release-monitoring.org, so that we actually get notifications for new versions
of all those crate packages.
Additionally, I would ask of all of you to make sure all your packages have been
added to the @rust-sig group on src.fedoraproject.org (at least with "commit"
access). Without that, it makes it very hard for us to keep the Rust stack
up-to-date and in working order, because the "rust-sig" list / bugzilla account
does not get CC'd on new bugs that way, and your bugs do not show up in our
BugZilla queries.
For example, I have been working on packaging and updating the RustCrypto
stack of crates, and found that most of the already existing
(security-sensitive!) crates are not "completely" set up, and are now out of
date, just because I didn't even know about those packages (and some were also
not set up with release-monitoring.org).
In the interest of keeping the Rust stack in Fedora in a good state, please
add "@rust-sig" group to all you Rust packages on src.fedoraproject.org, unless
there is a very good reason not to do so (and if that is the case for a
particular package in this list, I'd be interested in knowing the reason, as
well).
If you want a scripted way of adding "@rust-sig" group to many packages, you
can generate an API token on src.fedoraproject.org (with "Modify an existing
project") access level, and use the simple Python script from this GitHub gist:
https://gist.github.com/decathorpe/9d128982cb00e2d345d9e397372538ec
Below is the list of "incompletely set-up" packages, in alphabetic order, and
at the bottom, there is a list of packages per affected package maintainer.
Thanks,
Fabio
===
- rust-arrayvec0.5: eclipseo
- rust-asn1: cheimes
- rust-asn1_derive: cheimes
- rust-assert-impl: dcavalca
- rust-aws-nitro-enclaves-cose: pbrobinson
- rust-benfred-read-process-memory: dcavalca
- rust-biscuit: orphan
- rust-bitfield: ignatenkobrain
- rust-block-cipher: ignatenkobrain
- rust-blsctl: javierm
- rust-btrd: dcavalca
- rust-bytelines: ignatenkobrain
- rust-clap_generate: eclipseo
- rust-clap_generate_fig: eclipseo
- rust-clircle: eclipseo
- rust-combine: dcavalca
- rust-console0.13: ignatenkobrain
- rust-cryptoki: pbrobinson
- rust-cryptoki-sys: pbrobinson
- rust-cty: nickblack
- rust-dbus-codegen: pbrobinson
- rust-dbus-crossroads: pbrobinson
- rust-derivative: pbrobinson
- rust-directories-next: jbtrystram
- rust-dirs2: ignatenkobrain
- rust-elf: dcavalca
- rust-enumflags2: ignatenkobrain, pbrobinson
- rust-env_proxy: dcavalca
- rust-epoll: slp
- rust-event-listener: dcavalca
- rust-fasteval: zbyszek
- rust-hostname-validator: ignatenkobrain
- rust-inferno: dcavalca
- rust-itertools0.9: ignatenkobrain
- rust-josekit: pbrobinson
- rust-js-sys: pbrobinson
- rust-keccak: pbrobinson
- rust-log-panics: salimma
- rust-mbox: ignatenkobrain, pbrobinson
- rust-navi: jbtrystram
- rust-netlink-packet-core: cathay4t, ffmancera
- rust-netlink-packet-route: cathay4t, ffmancera
- rust-netlink-packet-utils: cathay4t, ffmancera
- rust-netlink-proto: cathay4t, ffmancera
- rust-netlink-sys: cathay4t, ffmancera
- rust-num-format: dcavalca
- rust-oauth2: ctron, jbtrystram
- rust-oid: pbrobinson
- rust-openat-ext: walters
- rust-pam-sys: eneville
- rust-parsec-client: pbrobinson
- rust-parsec-interface: pbrobinson
- rust-picky-asn1: pbrobinson
- rust-picky-asn1-der: pbrobinson
- rust-picky-asn1-x509: pbrobinson
- rust-psa-crypto: pbrobinson
- rust-pkcs11: pbrobinson
- rust-pleaser: eneville
- rust-process_control: atim, petersen
- rust-proc-maps: dcavalca
- rust-prost: pbrobinson
- rust-prost-build: pbrobinson
- rust-prost-derive: pbrobinson
- rust-prost-types: pbrobinson
- rust-psa-crypto-sys: pbrobinson
- rust-qstring: ctron, jbtrystram
- rust-rand0.7: ignatenkobrain
- rust-rand_chacha0.2: ignatenkobrain
- rust-rand_core0.5: ignatenkobrain
- rust-rand_pcg0.2: ignatenkobrain
- rust-rbspy-ruby-structs: dcavalca
- rust-rbspy-testdata: dcavalca
- rust-read-process-memory: dcavalca
- rust-remoteprocess: dcavalca
- rust-rsa: pbrobinson
- rust-rtnetlink: cathay4t, ffmancera
- rust-sd-notify: pbrobinson
- rust-secrecy: pbrobinson
- rust-serde_with: pbrobinson
- rust-sha3: pbrobinson
- rust-shadow-rs: atim
- rust-shellwords: jbtrystram
- rust-signal-hook-mio: dcavalca
- rust-signature: orphan
- rust-simple_asn1: pbrobinson
- rust-stratisd_proc_macros: jbaublitz
- rust-str_stack: dcavalca
- rust-subprocess: dcavalca
- rust-syslog: eneville
- rust-tabular: jbtrystram
- rust-textwrap0.11: ignatenkobrain
- rust-textwrap0.12: ignatenkobrain
- rust-thread-tree: dcavalca
- rust-toml_edit: dcavalca
- rust-tss-esapi-sys: pbrobinson
- rust-universal-hash: pbrobinson
- rust-version: pbrobinson
- rust-versions: atim
- rust-version-sync0.8: ignatenkobrain
- rust-virtio-bindings: slp
- rust-vm-memory: slp
- rust-vmm-sys-util: slp
- rust-vte_generate_state_changes: ignatenkobrain
- rust-webbrowser: ctron, jbtrystram
- rust-zmq: ueno
Lists by maintainer:
- atim (3): rust-process_control, rust-shadow-rs, rust-versions
- cathay4t (6): rust-netlink-packet-core, rust-netlink-packet-route,
rust-netlink-packet-utils, rust-netlink-proto, rust-netlink-sys,
rust-rtnetlink
- cheimes (2): rust-asn1, rust-asn1_derive
- ctron (3): rust-oauth2, rust-qstring, rust-webbrowser
- dcavalca (19): rust-assert-impl, rust-benfred-read-process-memory,
rust-btrd, rust-combine, rust-elf, rust-env_proxy,
rust-event-listener, rust-inferno, rust-num-format, rust-proc-maps,
rust-rbspy-ruby-structs, rust-rbspy-testdata,
rust-read-process-memory, rust-remoteprocess, rust-signal-hook-mio,
rust-str_stack, rust-subprocess, rust-thread-tree, rust-toml_edit
- eclipseo (4): rust-arrayvec0.5, rust-clap_generate,
rust-clap_generate_fig, rust-clircle
- eneville (3): rust-pam-sys, rust-pleaser, rust-syslog
- ffmancera (6): rust-netlink-packet-core, rust-netlink-packet-route,
rust-netlink-packet-utils, rust-netlink-proto, rust-netlink-sys,
rust-rtnetlink
- ignatenkobrain (17): rust-bitfield, rust-block-cipher,
rust-bytelines, rust-console0.13, rust-dirs2, rust-enumflags2,
rust-hostname-validator, rust-itertools0.9, rust-mbox, rust-rand0.7,
rust-rand_chacha0.2, rust-rand_core0.5, rust-rand_pcg0.2,
rust-textwrap0.11, rust-textwrap0.12, rust-version-sync0.8,
rust-vte_generate_state_changes
- javierm (1): rust-blsctl
- jbaublitz (1): rust-stratisd_proc_macros
- jbtrystram (7): rust-directories-next, rust-navi, rust-oauth2,
rust-qstring, rust-shellwords, rust-tabular, rust-webbrowser
- nickblack (1): rust-cty
- orphan (2): rust-biscuit, rust-signature
- pbrobinson (33): rust-aws-nitro-enclaves-cose, rust-cryptoki,
rust-cryptoki-sys, rust-dbus-codegen, rust-dbus-crossroads,
rust-derivative, rust-enumflags2, rust-josekit, rust-js-sys,
rust-keccak, rust-mbox, rust-oid, rust-parsec-client,
rust-parsec-interface, rust-picky-asn1, rust-picky-asn1-der,
rust-picky-asn1-x509, rust-psa-crypto, rust-pkcs11, rust-prost,
rust-prost-build, rust-prost-derive, rust-prost-types,
rust-psa-crypto-sys, rust-rsa, rust-sd-notify, rust-secrecy,
rust-serde_with, rust-sha3, rust-simple_asn1, rust-tss-esapi-sys,
rust-universal-hash, rust-version
- petersen (1): rust-process_control
- salimma (1): rust-log-panics
- slp (4): rust-epoll, rust-virtio-bindings, rust-vm-memory, rust-vmm-sys-util
- ueno (1): rust-zmq
- walters (1): rust-openat-ext
- zbyszek (1): rust-fasteval
2 years, 2 months