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

[EPEL-devel] Fedora EPEL 7 updates-testing report

The following builds have been pushed to Fedora EPEL 7 updates-testing dkms-3.0.5-1.el7 fpart-1.5.1-1.el7 Details about builds: dkms-3.0.5-1.el7 (FEDORA-EPEL-2022-f382c4b864) Dynamic Kernel Module

[Bug 2099388] perl-CPAN-Perl-Releases-5.20220620 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2099388 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2

[Bug 2099392] perl-Module-CoreList-5.20220620 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2099392 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Module-CoreList-5.2022 |perl-Module-CoreList-5.2022

[Bug 2068801] Please build perl-Text-CSV for EPEL 9

https://bugzilla.redhat.com/show_bug.cgi?id=2068801 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #8 from

[Bug 2099976] Please branch and build perl-DBIx-Simple in epel9

https://bugzilla.redhat.com/show_bug.cgi?id=2099976 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from

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: 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,

[Bug 2101943] perl-Text-Bidi-2.17 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2101943 --- Comment #5 from Fedora Update System --- FEDORA-2022-d7f7c24be4 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing

[Bug 2101943] perl-Text-Bidi-2.17 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2101943 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from

[Bug 2099388] perl-CPAN-Perl-Releases-5.20220620 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2099388 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2

[Bug 2099392] perl-Module-CoreList-5.20220620 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2099392 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In

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:

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

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

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

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

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

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

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

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=fedora-frame-pointer=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 looked at

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

[EPEL-devel] Re: Request for fence-agents-pve package

Correct, a fence-agents-epel package is probably the best choice here. Are you interested in creating and maintaining that? It's described in further detail in the EPEL docs [0], although it's lacking examples. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/ On

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

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

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

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

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

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

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: 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

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: 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

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

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

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 --

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

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

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 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

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

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

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

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

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

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 *

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

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: 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

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

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

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

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`

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`

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

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

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

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

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

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 >>

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

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

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

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

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

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

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

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

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

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

[Bug 2102191] New: Issue with build because "BuildRequires: %{_libdir}/libfbclient.so" in spec file

https://bugzilla.redhat.com/show_bug.cgi?id=2102191 Bug ID: 2102191 Summary: Issue with build because "BuildRequires: %{_libdir}/libfbclient.so" in spec file Product: Fedora Version: 36 Status: NEW Component:

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 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: 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

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,

[Bug 2099976] Please branch and build perl-DBIx-Simple in epel9

https://bugzilla.redhat.com/show_bug.cgi?id=2099976 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from

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

[Bug 2101943] perl-Text-Bidi-2.17 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2101943 --- Comment #2 from Fedora Update System --- FEDORA-2022-d7f7c24be4 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d7f7c24be4 -- You are receiving this mail because: You are on the CC list

[Bug 2101943] perl-Text-Bidi-2.17 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2101943 --- Comment #3 from Fedora Update System --- FEDORA-2022-26f339cffa has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-26f339cffa -- You are receiving this mail because: You are on the CC list

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: > >

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:

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

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: >

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.

[Bug 2068801] Please build perl-Text-CSV for EPEL 9

https://bugzilla.redhat.com/show_bug.cgi?id=2068801 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #7 from

[Bug 2060900] Please branch and build perl-Module-Install-TestBase for EPEL-8

https://bugzilla.redhat.com/show_bug.cgi?id=2060900 Jitka Plesnikova changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|---

[Bug 2101568] perl-Math-BigRat-0.2624 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2101568 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution|---

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

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 --

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

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

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 > >

[Bug 2101943] perl-Text-Bidi-2.17 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2101943 Petr Pisar changed: What|Removed |Added Fixed In Version||perl-Text-Bidi-2.17-1.fc37

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:

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 >

Can we start changing License to SPDX now?

> #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 to SPDX identifiers? --

[Bug 2101943] perl-Text-Bidi-2.17 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2101943 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED

Re: Suggestion: Use a unified kernel image by default in the future.

V Tue, Jun 28, 2022 at 08:27:16PM +0100, David Howells napsal(a): > Sharpened Blade via devel wrote: > > > It would be stored with permissions for only root to read it, and you disk > > should be encrypted, or none of this matters. > > It doesn't matter if your disk is encrypted. Whilst your