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://fedoraproject.
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: https://op
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:
https://fedoraproject.org/wiki/Infrastructure/Kerberos#C
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
sou
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 arg
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
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 curr
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
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 faile
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
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
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 th
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 compiler,
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 t
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 like
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 replace
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++ pr
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 o
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 c
在 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
o
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 bu
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 that
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 buildi
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 upstream
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 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, g
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 Clan
> 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
> existi
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 C
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
correctly,
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 curren
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
c
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 podman
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
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 selectio
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 --
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 specifi
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 versions
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/
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 Serv
* 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 fol
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: https://openqa.fedoraproj
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 cha
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 o
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
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 of
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
> > xma
Missing expected images:
Xfce raw-xz armhfp
Failed openQA tests: 5/189 (x86_64), 6/127 (aarch64)
New failures (same test not failed in Fedora-34-20210423.n.0):
ID: 868532 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/868532
ID: 868579
48 matches
Mail list logo
