Re: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

On Tue, May 9, 2023 at 12:18 PM Jens-Ulrik Petersen wrote: > On Tue, May 9, 2023 at 4:35 AM DJ Delorie wrote: > >> According to mpb at least: >> > (Okay I found mpb ) Are the results available? > The majority of those packages are

[Bug 2193159] perl-Devel-Dumpvar: FTBFS: No package found for: perl(inc::Module::Install::DSL) >= 0.91

https://bugzilla.redhat.com/show_bug.cgi?id=2193159 Jitka Plesnikova changed: What|Removed |Added Resolution|--- |RAWHIDE Fixed In Version|

disabling yum modular repos by default?

I have been thinking about proposing a Change to Fedora 39, which would disable yum modular repos by default in installs. I thought I would float the idea here first. I suspect the vast majority of Fedora users don't use the modular repos, so I don't see the point of enabling them by default

Re: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

On Tue, May 9, 2023 at 4:35 AM DJ Delorie wrote: > According to mpb at least: > mpb? The majority of those packages are maintained by me... so I can't say I thrilled. I thought ghc 9 was supposed to be okay with static trampolines? Jens ___ devel

[Bug 2187275] perl-User-Identity-1.02 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2187275 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-User-Identity-1.02-1.f |perl-User-Identity-1.02-1.f

[Bug 2187275] perl-User-Identity-1.02 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2187275 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-User-Identity-1.02-1.f |perl-User-Identity-1.02-1.f

[Bug 2187275] perl-User-Identity-1.02 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2187275 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-User-Identity-1.02-1.f |perl-User-Identity-1.02-1.f

[Bug 2187275] perl-User-Identity-1.02 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2187275 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|---

Re: colm update breaking ragel

On Tue, Apr 25, 2023 at 08:50:42PM -0500, Michel Alexandre Salim wrote: > Update: it's .. looking more complicated than I anticipated: > > The new ragel can in theory be built against the updated colm, *but* > it expect colm to provide some *.la files (libtool archives), which... > our packaging

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On 5/8/23 19:09, Neal Gompa wrote: > On Mon, May 8, 2023 at 7:05 PM Demi Marie Obenour > wrote: >> >> On 5/8/23 18:49, Kevin Fenzi wrote: >>> On Mon, May 08, 2023 at 09:29:02PM +0100, Sebastian Crane wrote: Dear Kevin, >> Hmm, quoting from https://pagure.io/releng/issue/11092:

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On Mon, May 8, 2023 at 7:05 PM Demi Marie Obenour wrote: > > On 5/8/23 18:49, Kevin Fenzi wrote: > > On Mon, May 08, 2023 at 09:29:02PM +0100, Sebastian Crane wrote: > >> Dear Kevin, > >> > Hmm, quoting from https://pagure.io/releng/issue/11092: > >> Also the aarch64 cluster is running

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On 5/8/23 18:49, Kevin Fenzi wrote: > On Mon, May 08, 2023 at 09:29:02PM +0100, Sebastian Crane wrote: >> Dear Kevin, >> Hmm, quoting from https://pagure.io/releng/issue/11092: >> Also the aarch64 cluster is running on Fedora 33 boxes, so we >> should probably try to do a full

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On Mon, May 08, 2023 at 09:29:02PM +0100, Sebastian Crane wrote: > Dear Kevin, > > > > Hmm, quoting from https://pagure.io/releng/issue/11092: > > > >> Also the aarch64 cluster is running on Fedora 33 boxes, so we > > > >> should probably try to do a full redeploy :-( > > > > We can't upgrade it

[Bug 2196384] Please branch and build perl-Net-SSH2 in epel8

https://bugzilla.redhat.com/show_bug.cgi?id=2196384 Carl George 鸞 changed: What|Removed |Added Blocks||2027767 Referenced Bugs:

[Bug 2196384] New: Please branch and build perl-Net-SSH2 in epel8

https://bugzilla.redhat.com/show_bug.cgi?id=2196384 Bug ID: 2196384 Summary: Please branch and build perl-Net-SSH2 in epel8 Product: Fedora Version: rawhide OS: Linux Status: NEW Component: perl-Net-SSH2

Re: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

Zbigniew Jędrzejewski-Szmek writes: > Sounds good. Can you post the list of affected packages here? According to mpb at least: 0ad Agda Io-language Macaulay2 ShellCheck alex bench brainfuck bustle cab cabal-install cabal-rpm chromium cjs cpphs darcs dhall dhall-json dl-fedora

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On 5/8/23 16:10, Stephen Smoogen wrote: > On Mon, 8 May 2023 at 15:58, Zbigniew Jędrzejewski-Szmek > wrote: > >> On Mon, May 08, 2023 at 09:24:08AM -0700, Kevin Fenzi wrote: >> >>> I'd like to note that making this blocking doesn't waive any kind of >>> magic wand that makes our infrastructure

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

Dear Kevin, > > Hmm, quoting from https://pagure.io/releng/issue/11092: > > >> Also the aarch64 cluster is running on Fedora 33 boxes, so we > > >> should probably try to do a full redeploy :-( > > > We can't upgrade it from f33 because docker is no longer in f34+ and > > > openshift origin /

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On Mon, May 08, 2023 at 07:57:30PM +, Zbigniew Jędrzejewski-Szmek wrote: > > I think we need some clarity wrt. to the dependency order here. > Let's say we: > > In order to do this at branch point, we will need to move building this > > image into the compose process and mark it blocking. >

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On Mon, 8 May 2023 at 15:58, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, May 08, 2023 at 09:24:08AM -0700, Kevin Fenzi wrote: > > > I'd like to note that making this blocking doesn't waive any kind of > > magic wand that makes our infrastructure more reliable. ;) > > The container build

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On Mon, May 08, 2023 at 09:24:08AM -0700, Kevin Fenzi wrote: > I'm broadly in favor here, some comments in line... > > ...snip... > > First, we want to ensure that there are up to date > > [https://src.fedoraproject.org/container/fedora-toolbox > > fedora-toolbox] OCI images published on > >

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

On Mon, May 08, 2023 at 04:49:09PM +0100, Barry wrote: > > fedora-toolbox] [https://opencontainers.org/ OCI] images must be > This url does not exist. > > [https://containertoolbx.org/ Toolbx] to be usable when a new Fedora > Nor this one. Both work fine here. Maybe some temporary network

Re: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

On Mon, May 08, 2023 at 02:50:21PM +0100, Aoife Moloney wrote: > https://fedoraproject.org/wiki/Changes/LIBFFI34_static_trampolines > == Summary == > Libffi is currently configured to use dynamic trampolines, which > require some source of memory which is both writable and executable. > This is an

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

I'm broadly in favor here, some comments in line... ...snip... > First, we want to ensure that there are up to date > [https://src.fedoraproject.org/container/fedora-toolbox > fedora-toolbox] OCI images published on > [https://registry.fedoraproject.org/ registry.fedoraproject.org] as >

Re: DNF Sytem Upgrade requirements for an F37 → F38 upgrade

On Sat, Apr 1, 2023 at 3:44 PM Alexander Ploumistos wrote: > > Something is glitching on my provider's side and it's impossible to > create new VMs. I've opened a ticket, but I doubt anyone is going to > deal with it before Monday. It has taken them over a month to (sort of) resolve the problem,

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

> On 8 May 2023, at 14:51, Aoife Moloney wrote: > > https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker > > 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

Re: memtest86plus v6.00

On Mon, May 8, 2023 at 10:59 AM Peter Lemenkov wrote: > > Sorry for reviving this old thread but memtest86+ just hit 6.20 > milestone and it looks like they restored non-UEFI boot support. Looks > like it could be done for both types of systems as easy as this > (assuming you're using grub2 for

Re: memtest86plus v6.00

Sorry for reviving this old thread but memtest86+ just hit 6.20 milestone and it looks like they restored non-UEFI boot support. Looks like it could be done for both types of systems as easy as this (assuming you're using grub2 for booting the kernel): menuentry 'memtest86+' { insmod

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

Hi Troy, If required, the epel8 & epel9 builds could have a patch added that changes the default of the new "allow setuid-mount extfs" to be "yes" instead of "no". That's all that would be required to disable the incompatible change. But as I said, I think it's a bad idea to make this behavior

F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

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

F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

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

F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

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

F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

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

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

That makes it more clear for epel7. But it will be strange for epel7 to have a higher version than epel8 and 9. Would the apptainer maintainers be willing to create an update that has the --userns option, as well as the original option? Then for epel7 the rpm's would have the original option

Fedora rawhide compose report: 20230508.n.0 changes

OLD: Fedora-Rawhide-20230507.n.0 NEW: Fedora-Rawhide-20230508.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 2 Dropped packages:0 Upgraded packages: 59 Downgraded packages: 0 Size of added packages: 144.58 KiB Size of dropped packages:0

Re: Build system clocks?

* Fabio Valentini: > Yeah, the way the forge macros determine "snapshot date" is a bit > broken / produces inconsistent results. > It uses the source file *modification time* ("mtime"), which might or > might not be consistent in all environments ... it's also an attempt > to get the "date the

Re: Build system clocks?

On Sun, May 7, 2023 at 11:11 PM Elliott Sales de Andrade wrote: > > On Sun, May 7, 2023 at 4:59 PM Chris Adams wrote: >> >> Once upon a time, Kevin Kofler said: >> > Chris Adams wrote: >> > > I updated the source of a package of mine last night. The upstream is >> > > on Github, and I use the

Re: mingw sysroot paths (and generalizing them)

* Daniel P. Berrangé: > Parallel install of different versions of mingw has never been > something we needed to consider. We only need parallel install > the different ABIs, which is handled by the higher level dir > in the path. So from that POV, I don't think mingw particularly > cares what

SPDX Statistics - Victory day

Two weeks ago we had: * 22961 spec files in Fedora * 29459license tags in all spec files * 19099 tags have not been converted to SPDX yet * 7404tags can be trivially converted using `license-fedora2spdx` * Progress: 35% ░░░███ 100% Today we have: * 23000 spec files in Fedora (wow,

Re: SPDX Statistics - ZX Spectrum edition

Dne 05. 05. 23 v 21:46 Artur Frenszek-Iwicki napsal(a): Now it uses SPDX identifiers, but lowercase ors, should probably be uppercase ORs. Yea. I've been reading through the spec lately, since I want to add proper SPDX support to my project, and it says joiners should be uppercase and parsers