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 cond
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 exceptio
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.fedora
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.
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/JdkInTreeLibsAndStdcl
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 propo
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
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
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 b
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://op
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
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
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_pl
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
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
UR
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 selectin
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 Pyt
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
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 --
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 certifi
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 sti
* 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.
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 t
> 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 expectat
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 t
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
__
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
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
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 product
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
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/
Hi all,
I'm willing to revive python-jenkins-job-builder by updating it to the latest
release 4.0.0 and backporting an upstream patch.
I already have a working Copr build: https://copr.fedorainfracloud.org/coprs/
sicherha/python-jenkins-job-builder/packages/
Bugzilla: https://bugzilla.redhat.com
32 matches
Mail list logo
