devel December 2021

devel@lists.stg.fedoraproject.org

191 participants
293 discussions

F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
by Ben Cotton 21 Jan '22

21 Jan '22

https://fedoraproject.org/wiki/Changes/Plocate_as_the_default_locate_implem… == 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

11 26

Firefox Hardware acceleration & VA-API how-to
by Martin Stransky 19 Jan '22

19 Jan '22

Hi folks, I was told that people were having trouble with Firefox/HW acceleration/VA-API setup on Fedora so I put some info at wiki at: https://fedoraproject.org/wiki/Firefox_Hardware_acceleration Hope it helps. Martin -- Martin Stransky Software Engineer / Red Hat, Inc

15 32

Rawhide kernel crash
by edmond pilon 18 Jan '22

18 Jan '22

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 .

5 12

F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
by Ben Cotton 17 Jan '22

17 Jan '22

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

33 135

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 17 Jan '22

17 Jan '22

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

6 9

Heads-up: trousers (TPM 1.2) silently orphaned
by Michel Alexandre Salim 15 Jan '22

15 Jan '22

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.fedoraproje… - 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

4 6

Self Introduction: Jan Baudisch
by Jan Baudisch 14 Jan '22

14 Jan '22

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

3 2

F36 Change: Default To Noto Fonts (System-Wide Change proposal)
by Ben Cotton 13 Jan '22

13 Jan '22

https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts == Summary == Changing the default fonts for various languages to Noto Fonts as much as possible, to make consistency on the text rendering. == Owner == * Name: [[User:Tagoh|Akira TAGOH]] * Email: <tagoh(a)redhat.com> == Detailed Description == For a long time we have used DejaVu fonts as the default font for European and other language scripts. On the other hand some language scripts are not covered by DejaVu and hence have other default fonts. (A few languages like Chinese, Japanese and Korean, as well as Gurmukhi, Sinhala, and emoji are already using Noto fonts by default for some time.) This situation leads to inconsistencies in text rendering on applications and desktops, particularly when mixing different character sets. Further Noto fonts bring some further advantages: the fonts are generally higher quality and support variable fonts for most scripts, making them more compact. This change aims to provide better experience and consistent text rendering across more languages by replacing DejaVu with Noto as the general system default set of fonts. The following packages will be installed by default to replace DejaVu's coverage: * google-noto-sans-vf-fonts * google-noto-serif-vf-fonts * google-noto-sans-mono-vf-fonts * google-noto-sans-arabic-vf-fonts * google-noto-sans-cherokee-vf-fonts * google-noto-sans-thaana-vf-fonts * google-noto-sans-hebrew-vf-fonts * google-noto-rashi-hebrew-vf-fonts * google-noto-sans-math-vf-fonts * google-noto-sans-armenian-vf-fonts * google-noto-serif-armenian-vf-fonts * google-noto-sans-canadian-aboriginal-vf-fonts * google-noto-sans-georgian-vf-fonts * google-noto-serif-georgian-vf-fonts * google-noto-sans-lao-vf-fonts * google-noto-serif-lao-vf-fonts * google-noto-serif-gurmukhi-vf-fonts * google-noto-serif-sinhala-vf-fonts And you can check [https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to see what languages will be affected by this change. == Benefit to Fedora == We would get better text rendering on applications and desktops. Also this change should save about 6MB on the fresh install. <pre> $ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts | awk 'BEGIN{a=0}{a+=$5}END{print a}' 10789272</pre> <pre> $ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts google-noto -sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f onts google-noto-serif-armenian-vf-fonts google-noto-sans-canadian-aboriginal-vf-fonts google-noto-sans-georgian-vf-f onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print a}' 4753340 </pre> == Scope == * Proposal owners: ** Update google-noto-fonts and dejavu-fonts to change the priority for fontconfig config. ** Update langpacks to update the dependency. ** Update comps to make Noto fonts default. ** Update lorax templates related to DejaVu. ** Update fontconfig to change the order of fonts in the builtin config. * Other developers: ** Packagers who owns packages implicitly expects DejaVu is installed by default will needs to update the dependency for them. * Release engineering: [https://pagure.io/releng/issue/10492 #10492] * 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 == The migration will be done by updating langpacks. after upgrading and rebooting, the default font will be Noto instead of DejaVu. Since this change aims to switch non-variable fonts to variable fonts, it may not works with legacy applications as expected such as missing some variants. in that case, you can install non-variable fonts packages. the package name will be similar and simply drop `-vf` from the variable fonts packages. == How To Test == * This change can be simply tested by `fc-match` command like `fc-match sans:lang=<your langauge>`, `fc-match serif:lang=<your language>` and `fc-match monospace:lang=<your language>`. You can check the expected result from [https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table]. * Test the text rendering in your favorite application, which use the system default font. == User Experience == Users will see the default font is changed to Noto by this change except for some languages which has much better quality of fonts. == Dependencies == Only dejavu-fonts, langpacks, and fontconfig are required to update. Other packages which explicitly has a dependency to dejavu-fonts are basicaly optional to update. == Contingency Plan == * Contingency mechanism: Revert the relevant packages updated. * Contingency deadline: Beta freeze * Blocks release? No == Documentation == None. == Release Notes == The default fonts for most languages will be Google Noto fonts instead of DejaVu, to keep consistency on the text rendering and to provide better quality among languages. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

10 18

Rust Stack Spring Cleaning (in Winter)
by Fabio Valentini 11 Jan '22

11 Jan '22

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

4 4

Koji notifications arriving days late
by Julian Sikorski 10 Jan '22

10 Jan '22

Hello, is it a known problem that koji notifications arrive way too late? For example, I got mame build notifications in the wee hours today (31.12) wheras the builds completed around noon on the 29th: https://koji.fedoraproject.org/koji/buildinfo?buildID=1871260 https://koji.fedoraproject.org/koji/buildinfo?buildID=1871254 https://koji.fedoraproject.org/koji/buildinfo?buildID=1871253 This does not seem normal. Is anybody seeing this too? Best regards, Julian

9 10

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel December 2021