Re: NVIDIA Open-Source GPU Kernel Modules: How does that affect Fedora Linux?

[Carmelo Sarta]

This is certainly good news but I think we'll need to wait until a release
on the mainline.

On Thu, May 12, 2022 at 7:44 AM Miro Hrončok  wrote:

> Hello Fedorans. I suppose this changes things, right? But how?
>
>
> https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/
>
> As far as I know this would still not be acceptable in Fedora due to the
> "No
> external kernel modules" rule, right?
>
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_no_external_kernel_modules
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 

and thanks for all the fish,

Carmelo Sarta

Red Hat 

csa...@redhat.com
@RedHat    Red Hat
  Red Hat


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

NVIDIA Open-Source GPU Kernel Modules: How does that affect Fedora Linux?

[Miro Hrončok]

Hello Fedorans. I suppose this changes things, right? But how?

https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/

As far as I know this would still not be acceptable in Fedora due to the "No 
external kernel modules" rule, right?


https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_no_external_kernel_modules

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2081143] perl-Hash-Merge-Simple for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-Hash-Merge-Simple-0.05
   ||1-15.el9
Last Closed||2022-05-12 03:35:21



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-1909b3f616 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=2081143
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-66c028a837   
slurm-20.11.9-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d7255ac6f5   
ecdsautils-0.4.1-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-cf82fb137a   
clamav-0.103.6-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-da4611426e   
python3-lxml-4.2.5-5.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

golang-1.17.7-1.el7
python-catkin_pkg-0.5.0-1.el7
python-colcon-core-0.8.3-1.el7

Details about builds:



 golang-1.17.7-1.el7 (FEDORA-EPEL-2022-f64d777807)
 The Go Programming Language

Update Information:

Update to 1.17.7, including fixes for CVE-2021-29923, CVE-2021-43565,
CVE-2022-23806, CVE-2022-23772, and CVE-2022-23773

ChangeLog:

* Tue May 10 2022 Dave Dykstra  - 1.17.7-1
- Update to 1.17.7, based on centos8-stream packaging except keeping
  go-srpm-macros and the "--with ignore_tests" rpmbuild option

References:

  [ 1 ] Bug #1992006 - CVE-2021-29923 golang: net: incorrect parsing of 
extraneous zero characters at the beginning of an IP address octet
https://bugzilla.redhat.com/show_bug.cgi?id=1992006
  [ 2 ] Bug #2030787 - CVE-2021-43565 golang.org/x/crypto: empty plaintext 
packet causes panic
https://bugzilla.redhat.com/show_bug.cgi?id=2030787
  [ 3 ] Bug #2053429 - CVE-2022-23806 golang: crypto/elliptic IsOnCurve returns 
true for invalid field elements
https://bugzilla.redhat.com/show_bug.cgi?id=2053429
  [ 4 ] Bug #2053532 - CVE-2022-23772 golang: math/big: uncontrolled memory 
consumption due to an unhandled overflow via Rat.SetString
https://bugzilla.redhat.com/show_bug.cgi?id=2053532
  [ 5 ] Bug #2053541 - CVE-2022-23773 golang: cmd/go: misinterpretation of 
branch names can lead to incorrect access control
https://bugzilla.redhat.com/show_bug.cgi?id=2053541




 python-catkin_pkg-0.5.0-1.el7 (FEDORA-EPEL-2022-c7a05df398)
 Library for retrieving information about catkin packages

Update Information:

Update to `catkin_pkg` 0.5.0

ChangeLog:

* Tue May 10 2022 Scott K Logan  - 0.5.0-1
- Update to 0.5.0 (rhbz#2083893)

References:

  [ 1 ] Bug #2083893 - python-catkin_pkg-0.5.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2083893




 python-colcon-core-0.8.3-1.el7 (FEDORA-EPEL-2022-24781dbb10)
 Command line tool to build sets of software packages

Update Information:

Update to `colcon-core` 0.8.3

ChangeLog:

* Sat May  7 2022 Scott K Logan  - 0.8.3-1
- Update to 0.8.3 (rhbz#2074923)

References:

  [ 1 ] Bug #2074923 - python-colcon-core-0.8.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2074923


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

Re: Uninitialized variables and F37

[Steve Grubb]

On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
> On Fri, Jan 21, 2022 at 01:04:51PM -0500, Steve Grubb wrote:
> > This is a continuation of the discussion from F36 Change: GNU Toolchain
> > Update.
> 
> snip.
> 
> > He talks about -ftrivial-auto-var-init=zero being used for production
> > builds and -ftrivial-auto-var-init=  being used for debug
> > builds. The use is not just the kernel. Consider a server that returns
> > data across the network to a client. It could possibly leak crypto keys
> > or passwords if the returned data structure has uninitialized memory.
> 
> snip
> 
> > I think this would be an important step forward to turn this on across
> > all compilations. We could wipe out an entire class of bugs in one fell
> > swoop.
> 
> Fast-forward a few months and I see GCC 12.1 is released now with
> -ftrivial-auto-var-init option support [2].
> 
> Are you going to take this idea forward and make a formal change proposal
> for Fedora to set -ftrivial-auto-var-init=zero by default in its default
> RPM build flags ?

I've connected with the gcc folks and we will file a proposal in the near 
future.

-Steve

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)

[Miro Hrončok]

On 11. 05. 22 18:37, Daniel P. Berrangé wrote:

On Wed, May 11, 2022 at 10:24:17AM -0400, Robbie Harwood wrote:

Ben Cotton  writes:


:Don’t prepend a potentially unsafe path to `sys.path`:


If this is a safety/security issue, why not just make it the default for
python itself?


I presume that approach is considered too disruptive to users.
I know I'm running python apps which relying on './someapp' being
able to import modules under './'. Typically this is where I've
checked out $random git repo and don't want to actually run
a full install of it, instead just run straight from git, so I
can switch branches at will. It would be pretty annoying if this
broke, despite the understandable security benefit.

This proposal at least gets the security benefits for all system
shipped stuff, without breaking anything the user has been using
from non-packaged locations.


I've added this to 
https://fedoraproject.org/wiki/Changes/PythonSafePath#Feeedback

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)

[Miro Hrončok]

On 11. 05. 22 16:24, Robbie Harwood wrote:

Ben Cotton  writes:


:Don’t prepend a potentially unsafe path to `sys.path`:


If this is a safety/security issue, why not just make it the default for
python itself?


I would like that, but -P is what we have now. If we pioneer this in Fedora, 
maybe we can convince upstream to make that the default, however, 
backwards-compatibility matters to many people and while I would appreciate 
such change, I don't really want to to drive it. Victor (the second change 
owner) might want to persuade that path, but it ain't gonna happen in Python 3.11.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> Yeah, I agree. I think Python upstream should own up to the fact that
> adding '.' to sys.path was always a mistake.

Yeah, perl bit that bullet a while ago now, dropping '.' from @INC.
It's really the only sane default.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)

[Daniel P . Berrangé]

On Wed, May 11, 2022 at 10:24:17AM -0400, Robbie Harwood wrote:
> Ben Cotton  writes:
> 
> > :Don’t prepend a potentially unsafe path to `sys.path`:
> 
> If this is a safety/security issue, why not just make it the default for
> python itself?

I presume that approach is considered too disruptive to users.
I know I'm running python apps which relying on './someapp' being
able to import modules under './'. Typically this is where I've
checked out $random git repo and don't want to actually run
a full install of it, instead just run straight from git, so I
can switch branches at will. It would be pretty annoying if this
broke, despite the understandable security benefit.

This proposal at least gets the security benefits for all system
shipped stuff, without breaking anything the user has been using
from non-packaged locations.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)

[Barry]

> On 11 May 2022, at 15:25, Robbie Harwood  wrote:
> 
> Ben Cotton  writes:
> 
>> :Don’t prepend a potentially unsafe path to `sys.path`:
> 
> If this is a safety/security issue, why not just make it the default for
> python itself?

It will break normal user use of python.

There is an expectation that if I have a.py and b.py in
the current directory then this must work.

In a.py:
import b

Then I can just do:

$ python a.py

Barry

> 
> Be well,
> --Robbie
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure


signature.asc
Description: Binary data
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 11, 2022 at 10:24:17AM -0400, Robbie Harwood wrote:
> Ben Cotton  writes:
> 
> > :Don’t prepend a potentially unsafe path to `sys.path`:
> 
> If this is a safety/security issue, why not just make it the default for
> python itself?

Yeah, I agree. I think Python upstream should own up to the fact that
adding '.' to sys.path was always a mistake.

Just ask a random user: is

  echo 'import sys; print(sys.version)' >/tmp/test.py
  python /tmp/test.py

safe to execute on a multi-user system?

Zbyszek

P.S. If we can't get the proper fix, this Change proposal is better
than nothing.  So I'll vote +1 on the proposal. But I think we can do
better.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: CentOS Stream 8 and 9 - KDE un-updateable for a week

[Dan Horák]

On Wed, 11 May 2022 08:16:10 -0700
Troy Dawson  wrote:

> EPEL8 on CentOS Stream 8 (epel8-next)
> We have rebuilt as many packages as we can.  We still cannot build
> qt5-qtwebengine, and thus any packages that depend on it.
> - qt5-qtwebengine
> -- The python27 module has been fixed, and you can now build packages that
> require python2 on epel8-next.
> -- qt5-qtwebengine builds fine on x86_64, but failed on aarch64
> --- Any help would be appreciated.
> --- https://kojipkgs.fedoraproject.org//work/tasks/6819/86886819/build.log
> --- We tried rebuilding the older qt5-qtwebengine, same errors.
> --- We tried the older gcc, again, same errors.
> --- Still working on it, but if you recognize the errors in the buildlog,
> let us (me) know.

it's an internal g++ error, it even creates preprocessed sources to be
included in the bug report. I think we should file bug against RHEL-8
gcc, if not done yet. Even if the guys won't fix it immediately, they
can provide some workaround on the source code level. If needed I can
grab the file from the builder.


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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Florian Weimer]

* Daniel P. Berrangé:

> On Wed, May 11, 2022 at 10:37:31AM -0400, Omair Majid wrote:
>> AFAIK, even if you rebuild the exact same sources with the exact same
>> toolchain with the exact same compiler flags, you still can't claim TCK
>> certification status from one build carries over to the next.
>
> With such a strict interpretation, then I would have thought that
> any time a dependency got an update it would invalidate certification
> too, even right down to any glibc update, or even kernel update ?

I think most TCK users do not control an entire operating system like
Fedora does.

Is there an actual contractual requirement for Fedora to distribute
OpenJDK builds only after they have passed the TCK?  That's just
impossible with the Fedora build system, and we would have to remove
OpenJDK from Fedora to comply.  Or maybe there is something we can do to
with the OpenJDK vendor strings to escape TCK testing requirements.
That would still be unfortunate because some Java software looks at
these strings and alters its behavior, so everyone loses because of the
reduced test coverage, but it's probably better than shipping no OpenJDK
at all.

If running the TCK is optional, then the TCK testing could be restricted
to a single Fedora release, plus testing of the RC of a new Fedora
release.  Fedora couldn't claim TCK compliance, of course, but it does
not look like we currently do anyway:

  
  

“TCK” isn't mentioned on docs.fedoraproject.org, either.

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

[EPEL-devel] Re: CentOS Stream 8 and 9 - KDE un-updateable for a week

[Troy Dawson]

On Wed, May 4, 2022 at 8:01 AM Troy Dawson  wrote:

>
> On Wed, Apr 27, 2022 at 9:31 AM Troy Dawson  wrote:
>
>> During the past week qt5 was updated on CentOS Stream 8 and 9 to version
>> 5.15.3.  This caused updates to break for KDE users running CentOS Stream 8
>> and 9.  The epel 8 and 9 packages affected are being rebuilt at this time.
>> We expect everything rebuilt and through testing next week.
>>
>> Question: Does this affect my RHEL/Alma/Rocky 8/9 install?
>> Answer: Not at this time.  This qt5 update isn't going to be released
>> until RHEL 8.7 and 9.1.
>>
>> Question: What is being rebuilt?
>> Answer:
>> epel8 - We believe about 30 packages.  That includes all of the qt5
>> packages in epel8, as well as several plasma and kf5 packages that have
>> tight version dependencies on qt5.
>>
>> epel9 - The entire KDE Plasma Desktop stack. (about 380 packages).  There
>> recently has been an update to wayland-protocols in Stream 9.  It didn't
>> break anything, but it had been an update that was needed to update to the
>> latest kf5 and plasma releases.  Since we knew that the qt5 update was
>> coming, we held off rebuilding everything until qt5 came out.  Now that it
>> is out, we are updating everything.
>>
>> Troy Dawson
>>
>
> Latest update on this.
>
> EPEL9 - Everything is in epel-next-testing.  To do your update do
>   dnf --enablerepo=epel-next-testing update
>
> Reminder, this is a complete KDE Plasma Desktop update to plasma 5.24.4,
> kf5 5.93, qt5 5.15.3
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-a6c0f04770
>
> EPEL8 - Some packages are rebuilt and available, but qt5-qtwebengine, and
> everything that depends on it, has not been rebuilt.
> This is due to a complex module bug in CentOS Stream 8 affecting the
> epel8-next buildroot.  It may, or may not, get fixed this week.
>
> Thank you all for your patience.
> Troy
>

Latest update (May 11)

EPEL9 on CentOS Stream 9 (epel9-next)
The complete KDE Plasma Desktop update is now in stable and on the mirrors.
There are two bugs found and the fixes are in testing.
- selinux and plasma-workspace.
-- This only affects a new install of KDE Plasma Desktop, it doesn't affect
updates.  You will know when you hit this.  Lot's of pop-up screens telling
you of this bug.
-- https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-9984d71297
--- Give it some karma so we don't have to wait a week.
- kf5-kapidox does not install
-- https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-88f6f718b8

Note: again, a reminder, RHEL 9.0 will have the slightly older KDE Plasma
Desktop.  This *updated* KDE Plasma Desktop will not be available for RHEL
9.0 GA, it will be available for RHEL 9.1.

EPEL8 on CentOS Stream 8 (epel8-next)
We have rebuilt as many packages as we can.  We still cannot build
qt5-qtwebengine, and thus any packages that depend on it.
- qt5-qtwebengine
-- The python27 module has been fixed, and you can now build packages that
require python2 on epel8-next.
-- qt5-qtwebengine builds fine on x86_64, but failed on aarch64
--- Any help would be appreciated.
--- https://kojipkgs.fedoraproject.org//work/tasks/6819/86886819/build.log
--- We tried rebuilding the older qt5-qtwebengine, same errors.
--- We tried the older gcc, again, same errors.
--- Still working on it, but if you recognize the errors in the buildlog,
let us (me) know.
- sddm and kscreenlocker not working.
-- We have found that it is indeed a RHEL 8 kernel issue.
-- https://bugzilla.redhat.com/show_bug.cgi?id=2043771
-- kernel issues take a while to make it through RHEL.  So if anyone finds
any type of workarounds.  Let us know.
--- sddm workaround
 dnf install gdm ; systemctl enable gdm -f
--- kscreenlocker workaround - unknown

Again, thank you for your patience and words of encouragement.
Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Daniel P . Berrangé]

On Wed, May 11, 2022 at 10:37:31AM -0400, Omair Majid wrote:
> Hi,
> 
> Daniel P. Berrangé  writes:
> 
> > One way to reduce this burden is to not introduce new JDKs to all
> > existing Fedora streams, only add it to rawhide so certification is
> > only needed once.
> >
> > Having said that I'm still not clear on the real impact of the
> > certification. Presumably thue certification is not re-done in each
> > JDK RPM re-build, nor on every RPM re-build of a library it depends
> > on.  If so, then do we really need to do certification for every
> > Fedora release stream when adding a new JDK. Can we do a build for
> > 35, certify it, and then do what is effectively no-change import
> > and rebuild for 36/37-rawhide and just consider the 35-certification
> > to cover those streams.
> 
> As I understand it, the certification (TCK) is only done on a binary
> level, and only applies to the OpenJDK package itself. It's not a
> one-time thing when a new version of the OpenJDK is added; it needs to
> be re-done on every single rebuild and/or update of OpenJDK.
> 
> AFAIK, even if you rebuild the exact same sources with the exact same
> toolchain with the exact same compiler flags, you still can't claim TCK
> certification status from one build carries over to the next.

With such a strict interpretation, then I would have thought that
any time a dependency got an update it would invalidate certification
too, even right down to any glibc update, or even kernel update ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Omair Majid]

Hi,

Daniel P. Berrangé  writes:

> One way to reduce this burden is to not introduce new JDKs to all
> existing Fedora streams, only add it to rawhide so certification is
> only needed once.
>
> Having said that I'm still not clear on the real impact of the
> certification. Presumably thue certification is not re-done in each
> JDK RPM re-build, nor on every RPM re-build of a library it depends
> on.  If so, then do we really need to do certification for every
> Fedora release stream when adding a new JDK. Can we do a build for
> 35, certify it, and then do what is effectively no-change import
> and rebuild for 36/37-rawhide and just consider the 35-certification
> to cover those streams.

As I understand it, the certification (TCK) is only done on a binary
level, and only applies to the OpenJDK package itself. It's not a
one-time thing when a new version of the OpenJDK is added; it needs to
be re-done on every single rebuild and/or update of OpenJDK.

AFAIK, even if you rebuild the exact same sources with the exact same
toolchain with the exact same compiler flags, you still can't claim TCK
certification status from one build carries over to the next.

If we import a binary (RPM) from one Fedora version to the other, then
we can continue claiming that the original binary is still certified.

Please note that it has been more than 5 years since I was last involved
with Java, so things might have changed. I might also be mis-remembering
something. But hopefully that gives some context on why the
certification (TCK) burden is so huge.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)

[Robbie Harwood]

Ben Cotton  writes:

> :Don’t prepend a potentially unsafe path to `sys.path`:

If this is a safety/security issue, why not just make it the default for
python itself?

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 13/231 (x86_64), 25/161 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220510.n.0):

ID: 1263470 Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/1263470
ID: 1263481 Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/1263481
ID: 1263492 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1263492
ID: 1263510 Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/1263510
ID: 1263533 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1263533
ID: 1263558 Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/1263558
ID: 1263584 Test: x86_64 Cloud_Base-qcow2-qcow2 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1263584
ID: 1263609 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1263609
ID: 1263611 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/1263611
ID: 1263613 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/1263613
ID: 1263616 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/1263616
ID: 1263627 Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/1263627
ID: 1263670 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1263670
ID: 1263701 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1263701
ID: 1263707 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1263707
ID: 1263804 Test: aarch64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/1263804
ID: 1263814 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1263814
ID: 1263824 Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1263824
ID: 1263831 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1263831
ID: 1263837 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1263837
ID: 1263850 Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1263850
ID: 1263851 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1263851
ID: 1263855 Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1263855
ID: 1263856 Test: aarch64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/1263856

Old failures (same test failed in Fedora-Rawhide-20220510.n.0):

ID: 1263525 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1263525
ID: 1263560 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1263560
ID: 1263563 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1263563
ID: 1263602 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1263602
ID: 1263630 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1263630
ID: 1263641 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1263641
ID: 1263661 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1263661
ID: 1263697 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1263697
ID: 1263702 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1263702
ID: 1263808 Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/1263808
ID: 1263852 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1263852
ID: 1263858 Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/1263858
ID: 1263859 Test: aarch64 universal install_serial_console@uefi
URL: https://openqa.fedoraproject.org/tests/1263859
ID: 1263890 Test: aarch64 universal install_rescue_encrypted@uefi
URL: 

F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/PythonSafePath

== Summary ==
The [https://docs.python.org/3.11/using/cmdline.html#cmdoption-P `-P`
flag] will be added to the Python shebang macros
(`%{py3_shbang_opts}`, `%{py3_shebang_flags}`, ...). Packages that
adhere to those macros will change their Python shebangs from `#!
/usr/bin/python3 -s` to `#! /usr/bin/python3 -sP` and as a result,
will no longer have the directory of the script (such as `/usr/bin`)
in `sys.path`. An opt-out mechanism exists.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]], [[User:Vstinner|Victor Stinner]]
* Email: python-ma...@redhat.com

== Detailed Description ==
All Python 3 shebang RPM macros will be changed to contain one more
flag: `-P`. Previously, they contained `-s`, now they will contain
`-sP`.

From the [https://docs.python.org/3.11/using/cmdline.html#cmdoption-P
documentation for the `-P` option]:

:Don’t prepend a potentially unsafe path to `sys.path`:
:
:* `python -m module` command line: Don’t prepend the current working directory.
:* `python script.py` command line: Don’t prepend the script’s
directory. If it’s a symbolic link, resolve symbolic links.
:* `python -c code` and `python` (REPL) command lines: Don’t prepend
an empty string, which means the current working directory.

In shebangs, only the middle option (''don’t prepend the script’s
directory'') is relevant.

Consider the following executbale script installed as
`/usr/bin/let-there-be-fun`:

 #! /usr/bin/python3 -s
 import abc
 ...

When the script is directly executed (e.g. by running
`let-there-be-fun` from the console), the script's directory
(`/usr/bin`) is prepended to `sys.path`. Python tries to locate an
importable `abc` module in `/usr/bin` first. This can cause real
issues: [https://bugzilla.redhat.com/2057340 python3-notebook:
ImportError: bad magic number in six] and
[https://github.com/benjaminp/six/issues/359 bad magic number in six].

When the shebang includes `-P`:

 #! /usr/bin/python3 -sP
 import abc
 ...

...the script's directory (`/usr/bin`) is '''not''' prepended to
`sys.path`. The change owners consider this approach safer for the
majority of Fedora's RPM packages.

By default, '''all standardly RPM-packaged Python packages with
scripts in `/usr/bin` will gain the `-P` flag in their shebang''',
assuming the software is packaged in a way that respects the Python
shebang RPM macros (see below for opt-out and explicit opt-in
mechanisms). Due to the variety of ways such scripts can be
created/packaged, there will likely be packages that will not be
affected by the change automatically. (In other words, the change is
applied on RPM macro level, no added mechanics to force the flag, such
as BRP scripts, are planned as part of this change.)

=== List of RPM macros that will gain `-P` ===

* `%{py3_shbang_opts}`
* `%{py3_shbang_opts_nodash}`
* `%{py3_shebang_flags}`
* `%{py_shbang_opts}`
* `%{py_shbang_opts_nodash}`
* `%{py_shebang_flags}`

=== Opting out ===

If the new behavior is not desirable to your package amend the macros
(e.g. with `sed`) to remove the `P` flag.

If you use the 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
current Python packaging guidelines], e.g. `%pyproject_wheel` and
`%pyproject_install`, use:

 # Don't add -P to Python shebang
 # This package only works when /usr/bin is in sys.path (use your own
rationale here)
 %global py3_shebang_flags %(echo %py3_shebang_flags | sed s/P//)

If you use the 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/
201x-era Python packaging guidelines], e.g. `%py3_build` and
`%py3_install`, use:

 # Don't add -P to Python shebang
 # This package only works when /usr/bin is in sys.path (use your own
rationale here)
 %global py3_shbang_opts %(echo %py3_shbang_opts | sed s/P//)

(The only difference is the name of the macro.)

=== Opting in ===

If you use the 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
current Python packaging guidelines], e.g. `%pyproject_wheel` and
`%pyproject_install`, the standard set of Python shebang flags is
applied to all files with Python shebangs installed in `/usr/bin/`.

If you use the 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/
201x-era Python packaging guidelines], e.g. `%py3_build` and
`%py3_install`, the standard set of Python shebang flags might be
applied to some files and not applied to others depending on the exact
structure of the packaged software.

If you wish to explicitly apply the standard set of Python shebang
flags on a certain file that is not handled automatically, use
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_shebang_fix
the `%py3_shebang_fix` macro].

=== What if the packager changes `%__python3` to an older version of Python ===

The `-P` flag was introduced in Python 3.11. When `%__python3` is
redefined to an older Python version, e.g. `/usr/bin/python3.10`,
including the `-P` flag in shebangs would break the 

F37 proposal: Python: Add -P to default shebangs (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/PythonSafePath

== Summary ==
The [https://docs.python.org/3.11/using/cmdline.html#cmdoption-P `-P`
flag] will be added to the Python shebang macros
(`%{py3_shbang_opts}`, `%{py3_shebang_flags}`, ...). Packages that
adhere to those macros will change their Python shebangs from `#!
/usr/bin/python3 -s` to `#! /usr/bin/python3 -sP` and as a result,
will no longer have the directory of the script (such as `/usr/bin`)
in `sys.path`. An opt-out mechanism exists.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]], [[User:Vstinner|Victor Stinner]]
* Email: python-ma...@redhat.com

== Detailed Description ==
All Python 3 shebang RPM macros will be changed to contain one more
flag: `-P`. Previously, they contained `-s`, now they will contain
`-sP`.

From the [https://docs.python.org/3.11/using/cmdline.html#cmdoption-P
documentation for the `-P` option]:

:Don’t prepend a potentially unsafe path to `sys.path`:
:
:* `python -m module` command line: Don’t prepend the current working directory.
:* `python script.py` command line: Don’t prepend the script’s
directory. If it’s a symbolic link, resolve symbolic links.
:* `python -c code` and `python` (REPL) command lines: Don’t prepend
an empty string, which means the current working directory.

In shebangs, only the middle option (''don’t prepend the script’s
directory'') is relevant.

Consider the following executbale script installed as
`/usr/bin/let-there-be-fun`:

 #! /usr/bin/python3 -s
 import abc
 ...

When the script is directly executed (e.g. by running
`let-there-be-fun` from the console), the script's directory
(`/usr/bin`) is prepended to `sys.path`. Python tries to locate an
importable `abc` module in `/usr/bin` first. This can cause real
issues: [https://bugzilla.redhat.com/2057340 python3-notebook:
ImportError: bad magic number in six] and
[https://github.com/benjaminp/six/issues/359 bad magic number in six].

When the shebang includes `-P`:

 #! /usr/bin/python3 -sP
 import abc
 ...

...the script's directory (`/usr/bin`) is '''not''' prepended to
`sys.path`. The change owners consider this approach safer for the
majority of Fedora's RPM packages.

By default, '''all standardly RPM-packaged Python packages with
scripts in `/usr/bin` will gain the `-P` flag in their shebang''',
assuming the software is packaged in a way that respects the Python
shebang RPM macros (see below for opt-out and explicit opt-in
mechanisms). Due to the variety of ways such scripts can be
created/packaged, there will likely be packages that will not be
affected by the change automatically. (In other words, the change is
applied on RPM macro level, no added mechanics to force the flag, such
as BRP scripts, are planned as part of this change.)

=== List of RPM macros that will gain `-P` ===

* `%{py3_shbang_opts}`
* `%{py3_shbang_opts_nodash}`
* `%{py3_shebang_flags}`
* `%{py_shbang_opts}`
* `%{py_shbang_opts_nodash}`
* `%{py_shebang_flags}`

=== Opting out ===

If the new behavior is not desirable to your package amend the macros
(e.g. with `sed`) to remove the `P` flag.

If you use the 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
current Python packaging guidelines], e.g. `%pyproject_wheel` and
`%pyproject_install`, use:

 # Don't add -P to Python shebang
 # This package only works when /usr/bin is in sys.path (use your own
rationale here)
 %global py3_shebang_flags %(echo %py3_shebang_flags | sed s/P//)

If you use the 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/
201x-era Python packaging guidelines], e.g. `%py3_build` and
`%py3_install`, use:

 # Don't add -P to Python shebang
 # This package only works when /usr/bin is in sys.path (use your own
rationale here)
 %global py3_shbang_opts %(echo %py3_shbang_opts | sed s/P//)

(The only difference is the name of the macro.)

=== Opting in ===

If you use the 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
current Python packaging guidelines], e.g. `%pyproject_wheel` and
`%pyproject_install`, the standard set of Python shebang flags is
applied to all files with Python shebangs installed in `/usr/bin/`.

If you use the 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/
201x-era Python packaging guidelines], e.g. `%py3_build` and
`%py3_install`, the standard set of Python shebang flags might be
applied to some files and not applied to others depending on the exact
structure of the packaged software.

If you wish to explicitly apply the standard set of Python shebang
flags on a certain file that is not handled automatically, use
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_shebang_fix
the `%py3_shebang_fix` macro].

=== What if the packager changes `%__python3` to an older version of Python ===

The `-P` flag was introduced in Python 3.11. When `%__python3` is
redefined to an older Python version, e.g. `/usr/bin/python3.10`,
including the `-P` flag in shebangs would break the 

FESCo election nominations are now open

[Ben Cotton]

Now through 25 May, you may nominate candidates for the five open
seats on the Fedora Engineering Steering Committee (FESCo).

To nominate yourself (or others, if you check with them first), visit:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

FESCo is currently selecting the questions for the interview
questionnaire, which will be finalized before the beginning of the
interview period.

For more information, see the Community Blog post:
https://communityblog.fedoraproject.org/f36-elections-nominations-now-open/

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@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-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

FESCo election nominations are now open

[Ben Cotton]

Now through 25 May, you may nominate candidates for the five open
seats on the Fedora Engineering Steering Committee (FESCo).

To nominate yourself (or others, if you check with them first), visit:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

FESCo is currently selecting the questions for the interview
questionnaire, which will be finalized before the beginning of the
interview period.

For more information, see the Community Blog post:
https://communityblog.fedoraproject.org/f36-elections-nominations-now-open/

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-37-20220511.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 3/15 (x86_64), 4/15 (aarch64)

ID: 1263863 Test: x86_64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1263863
ID: 1263872 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1263872
ID: 1263874 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/1263874
ID: 1263875 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1263875
ID: 1263878 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1263878
ID: 1263879 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/1263879
ID: 1263888 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/1263888

Passed openQA tests: 12/15 (x86_64), 11/15 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Mock tips

[Vít Ondruch]

Dne 10. 05. 22 v 13:32 Richard Shaw napsal(a):

On Tue, May 10, 2022 at 3:09 AM John Reiser  wrote:

Suggestion: extract mqtt.c.o from libmqttc.a, then run "readelf
--all --wide mqtt.c.o  > foo"
and look in file foo for more information about:
    relocation R_X86_64_PC32 against symbol `mqtt_fixed_header_rules'


I'll take a look, but this is one place where building in mock 
sucks... I can shell in to the chroot but not everything "works" 
exactly the same, especially vim, which I have to manually install :)




You can use your local VIM outside of the mock to edit some file inside 
mock, e.g.:



~~~

$ vim 
/var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/your-project-1.2.3/your-file


~~~

You don't even need root privileges editing files in the /builddir 
directory.



BTW sometimes it might also be useful to bind mount your local directory 
into mock. There is even mock plugin which makes it automatic for 
specific config file. You need to add there something like:



~~~

config_opts['plugin_conf']['bind_mount_enable'] = True
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/home/vondruch/projects/your-project', 
'/your-project/' ))


~~~


Vít



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

[Test-Announce] Fedora-IoT 37 RC 20220511.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora-IoT 37 RC 20220511.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/37iot

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_37_RC_20220511.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_37_RC_20220511.0_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20220511.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220510.n.0
NEW: Fedora-Rawhide-20220511.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  4
Dropped packages:0
Upgraded packages:   56
Downgraded packages: 0

Size of added packages:  820.20 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.72 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -109.97 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: dnsx-1.1.0-1.fc37
Summary: Dnsx is a fast and multi-purpose DNS toolkit
RPMs:dnsx golang-github-projectdiscovery-dnsx-devel
Size:12.40 MiB

Package: ephemeral-port-reserve-1.1.4-1.fc37
Summary: Bind to an ephemeral port, force it into the TIME_WAIT state, and 
unbind it.
RPMs:ephemeral-port-reserve
Size:12.90 KiB

Package: ghc9.4-9.4.0.20220501-2.fc37
Summary: Glasgow Haskell Compiler
RPMs:ghc9.4 ghc9.4-Cabal ghc9.4-Cabal-devel ghc9.4-Cabal-doc 
ghc9.4-Cabal-prof ghc9.4-Cabal-syntax ghc9.4-Cabal-syntax-devel 
ghc9.4-Cabal-syntax-doc ghc9.4-Cabal-syntax-prof ghc9.4-array 
ghc9.4-array-devel ghc9.4-array-doc ghc9.4-array-prof ghc9.4-base 
ghc9.4-base-devel ghc9.4-base-doc ghc9.4-base-prof ghc9.4-binary 
ghc9.4-binary-devel ghc9.4-binary-doc ghc9.4-binary-prof ghc9.4-bytestring 
ghc9.4-bytestring-devel ghc9.4-bytestring-doc ghc9.4-bytestring-prof 
ghc9.4-compiler ghc9.4-compiler-default ghc9.4-containers 
ghc9.4-containers-devel ghc9.4-containers-doc ghc9.4-containers-prof 
ghc9.4-deepseq ghc9.4-deepseq-devel ghc9.4-deepseq-doc ghc9.4-deepseq-prof 
ghc9.4-devel ghc9.4-directory ghc9.4-directory-devel ghc9.4-directory-doc 
ghc9.4-directory-prof ghc9.4-doc ghc9.4-doc-index ghc9.4-exceptions 
ghc9.4-exceptions-devel ghc9.4-exceptions-doc ghc9.4-exceptions-prof 
ghc9.4-filepath ghc9.4-filepath-devel ghc9.4-filepath-doc ghc9.4-filepath-prof 
ghc9.4-ghc ghc9.4-ghc-boot ghc9.4-ghc-boot-devel ghc9.4-ghc-boot-doc 
ghc9.4-ghc-boot-prof ghc9.4-ghc-boot-th ghc9.4-ghc-boot-th-devel 
ghc9.4-ghc-boot-th-doc ghc9.4-ghc-boot-th-prof ghc9.4-ghc-compact 
ghc9.4-ghc-compact-devel ghc9.4-ghc-compact-doc ghc9.4-ghc-compact-prof 
ghc9.4-ghc-devel ghc9.4-ghc-doc ghc9.4-ghc-heap ghc9.4-ghc-heap-devel 
ghc9.4-ghc-heap-doc ghc9.4-ghc-heap-prof ghc9.4-ghc-prof ghc9.4-ghci 
ghc9.4-ghci-devel ghc9.4-ghci-doc ghc9.4-ghci-prof ghc9.4-hadrian 
ghc9.4-haskeline ghc9.4-haskeline-devel ghc9.4-haskeline-doc 
ghc9.4-haskeline-prof ghc9.4-hpc ghc9.4-hpc-devel ghc9.4-hpc-doc 
ghc9.4-hpc-prof ghc9.4-libiserv ghc9.4-libiserv-devel ghc9.4-libiserv-doc 
ghc9.4-libiserv-prof ghc9.4-mtl ghc9.4-mtl-devel ghc9.4-mtl-doc ghc9.4-mtl-prof 
ghc9.4-parsec ghc9.4-parsec-devel ghc9.4-parsec-doc ghc9.4-parsec-prof 
ghc9.4-pretty ghc9.4-pretty-devel ghc9.4-pretty-doc ghc9.4-pretty-prof 
ghc9.4-process ghc9.4-process-devel ghc9.4-process-doc ghc9.4-process-prof 
ghc9.4-prof ghc9.4-stm ghc9.4-stm-devel ghc9.4-stm-doc ghc9.4-stm-prof 
ghc9.4-template-haskell ghc9.4-template-haskell-devel 
ghc9.4-template-haskell-doc ghc9.4-template-haskell-prof ghc9.4-terminfo 
ghc9.4-terminfo-devel ghc9.4-terminfo-doc ghc9.4-terminfo-prof ghc9.4-text 
ghc9.4-text-devel ghc9.4-text-doc ghc9.4-text-prof ghc9.4-time 
ghc9.4-time-devel ghc9.4-time-doc ghc9.4-time-prof ghc9.4-transformers 
ghc9.4-transformers-devel ghc9.4-transformers-doc ghc9.4-transformers-prof 
ghc9.4-unix ghc9.4-unix-devel ghc9.4-unix-doc ghc9.4-unix-prof ghc9.4-xhtml 
ghc9.4-xhtml-devel ghc9.4-xhtml-doc ghc9.4-xhtml-prof
Size:807.75 MiB

Package: golang-github-networkplumbing-nft-0.2.0-1.fc37
Summary: Go bindings for nft utility
RPMs:golang-github-networkplumbing-nft-devel
Size:31.69 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  aerc-0.10.0-1.fc37
Old package:  aerc-0.7.1-2.fc36
Summary:  Email client for your terminal
RPMs: aerc
Size: 14.75 MiB
Size change:  495.90 KiB
Changelog:
  * Tue May 10 2022 Robert-Andr?? Mauchin  0.10.0-1
  - Update to 0.10.0 Close: rhbz#2056300


Package:  apptainer-1.0.2-1.fc37
Old package:  apptainer-1.0.1-1.fc37
Summary:  Application and environment virtualization
RPMs: apptainer
Size: 98.63 MiB
Size change:  -57.97 KiB
Changelog:
  * Tue May 10 2022 Dave Dykstra  - 1.0.2
  - Update to upstream 1.0.2


Package:  chicken-5.3.0-1.fc37
Old package:  chicken-5.2.0-3.fc36
Summary:  A practical and portable Scheme system
RPMs: chicken chicken-libs chicken-static
Added RPMs:   chicken-static
Size: 17.98 MiB
Size change:  7.79 MiB
Changelog:
  * Tue May 10 2022 Jani Juhani Sinervo  - 5.3.0-1
  - Update to latest upstream version (RHBZ#2024501)
  - Add -static subpackage for users to link against (RHBZ#2083300)


Package:  containerd-1.6.4-1.fc37
Old package:  containerd-1.6.2-2.fc37
Summary:  Open and reliable container runtime
RPMs: containerd containerd-devel
Size: 114.96 MiB
Size change:  146.60

[Bug 2084076] New: perl-Net-ARP-1.0.12 is available

[bugzilla]

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

Bug ID: 2084076
   Summary: perl-Net-ARP-1.0.12 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-ARP
  Keywords: FutureFeature, Triaged
  Assignee: robinlee.s...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.0.12
Current version/release in rawhide: 1.0.11-5.fc36
URL: http://search.cpan.org/dist/Net-ARP/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/3143/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2084076
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2084076] perl-Net-ARP-1.0.12 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Scratch build failed. Details below:

BuilderException: Build started, but failure happened during post build
operations:
Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs',
'/var/tmp/thn-v7tj53ee/perl-Net-ARP.spec']' returned non-zero exit status 1.

StdOut:
error: Bad source: ./Net-ARP-1.0.12.tgz: No such file or directory


Traceback:
  File
"/usr/local/lib/python3.9/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line
188, in build
raise BuilderException(

If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2084076
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Fedora 37 Rawhide 20220511.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 37 Rawhide 20220511.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/37

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220511.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220511.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220511.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220511.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220511.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220511.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220511.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20220511.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20220510.0):

ID: 1263445 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1263445
ID: 1263454 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1263454

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 11/05/2022 11:03, Daniel P. Berrangé wrote:

It would be useful to have more details about how the certification
is taking place for JDK in Fedora today, so we have a better understanding
of how it is impacting the maintainer currently. When is certification
currently done, what rules need to be followed, etc.


Why do we need such certification? Fedora is a separate distribution, 
not related to Oracle at all.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 11/05/2022 10:44, Daniel P. Berrangé wrote:

JDK version in a Fedora 35 build root once, and then ship that built
binary in Fedora 35, Fedora 36 and Fedora rawhide (37) by just tagging
the F35 build into the newer Fedora koji tags too, instead of rebuilding
for each Fedora version.


This is so bad. The final death of Java on Fedora.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-36-20220511.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/15 (x86_64), 3/15 (aarch64)

New failures (same test not failed in Fedora-IoT-36-20220510.0):

ID: 1263425 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1263425
ID: 1263427 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/1263427
ID: 1263431 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1263431
ID: 1263432 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/1263432

Old failures (same test failed in Fedora-IoT-36-20220510.0):

ID: 1263428 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1263428

Passed openQA tests: 13/15 (x86_64), 12/15 (aarch64)

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.16 to 0.43
Previous test data: https://openqa.fedoraproject.org/tests/1261933#downloads
Current test data: https://openqa.fedoraproject.org/tests/1263429#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Daniel P . Berrangé]

On Tue, May 10, 2022 at 09:29:35AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> 
> 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 ==
> This is initial step to move JDKs to be more like other JDKs, to build
> proper transferable images, and to lower certification burden of each
> binary. Long storyshort, first step in:
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs

Reading this whole doc is really key, because it is clear that
(if approved) further changes are going to follow this one in
Fedora 38. So the decision on whether to approve this first
feature really needs to consider the acceptability of the overall
plan, not just this first step in isolation.


> == Owner ==
> * Name: [[User:jvanek| Jiri Vanek]]
> * Email: jva...@redhat.com
> 
> 
> == Detailed Description ==
> Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> for whole picture
> 
> Please see 
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JDKs_in_RPMs_to_become_portable
> for this particular step. I would rather keep the details  in the main
> page then here.
> 
> == Feedback ==
> According to short investigations, there are already precedents, where
> certification is a reason to build once, certificate, and repack.

It would be useful to have more details about how the certification
is taking place for JDK in Fedora today, so we have a better understanding
of how it is impacting the maintainer currently. When is certification
currently done, what rules need to be followed, etc.

> According to developers, the non-portbale JDK is  causing upredicted
> behavior different from other JDK vendors

IIUC, the Java certification is intended to identify any non-compliant
behaviour between JDK builds. Is this statement indicating that Fedora
builds are not passing the certification, or that we're introducing
regressions into JDK after the certification is done (eg through later
3rd party RPM updates), or is the breadth of JDK cert coverage simply
insufficient to detect enough problems upfront ?


> According to JDK packagers and testers, there is to much JDKs now, and
> the 
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fedora_JDKs_to_become_single-built.2C_portable.2C_ordinary_JDKs.2C_while_keeping_comfortable.2C_usual_system_integration
>  is the only way out

According to the doc we currently have jdk8, jdk11, jdk17 and jdk18,
across 3 Fedora releases (35, 36, 37-rawhde). So 12 build streams
effectively. IIUC, it is implied that when a new JDK comes out (jdk19
next), it would be added immediately to all Fedora streams (35, 36,
37rawhide). 

If separate builds for done for each release, it sounds like it is
meaning JDK certification is needed for each release separate. So
a new jdk19 would need certifying separately for (35, 36, 37-rawhide)

One way to reduce this burden is to not introduce new JDKs to all
existing Fedora streams, only add it to rawhide so certification is
only needed once.

Having said that I'm still not clear on the real impact of the
certification. Presumably thue certification is not re-done in each
JDK RPM re-build, nor on every RPM re-build of a library it depends
on.  If so, then do we really need to do certification for every
Fedora release stream when adding a new JDK. Can we do a build for
35, certify it, and then do what is effectively no-change import
and rebuild for 36/37-rawhide and just consider the 35-certification
to cover those streams.



With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Daniel P . Berrangé]

On Wed, May 11, 2022 at 12:58:22AM +0200, Fabio Valentini wrote:
> On Tue, May 10, 2022 at 11:51 PM Neal Gompa  wrote:
> >
> > On Tue, May 10, 2022 at 5:20 PM Robert Relyea  wrote:
> > >
> > > On 5/10/22 6:29 AM, Ben Cotton wrote:
> > > > https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> > > >
> > > > 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 ==
> > > > This is initial step to move JDKs to be more like other JDKs, to build
> > > > proper transferable images, and to lower certification burden of each
> > > > binary. Long storyshort, first step in:
> > > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> > > >
> > > > This first step will move, one by one, individual JDKs in F37 to be
> > > > built `--with-stdc++lib=static` and against in-tree (bundeld)
> > > > libraries:  `--with-zlib="bundled"  --with-freetype="bundled"
> > > > --with-libjpeg="bundled"  --with-giflib="bundled"
> > > > --withlibpng="bundled"  --with-lcms="bundled"
> > > > --with-harfbuzz="bundled" `
> > > >
> > > > We already made a heavy testing of the behavior, and user should not
> > > > face negative experience. I'm not sure if this is
> > >
> > > I'm very confused on why this reduces certification burden. In our
> > > crypto libraries this is exactly the kind of behavior we would *NOT*
> > > want packages to do because it increases our certification and support
> > > burden.
> > >
> >
> > I'm confused how this would not negatively impact the user experience,
> > because things like FreeType and HarfBuzz in Fedora have features and
> > configuration that are non-default that improve the font rendering
> > capabilities of applications that link to FreeType. I would rather
> > have our shared maintenance and evolution of font stuff be reused in
> > Java too...
> 
> I agree, I don't think there's positives for the user experience here.
> And I don't understand what actual problem this change is trying to
> solve?
> Are people really installing OpenJDK RPM packages, taking the
> "/usr/bin/java" binary, and putting it onto some other system?
> Unless that's really the case (and I don't think that should even ever
> be supported for distro packages), I don't see a reason to change how
> we build OpenJDK.

When the change talks about being "portable", my understanding is that
means within the context of Fedora. eg they want to be able to build the
JDK version in a Fedora 35 build root once, and then ship that built
binary in Fedora 35, Fedora 36 and Fedora rawhide (37) by just tagging
the F35 build into the newer Fedora koji tags too, instead of rebuilding
for each Fedora version.

> Also, I am particularly concerned with this statement from the linked
> follow-up change:
> "After this change is in air, we will certificate each binary only
> once, and redistribute."
> I cannot see how Fedora RPM packages for OpenJDK can redistributing
> pre-built binaries would ever be considered acceptable.

Normally when we talk about forbidding pre-built binaries, it is
because said binaries were built by a 3rd party into whose build
system Fdora has no visibility. This case appears different in
that Fedora is still building the binaries in one release stream,
but these pre-built binarijes are then copied into another
releases stream. Thus Fedora would still have visibility into the
build process, albeit in a rather convoluted  way, compared to
normally maintained package.

One downside with building in F35 and then re-tagging into newer
Fedora releases, is that we loose any insight into problems coming
down the pipe. Currently a Fedora rawhide mass rebuild will often
highlight pre-existing bugs in applications, and/or highlight bugs
in newly rebased GCC toolchain.

If the JDK is only really being built in the oldest stable Fedora
release, then we loose this early detection of problems. If a GCC
rebase has a bug that impacts JDK, we'd potentially only discover
it many many months later once that rawhide becomes the oldest
stable Fedora release, and an attempt is made to build new JDK.

Detecting bugs early in both applications and GCC toolchain, via
builds in rawhide is a really critical aspect of our dev model.
IME rawhide is the place where it is cheapest to fix problems &
least disruptive to our users, because we have time to find and
fix issues before they get into release.

Yes, it is tedious for package maintainers when their specific
app breaks in rawhide due to a toolchain regression, but it is
a win for Fedora as a whole to find these problems quickly.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: 

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Paul Howarth]

On Tue, 10 May 2022 19:36:22 +0200
Florian Weimer  wrote:
> * Vitaly Zaitsev via devel:
> 
> > On 10/05/2022 15:29, Ben Cotton wrote:  
> >> This is initial step to move JDKs to be more like other JDKs, to
> >> build proper transferable images, and to lower certification
> >> burden of each binary.  
> >
> > Strongly -1. Bundled versions are always outdated and may be even
> > vulnerable.  
> 
> And upstream only incorporates security fixes once per quarter, so the
> recent zlib bug (CVE-2018-25032) would have to be reintroduced, or a
> downstream-only patched for it applied.  There was some confusion
> whether this bug only happened with Z_FIXED, but there's been another
> reproducer now.  Given the lack of public discussion (following
> upstream policy), it's not clear whether this has been taken into
> account.

In this case upstream might actually get there first because this CVE
is not yet fixed in Fedora
(https://bugzilla.redhat.com/show_bug.cgi?id=2068066). Of course, this
is unusual.

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

New Fedora Developer Portal release

[Jarek Prokop]

Hi all,

I have just pushed a new minor update for Fedora Developer Portal, it is 
mostly replacing `dnf install` with flatpak counterparts

on orphaned packages (namely arduino and eclipse packages):
  * https://developer.fedoraproject.org/start/hw/arduino/about.html
  * 
https://developer.fedoraproject.org/tech/languages/dotnet/dotnet-ide.html

  * https://developer.fedoraproject.org/tools/eclipse/about.html

Thanks,
Jarek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 10/05/2022 15:29, Ben Cotton wrote:

https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs



Make the normal rpms to not built jdk, but to repack the portable rpms with all 
integration


No way. This violates Fedora policy. All packages **must** be built from 
sources. No exceptions.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL and CentOS specific Requires in spec file

[Vitaly Zaitsev via devel]

On 11/05/2022 00:17, Nico Kadel-Garcia wrote:

%if 0%{?rhel} == 8


"0%{?rhel} == X" or "0%{?rhel} > 8" are okay, but "0%{?rhel} < X" will 
break some things on non-RHEL/EPEL distributions, including Fedora.


Sometimes maintainers forget this behavior after changing the release 
version in a condition. That's why double checks are always preferable.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure