Fedora-Cloud-34-20211217.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211216.0): ID: 1088295 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1088295 ID: 1088306 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1088306 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
On Fri, Dec 17, 2021 at 5:14 AM Roberto Sassu via devel wrote: > > > In Fedora, we use a new package signing key for each Fedora release. > > What key would be used for the fs-verity signatures: the same key, > > a separate key? Edit: I see that the Change page says a dedicated key is > > used. > > Hi all > > I'm doing related work in this area. I'll provide some additional > thoughts. > > Probably, it could be possible to use the package signing key > for the fsverity signatures. However, this would require the > kernel to be able to load the PGP keys in the builtin keyring > and support PGP signatures. > > David Howells did that some time ago, and I adapted his > patches for the latest kernel. Without going into too much > detail, I've modified the kernel build to take the Fedora > keys. They are available to verify PGP signatures (I use > this feature to verify RPM headers). > > If there is interest, I could propose the patch set to the kernel > mailing list. > That would be phenomenal. That would allow us to tie things to our existing process of key rotation for each Fedora release and leverage the existing infrastructure for package signing for fsverity signatures too. > > IIUC, I need to do some steps at each boot: > > 1. add all the keys to the keyring > > 2. set sysctl fs.verity.require_signatures=1 > > > > So… in 1., do I always load all the keys that Fedora has used for this > > purpose, in case there are still some files on disk? Or is there some > > mechanism to say that e.g. keys older than F(N-2) are now not necessary? > > > > Who does 2.? > > > > I think it'd be hard to enable this during a system upgrade: one would need > > to reinstall all rpms (with new rpms carrying the fsverity metadata) > > or some files become unreadable once 2. is done. This brings a question: > > is there some rpm virtual Provides/Requires to specify that the fs-verity > > stuff is present? I assume the user would want to triple-check that they > > don't have any rpms without the metadata before enabling verification. > > The kernel does not enforce signature verification unless fsverity > is explicitly enabled on a file. I guess the rpm plugin can be configured > to enable fsverity only if it finds a signature in the RPM header. That > would allow a mixed configuration where some files are protected, > other not. > > This does not seem ideal for mandatory protection, where you want > to be sure that integrity is checked, even if only on a subset of files > (e.g. executables and shared libraries), regardless of whether fsverity > was enabled or not on a file. > > It could be task of the security subsystem to do this type of enforcement. > At the moment, IMA and IPE (Integrity Protection Enforcement) are > planning to support fsverity and do the enforcement based on a policy. > So that means there *will* be a policy control mechanism for this enforced by the kernel, cool! -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
RE: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
> From: Neal Gompa [mailto:ngomp...@gmail.com] > Sent: Friday, December 17, 2021 11:17 AM > On Fri, Dec 17, 2021 at 5:14 AM Roberto Sassu via devel > wrote: > > > > > In Fedora, we use a new package signing key for each Fedora release. > > > What key would be used for the fs-verity signatures: the same key, > > > a separate key? Edit: I see that the Change page says a dedicated key is > > > used. > > > > Hi all > > > > I'm doing related work in this area. I'll provide some additional > > thoughts. > > > > Probably, it could be possible to use the package signing key > > for the fsverity signatures. However, this would require the > > kernel to be able to load the PGP keys in the builtin keyring > > and support PGP signatures. > > > > David Howells did that some time ago, and I adapted his > > patches for the latest kernel. Without going into too much > > detail, I've modified the kernel build to take the Fedora > > keys. They are available to verify PGP signatures (I use > > this feature to verify RPM headers). > > > > If there is interest, I could propose the patch set to the kernel > > mailing list. > > > > That would be phenomenal. That would allow us to tie things to our > existing process of key rotation for each Fedora release and leverage > the existing infrastructure for package signing for fsverity > signatures too. Great. I will propose the patch set again. For another Fedora feature I'm proposing (related to this one): https://fedoraproject.org/wiki/Changes/DIGLIM I went as far as to be able to appraise with IMA existing RPM headers (I added support for PGP appended signatures). I'm using this information in a different way: loading the file digests from the RPM header to the kernel and querying them with IMA during appraisal. That would work with fsverity digests too. If the concern is the increased package size, adding fsverity digests to the RPM header instead of signatures might be more acceptable. I made a small demo: https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987...@huawei.com/ where loading of kernel modules is granted by IPE if their fsverity digest is found in the DIGLIM hash table. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > > > IIUC, I need to do some steps at each boot: > > > 1. add all the keys to the keyring > > > 2. set sysctl fs.verity.require_signatures=1 > > > > > > So… in 1., do I always load all the keys that Fedora has used for this > > > purpose, in case there are still some files on disk? Or is there some > > > mechanism to say that e.g. keys older than F(N-2) are now not necessary? > > > > > > Who does 2.? > > > > > > I think it'd be hard to enable this during a system upgrade: one would > > > need > > > to reinstall all rpms (with new rpms carrying the fsverity metadata) > > > or some files become unreadable once 2. is done. This brings a question: > > > is there some rpm virtual Provides/Requires to specify that the fs-verity > > > stuff is present? I assume the user would want to triple-check that they > > > don't have any rpms without the metadata before enabling verification. > > > > The kernel does not enforce signature verification unless fsverity > > is explicitly enabled on a file. I guess the rpm plugin can be configured > > to enable fsverity only if it finds a signature in the RPM header. That > > would allow a mixed configuration where some files are protected, > > other not. > > > > This does not seem ideal for mandatory protection, where you want > > to be sure that integrity is checked, even if only on a subset of files > > (e.g. executables and shared libraries), regardless of whether fsverity > > was enabled or not on a file. > > > > It could be task of the security subsystem to do this type of enforcement. > > At the moment, IMA and IPE (Integrity Protection Enforcement) are > > planning to support fsverity and do the enforcement based on a policy. > > > > So that means there *will* be a policy control mechanism for this > enforced by the kernel, cool! > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Keylime subpackaging and agent alternatives (Self-Contained Change proposal)
On Fri, Dec 17, 2021 at 5:45 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Keylime_subpackaging_and_agent_alternatives > > == Summary == > The [https://src.fedoraproject.org/rpms/keylime keylime] package will > be split into subpackages per role (agent, registrar, verifier, and > admin components), while allowing the alternative agent implementation > in Rust. > > == Owner == > * Name: [[User:Scorreia| Sergio Correia]] > * Email: scorr...@redhat.com > > * Name: [[User:Ueno| Daiki Ueno]] > * Email: du...@redhat.com > > > == Detailed Description == > The current [https://keylime.dev/ Keylime] package available in Fedora > provides all the components as a single package. To support the usage > scenarios where only agent or management component is deployed on a > specific host, we plan to split the package into subpackages per role. > This change also enables the alternative Keylime agent implementation > in Rust, which will eventually be preferred over the Python > implementation. > > > == Benefit to Fedora == > This makes it easier to deploy Keylime agent in IoT or Fedora CoreOS > spins and thus enable remote attestation without installing full > dependencies of Keylime. > > == Scope == > * Proposal owners: > ** The keylime package will provide subpackages (keylime-agent, > keylime-registrar, etc) > ** The keylime package will be a meta package that will install all > the subpackages > ** The Rust based [https://github.com/keylime/rust-keylime agent] will > be packaged along with its build dependencies > ** Both keylime-agent implementations, one written in Python, the > other written in Rust, will be selectively installable through > [https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ > alternatives] or a similar mechanism > Alternatives only make sense if parallel installability is desirable. It doesn't sound like that is the case for this situation. Instead, you probably want to leverage RPM's installable alternatives framework, which we use for PipeWire/PulseAudio and pipewire-media-session/wireplumber. For PipeWire/PulseAudio, the pipewire-pulseaudio and pulseaudio packages had the following stanzas added: Provides: pulseaudio-daemon Conflicts: pulseaudio-daemon For pipewire-media-session/wireplumber, those packages had the following stanzas added: Provides: pipewire-session-manager Conflicts: pipewire-session-manager The Provides+Conflicts on a single virtual name makes it so RPM knows that those packages are equivalent providers, but only one of them can be present on a system at a time. Attempting to install the other would trigger a Conflicts, and you'd need to use "dnf swap" to switch implementations. For your case, each Keylime agent package would have the following stanzas: Provides: keylime-tpm-agent Conflicts: keylime-tpm-agent Those two stanzas tell RPM that keylime-agent-python and keylime-agent-rust are equivalent, but conflicting providers of "keylime-tpm-agent" and will only allow one or the other. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
xorg-x11-server maintenance
Hi all, With the recent updates to use a standalone xwayland package, the "classic" xorg-x11-server package seems to have fallen into disrepair. It is multiple versions behind upstream (Fedora has 1.20.11, upstream has released 1.20.12, 1.20.13, 1.20.14, 21.1.0, 21.1.1, 21.1.2), and has open CVE issues attached to it. A BugZilla query for the xorg-x11-server package reveals a worrying state of things, with bugs not being touched in ages, and the xgl-maint account that is the "main admin" and bugzilla assignee for multiple xorg-related packages has a *deactivated BugZilla* account, so NEEDINFO requests etc. don't work (no idea what else doesn't work, I suppose maintainers won't get bug emails either, if their bugzilla account doesn't work ...). Does it count as "non-responsive maintainer", if the maintainer doesn't have an active BugZilla account? :) I know that Wayland is the default on many Fedora Editions / Spins, but some of us plebs still rely on X11 / X.org sessions and it would be great to have the X server package updated. For a security-sensitive component like the X server, this is a worrying state of things. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: xorg-x11-server maintenance
*** It is multiple versions behind upstream (Fedora has 1.20.11, upstream has released 1.20.12, 1.20.13, 1.20.14, 21.1.0, 21.1.1, 21.1.2), and has open CVE issues attached to it. *** On Fri, 2021-12-17 at 12:21 +0100, Fabio Valentini wrote: > Hi all, > > With the recent updates to use a standalone xwayland package, the > "classic" xorg-x11-server package seems to have fallen into disrepair. > It is multiple versions behind upstream (Fedora has 1.20.11, upstream > has released 1.20.12, 1.20.13, 1.20.14, 21.1.0, 21.1.1, 21.1.2), and > has open CVE issues attached to it. > > A BugZilla query for the xorg-x11-server package reveals a worrying > state of things, with bugs not being touched in ages, and the > xgl-maint account that is the "main admin" and bugzilla assignee for > multiple xorg-related packages has a *deactivated BugZilla* account, > so NEEDINFO requests etc. don't work (no idea what else doesn't work, > I suppose maintainers won't get bug emails either, if their bugzilla > account doesn't work ...). Does it count as "non-responsive > maintainer", if the maintainer doesn't have an active BugZilla > account? :) > > I know that Wayland is the default on many Fedora Editions / Spins, > but some of us plebs still rely on X11 / X.org sessions and it would > be great to have the X server package updated. For a > security-sensitive component like the X server, this is a worrying > state of things. > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: xorg-x11-server maintenance
Hi Fabio, On 12/17/21 12:21, Fabio Valentini wrote: > Hi all, > > With the recent updates to use a standalone xwayland package, the > "classic" xorg-x11-server package seems to have fallen into disrepair. > It is multiple versions behind upstream (Fedora has 1.20.11, upstream > has released 1.20.12, 1.20.13, 1.20.14, 21.1.0, 21.1.1, 21.1.2), and > has open CVE issues attached to it. > > A BugZilla query for the xorg-x11-server package reveals a worrying > state of things, with bugs not being touched in ages, and the > xgl-maint account that is the "main admin" and bugzilla assignee for > multiple xorg-related packages has a *deactivated BugZilla* account, > so NEEDINFO requests etc. don't work (no idea what else doesn't work, > I suppose maintainers won't get bug emails either, if their bugzilla > account doesn't work ...). Does it count as "non-responsive > maintainer", if the maintainer doesn't have an active BugZilla > account? :) > > I know that Wayland is the default on many Fedora Editions / Spins, > but some of us plebs still rely on X11 / X.org sessions and it would > be great to have the X server package updated. For a > security-sensitive component like the X server, this is a worrying > state of things. Thank you for pointing this out. I have it on good authority that an updated pkg for the CVE is being worked on. Note this does not takeaway that the classic Xorg server packages could definitely use some love / use some community co-maintainers. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Golang 1.18 (System-Wide Change proposal)
On Fri, Dec 17, 2021 at 12:54 AM Ben Cotton wrote: > > Note that this replaces the approved Golang 1.17 Change > > https://fedoraproject.org/wiki/Changes/golang1.18 > > > == Summary == > Rebase of Golang package to upcoming version 1.18 in Fedora 36, > including the rebuild of all dependent packages(the pre-release > version of Go will be used for the rebuild if released version will > not be available at the time of the mass rebuild). Will there be a separate go 1.18 mass rebuild in rawhide? Or will the f36 mass rebuild just happen with go 1.18 (beta/rc) present? > == Contingency Plan == > * Contingency mechanism:Reverting to golang version 1.16.X if > significant issues are discovered. > * Contingency deadline: Beta Freeze(?) > * Blocks release? No > * Blocks product? No If there's a separate mass rebuild (or any test builds with go 1.18) planned prior to the mass rebuild, that's a bit of a tight timeline, with the winter holidays coming up and the F36 mass rebuild planned to start on Jan. 19, 2021. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Review swap
Hi, I have a few rubygem packages that need a (re-)review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2010263 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2010313 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2010350 Thanks, Jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
> On 12/15/21 4:11 AM, Michael J Gruber wrote: > > Sorry to pile on but I somehow lost the original e-mail. > > "/usr/share/tessconfigs" seems to be missing so output to PDF or txt > fails with "read_params_file: Can't open txt" or "read_params_file: > Can't open pdf". Standard out works. Issue is similar to one mentioned > upstream[0]. > > [0] - https://github.com/tesseract-ocr/tesseract/issues/3411 How exactly do you reproduce this problem? mupdf (mutool) works with the tesseract5 build (tested on F35, though), as does PyMuPDF. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
On 17.12.21 16:13, Michael J Gruber wrote: On 12/15/21 4:11 AM, Michael J Gruber wrote: Sorry to pile on but I somehow lost the original e-mail. "/usr/share/tessconfigs" seems to be missing so output to PDF or txt fails with "read_params_file: Can't open txt" or "read_params_file: Can't open pdf". Standard out works. Issue is similar to one mentioned upstream[0]. [0] - https://github.com/tesseract-ocr/tesseract/issues/3411 How exactly do you reproduce this problem? mupdf (mutool) works with the tesseract5 build (tested on F35, though), as does PyMuPDF. It's reproducible via command line, say tesseract out image.tif PDF The CMake build scripts are pretty broken, they omit installing lots of stuff. I've reverted to autotools, but unfortunately there is some brokenness with ARM NEON detection which I'm trying to fix up Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: I quit packaging
Volker, thank you very much for maintaining such a huge list of scientific packages. I am certain lot of people are deeply grateful for your efforts. I personally know students who use Fedora and software you've maintained in their studies and post-doc research. вс, 12 дек. 2021 г. в 23:08, Volker Fröhlich : > > I don't want to be a package maintainer anymore. > > All of my packages are up for grabs. > > Volker (FAS volter) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- With best regards, Peter Lemenkov. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Non-responsive maintainer check for bpepple
Hi, This is a non-responsive maintainer check for bpepple. gstreamer1-plugins-bad-free has FTBFS in Rawhide for ~1 month. I submitted a PR with a fix on Nov 22, but there has been zero response: https://src.fedoraproject.org/rpms/gstreamer1-plugins-bad-free/pull-request/7 https://bugzilla.redhat.com/show_bug.cgi?id=2033707 https://bugzilla.redhat.com/show_bug.cgi?id=2025782 Does anyone know how to contact them? Direct email and bug reports have had no response. Thanks, Scott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
On 17.12.21 16:55, Sandro Mani wrote: On 17.12.21 16:13, Michael J Gruber wrote: On 12/15/21 4:11 AM, Michael J Gruber wrote: Sorry to pile on but I somehow lost the original e-mail. "/usr/share/tessconfigs" seems to be missing so output to PDF or txt fails with "read_params_file: Can't open txt" or "read_params_file: Can't open pdf". Standard out works. Issue is similar to one mentioned upstream[0]. [0] - https://github.com/tesseract-ocr/tesseract/issues/3411 How exactly do you reproduce this problem? mupdf (mutool) works with the tesseract5 build (tested on F35, though), as does PyMuPDF. It's reproducible via command line, say tesseract out image.tif PDF The CMake build scripts are pretty broken, they omit installing lots of stuff. I've reverted to autotools, but unfortunately there is some brokenness with ARM NEON detection which I'm trying to fix up Should be good now Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Review request to fix FailsToInstall: mingw-qt6-qtshadertools
On Thu, Dec 16, 2021 at 09:55:51PM +0100, Sandro Mani wrote: > > On 16.12.21 00:31, Michel Alexandre Salim wrote: > > On Wed, Dec 15, 2021 at 10:58:24PM +0100, Sandro Mani wrote: > > > Hi > > > > > > I'd need mingw-qt6-qtshadertools reviewed: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2009221 > > > > > > mingw-qt6-qtdeclarative, which is currently FailsToInstall, grew a > > > dependency on it. > > > > > Happy to take this! > > > > > Happy to review in exchange! > > > > > I'll just hit you up with package ACL requests :) > > Can I hit you with another review request? :) > > mingw-qt6-qtpositioning - > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033452 > Sure! -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Non-responsive maintainer check for bpepple
On Fri, 17 Dec 2021 11:50:42 -0500 (EST), Scott Talbert wrote: > Does anyone know how to contact them? Direct email and bug reports have > had no response. His twitter profile points at a few contact options as a last resort. https://twitter.com/bpepple ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Non-responsive maintainer check for bpepple
On Fri, Dec 17, 2021 at 11:50:42AM -0500, Scott Talbert wrote: > Hi, > > This is a non-responsive maintainer check for bpepple. > > gstreamer1-plugins-bad-free has FTBFS in Rawhide for ~1 month. I submitted > a PR with a fix on Nov 22, but there has been zero response: > > https://src.fedoraproject.org/rpms/gstreamer1-plugins-bad-free/pull-request/7 > https://bugzilla.redhat.com/show_bug.cgi?id=2033707 > https://bugzilla.redhat.com/show_bug.cgi?id=2025782 > > Does anyone know how to contact them? Direct email and bug reports have had > no response. > I hope we can reach him, bpepple has been around since the early days so I wonder if something is up ``` fedora-active-user on master via 🐍 v3.10.0 ❯ python3 ./fedora_active_user.py --user bpepple Last login in FAS: bpepple 2021-02-28 Last action on koji: Sat, 04 Dec 2021 tag_package_owners entry created by bodhi [still active] Last package update on bodhi: 2016-02-02 17:16:28 on package nautilus-image-converter-0.3.1-0.10.git430afce31.fc23 Last actions performed according to fedmsg: - s...@techie.net commented on RHBZ#2033707 'Non-responsive maintainer check for bpep...' on 2021-12-17 08:44:48 - s...@techie.net filed a new bug RHBZ#2033707 'Non-responsive maintainer check for bpep...' on 2021-12-17 08:44:48 - thedatum...@outlook.com updated 'cc' on RHBZ#2031441 'Broken sound after moving playhead in gs...' on 2021-12-12 22:40:57 - takuv...@gmail.com commented on RHBZ#2031441 'Broken sound after moving playhead in gs...' on 2021-12-11 18:14:54 - takuv...@gmail.com filed a new bug RHBZ#2031441 'Broken sound after moving playhead in gs...' on 2021-12-11 18:14:54 - deh...@gmail.com filed a new bug RHBZ#2029446 'rpicamsrc plugin is disabled' on 2021-12-06 06:28:20 - deh...@gmail.com commented on RHBZ#2029446 'rpicamsrc plugin is disabled' on 2021-12-06 06:28:19 - bcot...@redhat.com commented on RHBZ#1654216 'Empathy shows invalid certificates (inva...' on 2021-11-30 11:03:02 - bcot...@redhat.com updated 'bug_status' and 'resolution' on RHBZ#1654216 'Empathy shows invalid certificates (inva...' on 2021-11-30 11:03:02 - bcot...@redhat.com commented on RHBZ#1948948 'CVE-2021-3497 gstreamer1-plugins-good: g...' on 2021-11-30 10:32:53 ``` Best, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Non-responsive maintainer check for bpepple
On Fri, 17 Dec 2021, Michael Schwendt wrote: Does anyone know how to contact them? Direct email and bug reports have had no response. His twitter profile points at a few contact options as a last resort. https://twitter.com/bpepple Sorry, I don't use Twitter. If someone wants to reach out via Twitter that would be appreciated. Scott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Heads-up: trousers (TPM 1.2) silently orphaned
On Thu, Dec 16, 2021 at 10:11:53AM -0800, Michel Alexandre Salim wrote: > 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-comm...@lists.fedoraproject.org/message/JAAC32MNLJMMENVJG7QUSKHGZFABLUHX/ > > - 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) > I've taken this package for now. It's probably OK for most of the trousers dependent to drop their dependencies on it though, the use case I have in mind is rather specialized. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
On Thu, Dec 16, 2021 at 10:37:16AM -0800, Tom Stellard wrote: > On 12/16/21 09:07, Jeremy Newton wrote: > > 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 :) > > Would you be interested in maintaining the existing packages? I could use > some help keeping them up-to-date with the latest versions. > I'm also interested in helping package more of ROCm, but ideally everyone interested in this should co-maintain. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
I’m happy, in principle, to help co-maintain ROCm packages. However, before becoming a co-maintainer, I always like to take a look over packages and make sure I’m comfortable with them, i.e.: - I can reconcile them with packaging guidelines - I think I can fix most things that are likely to break - I have any special hardware required to fully test and debug them Do you have a list of the existing ROCm-related packages that you have in mind? – Ben On 12/17/21 13:41, Michel Alexandre Salim wrote: On Thu, Dec 16, 2021 at 10:37:16AM -0800, Tom Stellard wrote: On 12/16/21 09:07, Jeremy Newton wrote: 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 :) Would you be interested in maintaining the existing packages? I could use some help keeping them up-to-date with the latest versions. I'm also interested in helping package more of ROCm, but ideally everyone interested in this should co-maintain. Best regards, ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Recent python-pytest-cov update in F34/F35 causes many FTBFS
On Thu, 2021-12-16 at 22:08 -0500, Ben Beasley wrote: > It turns out that while a couple of packages I care about were actually > broken by the bump to 3.0, most of them were instead broken by the > update failing to install on F34[1]. This should be resolved when https://bodhi.fedoraproject.org/updates/FEDORA-2021-1e86cbf275 goes stable. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Recent python-pytest-cov update in F34/F35 causes many FTBFS
On Thu, 2021-12-16 at 21:53 +0100, Miro Hrončok wrote: > On 16. 12. 21 20:09, Ben Beasley wrote: > > It looks like python-pytest-cov was recently updated to 3.0.0 in F35[1] and > > F34[2]. I noticed this because, between my own packages and those > > maintained > > through @neuro-sig, I saw a wave of FTBFS notifications from Koschei. > > > > Unfortunately, because packages commonly pin a particular major version, > > and > > because pytest-cov has been in 2.x for a long time, a huge number of > > packages > > are likely to be affected. > > A good opportunity to patch/sed coverage out of those packages for good :) FWIW, I use a pattern in several projects I maintain where tests are always run via coverage, although actually generating and analyzing reports is only done in a tox environment that is run in CI workflows (and not in the package build). See: https://pagure.io/fedora-qa/fedfind/blob/main/f/tox.ini for e.g. If you have a better way to do this, let me know... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Mock v2.16 release, mock-core-configs v36.4
On Thu, Dec 16, 2021 at 1:55 PM Pavel Raiskup wrote: > > Hello! > > I'm glad I can announce that we have a new release of Mock. See the full > release notes [1]. The major change that happened is the removal of > 'epel-8' config files, as a follow-up for [2] discussion (and of course on > *devel lists, big thanks to everyone for the discussion). Why would v3 not be available for EPEL ? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Recent python-pytest-cov update in F34/F35 causes many FTBFS
On Thu, Dec 16, 2021 at 3:54 PM Ben Beasley wrote: > > It looks like python-pytest-cov was recently updated to 3.0.0 in F35[1] > and F34[2]. I noticed this because, between my own packages and those > maintained through @neuro-sig, I saw a wave of FTBFS notifications from > Koschei. It's been screwing up "mock" builds for Fedora 34 and Fedora 35, as well. It's one of the risks of many python modules, with a requirement.txt like "ansible-core<2.13,>=2.12.0", but do not necessarily list a maximum value range or a completely valid minimum value for their dependencies. Hilarity ensues. > Unfortunately, because packages commonly pin a particular major version, > and because pytest-cov has been in 2.x for a long time, a huge number of > packages are likely to be affected. > > It would be nice if Koschei could build against updates-testing so that > problems like this could be more easily detected before the updates have > already reached stable. > > – Ben > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-3b53235332 > [2] https://bodhi.fedoraproject.org/updates/FEDORA-2021-379e60a35b > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Update to tesseract-5.0.0 in rawhide
On 12/17/21 11:22 AM, Sandro Mani wrote: On 17.12.21 16:55, Sandro Mani wrote: On 17.12.21 16:13, Michael J Gruber wrote: On 12/15/21 4:11 AM, Michael J Gruber wrote: Sorry to pile on but I somehow lost the original e-mail. "/usr/share/tessconfigs" seems to be missing so output to PDF or txt fails with "read_params_file: Can't open txt" or "read_params_file: Can't open pdf". Standard out works. Issue is similar to one mentioned upstream[0]. [0] - https://github.com/tesseract-ocr/tesseract/issues/3411 How exactly do you reproduce this problem? mupdf (mutool) works with the tesseract5 build (tested on F35, though), as does PyMuPDF. It's reproducible via command line, say tesseract out image.tif PDF The CMake build scripts are pretty broken, they omit installing lots of stuff. I've reverted to autotools, but unfortunately there is some brokenness with ARM NEON detection which I'm trying to fix up Should be good now Sandro Works great, thank you so much! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: xorg-x11-server maintenance
On Fri, Dec 17 2021 at 03:10:11 PM +0100, Hans de Goede wrote: Note this does not takeaway that the classic Xorg server packages could definitely use some love / use some community co-maintainers. If xgl-maint isn't going to maintain the packages anymore, orphaning them is the right thing to do. Then somebody else can pick them up... or not. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Review swap
On 17.12.21 15:31, Jarek Prokop wrote: Hi, I have a few rubygem packages that need a (re-)review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2010263 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2010313 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2010350 I'll take these. Could you please review some of these in exchange? python-flask-paranoid - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033803 python-flask-principal - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033802 python-flask-security-too - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033801 python-flask-sphinx-themes - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033799 python-flask-wtf - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033798 python-httpagentparser - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033797 python-ua-parser - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033796 python-user-agents - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2033795 Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)
Hello! I'm a user of NVIDIA graphic card. On top of what others said, I add that there is also the nvidia-settings GUI that does not work on Wayland. I don't use it personally, but other people can use, for example, application/game profiles. It is also something to consider... Michaël Berteaux ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
