https://bugzilla.redhat.com/show_bug.cgi?id=1953146
Bug ID: 1953146
Summary: perl-PDL-2.039 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-PDL
Keywords: FutureFeature, Triaged
On Fri, Apr 23, 2021 at 06:25:21PM +0900, Stephen J. Turnbull wrote:
> Peter Hutterer writes:
>
> > Now that the XorgUtilityDeaggregation [1] is complete, I'm planning to
> > retire a set of old X utilities that I think don't need to be in Fedora:
> >
> > oclock
> > xbiff
> > xload
> >
OLD: Fedora-34-20210423.n.0
NEW: Fedora-34-20210423.n.1
= SUMMARY =
Added images:2
Dropped images: 3
Added packages: 0
Dropped packages:0
Upgraded packages: 18
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size
On 4/23/2021 6:37 PM, Tom Stellard wrote:
On 4/23/21 4:55 PM, Kevin Kofler via devel wrote:
Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
Is the change owners' plan here to resubmit this same rejected change
for
every single release until people get so fed up that
On 4/23/21 4:55 PM, Kevin Kofler via devel wrote:
Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
Is the change owners' plan here to resubmit this same rejected change for
every single release until people get so fed up that they end up approving
it just to get it out
Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
Is the change owners' plan here to resubmit this same rejected change for
every single release until people get so fed up that they end up approving
it just to get it out of the way?
Sorry, but resubmitting a rejected
No missing expected images.
Failed openQA tests: 3/189 (x86_64), 1/127 (aarch64)
ID: 867939 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/867939
ID: 867955 Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL:
* Gary Buhrmaster:
> For C/C++ projects:
>
> If the upstream has no stated preference for the compiler, the
>packager SHOULD use the system default compiler (i.e. GCC).
>
> If the upstream specifies a preference, in their documentation,
>build, or support processes, the packager SHOULD
No missing expected images.
Failed openQA tests: 3/189 (x86_64), 7/127 (aarch64)
New failures (same test not failed in Fedora-34-20210422.n.0):
ID: 867630 Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/867630
ID: 867673 Test: aarch64
The Fedora 34 Final RC1.2 compose [1] is GO and will be shipped live
on Tuesday, 27 April 2021.
For more information please check the Go/No-Go meeting minutes [2] or logs [3].
Thank you to everyone who has worked on this on-time release.
[1] https://dl.fedoraproject.org/pub/alt/stage/34_RC-1.2/
The Fedora 34 Final RC1.2 compose [1] is GO and will be shipped live
on Tuesday, 27 April 2021.
For more information please check the Go/No-Go meeting minutes [2] or logs [3].
Thank you to everyone who has worked on this on-time release.
[1] https://dl.fedoraproject.org/pub/alt/stage/34_RC-1.2/
Hi,
Just a quick update on an OpenVPN update which was released this week.
Fedora packages are in the release pipe, but needs to get some karma to
move on quicker. Since this issue is critical, I'm adding an additional
notice here.
The TL;DR version:
OpenVPN 2.5.1 and earlier
On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> The Red Hat tools team believes that LLVM/Clang and GCC should be
> considered equals from
> a Fedora policy standpoint. Selection of one toolchain over the other should
> be
> driven by the packager's preferences not by Fedora
On 23.04.2021 17:18, Ben Cotton wrote:
The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.
+1 for this change.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list
https://bugzilla.redhat.com/show_bug.cgi?id=1952976
Bug ID: 1952976
Summary: perl-List-AllUtils-0.19 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-List-AllUtils
Keywords: FutureFeature, Triaged
On 4/23/21 9:44 AM, Björn Persson wrote:
The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:
%bcond_with toolchain_clang
%bcond_with toolchain_gcc
[...]
Note this change is only for compiler
On 4/23/21 12:52 PM, Tom Stellard wrote:
On 4/23/21 9:38 AM, Robert Marcano via devel wrote:
On 4/23/21 11:18 AM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the
No missing expected images.
Failed openQA tests: 3/15 (aarch64)
New failures (same test not failed in Fedora-IoT-34-20210422.0):
ID: 868197 Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/868197
ID: 868202 Test: aarch64 IoT-dvd_ostree-iso
On 4/23/21 9:38 AM, Robert Marcano via devel wrote:
On 4/23/21 11:18 AM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM. This
On 4/23/21 9:27 AM, Qiyu Yan wrote:
在 2021-04-23星期五的 11:18 -0400，Ben Cotton写道：
The policy update will also recommend that packagers use standardized
macro names when using conditional options to control the compiler
choice:
%bcond_with toolchain_clang
%bcond_with toolchain_gcc
replacing
On Fri, Apr 23, 2021 at 3:57 PM Daniel P. Berrangé wrote:
> This is quite a niche problem that's unlikely to cause issues
> for most people, but its a illustration that swapping compilers
> out can have unexpected consequences/complications.
Presuming I am remembering my s390x history
On 4/23/2021 9:57 AM, Daniel P. Berrangé wrote:
On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy == Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported
> The policy update will also recommend that packagers use standardized
> macro names when using conditional options to control the compiler
> choice:
>
> %bcond_with toolchain_clang
> %bcond_with toolchain_gcc
[...]
> Note this change is only for compiler selection. It does not change
>
On 4/23/21 8:57 AM, Daniel P. Berrangé wrote:
On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported
On 4/23/21 11:18 AM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM. This
change proposal replaces that policy with one where,
On 4/23/2021 10:32 AM, Tom Stellard wrote:
On 4/23/21 8:27 AM, Ben Cotton wrote:
On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton wrote:
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the
On 4/23/21 8:37 AM, Gary Buhrmaster wrote:
On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CompilerPolicy
Ultimately, I think what the packaging guidelines should be if
the proposal is accepted are essentially:
For C/C++ projects:
If the
On 4/23/21 8:37 AM, Neal Gompa wrote:
On Fri, Apr 23, 2021 at 11:19 AM Ben Cotton wrote:
An example of a package that could benefit from this policy is
Firefox. Upstream, the Firefox project builds primarily with
Clang/LLVM. Yet we force the Fedora package owner to find and fix
issues
On Fri, Apr 23, 2021 at 12:32 PM Tom Stellard wrote:
> The proposed changes[1] to the packaging guidelines does require packagers
> document their reasons in bugzilla, but that's it.
>
At the risk of getting too bikesheddy, wouldn't it be better to
document it in the spec file? It seems like
On 4/23/21 8:27 AM, Ben Cotton wrote:
On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton wrote:
change proposal replaces that policy with one where, given a good
technical reason, a packager may:
* Choose to build with their package with clang even if the upstream
project supports gcc.
* Choose to
在 2021-04-23星期五的 11:18 -0400，Ben Cotton写道：
> The policy update will also recommend that packagers use standardized
> macro names when using conditional options to control the compiler
> choice:
>
> %bcond_with toolchain_clang
> %bcond_with toolchain_gcc
replacing current
%global toolchain clang
On Fri, Apr 23, 2021 at 3:38 PM Neal Gompa wrote:
> To me, this sounds like an excuse to avoid doing the right thing and
> leveraging the toolchain that offers the highest quality code
> generation (performance, security, etc.).
I am not in favor of switching the distro (or any
package) to the
On Fri, Apr 23, 2021 at 07:40:14AM +0200, Miroslav Suchý wrote:
> I have been using 2FA with the new Fedora Account system and the UX is ...
> can be improved. The question is how?
...snip...
I am pretty sure the IPA folks are aware that this can be improved and
are working on it. Hopefully one
Hi,
On 4/23/21 5:37 PM, Gary Buhrmaster wrote:
> On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton wrote:
>>
>> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>>
>
> Ultimately, I think what the packaging guidelines should be if
> the proposal is accepted are essentially:
>
>
>
> For C/C++
On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
> == Summary ==
> Fedora has historically forced packages to build with GCC unless the
> upstream project for the package only supported Clang/LLVM. This
> change proposal
First, it looks like the ELN composes have been broken for a while.
It's failing on "Cant locate template for uri 'runtime-install.tmpl'"[1]
but lorax-templates-generic is installed.[2]
I'm at a loss on this one.
Second, I thought we were shifting ELN Composes to just be once a day. It
looks
On Fri, Apr 23, 2021 at 3:30 PM Ben Cotton wrote:
> Or is it just a way of saying "we trust you to exercise good judgment"?
If one does not trust the packagers good
judgement you likely have a bigger
issue to address.
I doubt many packagers are going to
change from the default compiler
unless
On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
Ultimately, I think what the packaging guidelines should be if
the proposal is accepted are essentially:
For C/C++ projects:
If the upstream has no stated preference for the
On Fri, Apr 23, 2021 at 11:19 AM Ben Cotton wrote:
>
> An example of a package that could benefit from this policy is
> Firefox. Upstream, the Firefox project builds primarily with
> Clang/LLVM. Yet we force the Fedora package owner to find and fix
> issues building with GCC then either carry
On Fri, Apr 23, 2021 at 11:18 AM Ben Cotton wrote:
>
> change proposal replaces that policy with one where, given a good
> technical reason, a packager may:
> * Choose to build with their package with clang even if the upstream
> project supports gcc.
> * Choose to build with gcc even if upstream
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM. This
change proposal replaces that policy with one where, given a good
technical reason, a packager
https://fedoraproject.org/wiki/Changes/CompilerPolicy
== Summary ==
Fedora has historically forced packages to build with GCC unless the
upstream project for the package only supported Clang/LLVM. This
change proposal replaces that policy with one where, given a good
technical reason, a packager
https://bugzilla.redhat.com/show_bug.cgi?id=1952877
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1952766
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
jplesnik merged a pull-request against the project: `perl-File-ReadBackwards`
that you are following.
Merged pull-request:
``
Tests
``
https://src.fedoraproject.org/rpms/perl-File-ReadBackwards/pull-request/1
___
perl-devel mailing list --
jplesnik opened a new pull-request against the project:
`perl-File-ReadBackwards` that you are following:
``
Tests
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-File-ReadBackwards/pull-request/1
___
perl-devel mailing list
https://bugzilla.redhat.com/show_bug.cgi?id=1952877
--- Comment #1 from Petr Pisar ---
Some features removed. Suitable only for Rawhide.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list --
No missing expected images.
Compose FAILS proposed Rawhide gating check!
23 of 43 required tests failed, 17 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 104/189 (x86_64), 60/127 (aarch64)
New failures (same test not
https://bugzilla.redhat.com/show_bug.cgi?id=1952877
Petr Pisar changed:
What|Removed |Added
Status|NEW |ASSIGNED
OLD: Fedora-34-20210422.n.0
NEW: Fedora-34-20210423.n.0
= SUMMARY =
Added images:0
Dropped images: 2
Added packages: 0
Dropped packages:0
Upgraded packages: 5
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of upgraded
https://bugzilla.redhat.com/show_bug.cgi?id=1952766
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |ASSIGNED
According to the schedule [1], Fedora 34 Candidate RC-1.2 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan
Test coverage information for the
https://bugzilla.redhat.com/show_bug.cgi?id=1952877
Bug ID: 1952877
Summary: perl-Prima-1.61 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Prima
Keywords: FutureFeature, Triaged
Hello Lukas.
I have noticed that spinner component run when we are calling LOAD_DATA for
LandingPage component but not when we are loading LOAD_WIZARD_DATA for WIZARD
component. I like to implement this feature.
But I have some problem because we are using this.props.stable === 0 for
OLD: Fedora-Rawhide-20210422.n.0
NEW: Fedora-Rawhide-20210423.n.0
= SUMMARY =
Added images:1
Dropped images: 1
Added packages: 3
Dropped packages:1
Upgraded packages: 76
Downgraded packages: 1
Size of added packages: 34.44 MiB
Size of dropped packages
Peter Hutterer writes:
> Now that the XorgUtilityDeaggregation [1] is complete, I'm planning to
> retire a set of old X utilities that I think don't need to be in Fedora:
>
> oclock
> xbiff
> xload
> xman
> xrefresh
> xlogo
> xpr
> xfd
> viewres
> listres
> xconsole
Wow. Can't
Happy Friday everyone!
We just wanted to give you a brief update that we successfully started
the Fedora Source-git SIG [1] yesterday via our first SIG meeting [2].
As this was our first contact, we did mostly introductions, talked
about the SIG setup and finally touched a bit on the topic of
On 23. 04. 21 7:40, Miroslav Suchý wrote:
I have been using 2FA with the new Fedora Account system and the UX is ... can
be improved. The question is how?
If you are not using 2FA yet then you may not know what I am talking about.
Here:
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-33-20210422.0):
ID: 866805 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL:
On Friday, April 23, 2021 7:40:14 AM CEST Miroslav Suchý wrote:
> I have been using 2FA with the new Fedora Account system and the UX is ...
> can be improved. The question is how?
>
> If you are not using 2FA yet then you may not know what I am talking about.
> Here:
>
>
https://fedorapeople.org/groups/389ds/ci/nightly/2021/04/23/report-389-ds-base-2.0.4-20210423git4559a89c0.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
61 matches
Mail list logo
