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

[Jens-Ulrik Petersen]

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 maintained by me... so I can't say I
> thrilled.
> I thought ghc 9 was supposed to be okay with static trampolines?
>
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2193159

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
   Fixed In Version||perl-Devel-Dumpvar-1.06-37.
   ||fc39
 Status|NEW |CLOSED
Last Closed||2023-05-09 05:42:40




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2193159
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

disabling yum modular repos by default?

[Jens-Ulrik Petersen]

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 anymore. Does this make sense?

I know dnf5 is coming with performance improvements
but I still think turning off the modular repos would speed up dnf
and save users a lot of time.

Jens (pulling his flame-wear closer :)

ps I think it would be a good idea to disable the cisco-h264 repo too by
default in the fedora container image, and maybe also for headless Fedora
editions.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Jens-Ulrik Petersen]

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 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[bugzilla]

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
   |c37 |c37
   |perl-User-Identity-1.02-1.f |perl-User-Identity-1.02-1.f
   |c38 |c38
   |perl-User-Identity-1.02-1.e |perl-User-Identity-1.02-1.e
   |l8  |l8
   ||perl-User-Identity-1.02-1.e
   ||l9



--- Comment #18 from Fedora Update System  ---
FEDORA-EPEL-2023-8dc4aacd82 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2187275
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[bugzilla]

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
   |c37 |c37
   |perl-User-Identity-1.02-1.f |perl-User-Identity-1.02-1.f
   |c38 |c38
   ||perl-User-Identity-1.02-1.e
   ||l8



--- Comment #17 from Fedora Update System  ---
FEDORA-EPEL-2023-7beb39c8f8 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2187275
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[bugzilla]

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
   |c37 |c37
   ||perl-User-Identity-1.02-1.f
   ||c38



--- Comment #16 from Fedora Update System  ---
FEDORA-2023-90c5520f62 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2187275
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2187275

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-User-Identity-1.02-1.f
   ||c37
Last Closed||2023-05-09 01:38:25



--- Comment #15 from Fedora Update System  ---
FEDORA-2023-8fa5e08386 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2187275
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: colm update breaking ragel

[Michel Alexandre Salim]

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 guidelines require to be stripped out, and colm-devel
> rightly does not ship.
> 
> I'm adding this info to the FTI bug that got auto-filed against ragel:
> https://bugzilla.redhat.com/show_bug.cgi?id=2189702
> 
Fixed now with https://koji.fedoraproject.org/koji/taskinfo?taskID=100913236

- colm-0.14.7-2.fc39 with a backported commit to make libfsm
  discoverable
- ragel-7.0.4-1.fc39 with a backported commit to fallback to finding
  *.so

Thanks to Mamoru Tasaka for identifying the ragel commits.

Best regards,

Michel

> On Tue, Apr 25, 2023 at 07:10:12PM -0300, Filipe Rosset wrote:
> > thanks, next time I'll coordinate with the ragel update.
> > 
> > On Tue, Apr 25, 2023 at 6:45 PM Michel Alexandre Salim <
> > sali...@fedoraproject.org> wrote:
> > 
> > > Hi,
> > >
> > > I noticed when rebuilding mcrouter that it failed because ragel is not
> > > installable, because colm was updated:
> > >
> > > DEBUG util.py:443:  Error:
> > > DEBUG util.py:443:   Problem: conflicting requests
> > > DEBUG util.py:443:- nothing provides libcolm-0.13.0.7.so()(64bit)
> > > needed by ragel-7.0.0.12-9.fc38.x86_64
> > >
> > > Looks like the latest version of ragel (7.0.4) expects the new colm
> > > version, so I'll build it and resolve the breakage - only for Rawhide
> > > (both colm and ragel
> > > are maintained by the same upstream).
> > >
> > > CC:ing the colm and ragel maintainers so they can coordinate any update
> > > for other branches.
> > >
> > > --
> > > Michel Alexandre Salim
> > > identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
> > >
> 
> > ___
> > 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, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> 
> 
> -- 
> Michel Alexandre Salim
> identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2



> ___
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue


-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Demi Marie Obenour]

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:
 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 / 3.11 doesn't support any newer either.
>>
>> Is this still true? I don't think we want to make the Fedora release
>> process contingent on something that requires F33.
>
> yes, it's still true. Note thats the aarch64 osbs cluster.
> The x86_64 one is rhel7.

 Might it be possible to replace Docker with CRI-O on the OpenShift
 cluster?
>>>
>>> Nope. openshift 3 / osbs1 uses docker. :(
>>>
>>> kevin
>>
>> alias docker=podman
> 
> Using Podman with it through Podman's implementation of the Docker
> Host protocol *may* work, but a version of Podman that has it is not
> currently available for RHEL 7 (which is what OpenShift 3.11 runs on).

Time for an OpenShift upgrade?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Neal Gompa]

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 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 / 3.11 doesn't support any newer either.
> 
>  Is this still true? I don't think we want to make the Fedora release
>  process contingent on something that requires F33.
> >>>
> >>> yes, it's still true. Note thats the aarch64 osbs cluster.
> >>> The x86_64 one is rhel7.
> >>
> >> Might it be possible to replace Docker with CRI-O on the OpenShift
> >> cluster?
> >
> > Nope. openshift 3 / osbs1 uses docker. :(
> >
> > kevin
>
> alias docker=podman

Using Podman with it through Podman's implementation of the Docker
Host protocol *may* work, but a version of Podman that has it is not
currently available for RHEL 7 (which is what OpenShift 3.11 runs on).



-- 
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Demi Marie Obenour]

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 redeploy :-(
> We can't upgrade it from f33 because docker is no longer in f34+ and
> openshift origin / 3.11 doesn't support any newer either.

 Is this still true? I don't think we want to make the Fedora release
 process contingent on something that requires F33.
>>>
>>> yes, it's still true. Note thats the aarch64 osbs cluster.
>>> The x86_64 one is rhel7.
>>
>> Might it be possible to replace Docker with CRI-O on the OpenShift
>> cluster?
> 
> Nope. openshift 3 / osbs1 uses docker. :(
> 
> kevin

alias docker=podman
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Fenzi]

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 from f33 because docker is no longer in f34+ and
> > > > openshift origin / 3.11 doesn't support any newer either.
> > >
> > > Is this still true? I don't think we want to make the Fedora release
> > > process contingent on something that requires F33.
> >
> > yes, it's still true. Note thats the aarch64 osbs cluster.
> > The x86_64 one is rhel7.
> 
> Might it be possible to replace Docker with CRI-O on the OpenShift
> cluster?

Nope. openshift 3 / osbs1 uses docker. :(

kevin


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2196384

Carl George 鸞  changed:

   What|Removed |Added

 Blocks||2027767





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2027767
[Bug 2027767] Rex is not installable on epel8 because of missing dependencies
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196384
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[bugzilla]

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
  Severity: medium
  Assignee: jples...@redhat.com
  Reporter: c...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-Net-SSH2 in epel8.  The Rex package is not
installable without it.  See bug 2027767 for more details.

Reproducible: Always


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2196384
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[DJ Delorie]

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 
ecl 
fbrnch 
firefox 
gambas3 
gforth 
ghc 
ghc-DAV 
ghc-HaXml 
ghc-aeson-pretty 
ghc-cheapskate 
ghc-clientsession 
ghc-criterion 
ghc-doctest 
ghc-hakyll 
ghc-hgettext 
ghc-highlighting-kate 
ghc-hjsmin 
ghc-hspec-discover 
ghc-pretty-show 
ghc-pretty-simple 
ghc-servant-server 
ghc-tidal 
ghc-vty 
ghc-wai-app-static 
ghc-wai-websockets 
ghc9.0 
ghc9.2 
ghc9.4 
ghc9.6 
ghcid 
git-annex 
git-repair 
gitit 
gjs 
glib2 
gnustep-base 
gobject-introspection 
gtk2hs-buildtools 
guile 
guile22 
guile30 
hadolint 
happy 
haskell-platform 
hedgewars 
hledger 
hledger-ui 
hledger-web 
hlint 
hscolour 
hwk 
icecat 
idris 
ispc 
jna 
koji-tool 
libffi 
libomp 
librep 
lldb 
llvm 
llvm11 
llvm12 
llvm13 
llvm14 
llvm15 
llvm7.0 
llvm8.0 
lsfrom 
lua-lgi 
micropython 
moarvm 
mozjs102 
mozjs78 
mozjs91 
newlisp 
ocaml-ctypes 
ormolu 
p11-kit 
pagure-cli 
pandoc 
patat 
perl-Alien-FFI 
perl-FFI-Platypus 
perl-Glib-Object-Introspection 
php 
pkgtreediff 
polyml 
pygobject2 
pygobject3 
pypy 
pypy3.9 
python-cffi 
python-pyopencl 
python-tox 
python2.7 
python3.10 
python3.11 
python3.12 
python3.6 
python3.7 
python3.8 
python3.9 
qt-creator 
racket 
rakudo 
rhbzquery 
rocm-runtime 
rpmbuild-order 
ruby 
rubygem-ffi 
seamonkey 
shake 
squeak-vm 
thunderbird 
unlambda 
wayland 
xmobar 
xmonad 
yosys 
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Demi Marie Obenour]

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 more reliable. ;)
>>> The container build pipeline is a long collection of fragile things.
>>> It may well result in us slipping more based on things not working. ;(
>>
>> 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 / 3.11 doesn't support any newer either.
>>
>> Is this still true? I don't think we want to make the Fedora release
>> process contingent on something that requires F33.
>>
>> ```
> $ sudo -i ssh osbs-aarch64-node01.iad2.fedoraproject.org cat
> /etc/system-release
> Fedora release 33 (Thirty Three)
> ```
> 
> My memory of this is that this is not an easy thing to 'fix'.

Podman instead of Docker?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Sebastian Crane]

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 / 3.11 doesn't support any newer either.
> >
> > Is this still true? I don't think we want to make the Fedora release
> > process contingent on something that requires F33.
>
> yes, it's still true. Note thats the aarch64 osbs cluster.
> The x86_64 one is rhel7.

Might it be possible to replace Docker with CRI-O on the OpenShift
cluster?

Best wishes,

Sebastian
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Fenzi]

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.
> OK, so we build things, but then we need to publish to registry.fp.o,
> which is asynchrounous (?). When we test the newly built ISOs, do

No, it happens at the end of the compose (if no blocking deliverables
failed causing the compose to fail)

> we test them also with the latest image that we get from registry.fp.o?
> And if we find a bug anywhere in this pipeline, we respin everything?

Good question. I'll note that currently we do not do any specific
testing after branch point. We freeze things to get a compose to
complete, but then we move on. It's not like Beta or Final.

> > 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 pipeline is a long collection of fragile things. 
> > It may well result in us slipping more based on things not working. ;(
> 
> 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 / 3.11 doesn't support any newer either.
> 
> Is this still true? I don't think we want to make the Fedora release
> process contingent on something that requires F33.

yes, it's still true. Note thats the aarch64 osbs cluster.
The x86_64 one is rhel7.

So, perhaps it would make sense to only make the x86_64 one blocking?

kevin


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Stephen Smoogen]

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 pipeline is a long collection of fragile things.
> > It may well result in us slipping more based on things not working. ;(
>
> 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 / 3.11 doesn't support any newer either.
>
> Is this still true? I don't think we want to make the Fedora release
> process contingent on something that requires F33.
>
> ```
$ sudo -i ssh osbs-aarch64-node01.iad2.fedoraproject.org cat
/etc/system-release
Fedora release 33 (Thirty Three)
```

My memory of this is that this is not an easy thing to 'fix'.



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Zbigniew Jędrzejewski-Szmek]

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
> > [https://registry.fedoraproject.org/ registry.fedoraproject.org] as
> > release-blocking deliverables at critical points in the development
> > schedule, just like the installation ISOs for the Editions from
> > [https://download.fedoraproject.org/pub/fedora/linux/releases/
> > download.fedoraproject.org].  This must at least happen when an
> > upcoming Fedora release is branched from Rawhide, and for the Beta and
> > Final release candidates.  If possible, they should be updated more
> > frequently as part of the nightly composes.  We do not expect this to
> > happen after a Fedora release has gone GA.

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.
OK, so we build things, but then we need to publish to registry.fp.o,
which is asynchrounous (?). When we test the newly built ISOs, do
we test them also with the latest image that we get from registry.fp.o?
And if we find a bug anywhere in this pipeline, we respin everything?

> ...snip...
> > It will be beneficial to consider the
> > [https://src.fedoraproject.org/container/fedora-toolbox
> > fedora-toolbox] images as release-blocking deliverables because
> > Fedora's [https://opencontainers.org/ OCI] infrastructure is often
> > broken.  Here are [https://pagure.io/releng/issue/11092 two]
> > [https://pagure.io/releng/issue/11367 recent] examples of fedpkg
> > container-build not working.  In the second case, it was
> > preventing the images from being rebuilt to pull in an
> > [https://bugzilla.redhat.com/show_bug.cgi?id=2170878 important]
> > bug-fix.  The broken infrastructure prevents regular Fedora
> > contributors from jumping in to rebuild and publish the images at
> > critical points in the development schedule.  Making them
> > release-blocking deliverables would attract greater attention and
> > scrutiny from release engineering and ensure that a Fedora development
> > cycle does not proceed with broken or outdated or missing
> > fedora-toolbox images.
> 
> 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 pipeline is a long collection of fragile things. 
> It may well result in us slipping more based on things not working. ;(

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 / 3.11 doesn't support any newer either.

Is this still true? I don't think we want to make the Fedora release
process contingent on something that requires F33.

Zbyszek
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Zbigniew Jędrzejewski-Szmek]

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

Zbyszek
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Zbigniew Jędrzejewski-Szmek]

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 obvious security issue, and selinux and system defaults
> have made it more and more difficult to safely provide this memory to
> libffi clients.  With this change, libffi will be configured to use
> static trampolines, which do not require such memory, and will not
> pose those security and administrative risks.

Sounds good. Can you post the list of affected packages here?

Zbyszek
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Fenzi]

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
> release-blocking deliverables at critical points in the development
> schedule, just like the installation ISOs for the Editions from
> [https://download.fedoraproject.org/pub/fedora/linux/releases/
> download.fedoraproject.org].  This must at least happen when an
> upcoming Fedora release is branched from Rawhide, and for the Beta and
> Final release candidates.  If possible, they should be updated more
> frequently as part of the nightly composes.  We do not expect this to
> happen after a Fedora release has gone GA.

In order to do this at branch point, we will need to move building this
image into the compose process and mark it blocking. Which hopefully we
can do. ;) 

...snip...
> It will be beneficial to consider the
> [https://src.fedoraproject.org/container/fedora-toolbox
> fedora-toolbox] images as release-blocking deliverables because
> Fedora's [https://opencontainers.org/ OCI] infrastructure is often
> broken.  Here are [https://pagure.io/releng/issue/11092 two]
> [https://pagure.io/releng/issue/11367 recent] examples of fedpkg
> container-build not working.  In the second case, it was
> preventing the images from being rebuilt to pull in an
> [https://bugzilla.redhat.com/show_bug.cgi?id=2170878 important]
> bug-fix.  The broken infrastructure prevents regular Fedora
> contributors from jumping in to rebuild and publish the images at
> critical points in the development schedule.  Making them
> release-blocking deliverables would attract greater attention and
> scrutiny from release engineering and ensure that a Fedora development
> cycle does not proceed with broken or outdated or missing
> fedora-toolbox images.

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 pipeline is a long collection of fragile things. 
It may well result in us slipping more based on things not working. ;( 

kevin


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Alexander Ploumistos]

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, but
in any case, I was able to set up another VM to test.
I can confirm that with the backported fix in 251.14-2.fc37, 2GB of
RAM is more than enough to perform the upgrade.
Sorry for the delay.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Barry]

> 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 be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> 
> == Summary ==
> 
> Up to date [https://src.fedoraproject.org/container/fedora-toolbox
> fedora-toolbox] [https://opencontainers.org/ OCI] images must be

This url does not exist.

> published on [https://registry.fedoraproject.org/
> registry.fedoraproject.org] as release-blocking deliverables, and
> there must be release-blocking test criteria to ensure usable
> [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs.
> 
> == Owner ==
> 
> * Name: [[User:Rishi|Debarshi Ray]], [[User:Sumantrom|Sumantro Mukherjee]]
> * Email: debars...@redhat.com, sumuk...@redhat.com
> 
> 
> 
> == Detailed Description ==
> Currently, there is no formal requirement for
> [https://containertoolbx.org/ Toolbx] to be usable when a new Fedora

Nor this one.

Barry

> is released.  This is a problem for a tool that's so popular and
> provides something as fundamental as an interactive command line
> environment for software development and troubleshooting the host
> operating system.  This Change aims to address this.
> 
> Toolbx has two parts — an [https://opencontainers.org/ OCI] image,
> which defaults to
> [https://src.fedoraproject.org/container/fedora-toolbox
> fedora-toolbox] on Fedora hosts, and the
> [https://src.fedoraproject.org/rpms/toolbox toolbox] RPM.  The OCI
> image is pulled by the RPM to set up a containerized interactive CLI
> environment.
> 
> 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
> release-blocking deliverables at critical points in the development
> schedule, just like the installation ISOs for the Editions from
> [https://download.fedoraproject.org/pub/fedora/linux/releases/
> download.fedoraproject.org].  This must at least happen when an
> upcoming Fedora release is branched from Rawhide, and for the Beta and
> Final release candidates.  If possible, they should be updated more
> frequently as part of the nightly composes.  We do not expect this to
> happen after a Fedora release has gone GA.
> 
> Second, we want to have release-blocking test criteria to ensure
> usable [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs at
> critical points in the development schedule.  This must be used to
> ensure that both changes in the Toolbx stack, and future
> [https://docs.fedoraproject.org/en-US/program_management/changes_policy/
> Changes] in other parts of the OS do not break Toolbx, and at least
> cover the Beta and Final release candidates.
> 
> Examples of changes in the Toolbx stack causing breakage can be
> [https://bugzilla.redhat.com/show_bug.cgi?id=2183034 FUSE] preventing
> RPMs with file capabilities from being installed inside Toolbx
> containers, Toolbx [https://github.com/containers/toolbox/issues/643
> bind mounts] preventing RPMs with %attr() from being
> installed or causing
> [https://bugzilla.redhat.com/show_bug.cgi?id=2188304
> systemd-tmpfiles(8)] to throw errors, etc..  Examples of changes in
> other parts of the OS can be changes to Fedora's Kerberos stack
> causing Kerberos to stop working inside Toolbx containers,
> [[Changes/EnableSysctlPingGroupRange|changes]] to the
> sysctl(8)
> [https://github.com/systemd/systemd/commit/90ce7627dfe824ff6e7c0ca5f96350fbcfec7118
> configuration] breaking ping(8), changes in
> [https://github.com/containers/toolbox/issues/562 Mutter] breaking
> graphical applications, etc..
> 
> Note that having release-blocking test criteria for the
> toolbox RPM will also implicitly test the
> fedora-toolbox image.
> 
> == Feedback ==
> 
> 
> == Benefit to Fedora ==
> 
> This Change improves the quality of the containerized interactive
> command line [https://containertoolbx.org/ Toolbx] environments on
> Fedora by adding formal requirements to ensure that they are usable
> when a new Fedora is released.  This will bring them closer to the
> reliability of similar environments running directly on the host
> operating system.
> 
> Toolbx is installed by default on CoreOS, Silverblue and Workstation.
> It is indispensable for software developers using Silverblue to bypass
> the difficulty of setting up a development environment in the usual
> way. It is widely used, even on Workstation, by those who don't want
> to pollute their host OS, or want to access a CLI environment that's
> different from the host's without installing a virtual machine, or
> want a pre-configured development environment.
> 
> It will be beneficial to consider the
> [https://src.fedoraproject.org/container/fedora-toolbox
> 

Re: memtest86plus v6.00

[Neal Gompa]

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 booting the kernel):
>
> menuentry 'memtest86+' {
> insmod part_gpt
> insmod ext2
> set root='hd0,gpt1'
> if [ x$feature_platform_search_hint = xy ]; then
>   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1
> --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  
> else
>   search --no-floppy --fs-uuid --set=root 
> fi
> linux /boot/memtest64.efi
> }
>
> Should we just start moving forward away from the quite antique 5.xx version?
>

Yes, please! :D



-- 
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: memtest86plus v6.00

[Peter Lemenkov]

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 part_gpt
insmod ext2
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1
--hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  
else
  search --no-floppy --fs-uuid --set=root 
fi
linux /boot/memtest64.efi
}

Should we just start moving forward away from the quite antique 5.xx version?

On Fri, Oct 7, 2022 at 3:00 PM Richard W.M. Jones  wrote:
>
>
> Earlier discussion:
> https://www.mail-archive.com/devel@lists.fedoraproject.org/msg169800.html
>
> Current memtest86+ 5.x requires non-UEFI, which makes it increasingly
> irrelevant to modern hardware.  memtest86 forked into a proprietary
> product some time ago.  However there is hope because upstream
> memtest86+ 6.00 is (a) open source and (b) seems to work despite the
> large warnings on the website:
>
> https://memtest.org/
>
> Note this new version is derived from pcmemtest mentioned in the
> thread above which is only indirectly derived from memtest86+ 5.x and
> removes some features.
>
> So my question is are we planning to move to v6.00 in future?
>
> I did attempt to build a Fedora RPM, but it basically involves
> removing large sections of the existing RPM (eg. the downstream script
> we add seems unnecessary now and the downstream README would need to
> be completely rewritten).  It's probably only necessary to have
> memtest.efi be installed as /boot/memtest.efi and although it won't
> appear automatically in the grub menu, it can be accessed by a trivial
> two line command.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> ___
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Dave Dykstra via epel-devel]

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 different
on different OS versions.  Epel8 & 9 are still vulnerable to the same
general issue; even though they're likely to get patches for future low
or moderate level severity vulnerabilities, they don't get patches
quickly and so admins will have to turn this off for the period of time
between announcement and patch upstream.  Also the incompatibility is
going to only affect a small percentage of epel8 & 9 users, and they
should be able to quickly workaround it by adding the --userns option.

The --userns option is already available everywhere.  Are you
suggesting that it default to --userns option behavior on epel8 & 9, at
least for ext3, when "allow setuid-mount extfs = no"?  I have thought
of that but I believe that we cannot mix the setuid mode and the
fuse2fs mount, at least not without a lot of major rework and careful
investigation of the security implications.  I don't think it would be
good to automatically switch fully to the --userns mode with a setuid
installation and "allow setuid-mount extfs = no", because then users
will get subtle differences with other behavior depending on whether or
not they are requesting something that is using an ext3 filesystem.

Dave

On Mon, May 08, 2023 at 06:47:04AM -0700, Troy Dawson wrote:
> 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 turned off, but for
> epel8 and 9 the option could be there and update wouldn't be a breaking
> update.
> 
> That would allow users that have machines on RHEL 7,8 and 9 to use the same
> version and secure options.
> Users that only have machines on RHEL 8 and 9, would then have the option
> to move to the more secure option when the time is good for them.
> 
> Troy
> 
> On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via epel-devel <
> epel-devel@lists.fedoraproject.org> wrote:
> 
> > The NVD analysis at
> > https://nvd.nist.gov/vuln/detail/CVE-2023-30549 
> > is now finished and they agreed with the impact score that I gave it.
> > They ended up with an even higher rating because they said the attack
> > complexity was low.  I think the complexity is high, but in either case the
> > overall severity is rated High.
> >
> > Dave
> >
> > On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote:
> > > DT,
> > >
> > > I am not all arguing that CVE-2022-1184 impact score was incorrect.  I
> > can't imagine why you think that.
> > >
> > > By itself, CVE-2022-1184 is not a privilege escalation, because it can
> > normally only be exploited by someone with write access to the filesystem
> > boots, that is, root.  Only with setuid-root apptainer/singularity does it
> > become a privilege escalation.
> > >
> > > I have said that I think that CVE-2022-1184's "Privileges Required" was
> > incorrect.  It was you who suggested USB automounts being available to
> > users may have been their reason for setting it to "low".  If that's what
> > they meant, then I think it makes perfect sense that they don't count that
> > as a privilege escalation because physical access already gives privilege
> > escalation in much easier ways.  I said that that's probably why they only
> > counted it as denial of service since that was the only thing new.
> > >
> > > Dave
> > >
> > > On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote:
> > > > Dave,
> > > >
> > > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel wrote:
> > > > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote:
> > > > > > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote:
> > > > > ...
> > > > > > > > The Red Hat CVSS score for CVE-2022-1184 has the same
> > breakdown as the
> > > > > > > > NVD CVSS score.  Both rate the "privileges required" property
> > as low.
> > > > > > > > From what I can tell that property would be rated high if they
> > > > > > > > considered root privileges to be required.  How does
> > apptainer's use
> > > > > > > > of setuid change anything here?
> > > > > > >
> > > > > > > According to the explanation I received from the ext4 kernel
> > developer,
> > > > > > > Red Hat's CVSS rating was incorrect on that property.  Without
> > singularity
> > > > > > > or apptainer it does require high privileges to exploit.
> > > > > >
> > > > > > Red Hat's CVSS score breakdown for CVE-2022-1184 is:
> > > > > >
> > > > > > CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
> > > > 

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

[Aoife Moloney]

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


== Summary ==

Up to date [https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] [https://opencontainers.org/ OCI] images must be
published on [https://registry.fedoraproject.org/
registry.fedoraproject.org] as release-blocking deliverables, and
there must be release-blocking test criteria to ensure usable
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs.

== Owner ==

* Name: [[User:Rishi|Debarshi Ray]], [[User:Sumantrom|Sumantro Mukherjee]]
* Email: debars...@redhat.com, sumuk...@redhat.com



== Detailed Description ==
Currently, there is no formal requirement for
[https://containertoolbx.org/ Toolbx] to be usable when a new Fedora
is released.  This is a problem for a tool that's so popular and
provides something as fundamental as an interactive command line
environment for software development and troubleshooting the host
operating system.  This Change aims to address this.

Toolbx has two parts — an [https://opencontainers.org/ OCI] image,
which defaults to
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] on Fedora hosts, and the
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPM.  The OCI
image is pulled by the RPM to set up a containerized interactive CLI
environment.

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
release-blocking deliverables at critical points in the development
schedule, just like the installation ISOs for the Editions from
[https://download.fedoraproject.org/pub/fedora/linux/releases/
download.fedoraproject.org].  This must at least happen when an
upcoming Fedora release is branched from Rawhide, and for the Beta and
Final release candidates.  If possible, they should be updated more
frequently as part of the nightly composes.  We do not expect this to
happen after a Fedora release has gone GA.

Second, we want to have release-blocking test criteria to ensure
usable [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs at
critical points in the development schedule.  This must be used to
ensure that both changes in the Toolbx stack, and future
[https://docs.fedoraproject.org/en-US/program_management/changes_policy/
Changes] in other parts of the OS do not break Toolbx, and at least
cover the Beta and Final release candidates.

Examples of changes in the Toolbx stack causing breakage can be
[https://bugzilla.redhat.com/show_bug.cgi?id=2183034 FUSE] preventing
RPMs with file capabilities from being installed inside Toolbx
containers, Toolbx [https://github.com/containers/toolbox/issues/643
bind mounts] preventing RPMs with %attr() from being
installed or causing
[https://bugzilla.redhat.com/show_bug.cgi?id=2188304
systemd-tmpfiles(8)] to throw errors, etc..  Examples of changes in
other parts of the OS can be changes to Fedora's Kerberos stack
causing Kerberos to stop working inside Toolbx containers,
[[Changes/EnableSysctlPingGroupRange|changes]] to the
sysctl(8)
[https://github.com/systemd/systemd/commit/90ce7627dfe824ff6e7c0ca5f96350fbcfec7118
configuration] breaking ping(8), changes in
[https://github.com/containers/toolbox/issues/562 Mutter] breaking
graphical applications, etc..

Note that having release-blocking test criteria for the
toolbox RPM will also implicitly test the
fedora-toolbox image.

== Feedback ==


== Benefit to Fedora ==

This Change improves the quality of the containerized interactive
command line [https://containertoolbx.org/ Toolbx] environments on
Fedora by adding formal requirements to ensure that they are usable
when a new Fedora is released.  This will bring them closer to the
reliability of similar environments running directly on the host
operating system.

Toolbx is installed by default on CoreOS, Silverblue and Workstation.
It is indispensable for software developers using Silverblue to bypass
the difficulty of setting up a development environment in the usual
way. It is widely used, even on Workstation, by those who don't want
to pollute their host OS, or want to access a CLI environment that's
different from the host's without installing a virtual machine, or
want a pre-configured development environment.

It will be beneficial to consider the
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] images as release-blocking deliverables because
Fedora's [https://opencontainers.org/ OCI] infrastructure is often
broken.  Here are [https://pagure.io/releng/issue/11092 two]
[https://pagure.io/releng/issue/11367 recent] examples of fedpkg
container-build not working.  In the second case, it was

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

[Aoife Moloney]

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


== Summary ==
Libffi is currently configured to use dynamic trampolines, which
require some source of memory which is both writable and executable.
This is an obvious security issue, and selinux and system defaults
have made it more and more difficult to safely provide this memory to
libffi clients.  With this change, libffi will be configured to use
static trampolines, which do not require such memory, and will not
pose those security and administrative risks.

== Owner ==

* Name: [[User:djdelorie| DJ Delorie]]
* Email: d...@redhat.com



== Detailed Description ==
The change itself is simple - libffi will no longer be configured with
--disable-exec-static-tramp, which changes how closures are generated.
Closures, and libffi, are used in many interpreted languages.  There
are about 145 packages that depend, directly or indirectly, on libffi.
I ran the Mass Prebuilder.  Of those 145, 10 already FTBFS, and 1 saw
a new failure.

The Mass PreBuilder has indicated that cjs (Javascript Bindings for
Cinnamon) will fail to build with static trampolines.  We debugged
this a bit and noted that cjs's upstream seems to be behind the gjs
upstream (the gjs package builds OK) it tracks, and is missing at
least two closure-related changes (although simply adding those two
changes proved nontrivial).

== Feedback ==


== Benefit to Fedora ==

This change is needed to fully secure Fedora systems against attacks
that use self-modifying code.

The cjs build failure affects the Cinnamon spin.

== Scope ==
* Proposal owners:
The change is a single line in the spec file.

* Other developers:

The cjs package will need to be fixed to build with the new libffi.

Other libffi users will need to be aware of this change if they make
closure-related changes to their packages, but should not need to take
any actions at this time.

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

This change does not affect release engineering or any other packaging
issues.  No mass rebuild is required.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)


* Alignment with Community Initiatives: N/A

== Upgrade/compatibility impact ==

This change does not change ABI but that assumes clients are not
abusing the ABI; the static vs dynamic trampoline change is an
internal implementation.


== How To Test ==

Testing static trampolines is the same as testing libffi, with the
exception that the tests should pass despite having all writable
filesystems locked with selinux such that executable maps cannot be
requested.  A security context that does not allow the memfd_create()
syscall would further isolate this change.


== User Experience ==

Users will be able to follow latest security recommendations without
concern for whether interpreters will stop working.

== Dependencies ==

As noted above, the cjs package requires work before this change can
go through.  They have noted that they'll be rebasing to 5.8.x:
https://bugzilla.redhat.com/show_bug.cgi?id=2193287

Note that cjs has rebased to 5.6.1 in the interim, just to fix this
bug.  I've tested it and it works with static trampolines.


== Contingency Plan ==

Reverting the one line spec file change will revert this change, with
no changes needed elsewhere.  Not completing this change in time does
not negatively impact other package, or Fedora's ability to ship on
time.

* Contingency mechanism: We can revert the change at any time, without
needing to rebuild any other packages.

* Contingency deadline: Any time before shipping.

* Blocks release? No.


== Documentation ==

This is an internal change that should not need nor affect any documentation.

== Release Notes ==

This change should not require any release notes.


--
Aoife Moloney

Product Owner

Community Platform Engineering Team

Red Hat EMEA

Communications House

Cork Road

Waterford
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Aoife Moloney]

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


== Summary ==

Up to date [https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] [https://opencontainers.org/ OCI] images must be
published on [https://registry.fedoraproject.org/
registry.fedoraproject.org] as release-blocking deliverables, and
there must be release-blocking test criteria to ensure usable
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs.

== Owner ==

* Name: [[User:Rishi|Debarshi Ray]], [[User:Sumantrom|Sumantro Mukherjee]]
* Email: debars...@redhat.com, sumuk...@redhat.com



== Detailed Description ==
Currently, there is no formal requirement for
[https://containertoolbx.org/ Toolbx] to be usable when a new Fedora
is released.  This is a problem for a tool that's so popular and
provides something as fundamental as an interactive command line
environment for software development and troubleshooting the host
operating system.  This Change aims to address this.

Toolbx has two parts — an [https://opencontainers.org/ OCI] image,
which defaults to
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] on Fedora hosts, and the
[https://src.fedoraproject.org/rpms/toolbox toolbox] RPM.  The OCI
image is pulled by the RPM to set up a containerized interactive CLI
environment.

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
release-blocking deliverables at critical points in the development
schedule, just like the installation ISOs for the Editions from
[https://download.fedoraproject.org/pub/fedora/linux/releases/
download.fedoraproject.org].  This must at least happen when an
upcoming Fedora release is branched from Rawhide, and for the Beta and
Final release candidates.  If possible, they should be updated more
frequently as part of the nightly composes.  We do not expect this to
happen after a Fedora release has gone GA.

Second, we want to have release-blocking test criteria to ensure
usable [https://src.fedoraproject.org/rpms/toolbox toolbox] RPMs at
critical points in the development schedule.  This must be used to
ensure that both changes in the Toolbx stack, and future
[https://docs.fedoraproject.org/en-US/program_management/changes_policy/
Changes] in other parts of the OS do not break Toolbx, and at least
cover the Beta and Final release candidates.

Examples of changes in the Toolbx stack causing breakage can be
[https://bugzilla.redhat.com/show_bug.cgi?id=2183034 FUSE] preventing
RPMs with file capabilities from being installed inside Toolbx
containers, Toolbx [https://github.com/containers/toolbox/issues/643
bind mounts] preventing RPMs with %attr() from being
installed or causing
[https://bugzilla.redhat.com/show_bug.cgi?id=2188304
systemd-tmpfiles(8)] to throw errors, etc..  Examples of changes in
other parts of the OS can be changes to Fedora's Kerberos stack
causing Kerberos to stop working inside Toolbx containers,
[[Changes/EnableSysctlPingGroupRange|changes]] to the
sysctl(8)
[https://github.com/systemd/systemd/commit/90ce7627dfe824ff6e7c0ca5f96350fbcfec7118
configuration] breaking ping(8), changes in
[https://github.com/containers/toolbox/issues/562 Mutter] breaking
graphical applications, etc..

Note that having release-blocking test criteria for the
toolbox RPM will also implicitly test the
fedora-toolbox image.

== Feedback ==


== Benefit to Fedora ==

This Change improves the quality of the containerized interactive
command line [https://containertoolbx.org/ Toolbx] environments on
Fedora by adding formal requirements to ensure that they are usable
when a new Fedora is released.  This will bring them closer to the
reliability of similar environments running directly on the host
operating system.

Toolbx is installed by default on CoreOS, Silverblue and Workstation.
It is indispensable for software developers using Silverblue to bypass
the difficulty of setting up a development environment in the usual
way. It is widely used, even on Workstation, by those who don't want
to pollute their host OS, or want to access a CLI environment that's
different from the host's without installing a virtual machine, or
want a pre-configured development environment.

It will be beneficial to consider the
[https://src.fedoraproject.org/container/fedora-toolbox
fedora-toolbox] images as release-blocking deliverables because
Fedora's [https://opencontainers.org/ OCI] infrastructure is often
broken.  Here are [https://pagure.io/releng/issue/11092 two]
[https://pagure.io/releng/issue/11367 recent] examples of fedpkg
container-build not working.  In the second case, it was

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

[Aoife Moloney]

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


== Summary ==
Libffi is currently configured to use dynamic trampolines, which
require some source of memory which is both writable and executable.
This is an obvious security issue, and selinux and system defaults
have made it more and more difficult to safely provide this memory to
libffi clients.  With this change, libffi will be configured to use
static trampolines, which do not require such memory, and will not
pose those security and administrative risks.

== Owner ==

* Name: [[User:djdelorie| DJ Delorie]]
* Email: d...@redhat.com



== Detailed Description ==
The change itself is simple - libffi will no longer be configured with
--disable-exec-static-tramp, which changes how closures are generated.
Closures, and libffi, are used in many interpreted languages.  There
are about 145 packages that depend, directly or indirectly, on libffi.
I ran the Mass Prebuilder.  Of those 145, 10 already FTBFS, and 1 saw
a new failure.

The Mass PreBuilder has indicated that cjs (Javascript Bindings for
Cinnamon) will fail to build with static trampolines.  We debugged
this a bit and noted that cjs's upstream seems to be behind the gjs
upstream (the gjs package builds OK) it tracks, and is missing at
least two closure-related changes (although simply adding those two
changes proved nontrivial).

== Feedback ==


== Benefit to Fedora ==

This change is needed to fully secure Fedora systems against attacks
that use self-modifying code.

The cjs build failure affects the Cinnamon spin.

== Scope ==
* Proposal owners:
The change is a single line in the spec file.

* Other developers:

The cjs package will need to be fixed to build with the new libffi.

Other libffi users will need to be aware of this change if they make
closure-related changes to their packages, but should not need to take
any actions at this time.

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

This change does not affect release engineering or any other packaging
issues.  No mass rebuild is required.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)


* Alignment with Community Initiatives: N/A

== Upgrade/compatibility impact ==

This change does not change ABI but that assumes clients are not
abusing the ABI; the static vs dynamic trampoline change is an
internal implementation.


== How To Test ==

Testing static trampolines is the same as testing libffi, with the
exception that the tests should pass despite having all writable
filesystems locked with selinux such that executable maps cannot be
requested.  A security context that does not allow the memfd_create()
syscall would further isolate this change.


== User Experience ==

Users will be able to follow latest security recommendations without
concern for whether interpreters will stop working.

== Dependencies ==

As noted above, the cjs package requires work before this change can
go through.  They have noted that they'll be rebasing to 5.8.x:
https://bugzilla.redhat.com/show_bug.cgi?id=2193287

Note that cjs has rebased to 5.6.1 in the interim, just to fix this
bug.  I've tested it and it works with static trampolines.


== Contingency Plan ==

Reverting the one line spec file change will revert this change, with
no changes needed elsewhere.  Not completing this change in time does
not negatively impact other package, or Fedora's ability to ship on
time.

* Contingency mechanism: We can revert the change at any time, without
needing to rebuild any other packages.

* Contingency deadline: Any time before shipping.

* Blocks release? No.


== Documentation ==

This is an internal change that should not need nor affect any documentation.

== Release Notes ==

This change should not require any release notes.


--
Aoife Moloney

Product Owner

Community Platform Engineering Team

Red Hat EMEA

Communications House

Cork Road

Waterford
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Troy Dawson]

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 turned off, but for
epel8 and 9 the option could be there and update wouldn't be a breaking
update.

That would allow users that have machines on RHEL 7,8 and 9 to use the same
version and secure options.
Users that only have machines on RHEL 8 and 9, would then have the option
to move to the more secure option when the time is good for them.

Troy

On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> The NVD analysis at
> https://nvd.nist.gov/vuln/detail/CVE-2023-30549
> is now finished and they agreed with the impact score that I gave it.
> They ended up with an even higher rating because they said the attack
> complexity was low.  I think the complexity is high, but in either case the
> overall severity is rated High.
>
> Dave
>
> On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote:
> > DT,
> >
> > I am not all arguing that CVE-2022-1184 impact score was incorrect.  I
> can't imagine why you think that.
> >
> > By itself, CVE-2022-1184 is not a privilege escalation, because it can
> normally only be exploited by someone with write access to the filesystem
> boots, that is, root.  Only with setuid-root apptainer/singularity does it
> become a privilege escalation.
> >
> > I have said that I think that CVE-2022-1184's "Privileges Required" was
> incorrect.  It was you who suggested USB automounts being available to
> users may have been their reason for setting it to "low".  If that's what
> they meant, then I think it makes perfect sense that they don't count that
> as a privilege escalation because physical access already gives privilege
> escalation in much easier ways.  I said that that's probably why they only
> counted it as denial of service since that was the only thing new.
> >
> > Dave
> >
> > On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote:
> > > Dave,
> > >
> > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel wrote:
> > > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote:
> > > > > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote:
> > > > ...
> > > > > > > The Red Hat CVSS score for CVE-2022-1184 has the same
> breakdown as the
> > > > > > > NVD CVSS score.  Both rate the "privileges required" property
> as low.
> > > > > > > From what I can tell that property would be rated high if they
> > > > > > > considered root privileges to be required.  How does
> apptainer's use
> > > > > > > of setuid change anything here?
> > > > > >
> > > > > > According to the explanation I received from the ext4 kernel
> developer,
> > > > > > Red Hat's CVSS rating was incorrect on that property.  Without
> singularity
> > > > > > or apptainer it does require high privileges to exploit.
> > > > >
> > > > > Red Hat's CVSS score breakdown for CVE-2022-1184 is:
> > > > >
> > > > > CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
> > > > >
> > > > > You're suggesting that Red Hat's rating should have been higher
> > > > > because they didn't factor in low privileges, but that is
> objectively
> > > > > false because they did score it with low privileges.  If they had
> > > > > scored it for high privileges, that would have dropped the rating
> down
> > > > > from 5.5 to 4.4.
> > > >
> > > > As DT pointed out, perhaps Red Hat was thinking that low privileges
> could
> > > > have been used by automounts of a USB device, but since that requires
> > > > physical access and there are much easier ways to get privilege
> escalation
> > > > with physical access, the only additional capability that would give
> to
> > > > a user is a crash, a denial of service.
> > >
> > > Impact scoring for a CVE doesn't depend on how it is triggered,
> though. If CVE-2022-1184 can provably give privilege escalation then it
> should be scored high on the impact
> (confidentiality/integrity/availability) metrics. It is not relevant to the
> impact whether I need physical access. The ease of the exploit is covered
> by the exploitability metrics, not the impact metrics.
> > >
> > > https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
> > >
> > > My comment about automounts etc. was only related to why Red Hat might
> hve set the 'Privileges Required' property to low, even though `mount` is
> usually a root-only operation. Here you are arguing that CVE-2022-1184 was
> mis-scored on impact (confidentiality/integrity/availability). This is not
> related to my point about privileges required.
> > >
> > > > > There is no reason to believe that CVE-2022-1184
> > > > > should have been marked as higher impact than it was, and thus I
> see
> > > > 

Fedora rawhide compose report: 20230508.n.0 changes

[Fedora Rawhide Report]

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 B
Size of upgraded packages:   498.48 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   2.24 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-Rawhide-20230508.n.0.s390x.qcow2
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20230508.n.0.s390x.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: rust-sctk-adwaita-0.5.4-1.fc39
Summary: Adwaita-like SCTK Frame
RPMs:rust-sctk-adwaita+ab_glyph-devel rust-sctk-adwaita+crossfont-devel 
rust-sctk-adwaita+default-devel rust-sctk-adwaita-devel
Size:53.89 KiB

Package: rust-wayland-sys0.29-0.29.5-1.fc39
Summary: FFI bindings to the various libwayland-*.so libraries
RPMs:rust-wayland-sys0.29+client-devel rust-wayland-sys0.29+cursor-devel 
rust-wayland-sys0.29+default-devel rust-wayland-sys0.29+dlib-devel 
rust-wayland-sys0.29+dlopen-devel rust-wayland-sys0.29+egl-devel 
rust-wayland-sys0.29+lazy_static-devel rust-wayland-sys0.29+libc-devel 
rust-wayland-sys0.29+memoffset-devel rust-wayland-sys0.29+server-devel 
rust-wayland-sys0.29-devel
Size:90.69 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  AusweisApp2-1.26.4-2.fc39
Old package:  AusweisApp2-1.26.4-1.fc39
Summary:  Online identification with German ID card (Personalausweis)
RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc
Size: 20.62 MiB
Size change:  1.25 KiB
Changelog:
  * Sun May 07 2023 Bj??rn Esser  - 1.26.4-2
  - Rebuild(Qt_6.5)


Package:  ImageMagick-1:7.1.1.8-1.fc39
Old package:  ImageMagick-1:7.1.1.4-3.fc39
Summary:  An X application for displaying and manipulating images
RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel 
ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-heic 
ImageMagick-libs ImageMagick-perl
Size: 38.74 MiB
Size change:  171.85 KiB
Changelog:
  * Sat Apr 22 2023 Fedora Release Monitoring 
 - 1:7.1.1.8-1
  - Update to 7.1.1.8 (#2181846)


Package:  Mayavi-4.8.1-3.fc39
Old package:  Mayavi-4.8.1-1.fc38
Summary:  Scientific data 3-dimensional visualizer
RPMs: Mayavi Mayavi-doc python3-mayavi
Size: 87.58 MiB
Size change:  769.17 KiB
Changelog:
  * Wed Jan 18 2023 Fedora Release Engineering  - 
4.8.1-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

  * Mon May 08 2023 Orion Poplawski  - 4.8.1-3
  - Add upstream patch to fix build with Python 3.11 (FTBFS bz#2171427)


Package:  amavis-2.13.0-4.fc39
Old package:  amavis-2.13.0-3.fc39
Summary:  Email filter with virus scanner and spamassassin support
RPMs: amavis amavis-doc amavis-snmp perl-Amavis
Size: 891.86 KiB
Size change:  31 B
Changelog:
  * Sat May 06 2023 Chris Adams  - 2.13.0-4
  - Add a syconfig file to be able to add arguments


Package:  bugzilla-5.0.6-18.fc39
Old package:  bugzilla-5.0.6-17.fc39
Summary:  Bug tracking system
RPMs: bugzilla bugzilla-contrib bugzilla-doc bugzilla-doc-build
Size: 2.91 MiB
Size change:  -112.31 KiB
Changelog:
  * Sun May 07 2023 Emmanuel Seyman  - 5.0.6-18
  - Patch to build against Sphinx 6.1.3 (#2180465)
  - Use new patch syntax


Package:  cairo-dock-plug-ins-3.4.1-43.20210730gitf24f769.fc39
Old package:  cairo-dock-plug-ins-3.4.1-42.20210730gitf24f769.fc38.1
Summary:  Plug-ins files for Cairo-Dock
RPMs: cairo-dock-plug-ins cairo-dock-plug-ins-base 
cairo-dock-plug-ins-common cairo-dock-plug-ins-dbus cairo-dock-plug-ins-kde 
cairo-dock-plug-ins-unstable cairo-dock-plug-ins-webkit 
cairo-dock-plug-ins-xfce cairo-dock-python3 cairo-dock-ruby cairo-dock-vala 
cairo-dock-vala-devel
Size: 17.37 MiB
Size change:  -28.83 KiB
Changelog:
  * Sun May 07 2023 Mamoru TASAKA  - 
3.4.1-43.20210730gitf24f769
  - Use webkit2gtk-4.1 for F-39+
https://fedoraproject.org/wiki/Changes/Remove_webkit2gtk-4.0_API_Version


Package:  crawl-0.30.0-1.fc39
Old package:  crawl-0.30-0.1.beta1.fc39
Summary:  Roguelike dungeon exploration game
RPMs: crawl crawl-common-data crawl-tiles
Size: 118.95 MiB
Size change:  6.33 KiB
Changelog:
  * Sun May 07 2023 Antonio Trande  - 0.30-0-1
  - Release 0.30.0


Package:  digikam-8.0.0-3.fc39
Old package:  digikam-8.0.0-2.fc39
Summary:  A digital camera accessing & photo management application
RPMs: digikam digikam-devel digikam-libs
Dropped RPMs: digikam-doc
Size: 104.89 MiB
Size change:  -44.78 KiB
Changelog:
  * Sun May 07 2023 Alexey Kurov  - 8.0.0-3
  - backport thumbbar fix (kde#468593)
  - removed BR phonon4qt5
  - obsoleted 

Re: Build system clocks?

[Florian Weimer]

* 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 snapshot was taken" (not the "date the specified
> commit was committed") which always seemed a bit misguided to me, but
> what do I know :)

fedpkg-minimal uses curl -R (--remote-time) to get the timestamp from
the lookaside cache.  But maybe the lookaside cache servers are not
guaranteed to provide Last-Modified: headers?  The public view appears
to be okay, though.

It would be interesting to see the timestamps the server returned (curl
-v output).

But maybe it's something else entirely and the build manages the modify
the tarball somehow.

Thanks,
Florian
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build system clocks?

[Fabio Valentini]

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 %forgemeta macro for an easy spec file.  When I
>> > > tried to run "fedpkg build" though, it failed - the build system
>> > > rejected the build because it was expecting an SRPM with a release
>> > > string including 20230507, but instead got one with 20230506.
>> >
>> > Could it be that you built the package over midnight UTC, so the SRPM was
>> > still built with 20230506, but when the build happened, it was already
>> > 20230507?
>>
>> It wasn't that, I tried it several times.  Also, the forge macro is
>> using the timestamp of the source file, not the wall clock (so the
>> system clock being wrong wouldn't have caused it either).
>>
>
> It uses the timestamp of the source file, but are those timestamps the same? 
> When you download from the forge, the timestamp on the file will be the time 
> that you downloaded it. When you upload to the lookaside cache, the timestamp 
> will be for when it was put there, but your local file has not changed. When 
> fedpkg or koji download from the lookaside cache, it will copy the timestamp 
> from it for reproducibility.
>
> However, if the file already exists, fedpkg won't touch it. I suspect if you 
> delete the tarball and have fedpkg download it again, everything will appear 
> consistent again.

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 snapshot was taken" (not the "date the specified
commit was committed") which always seemed a bit misguided to me, but
what do I know :)

Anyway, those are the reasons why - back in the days when I did more
Go packaging - I added a way to override the date with a fixed value
to make the "Release" tag reproducible when using the %forge macros.

(Side note: The %forge macros don't even follow the new Versioning
guidelines for snapshots - i.e. using caret and tilde - which puts the
snapshot info into the "Version" tag instead of the "Release" tag ...
but I'm not sure if anybody is still around who could fix that.)

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: mingw sysroot paths (and generalizing them)

[Florian Weimer]

* 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 semantics are attached to the 4th path component
> 'mingw'. As long as we don't have to change our paths currently
> used in Fedora, I think it'd be OK for you to define the 4th
> component as the OS version indicator. 

Okay, then I'll keep the path layout as we have it today for now.  It's
toolchain-internal for now anyway, so we can adjust it easily later.

Thanks,
Florian
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

SPDX Statistics - Victory day

[Miroslav Suchý]

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, nice round number :) )

* 29503license tags in all spec files

* 18744 tags have not been converted to SPDX yet

* 7157tags can be trivially converted using `license-fedora2spdx`

* Progress: 36% ░░░███ 100%

ELN subset:

* 1987 out of 4704 packages are not converted yet

The list of packages needed to be converted is again here:

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt

List by package maintainers is here

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt

List of packages from ELN subset that needs to be converted:

https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt

New version of fedora-license-data has been released.

Legal docs and especially

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

was updated too.

I updated the progress in this spreadsheet:

https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing

You converted about 400 license tags in 14 days.

New projection when we will be finished is 2024-07-30. Pure linear 
approximation.

If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license 
tag matches SPDX formula, you can put your package on ignore list


https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt

Either pull-request or email to me is fine.


Why Victory day? On this day, 78 years ago Karl Dönitz announce capitulation of 
Germany via radio.

You can listen to his announcement https://www.youtube.com/watch?v=b8tXt0buPbA or read about the Victory day 
https://en.wikipedia.org/wiki/Victory_in_Europe_Day



Do you hesitate how to proceed with the migration? Please follow

https://docs.fedoraproject.org/en-US/legal/update-existing-packages/

or attend SPDX office hours (see different thread in this mailing list)

Miroslav


___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Statistics - ZX Spectrum edition

[Miroslav Suchý]

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 should match 
case-sensitively.


License expression operators (AND, OR and WITH) should be matched in a 
case-sensitive manner.

https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/#d2-case-sensitivity


Right.

So:

0BSD OR AAL

0bsd OR AAL

0Bsd OR aAl

are all correct while

0BSD or AAL

is not correct.

Miroslav
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue