Re: Can we start changing License to SPDX now?

On Wed, Jun 29, 2022 at 08:54:37AM +0200, Petr Pisar wrote: > > #2799 F38 Change proposal: SPDX License Phase 1 > > APPROVED (+5,0,-0) > > Do I understand it correctly that we can change License tags in our spec files > to SPDX syntax right now? > > Or should we wait until updating >

Fedora-Cloud-36-20220629.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-36-20220628.0): ID: 1309280 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Re: Can we start changing License to SPDX now?

On Wed, 29 Jun 2022, 09:48 Zbigniew Jędrzejewski-Szmek, wrote: > On Wed, Jun 29, 2022 at 08:54:37AM +0200, Petr Pisar wrote: > > > #2799 F38 Change proposal: SPDX License Phase 1 > > > APPROVED (+5,0,-0) > > > > Do I understand it correctly that we can change License tags in our spec > files > >

Re: Fix aarch64 build on embree

On Wed, Jun 29, 2022 at 3:15 AM Luya Tshimbalanga wrote: > > Hello team, > > What is the way to disable `-mss2 for aarch64 build in embree? I think you mean msse2, the build should be using the distro default C flags for builds so it shouldn't be an issue, if you fix the build to use the proper d

Package proposal: google-drive-ocamlfuse

I recently discovered this project: https://github.com/astrada/google-drive-ocamlfuse Supposedly it makes it possible to mount google drive as a filesystem using fuse. I wanted to try to package it myself, but ocaml seems a bit esoteric and we are currently missing at least 5 dependencies in

mujs license change from AGPLv3+ to ISC

As a new maintainer for this package [1], considering the upstream files [2], I changed the License: field to ISC. Regards. [1] https://src.fedoraproject.org/rpms/mujs [2] https://mujs.com/ -- Alain V. ___ devel mailing list -- devel@lists.fedoraproject

Re: Package proposal: google-drive-ocamlfuse

Quoting Marián Konček (2022-06-29 10:26:13) > I recently discovered this project: > https://github.com/astrada/google-drive-ocamlfuse > > Supposedly it makes it possible to mount google drive as a filesystem > using fuse. Not to devalue the request, but this requirement alone should be covered by

Re: Fix aarch64 build on embree

> > Hello team, > > > > What is the way to disable `-mss2 for aarch64 build in embree? > > I think you mean msse2, the build should be using the distro default C > flags for builds so it shouldn't be an issue, if you fix the build to > use the proper distro flags the problem should go away. Details

Re: Fix aarch64 build on embree

V Tue, Jun 28, 2022 at 07:08:31PM -0700, Luya Tshimbalanga napsal(a): > Hello team, > > What is the way to disable `-mss2 for aarch64 build in embree? > > Spec file: > https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree.spec > > Scratch build result: > https://koji.fedoraproject.org/

Re: Grafana license change from ASL 2.0 to AGPLv3

On 28.06.22 18:11, Tomasz Torcz wrote: On Tue, Jun 28, 2022 at 05:16:14PM +0200, Andreas Gerstmayr wrote: I plan to submit a Grafana 8.5.6 rebase to Fedora rawhide in the coming days. Why not to v9? Mainly because I had the v8 rebase 98% ready since a few months, but due to vacation and

Fedora-Cloud-35-20220629.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-35-20220628.0): ID: 1309357 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Re: Fix aarch64 build on embree

On Wed, Jun 29, 2022 at 10:06 AM Petr Pisar wrote: > > V Tue, Jun 28, 2022 at 07:08:31PM -0700, Luya Tshimbalanga napsal(a): > > Hello team, > > > > What is the way to disable `-mss2 for aarch64 build in embree? > > > > Spec file: > > https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree

Re: Package proposal: google-drive-ocamlfuse

On Wed, 2022-06-29 at 10:26 +0200, Marián Konček wrote: > I recently discovered this project: > https://github.com/astrada/google-drive-ocamlfuse > > Supposedly it makes it possible to mount google drive as a filesystem > using fuse. > > I wanted to try to package it myself, but ocaml seems a bi

Self Introduction: Patrick Cullen

Hey all, I work at Meta on the team dealing with all things time distribution related (NTP and PTP) and including the OCP Time Appliance Project. I'll be actively supporting and updating open-source software including github.com/facebookincubator/ntp, github.com/facebookincubator/ptp, github.co

Re: Can we start changing License to SPDX now?

V Wed, Jun 29, 2022 at 10:17:48AM +0200, Bob Mauchin napsal(a): > Weren't there a proposal for a macro allowing to use both Spottags and SPDX > so we could merge --ff-only to the old branches? Not being able to do that > is a PITA. > SPDX is allowed in all Fedora branches

Fedora rawhide compose report: 20220629.n.0 changes

OLD: Fedora-Rawhide-20220628.n.0 NEW: Fedora-Rawhide-20220629.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:2 Upgraded packages: 240 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:494.29

Re: release-monitoring.org 1.4.0 is now live

On 22. 06. 22 17:36, Michal Konecny wrote: * Add Python (PEP 440) versioning scheme Hey Michal, I'm glad this has landed. Is there a way to automatically update all the PyPI sourced packages to use this? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok __

Fedora CI runs tests on the wrong branch?

Hello everyone, I've been taking a look at adding tests to the Puppet package. Initially this worked well when I added it to Rawhide[1] and it did what I expected. Now I'm trying to add the same tests to the epel9 branch[2]. It should be noted that epel9 is exactly the same as rawhide now (s

Orphaning my packages

Hello, I've been maintaining some packages, but I can't at this time continue taking care of them. So, next Sunday I'll orphan them if nobody ask me the transfer: * ascii * netmask * ez-pine-gpg * python-meld3 * gpart * python-sysv_ipc * reptyr * supervisor -- Francisco J. Tsao Santín http://gat

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

Dear colleagues, If I correctly follow the discussion, the biggest show-stopper is Python 2.*, which has some incomplete patches to deal with OpenSSL 3.0. If we assist you in moving these patches forward, can we get rid of the devel package and leave the compat package only for 3rd-party packages?

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On 29. 06. 22 17:11, Dmitry Belyavskiy wrote: Dear colleagues, If I correctly follow the discussion, the biggest show-stopper is Python 2.*, which has some incomplete patches to deal with OpenSSL 3.0. We would also need it in for Python 3.6 and pypys. If we assist you in moving these patches

Re: Fedora CI runs tests on the wrong branch?

On Wed, 2022-06-29 at 14:49 +0200, Ewoud Kohl van Wijngaarden wrote: > Hello everyone, > > I've been taking a look at adding tests to the Puppet package. Initially > this worked well when I added it to Rawhide[1] and it did what I > expected. > > Now I'm trying to add the same tests to the epel

Fedora-Rawhide-20220629.n.0 compose check report

Missing expected images: Minimal raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 11/233 (x86_64), 34/163 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220628.n.0): ID: 1309372 Test: x86_64 Server-dvd-iso install_

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

Dear Miro, On Wed, Jun 29, 2022 at 5:27 PM Miro Hrončok wrote: > On 29. 06. 22 17:11, Dmitry Belyavskiy wrote: > > Dear colleagues, > > > > If I correctly follow the discussion, the biggest show-stopper is Python > 2.*, > > which has some incomplete patches to deal with OpenSSL 3.0. > > We would

Re: Unresponsive maintainer: Alex Chernyakhovsky

Maxwell G via devel writes: > On Tuesday, June 28, 2022 4:30:14 PM CDT Robbie Harwood wrote: >> I have started the responsive maintainer process due to lack of contact >> through bugzilla mail. Specifically, this is about an epel9 branch, >> which has been repeatedly requested since March (inclu

Re: Unresponsive maintainer: Alex Chernyakhovsky

On 29/06/2022 01:18, Maxwell G via devel wrote: You might also be interested in the Stalled EPEL Requests policy[1]. This would've allowed you to get permissions to branch the package for EPEL without going through the non-responsive maintainer process. This policy looks like a package hijack a

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On Wed, Jun 29, 2022 at 5:46 PM Dmitry Belyavskiy wrote: > > On Wed, Jun 29, 2022 at 5:27 PM Miro Hrončok wrote: >> >> Please don't remove the devel package if you aim for deprecation. As other >> have >> said, removing the devel package is essentially retirement, not deprecation. > > OK, it's n

Re: Unresponsive maintainer: Alex Chernyakhovsky

Vitaly Zaitsev via devel writes: > On 29/06/2022 01:18, Maxwell G via devel wrote: > >> You might also be interested in the Stalled EPEL Requests >> policy[1]. This would've allowed you to get permissions to branch the >> package for EPEL without going through the non-responsive maintainer >> pro

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On 29. 06. 22 17:45, Dmitry Belyavskiy wrote: Dear Miro, On Wed, Jun 29, 2022 at 5:27 PM Miro Hrončok > wrote: On 29. 06. 22 17:11, Dmitry Belyavskiy wrote: > Dear colleagues, > > If I correctly follow the discussion, the biggest show-stopper is P

Re: Orphaning my packages

I'll take python-meld3 if no one else speaks for it. --  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with Proton Mail secure email. --- Original Message --- On Wednesday, June 29t

Re: Orphaning my packages

Actually, ignore that. --  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with Proton Mail secure email. --- Original Message --- On Wednesday, June 29th, 2022 at 11:50 AM, Gwyn Cies

F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)

This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Firefox langpacks, which have been bu

F37 Change Proposal: IBus 1.5.27 (System-Wide change)

This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == In IBus 1.5.27, `ibus restart` subco

F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The flatpak remote for Flathub will

Fedora Flatpaks: fedmod has been retired

I wanted to try building a Fedora Flatpak, so I headed over to the docs and started with the tutorial. https://docs.fedoraproject.org/en-US/flatpak/tutorial/ The first step instructed me to install some packaging tools: $ dnf install flatpak-module-tools fedmod DNF complained that it could not f

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

On 29/06/2022 19:34, Vipul Siddharth wrote: The flatpak remote for Flathub will have no filtering, making all the Flathub content available in GNOME Software and via the flatpak commandline. Strongly -1, because Flatpaks have higher priority over RPMs in Gnome Software. 1. GNOME Software nee

Re: Unresponsive maintainer: Alex Chernyakhovsky

On 29/06/2022 18:47, Robbie Harwood wrote: I don't see how you got there. Nowhere does it say that the maintainer(s) are removed - just that one is added, and made contact for EPEL bugs. Newly added EPEL maintainers can make any changes to Fedora branches. I don't like that. -- Sincerely,

Re: Orphaning my packages

On Wed, 29 Jun 2022, Gwyn Ciesla wrote: > Actually, ignore that. > Yes, I forgot to clarify that python-meld3 is being retired because it has been fully integrated in supervisor. But it is still an independent package in EPEL 7 and 8. -- Francisco J. Tsao Santín http://gattaca.es 1024D/71CF4D6

Re: Orphaning my packages

Hey, On 6/29/22 16:56, Francisco J. Tsao Santín via devel wrote: Hello, I've been maintaining some packages, but I can't at this time continue taking care of them. So, next Sunday I'll orphan them if nobody ask me the transfer: * ascii * netmask * ez-pine-gpg * python-meld3 * gpart * python-sys

F37 Change Proposal: libsoup 3: Part One (System-Wide Change)

This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == libsoup 3 is a new API version of libs

Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

On Wednesday, June 29, 2022 1:09:07 PM CDT Vitaly Zaitsev via devel wrote: > On 29/06/2022 18:47, Robbie Harwood wrote: > > I don't see how you got there. Nowhere does it say that the > > maintainer(s) are removed - just that one is added, and made contact for > > EPEL bugs. > > Newly added EPEL

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

On Wed, Jun 29 2022 at 08:06:28 PM +0200, Vitaly Zaitsev via devel wrote: 1. GNOME Software need to be patched to prefer RPMs over Flatpaks for non-ostree Fedora variants, because it will replace Fedora packages with Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for Fedora

Re: F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)

On 29/06/2022 19:00, Vipul Siddharth wrote: Firefox langpacks, which have been bundled in the Fedora firefox base package until now, will be moved to a firefox-langpacks subpackage. +1. It might be better to split it even more: firefox-langpack-%{lang} and depend on the system-wide language (j

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On Wednesday, June 29, 2022 11:49:07 AM CDT Miro Hrončok wrote: > Now you are mixing the two kinda together in a weird way. The change is > called "deprecation" but is in fact "incomplete retirement". I agree. There seems to be a recent trend of Changes confusing the difference between deprecation

Re: Unresponsive maintainer: Alex Chernyakhovsky

On Wed, 29 Jun 2022 at 14:10, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 29/06/2022 18:47, Robbie Harwood wrote: > > I don't see how you got there. Nowhere does it say that the > > maintainer(s) are removed - just that one is added, and made contact for > > EPEL bugs. >

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

On 29/06/2022 20:25, Michael Catanzaro wrote: GNOME Software already has a hidden setting for this: Yes and it should be configured to "['RPM', 'flatpak']" for all non-ostree Fedora variants (Workstation, Spins). When the Flathub filtering is removed, most Fedora packages will be silently r

Re: Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

On 29/06/2022 20:24, Maxwell G wrote: I'm a bit confused. You say this sounds like a "package hijack attempt," but then you also say you don't like that it only allows access to epel* branches. It is not possible to restrict access to only selected branches. EPEL maintainers can commit to Fedo

Re: Orphaning my packages

On Wed, 29 Jun 2022, František Šumšal wrote: > I'll gladly take over reptyr. > Ok, it's yours now :-) Thanks! -- Francisco J. Tsao Santín http://gattaca.es 1024D/71CF4D62 42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB ___ devel mailing list -- devel

Re: Unresponsive maintainer: Alex Chernyakhovsky

On 29/06/2022 20:32, Stephen Smoogen wrote: Yes, they can. So can a lot of other people and things in Fedora. Only proven-packagers in limited situations or people who have been granted access by the package owner. This isn't other distros where a package maintainer is a defacto dictator of

Re: Unresponsive maintainer: Alex Chernyakhovsky

On 29. 06. 22 20:50, Vitaly Zaitsev via devel wrote: On 29/06/2022 20:32, Stephen Smoogen wrote: Yes, they can. So can a lot of other people and things in Fedora. Only proven-packagers in limited situations or people who have been granted access by the package owner. This isn't other distro

Re: Unresponsive maintainer: Alex Chernyakhovsky

On Wed, 29 Jun 2022 at 14:52, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 29/06/2022 20:32, Stephen Smoogen wrote: > > Yes, they can. So can a lot of other people and things in Fedora. > > Only proven-packagers in limited situations or people who have been > granted acces

Re: Unresponsive maintainer: Alex Chernyakhovsky

Hi Robbie, On Wed, 2022-06-29 at 12:02 -0400, Robbie Harwood wrote: > In this case, because no one needinfo'd the maintainer, the EPEL > policy > can be slower (two weeks compared to the minimum ten days for > nonresponsive).  Also, a literal reading of the EPEL policy says that > the same person

Re: F37 Change Proposal: libsoup 3: Part One (System-Wide Change)

On Wed, Jun 29, 2022 at 11:49:51PM +0530, Vipul Siddharth wrote: > Fedora 37 as a compatibility library. Because libsoup is a sensitive > network-facing HTTP library written in an unsafe language and where > CVEs may have disastrous impact, it is not safe to leave libsoup 2 > hanging around indefin

Re: F37 Change Proposal: libsoup 3: Part One (System-Wide Change)

On Wed, Jun 29 2022 at 03:14:06 PM -0400, Chuck Anderson wrote: Why are we using a "network-facing HTTP library written in an unsafe language"? Shouldn't we take this opportunity to move to a safer HTTP library? Or is libsoup 3 safe(r) than libsoup 2? Not aware of any plausible alternatives

Re: Unresponsive maintainer: Alex Chernyakhovsky

On 29/06/2022 20:58, Miro Hrončok wrote: No, it isn't. It's great ;) Why? I doubt fighting maintainers is a good thing for Fedora. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsub

Re: Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

On 6/29/22 8:45 PM, Vitaly Zaitsev via devel wrote: On 29/06/2022 20:24, Maxwell G wrote: > I'm a bit confused. You say this sounds like a "package hijack attempt," but > then you also say you don't like that it only allows access to epel* branches. It is not possible to restrict access to onl

Re: F37 Change Proposal: libsoup 3: Part One (System-Wide Change)

On 6/29/22 15:14, Chuck Anderson wrote: > On Wed, Jun 29, 2022 at 11:49:51PM +0530, Vipul Siddharth wrote: >> Fedora 37 as a compatibility library. Because libsoup is a sensitive >> network-facing HTTP library written in an unsafe language and where >> CVEs may have disastrous impact, it is not saf

Re: Unresponsive maintainer: Alex Chernyakhovsky

On 29/06/2022 21:06, Stephen Smoogen wrote: Maintainers are custodians and do not own the package. This becomes true with the new EPEL policy. I think it should be revisited to follow Fedora's non-responsive maintainer procedure with an explicit FESCo approval on a case-by-case basis. -- Si

Re: Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

On 29/06/2022 21:23, zebo...@gmail.com wrote: What do you mean it is not possible? Isn't the new "collaborator" role exactly for this? Yes, didn't know about it. My bad. Thanks for the info. Collaborator: A user or a group with this level of access can do everything what a user/group with ti

Re: Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

On Wednesday, June 29, 2022 1:24:07 PM CDT Maxwell G via devel wrote: > On Wednesday, June 29, 2022 1:09:07 PM CDT Vitaly Zaitsev via devel wrote: > > Newly added EPEL maintainers can make any changes to Fedora branches. I > > don't like that. > > I'm a bit confused. You say this sounds like a "pa

Re: Claim delve

(I know, it took a while) I just submitted it for review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2102388 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

Given the recent benchmarks from Phoronix (https://www.phoronix.com/scan.php?page=article&item=fedora-frame-pointer&num=1) on the proposal that showed some surprising results, we went and tried to reproduce some of the benchmarks to make sure they were actually making sense. The first one we lo

Re: Unresponsive maintainer: Alex Chernyakhovsky

On Wed, Jun 29, 2022 at 1:09 PM Vitaly Zaitsev via devel wrote: > > On 29/06/2022 18:47, Robbie Harwood wrote: > > I don't see how you got there. Nowhere does it say that the > > maintainer(s) are removed - just that one is added, and made contact for > > EPEL bugs. > > Newly added EPEL maintaine

Re: Unresponsive maintainer: Alex Chernyakhovsky

On Wed, Jun 29, 2022 at 2:09 PM Vitaly Zaitsev via devel wrote: > > On 29/06/2022 18:47, Robbie Harwood wrote: > > I don't see how you got there. Nowhere does it say that the > > maintainer(s) are removed - just that one is added, and made contact for > > EPEL bugs. > > Newly added EPEL maintaine

Re: Unresponsive maintainer: Alex Chernyakhovsky

On Wed, Jun 29, 2022 at 2:30 PM Vitaly Zaitsev via devel wrote: > > On 29/06/2022 21:06, Stephen Smoogen wrote: > > Maintainers are custodians and do not own the package. > > This becomes true with the new EPEL policy. I think it should be > revisited to follow Fedora's non-responsive maintainer p

Re: Unresponsive maintainer: Alex Chernyakhovsky

Jumping in on this... I opened BZ 2095512 a few weeks ago about getting pure-ftpd for EPEL 9, with a follow-up a week ago. There's already an EPEL 8 branch, so I guess that maintainer was notified (or do all get notified)? Looking at src.fedoraproject.org, it doesn't look like any of the maintain

Re: Unresponsive maintainer: Alex Chernyakhovsky

If you're happy with the current version 1.0.49 from rawhide being branched for epel9, then the stalled process would be a good fit. With collaborator permissions on epel* branches, you can request the epel9 branch, merge commits from rawhide to epel9, create builds, and create bodhi updates. If y

Re: Unresponsive maintainer: Alex Chernyakhovsky

On Wed, 2022-06-29 at 20:09 +0200, Vitaly Zaitsev via devel wrote: > On 29/06/2022 18:47, Robbie Harwood wrote: > > I don't see how you got there.  Nowhere does it say that the > > maintainer(s) are removed - just that one is added, and made > > contact for > > EPEL bugs. > > Newly added EPEL main

Re: Fix aarch64 build on embree

On 2022-06-29 01:56, Peter Robinson wrote: Hello team, What is the way to disable `-mss2 for aarch64 build in embree? I think you mean msse2, the build should be using the distro default C flags for builds so it shouldn't be an issue, if you fix the build to use the proper distro flags the pro

Re: Fix aarch64 build on embree

On 2022-06-29 02:05, Petr Pisar wrote: V Tue, Jun 28, 2022 at 07:08:31PM -0700, Luya Tshimbalanga napsal(a): Hello team, What is the way to disable `-mss2 for aarch64 build in embree? Spec file: https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree.spec Scratch build result: https:

Re: Fix aarch64 build on embree

On 2022-06-29 01:24, Peter Robinson wrote: On Wed, Jun 29, 2022 at 3:15 AM Luya Tshimbalanga wrote: Hello team, What is the way to disable `-mss2 for aarch64 build in embree? I think you mean msse2, the build should be using the distro default C flags for builds so it shouldn't be an issue,

Fedora-IoT-36-20220629.0 compose check report

No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-36-20220624.0): ID: 1311180 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1311180 Passed openQA tests: 15/15 (x86_64), 14/15 (aarch64)

Re: Fedora Flatpaks: fedmod has been retired

Hi Artur, On Wed, Jun 29, 2022 at 7:58 PM Artur Frenszek-Iwicki < s...@fedoraproject.org> wrote: > I wanted to try building a Fedora Flatpak, so I headed over to the docs > and started with the tutorial. > https://docs.fedoraproject.org/en-US/flatpak/tutorial/ > > The first step instructed me to

Re: Orphaning my packages

I'll take reptyr and supervisor, thank you. On 29/06/2022 17:56, Francisco J. Tsao Santín via devel wrote: Hello, I've been maintaining some packages, but I can't at this time continue taking care of them. So, next Sunday I'll orphan them if nobody ask me the transfer: * ascii * netmask * ez-pi