[Heads up] Fedora Container base image is getting smaller

[Clement Verna]

Hi all,

The Container SIG has been busy in the last few weeks working on
getting the Fedora container base image smaller (It was growing over
300MB). While a few minor changes [0-1] have recently landed in the
fedora:latest and fedora:rawhide images.

Last couple days a bigger change [2] have been introduced in the
fedora:rawhide image. This change drops all the weak dependencies from
the base image which allowed us to have a smaller base image (215MB).

Currently the plan is to keep this change in fedora:rawhide and wait
for Fedora 31 GA to propagate to the change to the fedora:latest
image. If you are currently using the fedora:latest image I would
encourage you to give a try using
registry.fedoraproject.org/fedora:rawhide as a base image since you
might need to adjust your Dockerfile if you were depending on some of
the weak dependencies.

If you think that a package should be added or removed from the base
image please file a ticket to the Container SIG tracker [3].

Also if you are interested to help improve the Fedora Container base
image in general you can join the Container SIG [4].

Thanks and Happy Containerization,
Clément


[0] - https://pagure.io/fedora-kickstarts/pull-request/535
[1] - https://pagure.io/fedora-kickstarts/pull-request/536
[2] - https://pagure.io/fedora-kickstarts/pull-request/551
[3] - https://teams.fedoraproject.org/project/cverna-container-sig/issues
[4] - https://teams.fedoraproject.org/project/cverna-container-sig/wiki/home
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Frank R Dana Jr.]

> Le mar. 23 juil. 2019 à 08:30, Igor Gnatenko
> > * Define new architecture in RPM/libsolv (let's call it "haswell" or
>> "x86_64modern")
> x86_64avx2 ? or even avx2 ?

SOMETHING, though. I can't be the only one here old enough to remember when 
Linux packages came in .i386, .i486, .i586, and then .i686 flavors. And then 
gradually the earlier generations were dropped off, and it was all just .i686. 
(Which some distros merged back into .i386 — a mistake, IMHO — while others 
kept as .i686.)

Doing this split, as much work as it would be on the infrastructure side, would 
also give us the numbers everyone is clamoring for. We could observe actual 
download/install rates for both arches, and pull the plug on legacy .x86_64 
when the time is right, just as it was done with .i686.

Because if something isn't going to run on even some CURRENT x86_64 processors 
being sold, calling it "x86_64" is just wrong, just like calling Pentium-only 
packages "i386" was.
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Thomas Daede]

On 7/23/19 7:52 AM, Andrew Lutomirski wrote:
> 
> In the interest of a productive discussion, could we maybe focus on what
> the benefits are, both of changing the baseline in general and of
> enabling any particular features?

As someone whose software heavily depends on SSE and AVX2 assembly code,
we always do runtime detection. The SSE2 baseline of x86_64 is handy as
there are a few things I can inline as a result, but there is no
performance benefit to an AVX2 baseline, other than possibly the binary
size dropping a bit as it no longer has to include the SSE2 versions of
the functions.
___
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

[389-devel] 389 DS nightly 2019-07-24 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/07/24/report-389-ds-base-1.4.1.6-20190723git9ea5b9b.fc30.x86_64.html
___
389-devel mailing list -- 389-de...@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-de...@lists.fedoraproject.org

[Bug 1729858] Upgrade perl-BSON to 1.12.0

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-BSON-1.12.0-1.fc31 |perl-BSON-1.12.0-1.fc31
   |perl-BSON-1.12.0-1.fc30 |perl-BSON-1.12.0-1.fc30
   ||perl-BSON-1.12.0-1.fc29



--- Comment #7 from Fedora Update System  ---
perl-BSON-1.12.0-1.fc29 has been pushed to the Fedora 29 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1729860] Upgrade perl-IPC-Cmd to 1.04

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-IPC-Cmd-1.04-1.fc31|perl-IPC-Cmd-1.04-1.fc31
   |perl-IPC-Cmd-1.04-1.fc30|perl-IPC-Cmd-1.04-1.fc30
   ||perl-IPC-Cmd-1.04-1.fc29



--- Comment #7 from Fedora Update System  ---
perl-IPC-Cmd-1.04-1.fc29 has been pushed to the Fedora 29 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

Request to take ownership of gimp-resynthetizer

[Luya Tshimbalanga]

Following the bug report[1], I would like to take ownership of
gimp-resynthetizer because of its use on Fedora Design Suite Labs. Would
it be possible to orphan that package?


Reference

--

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1674969

Luya

___
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

[Bug 1729860] Upgrade perl-IPC-Cmd to 1.04

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-IPC-Cmd-1.04-1.fc31|perl-IPC-Cmd-1.04-1.fc31
   ||perl-IPC-Cmd-1.04-1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-07-24 00:58:25



--- Comment #6 from Fedora Update System  ---
perl-IPC-Cmd-1.04-1.fc30 has been pushed to the Fedora 30 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[Bug 1729858] Upgrade perl-BSON to 1.12.0

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-BSON-1.12.0-1.fc31 |perl-BSON-1.12.0-1.fc31
   ||perl-BSON-1.12.0-1.fc30
 Resolution|--- |ERRATA
Last Closed||2019-07-24 00:58:24



--- Comment #6 from Fedora Update System  ---
perl-BSON-1.12.0-1.fc30 has been pushed to the Fedora 30 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

Re: portable performance engineering (was: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update)

[Kevin Kofler]

Dave Love wrote:
> they'd be rather limited by the compiler options we're supposed to use,
> that don't include vectorization, so you don't even get the benefit you
> could from SSE2.  (I've been told off in review for turning that on,
> though an FPC member has approved it.)

Why don't we enable -ftree-vectorize by default?

> However, hwcaps won't help for programs with no separate library
> performance component; Gromacs is an example.  On a heterogeneous HPC
> system you need multiple parallel-installable versions with a convention
> for the paths they'll be on.

As I wrote elsewhere in this huge thread: just turn the program into a 
library with a dummy main program.

> There's already multi-simd support for ATLAS -- though I know no good
> reason to ATLAS

You mean the atlas-* subpackages that one has to manually install? That's 
actually one big reason to NOT use ATLAS, now that we have OpenBLAS that 
does it right.

> and at least one package (libxsmm) has a minimum requirement of SSE3
> without complaint.  (I got that down from SSE4 for the benefit of systems
> we had, though you wouldn't use them for anything CPU-bound.)

Now you have a complaint. :-)

The baseline is SSE2, so the packages are supposed to support systems with 
nothing beyond SSE2. Just waiting until somebody reports the inevitable 
SIGILL is not a nice thing to do.

Now, if upstream doesn't support non-SSE3 CPUs, it might be nontrivial to 
fix the issue. But in principle, a package that requires SSE3 must be 
considered a bug.

Kevin Kofler
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kevin Kofler]

Andrew Lutomirski wrote:
> Features like SSE2: enabling SSE2 as the basic floating point mechanism
> changes the ABI drastically.  But x86_64 already requires SSE2, so this is
> irrelevant.

For what it's worth, only the x86_64 ABI actually makes use of this. For 
i686 (32-bit), even when Fedora moved to requiring SSE2, the ABI was not 
changed (because that would have meant bootstrapping a whole new 
architecture, breaking compatibility with all existing binaries in the 
process). So i686 is stuck with the x87 ABI, copying floating-point data 
back and forth between x87 and SSE registers.

> Things like SSSE3, SSE3, SSE4, AVX1, AVX2, FMA, etc: for the most part,
> these accelerate existing algorithms.  I'm sure that someone somewhere has
> written an algorithm that requires FMA for enhanced precision, but
> otherwise pretty much any code that benefits from any of these features
> would work just fine, if slower, without the features.

FMA can also be emulated in pure software (while still using hardware 
floating-point instructions!), it is even implemented in glibc. So this also 
falls under "would work just fine, if slower, without the features".

> but FSGSBASE is not a credible requirement for Fedora since IIRC it's not
> supported on Sandy Bridge.  Even Intel seems to consider Sandy Bridge to
> be an important CPU to support.

AVX2 is also not supported on Sandy Bridge.

> I think that, for vector extensions, Fedora shouldn't require anything
> beyond SSE2 for basic functionality.  Instead, Fedora should figure out
> where there are material benefits to using them and find ways to make it
> easier for packagers to make them available.  Ideally this would all be
> figured out at runtime,

I agree.

> but install-time choices could make sense, too.

I think we should just do it right and figure it out at runtime. Otherwise, 
the user ends up having to manually install things such as those infamous 
atlas-sse* subpackages, and most users will not bother doing that, or even 
not even know that they exist or at least which one to pick.

Kevin Kofler
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Neal Gompa]

On Tue, Jul 23, 2019 at 7:14 PM Kevin Kofler  wrote:
>
> Peter Robinson wrote:
> > The problem with that is getting someone to do the work. The whole
> > reason that the i686 kernel was retired was due to people not stepping
> > up to do the maintenance of the kernel, and the kernel alone. Having
> > been one of the few people in the community that's been involved in
> > and lead arch bring ups and maintained architectures in the bad old
> > days of secondary koji instances and continue to lead the ARMv7 and
> > aarch64 architectures I can tell you it's not an insignificant amount
> > of work, both the initial boot strap and ongoing maintenance. I've
> > been involved in the alternate architecture projects in Fedora for ~
> > 9.5 years and it's a LOT of work and it's not a do it once and it's
> > done, it's constant and ongoing.
>
> Well, to be fair, the initial bootstrapping wouldn't be that big an issue
> because the bootstrap for x86_64+AVX2 would just be a copy of the normal
> x86_64, which would then be gradually replaced by mass rebuilds.
>

Yep. This is how OpenMandriva bootstrapped the AMD Ryzen optimized
build. Their path also involved declaring a new architecture ("znver1"
is currently unknown to upstream rpm, libsolv, dnf, etc.).

> The bigger issue is the resource overhead, and especially the scarce
> resource that is time humans have to spend for debugging.
>

Right. The other thing to keep in mind is that this is only slightly
less scarce than distro developer friendly ARM hardware. At least for
the proposed architecture, most of us don't have the hardware to use
it. Regardless of the willingness of humans, most of us aren't going
to spend literally thousands of dollars to get new PCs that have the
necessary instructions. Many of us are likely not able to afford it,
and those who can are also mindful of how much waste that causes and
may not do it anyway.



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: are the ppc64le builders healthy?

[Kevin Fenzi]

On 7/23/19 11:36 AM, Jason L Tibbitts III wrote:
>> "KK" == Kaleb Keithley  writes:
> 
> KK> I built the latest ceph-14 (14.2.2) on rawhide successfully two days
> KK> ago.  Two different builds on f30 built or are building fine on
> KK> x86_64, i686, and aarch64, but failed with different errors on
> KK> ppc64le at different places in the build.  One looks like it ran out
> KK> of space in the file system. The other may have been OOM killed (?).
> 
> There was just a bit of talk about this in IRC.  The issue seems to be
> that the CPU count of the PPC64le builders was bumped from 4 to 12, but
> the amount of memory was unchanged at 10GB RAM/2GB swap.  This could
> potentially cause resource exhaustion.
> 
> Seems they've now been bumped to 22GB of RAM, which should help with OOM
> issues but probably not with disk space issues.

Right. Please file a ticket or let us know if you hit the disk issue again.

kevin




signature.asc
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

Nonreponsive maintainer check for moezroy (system-config-users)

[Miro Hrončok]

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

Anyone knows how to contact Moez?
--
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kevin Kofler]

Peter Robinson wrote:
> The problem with that is getting someone to do the work. The whole
> reason that the i686 kernel was retired was due to people not stepping
> up to do the maintenance of the kernel, and the kernel alone. Having
> been one of the few people in the community that's been involved in
> and lead arch bring ups and maintained architectures in the bad old
> days of secondary koji instances and continue to lead the ARMv7 and
> aarch64 architectures I can tell you it's not an insignificant amount
> of work, both the initial boot strap and ongoing maintenance. I've
> been involved in the alternate architecture projects in Fedora for ~
> 9.5 years and it's a LOT of work and it's not a do it once and it's
> done, it's constant and ongoing.

Well, to be fair, the initial bootstrapping wouldn't be that big an issue 
because the bootstrap for x86_64+AVX2 would just be a copy of the normal 
x86_64, which would then be gradually replaced by mass rebuilds.

The bigger issue is the resource overhead, and especially the scarce 
resource that is time humans have to spend for debugging.

Kevin Kofler
___
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

Re: Rolling out Phase I of rawhide package gating

[Tom Hughes]

On 23/07/2019 21:51, Pierre-Yves Chibon wrote:


When you run `fedpkg build` on Rawhide, your package will be built in a new koji
tag (which will be the default target for Rawhide). The package will be picked
up from this koji tag, signed and moved onto a second tag. Bodhi will be
notified by koji once this new build is signed and will automatically create an
update for it (you will be notified about this by email by bodhi directly) with
a “Testing” status. If the package maintainer has not opted in into the CI
workflow, the update will be pushed to “Stable” and the build will be pushed
into the regular Rawhide tag, making it available in the Rawhide buildroot, just
as it is today.


Do we have an estimate of how much extra latency this is likely to add
both with and without gating enabled? ie how much more delay there is
likely to be before new builds are available?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

Re: Rolling out Phase I of rawhide package gating

[Matthew Miller]

On Tue, Jul 23, 2019 at 10:51:28PM +0200, Pierre-Yves Chibon wrote:
> TL;DR: On July 24th we will turn on the first phase of Rawhide package gating,

This is very exciting! I suppose I'll not jinx things by congratulating too
soon, but this is great work and huge news.



-- 
Matthew Miller

Fedora Project Leader
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Matthew Miller]

On Tue, Jul 23, 2019 at 09:50:17PM +0200, Kevin Kofler wrote:
> > I would suggest that there is this nebulous thing called "the cloud"
> > that mitigates a small part of that, but I also fully understand using
> > that magical machine resource presents its own challenges.
> As the FSF puts it: "There is no cloud, just other people's computers."

Yes, and that's not necessarily always bad. In this case, it's exactly the
point.

-- 
Matthew Miller

Fedora Project Leader
___
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

Rolling out Phase I of rawhide package gating

[Pierre-Yves Chibon]

Good Morning Everyone,

TL;DR: On July 24th we will turn on the first phase of Rawhide package gating,
for single build updates.
In a later phase, Rawhide updates that contain multiple builds will also be
enabled for gating. Our goal is to improve our ability to continuously turn out
a useful Fedora OS. So we hope and expect to get opt-in from as many Fedora
package maintainers as possible, including maintainers of the base OS. But this
phase of gating remains opt-in, and should not affect packagers who choose for
now not to opt in.


Last April FESCo approved a change proposal[1] allowing to gate Rawhide packages
based on test results. The proposal included gating updates with only a single
build as well as updates with multiple builds. It was designed to cause minimal
to no interference with the current workflow of packagers who do not opt-in.

The team has been working hard on this proposal, and decided to do a phased
roll-out of this change, so that we can gather feedback as early as possible
from the packagers interested in testing this workflow without impacting
everyone.

On July 24th, we plan to turn on the first phase of this change.



What does it mean for us as packagers?
--

When you run `fedpkg build` on Rawhide, your package will be built in a new koji
tag (which will be the default target for Rawhide). The package will be picked
up from this koji tag, signed and moved onto a second tag. Bodhi will be
notified by koji once this new build is signed and will automatically create an
update for it (you will be notified about this by email by bodhi directly) with
a “Testing” status. If the package maintainer has not opted in into the CI
workflow, the update will be pushed to “Stable” and the build will be pushed
into the regular Rawhide tag, making it available in the Rawhide buildroot, just
as it is today.

If the package maintainer has opted in into the CI workflow, the creation of the
update will trigger the CI pipeline which will send its results to resultsdb,
triggering greenwave to evaluate if all the required tests have passed or not,
thus allowing the update to go through the gate or not.


This is the first roll-out of this gating change, and so there may be additional
tuning and fixes until things are as smooth as we want them to be. With this
release we are looking for feedback on what can be improved. We have a dedicated
team working on this project and we will be taking your feedback into account to
improve the experience.


Small FAQ:
--
But I do not want to use gating!
While we believe CI and gating will ultimately help making a better Fedora,
there is nothing enforced at this point. Keep packaging as you do now!

How do I enroll?
Great! We’re glad to see such enthusiasm! You can find the instruction in the
docs on how to enable gating: https://docs.fedoraproject.org/en-US/ci/gating/

It does not work!
Bugs will be bugs. This is the first roll-out of this change, and more will
come. This rollout lets us gather feedback and iterate on the approach in an
open source fashion.
If you did not opt-in and you can’t do your packaging work as you used to,
please file a infrastructure ticket, since it’s likely a bug:
https://pagure.io/fedora-infrastructure/new_issue?title=[CI]
If you did opt-in and something in the gating of your update doesn’t work (for
example, CI ran but its results aren’t being considered, waiving didn’t work…),
file an infrastructure ticket:
https://pagure.io/fedora-infrastructure/new_issue?title=[CI]
If you opted-in and the tests don’t run the way you expect, file a fedora-ci
ticket: https://pagure.io/fedora-ci/general/new_issue

I enrolled but now I want to step out for some reasons
:sad trombone:
We hope you reported all the issues you’ve found/faced and are helping us
resolving them.
In the meanwhile, you can simply remove the gating.yaml file you’ve added in
your git repo and that should be enough to make greenwave ignore your package.

Want to know more? Your question isn’t here? Check our documentation on
rawhide gating: https://docs.fedoraproject.org/en-US/rawhide-gating/ [2]
We’ll keep it up to date as we face or solve questions.


Pierre
For the Rawhide package gating team

[1] https://pagure.io/fesco/issue/2102

[2] At the time of writing this, it looks like the website is having some
difficulties build the new version of the docs. This should get resolved in the
coming hours, sorry for the inconvenience.
(If only it had CI... :-))


signature.asc
Description: PGP signature
___
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: 

Rolling out Phase I of rawhide package gating

[Pierre-Yves Chibon]

Good Morning Everyone,

TL;DR: On July 24th we will turn on the first phase of Rawhide package gating,
for single build updates.
In a later phase, Rawhide updates that contain multiple builds will also be
enabled for gating. Our goal is to improve our ability to continuously turn out
a useful Fedora OS. So we hope and expect to get opt-in from as many Fedora
package maintainers as possible, including maintainers of the base OS. But this
phase of gating remains opt-in, and should not affect packagers who choose for
now not to opt in.


Last April FESCo approved a change proposal[1] allowing to gate Rawhide packages
based on test results. The proposal included gating updates with only a single
build as well as updates with multiple builds. It was designed to cause minimal
to no interference with the current workflow of packagers who do not opt-in.

The team has been working hard on this proposal, and decided to do a phased
roll-out of this change, so that we can gather feedback as early as possible
from the packagers interested in testing this workflow without impacting
everyone.

On July 24th, we plan to turn on the first phase of this change.



What does it mean for us as packagers?
--

When you run `fedpkg build` on Rawhide, your package will be built in a new koji
tag (which will be the default target for Rawhide). The package will be picked
up from this koji tag, signed and moved onto a second tag. Bodhi will be
notified by koji once this new build is signed and will automatically create an
update for it (you will be notified about this by email by bodhi directly) with
a “Testing” status. If the package maintainer has not opted in into the CI
workflow, the update will be pushed to “Stable” and the build will be pushed
into the regular Rawhide tag, making it available in the Rawhide buildroot, just
as it is today.

If the package maintainer has opted in into the CI workflow, the creation of the
update will trigger the CI pipeline which will send its results to resultsdb,
triggering greenwave to evaluate if all the required tests have passed or not,
thus allowing the update to go through the gate or not.


This is the first roll-out of this gating change, and so there may be additional
tuning and fixes until things are as smooth as we want them to be. With this
release we are looking for feedback on what can be improved. We have a dedicated
team working on this project and we will be taking your feedback into account to
improve the experience.


Small FAQ:
--
But I do not want to use gating!
While we believe CI and gating will ultimately help making a better Fedora,
there is nothing enforced at this point. Keep packaging as you do now!

How do I enroll?
Great! We’re glad to see such enthusiasm! You can find the instruction in the
docs on how to enable gating: https://docs.fedoraproject.org/en-US/ci/gating/

It does not work!
Bugs will be bugs. This is the first roll-out of this change, and more will
come. This rollout lets us gather feedback and iterate on the approach in an
open source fashion.
If you did not opt-in and you can’t do your packaging work as you used to,
please file a infrastructure ticket, since it’s likely a bug:
https://pagure.io/fedora-infrastructure/new_issue?title=[CI]
If you did opt-in and something in the gating of your update doesn’t work (for
example, CI ran but its results aren’t being considered, waiving didn’t work…),
file an infrastructure ticket:
https://pagure.io/fedora-infrastructure/new_issue?title=[CI]
If you opted-in and the tests don’t run the way you expect, file a fedora-ci
ticket: https://pagure.io/fedora-ci/general/new_issue

I enrolled but now I want to step out for some reasons
:sad trombone:
We hope you reported all the issues you’ve found/faced and are helping us
resolving them.
In the meanwhile, you can simply remove the gating.yaml file you’ve added in
your git repo and that should be enough to make greenwave ignore your package.

Want to know more? Your question isn’t here? Check our documentation on
rawhide gating: https://docs.fedoraproject.org/en-US/rawhide-gating/ [2]
We’ll keep it up to date as we face or solve questions.


Pierre
For the Rawhide package gating team

[1] https://pagure.io/fesco/issue/2102

[2] At the time of writing this, it looks like the website is having some
difficulties build the new version of the docs. This should get resolved in the
coming hours, sorry for the inconvenience.
(If only it had CI... :-))


signature.asc
Description: PGP signature
___
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: 

Re: Discussion around app retirements and categorizations by the CPE team

[Adam Williamson]

On Tue, 2019-07-23 at 09:32 +0300, Alexander Bokovoy wrote:
> 
> > I'd suggest we do what we do all over the place: carry patches as
> > necessary. It sucks, and rebasing is non-trivial work, but I would argue
> > it's not nearly as much work as rebuilding everything from scratch.
> > That's like forking a project, but deleting all the code you forked
> > before you begin.
> 
> I think there is a logical mistake in the above statement because we
> aren't starting from scratch here. We have pagure.io and ipsilon and a
> lot of other applications already. They have a lot of deployments that
> proved themselves.

> What we faced with is a bit where adding new features to them means a
> need to find new contributors to share the load.

Not just that. AIUI, there are significant issues with scaling for
Pagure. It wasn't really initially designed to be very scalable, so now
we have bigger and bigger instances of it and more and more people
throwing in pull requests and issues and things, it's getting pretty
creaky. Pingou and Patrick are working on this, AIUI, but it's not an
*easy* problem to solve.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: Discussion around app retirements and categorizations by the CPE team

[Emmanuel Seyman]

* Nicolas Mailhot via devel [23/07/2019 11:51] :
>
> That is not true. Search the list archive for Michael Zhang’s questions on
> how to get Open Liberty in Fedora. About 4 months later, can anyone do a dnf
> install open liberty, pointing to a Fedora repo?

No but that's probably because he got several comments on his review request
and hasn't replied to them (his last comment on the bug[1] was in February).

Emmanu
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kevin Kofler]

Igor Gnatenko wrote:
> From what I saw, openblas does not do any runtime detection. You
> either compile it with avx2 or not. And in runtime it will check
> whether it was enabled during compilation and use some kind of
> fallback.

If built with the DYNAMIC_ARCH option, which is the case in the Fedora 
packages, OpenBLAS actually compiles its routines several times, for many 
different architectures it supports (even some with the same instruction 
sets, but different performance characteristics), and then picks whatever is 
best according to the runtime CPUID information.

>> We already have 2 such mechanisms:
>> * several upstream software packages check CPUID directly. See, e.g., how
>>   OpenBLAS does it. Or the performance-sensitive parts of Chromium. Etc.
> 
> You can't do several things with this, like FMA.

Sure you can! OpenBLAS actually also checks for both FMA variants (FMA3 and 
FMA4) during the runtime detection. The routines for the CPUs that support 
FMA also make use of it.

> You are talking about libraries while I am talking about binaries.

Then just build the binary as a library, twice, and make a dummy main 
program that links to the library. (See also the "kdeinit hack", which 
does/did something similar for different reasons.)

Kevin Kofler
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Ben Cotton]

On Tue, Jul 23, 2019 at 3:48 PM Kevin Kofler  wrote:
>
> What "wider aspects" would you want to consider? What implications other
> than technical matter for a technical decision such as this one?
>
This is much larger than a technical decision. There are big impacts,
as we've seen, on who can use Fedora if we implement the change as
proposed.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kevin Kofler]

Josh Boyer wrote:
> I would suggest that there is this nebulous thing called "the cloud"
> that mitigates a small part of that, but I also fully understand using
> that magical machine resource presents its own challenges.

As the FSF puts it: "There is no cloud, just other people's computers."

Kevin Kofler
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kevin Kofler]

Josh Boyer wrote:
> I think too often we focus on the technical implications (performance
> gain, etc) and sometimes don't consider wider aspects.

What "wider aspects" would you want to consider? What implications other 
than technical matter for a technical decision such as this one?

Kevin Kofler
___
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

Re: Fedora-Rawhide-20190722.n.1 compose check report

[Adam Williamson]

On Tue, 2019-07-23 at 04:15 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Compose FAILS proposed Rawhide gating check!
> 24 of 47 required tests failed, 19 results missing
> openQA tests matching unsatisfied gating requirements shown with **GATING** 
> below
> Unsatisfied gating requirements that could not be mapped to openQA tests:
> FAILED: compose.cloud.all
> MISSING: fedora.universal.i386.64bit - 
> compose.install_repository_http_graphical
> MISSING: fedora.universal.i386.64bit - compose.install_scsi_updates_img
> 
> Failed openQA tests: 78/147 (x86_64), 1/2 (arm)
> 
> New failures (same test not failed in Fedora-Rawhide-20190721.n.0):

For this and 0723.n.0: anaconda changed so that the user and root
password spokes are now on the main hub, not the 'during installation'
hub. This broke almost all the openQA tests. Never a dull moment around
here!

I'm testing a tweak to the tests that handles this change on staging
ATM. If it works out OK I'll re-run the tests in production and send
out updated reports.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: Discussion around app retirements and categorizations by the CPE team

[Gordon Messmer]

On 7/23/19 4:18 AM, Neal Gompa wrote:

Also, for $DAYJOB, I run a GitLab server. If you think maintaining a
GitLab server is easy, you have another think coming.



For what it's worth: I'm afraid I have to agree.  I've been running 
Gitlab for my employer for the last 18 months.  It's *incredibly* 
labor-intensive.  There are lots of bugs.  Things change in unexpected 
ways which creates a lot of user tickets. There's no published 
documentation on sharding, so scaling the application out is 
challenging.  Most of the UI functionality is async and queued in 
memory, and can be silently lost relatively easily.


Of course, I can see that running Gitlab probably requires fewer 
man-hours than developing a new product and then running that. But, it 
sounds like Fedora would need a lot of customization that upstream would 
not accept for integration, and the project would be on the hook for 
maintaining a fork in perpetuity anyway.

___
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

Fedora 31 Self-Contained Change proposal: AArch64 Xfce Desktop image

[Ben Cotton]

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

== Summary ==
Add an AArch64 Xfce Desktop image to deliverables in Fedora 31.

== Owner ==
* Name: [[User:pwhalen| Paul Whalen]]
* Email: pwha...@fedoraproject.org
* Responsible WG: ARM SIG

== Detailed Description ==

We currently offer Workstation, Minimal and Server images for use with
AArch64 Single Board Computer's (SBC's). We would like to add a
lighter weight desktop image for hardware that lacks the ability to
run accelerated desktops.

An initial set of supported devices:
* Pine64
* Raspberry Pi 3/4
* 96boards HiKey
* 96boards Dragonboard 410c

== Benefit to Fedora ==
Better user experience and an additional desktop choice for AArch64 SBC's.

== Scope ==
* Proposal owners: The ARM SIG will make the kickstart changes needed
to add the desktop images to the compose.
* Other developers: N/A
* Release engineering: Enable building of the AArch64 XFCE desktop
image. Small tweaks may be required to the pungi configs or fedora
kickstarts but those will be completed by the SIG and sent as pull
requests. Issue[https://pagure.io/releng/issue/8556 #8556]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
No upgrade compatibility required, this is a new image variant.

== How To Test ==
Testing can be completed on any supported AArch64 SBC using the
existing arm-image-installer. Any additional instructions will be
added to the ARM installation documentation.

== User Experience ==
Users will have increased choice in desktop offerings for AArch64
SBC's. Those looking to install a desktop on hardware that lacks an
accelerated graphics driver or lower system specifications will have a
useable option.

== Dependencies ==

N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: N/A
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No

== Documentation ==
All documentation will be added or updated via the ARM Landing Page.

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

Fedora 31 Self-Contained Change proposal: AArch64 Xfce Desktop image

[Ben Cotton]

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

== Summary ==
Add an AArch64 Xfce Desktop image to deliverables in Fedora 31.

== Owner ==
* Name: [[User:pwhalen| Paul Whalen]]
* Email: pwha...@fedoraproject.org
* Responsible WG: ARM SIG

== Detailed Description ==

We currently offer Workstation, Minimal and Server images for use with
AArch64 Single Board Computer's (SBC's). We would like to add a
lighter weight desktop image for hardware that lacks the ability to
run accelerated desktops.

An initial set of supported devices:
* Pine64
* Raspberry Pi 3/4
* 96boards HiKey
* 96boards Dragonboard 410c

== Benefit to Fedora ==
Better user experience and an additional desktop choice for AArch64 SBC's.

== Scope ==
* Proposal owners: The ARM SIG will make the kickstart changes needed
to add the desktop images to the compose.
* Other developers: N/A
* Release engineering: Enable building of the AArch64 XFCE desktop
image. Small tweaks may be required to the pungi configs or fedora
kickstarts but those will be completed by the SIG and sent as pull
requests. Issue[https://pagure.io/releng/issue/8556 #8556]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
No upgrade compatibility required, this is a new image variant.

== How To Test ==
Testing can be completed on any supported AArch64 SBC using the
existing arm-image-installer. Any additional instructions will be
added to the ARM installation documentation.

== User Experience ==
Users will have increased choice in desktop offerings for AArch64
SBC's. Those looking to install a desktop on hardware that lacks an
accelerated graphics driver or lower system specifications will have a
useable option.

== Dependencies ==

N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: N/A
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No

== Documentation ==
All documentation will be added or updated via the ARM Landing Page.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Adam Williamson]

On Tue, 2019-07-23 at 14:57 -0400, Josh Boyer wrote:
> 
> > Also, we can't really solve the machine resources of mirrors. Well, I
> > mean, I guess we *could*, but I doubt anyone in RH is going to sign off
> > on us buying a ton of expensive storage hardware and shipping it off to
> > random universities around the world...
> 
> Honestly, I'm less concerned about this.  Why?  Because anything new
> like this does not immediately require the full weight of a mirror
> system.  The level of interest is likely to be small enough at the
> start that we can and should approach it in a measured way.

True, but the way our build process, repo layout and mirroring system
work, if you want to leave a bit of Fedora out when you're mirroring
it, this is not easy. rsync bundles can't really do the job in cases
like this, because of how they're based on directory structures
combined with how we structure our repos. Mirrors have to use some kind
of script with a filter to do this; quick-fedora-mirror helps, but you
still have to maintain and write the filters. My mirror currently
rejoices in this:

FILTEREXP='(/i386/|/armhfp/|/aarch64/|/source/|/SRPMS|/debug/|\.iso|\.qcow2|\.raw\.xz|\.box|/releases/test|/22/|/23/|/24/|/25/|/26/|/27/)'

to try and reduce the amount of bandwidth it eats. Which is of course
fun to remember about and maintain. And hey look, indeed I haven't, cos
I didn't add 28 to it yet...

Of course we could completely rearrange how we build and store things,
but...see under 'human resources' :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

REMINDER: Software string freeze is 30 July

[Ben Cotton]

The software string freeze begins 30 July. For more information, see
the String Freeze Policy[1]. For more upcoming development[2] and
translation[3] milestones, see the schedule site.

[1] https://fedoraproject.org/wiki/Software_String_Freeze_Policy
[2] https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html
[3] https://fedorapeople.org/groups/schedule/f-31/f-31-trans-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Josh Boyer]

On Tue, Jul 23, 2019 at 2:37 PM Adam Williamson
 wrote:
>
> On Tue, 2019-07-23 at 13:32 -0400, Josh Boyer wrote:
> > On Tue, Jul 23, 2019 at 12:39 PM Kevin Fenzi  wrote:
> > > On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> > > > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> > > >  wrote:
> > > > Thinking about this even more, it should not be very hard thing to do:
> > > >
> > > > * Define new architecture in RPM/libsolv (let's call it "haswell" or
> > > > "x86_64modern")
> > > > * Define set of capabilities it should have, write appropriate check
> > > > in RPM/libdnf
> > > > * Add new architecture in Fedora Koji
> > > > * Once bootstrapped, create composes
> > > > * At some point in future, merge this arch back to x86_64 and move 
> > > > forward
> > > >
> > > > What do you think?
> > >
> > > Unless someone can show some kind of MASSIVE benefit, I'm not in favor.
> >
> > I think too often we focus on the technical implications (performance
> > gain, etc) and sometimes don't consider wider aspects.  So I'm curious
> > what your view is.  Can you elaborate on what kind of benefit you
> > would view as warranting this?
> >
> > > It's a ton of duplication of effort, tons more disk space, tons more cpu
> > > cycles wasted, a ton more mirror disk space, a ton more bandwith, etc.
> >
> > So let's look at this statement, for example.  Everything listed is
> > machine related, except the first part on duplication of effort.
> > Machine related items are solvable with more machine resources.  (That
> > is not to be flippant, but it's far easier to solve than human
> > impact.)
>
> Well, sort of - except that, life being life, machines inevitably go
> wrong. Fans give out and they choke. Builds mysteriously fail because
> of some test flake or a neutrino hitting the CPU at just the wrong
> moment or something. Disks go wonky. And all of these things get fixed
> by...people. Adding an arch adds another arch worth of all those things
> happening and needing to be fixed by someone.

Agreed.  I'd like to frame the discussion less around "adding another
arch" and more around "adding a new thing", but you mostly correct.  I
would suggest that there is this nebulous thing called "the cloud"
that mitigates a small part of that, but I also fully understand using
that magical machine resource presents its own challenges.

> Also, we can't really solve the machine resources of mirrors. Well, I
> mean, I guess we *could*, but I doubt anyone in RH is going to sign off
> on us buying a ton of expensive storage hardware and shipping it off to
> random universities around the world...

Honestly, I'm less concerned about this.  Why?  Because anything new
like this does not immediately require the full weight of a mirror
system.  The level of interest is likely to be small enough at the
start that we can and should approach it in a measured way.

> > On the effort part, what if we structured it so it wasn't immediately
> > 2x the effort.  That would indeed be poor.  If we assume for a minute
> > that we have the machine resources, we can certainly come up with
> > workflows that facilitate something like this in a manner that doesn't
> > cause a large human overhead.  I'm actually thinking of other areas
> > that would benefit from not exactly the new architecture approach as
> > traditionally know, but a new target space that allows the Fedora
> > project to do new things.
>
> I agree that this would be possible, but it comes with the caveat that
> the people who would likely get stuck with improving the workflows are
> the same people currently being overworked by the bad workflows.

This makes the assumption that there is no influx of actual humans.
Given history, maybe that's a fair assumption.  I think for anything
new to work, we'd need at least some way to add actual human
participants.  Either by freeing up existing people, or bringing new,
interested people in.

> The 'don't do a release for a year' proposal (or whatever variations of
> it were discussed) was supposed to help with that kinda thing,
> but...that didn't happen. So, we're all still on the treadmills.

It didn't happen, but I'm seeing different approaches already being
taken to address similar issues.  The current discussion around
dropping a number of apps, for example.

All of these things require a cost/benefit analysis for sure.  That is
very hard, but it's also very healthy.  Just doing the same thing
forever just gets you the same thing forever, right?  I haven't been a
super-active Fedora participant very recently, but I'm encouraged that
the project is starting to look at things in new ways and evaluating
what is actually a valuable thing to do.  I find it very exciting.

josh
___
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: 

Re: Packages with wrong Python unversioned commands

[Antonio Trande]

On 22/07/19 12:03, Miro Hrončok wrote:
> Hello Bcc'ed maintainers.

Hi Miro.

> sagitter   ProDy autowrap future preprocess scons

These packages should be okay.
'Scons' will need of an exception for Python2

> 
> According to the
> https://fedoraproject.org/wiki/Changes/Python_means_Python3 change, the
> unversioned Python commands shell be Python 3.
> 
> The following packages have Python 3 marked commands (executables in
> /usr/bin/) but miss the not marked files.
> 
> The format is:
> 
> : [python2-package]:
> 
> Please, make the normal unversioned command Python 3 and move it to the
> python3 subpackage.
> Add proper conflicts when moving files from one package to another.
> 
> Note that if the user shall not care whether the tool is executed by
> Python 2 or Python 3, drop the Python 2 command completely.
> 
> Do this in rawhide (Fedora 31+) only.
> 
> Thanks...
> 


-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital signature
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Re: Packages with wrong Python unversioned commands

[Antonio Trande]

On 22/07/19 12:03, Miro Hrončok wrote:
> Hello Bcc'ed maintainers.

Hi Miro.

> sagitter   ProDy autowrap future preprocess scons

These packages should be okay.
'Scons' will need of an exception for Python2

> 
> According to the
> https://fedoraproject.org/wiki/Changes/Python_means_Python3 change, the
> unversioned Python commands shell be Python 3.
> 
> The following packages have Python 3 marked commands (executables in
> /usr/bin/) but miss the not marked files.
> 
> The format is:
> 
> : [python2-package]:
> 
> Please, make the normal unversioned command Python 3 and move it to the
> python3 subpackage.
> Add proper conflicts when moving files from one package to another.
> 
> Note that if the user shall not care whether the tool is executed by
> Python 2 or Python 3, drop the Python 2 command completely.
> 
> Do this in rawhide (Fedora 31+) only.
> 
> Thanks...
> 


-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.openpgp.org/



signature.asc
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

Fedora 31 Mass Rebuild

[Mohan Boddu]

Hi all,

Per the Fedora 31 schedule[1] we will be starting a mass rebuild for Fedora
31 tomorrow. We are doing a mass rebuild for Fedora 31 for all the changes
listed in

https://pagure.io/releng/issue/8555

we will start the mass rebuild on 2019-07-23

This is a heads up that it will be done in a side tag and moved over
when completed. We will be running scripts to output failure stats.
please be sure to let releng know if you see any bugs in the reporting.

You can contact releng in #fedora-releng on freenode.

Failures can be seen

https://kojipkgs.fedoraproject.org/mass-rebuild/f31-failures.html

Things still needing rebuilt

https://kojipkgs.fedoraproject.org/mass-rebuild/f31-need-rebuild.html

[1] https://fedoraproject.org/wiki/Releases/31/Schedule

Regards,
Mohan Boddu
___
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
___
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

Fedora 31 Mass Rebuild

[Mohan Boddu]

Hi all,

Per the Fedora 31 schedule[1] we will be starting a mass rebuild for Fedora
31 tomorrow. We are doing a mass rebuild for Fedora 31 for all the changes
listed in

https://pagure.io/releng/issue/8555

we will start the mass rebuild on 2019-07-23

This is a heads up that it will be done in a side tag and moved over
when completed. We will be running scripts to output failure stats.
please be sure to let releng know if you see any bugs in the reporting.

You can contact releng in #fedora-releng on freenode.

Failures can be seen

https://kojipkgs.fedoraproject.org/mass-rebuild/f31-failures.html

Things still needing rebuilt

https://kojipkgs.fedoraproject.org/mass-rebuild/f31-need-rebuild.html

[1] https://fedoraproject.org/wiki/Releases/31/Schedule

Regards,
Mohan Boddu
___
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

Re: are the ppc64le builders healthy?

[Jason L Tibbitts III]

> "KK" == Kaleb Keithley  writes:

KK> I built the latest ceph-14 (14.2.2) on rawhide successfully two days
KK> ago.  Two different builds on f30 built or are building fine on
KK> x86_64, i686, and aarch64, but failed with different errors on
KK> ppc64le at different places in the build.  One looks like it ran out
KK> of space in the file system. The other may have been OOM killed (?).

There was just a bit of talk about this in IRC.  The issue seems to be
that the CPU count of the PPC64le builders was bumped from 4 to 12, but
the amount of memory was unchanged at 10GB RAM/2GB swap.  This could
potentially cause resource exhaustion.

Seems they've now been bumped to 22GB of RAM, which should help with OOM
issues but probably not with disk space issues.

 - J<
___
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

Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Göran Uddeborg]

I was going to argue this would make us lose a lot of hardware and
most likely a lot of our the hardware owners as users too.

But I see that most of what I planned to say is already said, so I'll
just add my: please, don't do this.

(My sample from home and work: out of 6 Fedora hosts expected to still
live during F32, 2 have AVX2, 3 have AVX only, and one has naither.)
___
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

Re: Non-responsive maintainer: tonet666p

[Tonet Pascualet Jallo Colquehuanca]

ohhh, i'm alive, sorry, i'll repply soon
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Adam Williamson]

On Tue, 2019-07-23 at 13:32 -0400, Josh Boyer wrote:
> On Tue, Jul 23, 2019 at 12:39 PM Kevin Fenzi  wrote:
> > On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> > > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> > >  wrote:
> > > Thinking about this even more, it should not be very hard thing to do:
> > > 
> > > * Define new architecture in RPM/libsolv (let's call it "haswell" or
> > > "x86_64modern")
> > > * Define set of capabilities it should have, write appropriate check
> > > in RPM/libdnf
> > > * Add new architecture in Fedora Koji
> > > * Once bootstrapped, create composes
> > > * At some point in future, merge this arch back to x86_64 and move forward
> > > 
> > > What do you think?
> > 
> > Unless someone can show some kind of MASSIVE benefit, I'm not in favor.
> 
> I think too often we focus on the technical implications (performance
> gain, etc) and sometimes don't consider wider aspects.  So I'm curious
> what your view is.  Can you elaborate on what kind of benefit you
> would view as warranting this?
> 
> > It's a ton of duplication of effort, tons more disk space, tons more cpu
> > cycles wasted, a ton more mirror disk space, a ton more bandwith, etc.
> 
> So let's look at this statement, for example.  Everything listed is
> machine related, except the first part on duplication of effort.
> Machine related items are solvable with more machine resources.  (That
> is not to be flippant, but it's far easier to solve than human
> impact.)

Well, sort of - except that, life being life, machines inevitably go
wrong. Fans give out and they choke. Builds mysteriously fail because
of some test flake or a neutrino hitting the CPU at just the wrong
moment or something. Disks go wonky. And all of these things get fixed
by...people. Adding an arch adds another arch worth of all those things
happening and needing to be fixed by someone.

Also, we can't really solve the machine resources of mirrors. Well, I
mean, I guess we *could*, but I doubt anyone in RH is going to sign off
on us buying a ton of expensive storage hardware and shipping it off to
random universities around the world...

> On the effort part, what if we structured it so it wasn't immediately
> 2x the effort.  That would indeed be poor.  If we assume for a minute
> that we have the machine resources, we can certainly come up with
> workflows that facilitate something like this in a manner that doesn't
> cause a large human overhead.  I'm actually thinking of other areas
> that would benefit from not exactly the new architecture approach as
> traditionally know, but a new target space that allows the Fedora
> project to do new things.

I agree that this would be possible, but it comes with the caveat that
the people who would likely get stuck with improving the workflows are
the same people currently being overworked by the bad workflows.

The 'don't do a release for a year' proposal (or whatever variations of
it were discussed) was supposed to help with that kinda thing,
but...that didn't happen. So, we're all still on the treadmills.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2019-07-24 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. Agenda is in the 
https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next 


Source: https://apps.fedoraproject.org/calendar/meeting/9364/

___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Matthew Miller]

On Mon, Jul 22, 2019 at 05:11:23PM -0400, Josh Boyer wrote:
> > I think I'd be more inclined to consider it if the Change was proposed
> > as a new architecture bring-up. Effectively, this would be a whole new
> > architecture that would just happen to be largely compatible with
> > x86_64.
> 
> That is one way.  I think there might be others.
> 
> Depending on exactly what the target usecase is, we might be able to
> accommodate this under the Fedora project umbrella in a way that
> doesn't require moving the entire distro immediately here.

I am very much interested in finding such an approach.

-- 
Matthew Miller

Fedora Project Leader
___
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

Fedora 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda

[Ben Cotton]

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

== Summary ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with a simple list of
predefined choices.

== Owner ==
* Name: [[User:Vponcova| Vendula Poncova]]
* Email: vponc...@redhat.com


== Detailed Description ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with the following
list of choices:

* Use all disk space
* Use free space available for use
* Replace existing Linux system(s)
* Shrink or remove existing partitions

The first three options will redirect users to the Installation
Summary screen. The automatic partitioning will be configured based on
the selected action.

The last option will redirect users to the Manual Partitioning screen.
Users can shrink or remove existing partitions, automatically create
new partitions and leave the screen.

The Manual Partitioning screen supports all actions of the Resize Disk
Space dialog, so it doesn't make sense to have two user interfaces
with the same functionality.

== Benefit to Fedora ==
Simple predefined choices should improve the user experience for
users, who are not interested in shrinking or removing specific
partitions. Beginners can use all or free disk space without other
interaction. Advanced users can quickly reinstall their systems and
virtual machines.

== Scope ==
* Proposal owners: Implement the new dialog window for the graphical
user interface. The support for the dialog actions is already
implemented for the text user interface and kickstart installations.
It is a very small and isolated change.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==
During the Fedora installation, it will be easier to set up the
automatic partitioning in the graphical user interface. Users can
choose with one click to use all disk space, all free space or to
replace existing Linux systems.

These options are supported also in the text user interface and
kickstart files, so users might be already familiar with them.

Advanced users can choose to shrink or remove existing partitions.
They will be redirected to the Manual Partitioning screen, where they
can delete and shrink partitions and automatically generate partitions
for the new installation. However, users have much more flexibility at
this point. They can create a fully customized configuration without
having to revisit the Installation Destination screen.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: Revert the changes in Anaconda.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
N/A (not a System Wide Change)



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

are the ppc64le builders healthy?

[Kaleb Keithley]

I built the latest ceph-14 (14.2.2) on rawhide successfully two days ago.

Two different builds on f30 built or are building fine on x86_64, i686, and
aarch64, but failed with different errors on ppc64le at different places in
the build.  One looks like it ran out of space in the file system. The
other may have been OOM killed (?).

https://kojipkgs.fedoraproject.org//work/tasks/2448/36422448/build.log

https://kojipkgs.fedoraproject.org//work/tasks/4819/36444819/build.log

Thanks,

--

Kaleb
___
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

Fedora 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda

[Ben Cotton]

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

== Summary ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with a simple list of
predefined choices.

== Owner ==
* Name: [[User:Vponcova| Vendula Poncova]]
* Email: vponc...@redhat.com


== Detailed Description ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with the following
list of choices:

* Use all disk space
* Use free space available for use
* Replace existing Linux system(s)
* Shrink or remove existing partitions

The first three options will redirect users to the Installation
Summary screen. The automatic partitioning will be configured based on
the selected action.

The last option will redirect users to the Manual Partitioning screen.
Users can shrink or remove existing partitions, automatically create
new partitions and leave the screen.

The Manual Partitioning screen supports all actions of the Resize Disk
Space dialog, so it doesn't make sense to have two user interfaces
with the same functionality.

== Benefit to Fedora ==
Simple predefined choices should improve the user experience for
users, who are not interested in shrinking or removing specific
partitions. Beginners can use all or free disk space without other
interaction. Advanced users can quickly reinstall their systems and
virtual machines.

== Scope ==
* Proposal owners: Implement the new dialog window for the graphical
user interface. The support for the dialog actions is already
implemented for the text user interface and kickstart installations.
It is a very small and isolated change.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==
During the Fedora installation, it will be easier to set up the
automatic partitioning in the graphical user interface. Users can
choose with one click to use all disk space, all free space or to
replace existing Linux systems.

These options are supported also in the text user interface and
kickstart files, so users might be already familiar with them.

Advanced users can choose to shrink or remove existing partitions.
They will be redirected to the Manual Partitioning screen, where they
can delete and shrink partitions and automatically generate partitions
for the new installation. However, users have much more flexibility at
this point. They can create a fully customized configuration without
having to revisit the Installation Destination screen.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: Revert the changes in Anaconda.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
N/A (not a System Wide Change)



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Josh Boyer]

On Tue, Jul 23, 2019 at 12:39 PM Kevin Fenzi  wrote:
>
> On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> >  wrote:
>
> > Thinking about this even more, it should not be very hard thing to do:
> >
> > * Define new architecture in RPM/libsolv (let's call it "haswell" or
> > "x86_64modern")
> > * Define set of capabilities it should have, write appropriate check
> > in RPM/libdnf
> > * Add new architecture in Fedora Koji
> > * Once bootstrapped, create composes
> > * At some point in future, merge this arch back to x86_64 and move forward
> >
> > What do you think?
>
> Unless someone can show some kind of MASSIVE benefit, I'm not in favor.

I think too often we focus on the technical implications (performance
gain, etc) and sometimes don't consider wider aspects.  So I'm curious
what your view is.  Can you elaborate on what kind of benefit you
would view as warranting this?

> It's a ton of duplication of effort, tons more disk space, tons more cpu
> cycles wasted, a ton more mirror disk space, a ton more bandwith, etc.

So let's look at this statement, for example.  Everything listed is
machine related, except the first part on duplication of effort.
Machine related items are solvable with more machine resources.  (That
is not to be flippant, but it's far easier to solve than human
impact.)

On the effort part, what if we structured it so it wasn't immediately
2x the effort.  That would indeed be poor.  If we assume for a minute
that we have the machine resources, we can certainly come up with
workflows that facilitate something like this in a manner that doesn't
cause a large human overhead.  I'm actually thinking of other areas
that would benefit from not exactly the new architecture approach as
traditionally know, but a new target space that allows the Fedora
project to do new things.

Dismissing ideas like this because we thought too narrowly about the
single discussion starter is something I often see Fedora do, and I
honestly think it's causing the project to miss opportunities to add
value in multiple ways.

josh
___
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

Non-responsive maintainer: tonet666p

[Fabio Valentini]

Hi everybody,

Does anybody know how to contact tonet666p? One of his packageshas
been broken for a while, and he doesn't respond on bugzilla:

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

If there's no positive response within the next week, I'll open a
fesco ticket in accordance with the non-responsive maintainer process.

Thanks,
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: portable performance engineering

[Benson Muite]

Tradeoffs to satisfy a wide variety of users - a base system with most 
common software easy to try which can then be re-installed for 
performance. Flatpacks should help with easy but not performance optimal 
installation of many packages. Spack (https://spack.io/) may be a 
packaging approach that gives some performance portability - one can get 
a compilation recipie so that performance is reasonable good. Easybuild 
(https://easybuild.readthedocs.io) is another way to go. Source based 
systems such as Gentoo may give better performance if configured correctly.


On 7/23/19 7:00 PM, Dave Love wrote:

I'm afraid this turned into a bit of and essay on more useful things
Fedora could do for portable performance engineering, should anyone
care.

I actually have no interest in Fedora except as a requirement to work on
packaging for research software around EPEL, specifically for HPC and so
performance-oriented.  I'm not sure how long it's worth persisting in
view of how difficult it is to contribute now, but these points are
mostly general.

The x86 change is clearly a non-starter, and I'm surprised to see where
it came from, but I don't see anyone mentioning much on rationale
higher-level aspects, apart from some better things to do.  Strikingly,
there's no quantification of expected performance benefits.  Anyway,
they'd be rather limited by the compiler options we're supposed to use,
that don't include vectorization, so you don't even get the benefit you
could from SSE2.  (I've been told off in review for turning that on,
though an FPC member has approved it.)

I've seen lack of support for things that would help, and plenty of
comments from people who clearly haven't work in this area.  At least
one sensible portable performance-oriented change has been blocked in
committee (interchangeable BLAS implementations), and what I've seen
from Red Hat and Fedora makes it increasingly hard to justify a RHEL-ish
basis for HPC.  However, things could be done for computational
performance where it matters.

SIMD hwcaps have been mentioned, and I'm baffled why they haven't been
implemented generally.  That and similar changes are actually more
important for non-x86 architectures less likely to have
dynamically-dispatched SIMD-specific implementations.  [The value of
"SIMD" includes things like FMA, and I know not just for floating point.]

However, hwcaps won't help for programs with no separate library
performance component; Gromacs is an example.  On a heterogeneous HPC
system you need multiple parallel-installable versions with a convention
for the paths they'll be on.  Other than that, maintainers could look at
function multi-versioning for performance-critical code where that's
possible.  It isn't always, specifically not for Fortran, and I'd
probably look at that first if I got back to GCC maintenance.
(Actually, adding FMV to BLIS wasn't effective for some reason I haven't
had time to chase.)

The "Clear Linux" stuff mentioned is unconvincing.  The only worked
example I've seen is for FFTW, where it actually has no effect, and I've
seen no numbers.  Using FMV outside performance-critical kernels -- just
something GCC says is vectorizable -- is probably not a good idea, and
any changes ought to be contributed explicitly for the source and
support non-x86.  (By the way, don't even Intel assume AVX as a
baseline, not AVX2?)

There's already multi-simd support for ATLAS -- though I know no good
reason to ATLAS -- and at least one package (libxsmm) has a minimum
requirement of SSE3 without complaint.  (I got that down from SSE4 for
the benefit of systems we had, though you wouldn't use them for anything
CPU-bound.)
___
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

___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kevin Fenzi]

On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
>  wrote:

> Thinking about this even more, it should not be very hard thing to do:
> 
> * Define new architecture in RPM/libsolv (let's call it "haswell" or
> "x86_64modern")
> * Define set of capabilities it should have, write appropriate check
> in RPM/libdnf
> * Add new architecture in Fedora Koji
> * Once bootstrapped, create composes
> * At some point in future, merge this arch back to x86_64 and move forward
> 
> What do you think?

Unless someone can show some kind of MASSIVE benefit, I'm not in favor.

It's a ton of duplication of effort, tons more disk space, tons more cpu
cycles wasted, a ton more mirror disk space, a ton more bandwith, etc.

kevin




signature.asc
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

portable performance engineering (was: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update)

[Dave Love]

I'm afraid this turned into a bit of and essay on more useful things
Fedora could do for portable performance engineering, should anyone
care.

I actually have no interest in Fedora except as a requirement to work on
packaging for research software around EPEL, specifically for HPC and so
performance-oriented.  I'm not sure how long it's worth persisting in
view of how difficult it is to contribute now, but these points are
mostly general.

The x86 change is clearly a non-starter, and I'm surprised to see where
it came from, but I don't see anyone mentioning much on rationale
higher-level aspects, apart from some better things to do.  Strikingly,
there's no quantification of expected performance benefits.  Anyway,
they'd be rather limited by the compiler options we're supposed to use,
that don't include vectorization, so you don't even get the benefit you
could from SSE2.  (I've been told off in review for turning that on,
though an FPC member has approved it.)

I've seen lack of support for things that would help, and plenty of
comments from people who clearly haven't work in this area.  At least
one sensible portable performance-oriented change has been blocked in
committee (interchangeable BLAS implementations), and what I've seen
from Red Hat and Fedora makes it increasingly hard to justify a RHEL-ish
basis for HPC.  However, things could be done for computational
performance where it matters.

SIMD hwcaps have been mentioned, and I'm baffled why they haven't been
implemented generally.  That and similar changes are actually more
important for non-x86 architectures less likely to have
dynamically-dispatched SIMD-specific implementations.  [The value of
"SIMD" includes things like FMA, and I know not just for floating point.]

However, hwcaps won't help for programs with no separate library
performance component; Gromacs is an example.  On a heterogeneous HPC
system you need multiple parallel-installable versions with a convention
for the paths they'll be on.  Other than that, maintainers could look at
function multi-versioning for performance-critical code where that's
possible.  It isn't always, specifically not for Fortran, and I'd
probably look at that first if I got back to GCC maintenance.
(Actually, adding FMV to BLIS wasn't effective for some reason I haven't
had time to chase.)

The "Clear Linux" stuff mentioned is unconvincing.  The only worked
example I've seen is for FFTW, where it actually has no effect, and I've
seen no numbers.  Using FMV outside performance-critical kernels -- just
something GCC says is vectorizable -- is probably not a good idea, and
any changes ought to be contributed explicitly for the source and
support non-x86.  (By the way, don't even Intel assume AVX as a
baseline, not AVX2?)

There's already multi-simd support for ATLAS -- though I know no good
reason to ATLAS -- and at least one package (libxsmm) has a minimum
requirement of SSE3 without complaint.  (I got that down from SSE4 for
the benefit of systems we had, though you wouldn't use them for anything
CPU-bound.)
___
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

Re: Fedora 31 Self-Contained Change proposal: Add LLD As Update Alternatives Option For LD

[Stephen John Smoogen]

On Tue, 23 Jul 2019 at 11:10, Neal Gompa  wrote:

> On Tue, Jul 23, 2019 at 10:28 AM Stephen John Smoogen 
> wrote:
> >
> >
> >
> > On Tue, 23 Jul 2019 at 09:33, Ben Cotton  wrote:
> >>
> >>
> https://fedoraproject.org/wiki/Changes/Add_LLD_As_Update_Alternatives_Option_For_LD
> >>
> >>
> >> == Dependencies ==
> >> N/A (not a System Wide Change)
> >>
> >
> > I am not sure about this. We are looking at making a system-wide change
> of having /usr/bin/ld be a symlink to /etc/alternatives/ld with all the
> headaches of where it should work but doesn't for a multitude of little
> reasons.
> >
>
> Isn't it already this way?
>


You know what helps.. looking at the right system before making an email
about this being a system wide change. You are correct Neal:

[smooge@fedora00 ~]$ ls -l /usr/bin/ld
lrwxrwxrwx. 1 root root 20 Jul 19 18:51 /usr/bin/ld -> /etc/alternatives/ld

{ I was on a CentOS-6 box when I checked and thought I was on my F30 box }

-- 
Stephen J Smoogen.
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Solomon Peachy]

On Tue, Jul 23, 2019 at 07:52:09AM -0700, Andrew Lutomirski wrote:
> Things like CMPXCHG16B that change the set of things that can be done on
> the CPU.  I could easily imagine programs that use algorithms that
> fundamentally depend on CMPXCHG16B.  There is no drop-in replacement.

FWIW, CMPXCH16B is a hard requirement for Windows 8.1 (August 2013!) and 
beyond.

In AMD-land, it seems that CMPXCHG16B support was added at the same time 
as they added SSE3 (ie April 2005). so requiring that would cut off the 
1st-gen single-core x86_64 AMD parts)

All non-AMD x86_64 parts support both CMPXCHG16B and SSE3.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

Fedora Atomic Host Two Week Release Announcement: 29.20190722.0

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 29.20190722.0
Commit(x86_64): 74566c9d78aeb334f497b77d85d726932ebf5b6ee6ef33594fb4ec072ac880bc
Commit(aarch64): 
c570fbbcc753ee9c3198ddd7c6344ecb7d4b3ee456a20e309bec4ec4a811ab0e
Commit(ppc64le): 
41ffdaa7a8271976a8db344ec8d1ee7c7cb668f6e2f9e89945f7d85336dd2ff5


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190722.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190722.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190722.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190722.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190722.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190722.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190722.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190722.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190722.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190722.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190722.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190722.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190722.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190722.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190722.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190722.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190722.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190722.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Gerald B. Cox]

>...I think this should be retracted before it ends up being a
> phoronix article making the project look bad.

I 100% agree... but too late:  
https://www.phoronix.com/scan.php?page=news_item=Fedora-31-Possible-AVX2-Require
___
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

Re: ownership of /proc and /sys

[Lennart Poettering]

On Di, 23.07.19 10:56, Adam Jackson (a...@redhat.com) wrote:

> On Tue, 2019-07-23 at 11:01 +0200, Miroslav Suchý wrote:
> > Hi,
> > directories /proc/ and /sys/ are owned by filesystem package. This worked 
> > in past where we needed those directories to
> > exist so we can mount the procfs and sysfs.
> >
> > However this cause issues in containers:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> > and during building where hacks are needed:
> > https://github.com/rpm-software-management/mock/pull/234/commits/d7e0b413c83bec00fd1ed75ee15122a9cc6db62e
> >
> > I have bunch of ideas, but all of them ugly (e.g., not own that file and 
> > create that directories in scriptlet). Do you
> > have any ideas about this situation?
>
> Make systemd create them? It has to manage them anyway.

It does, if they are missing. In fact, it's totally supported to boot
up with an empty / (for example: tmpfs, which is what
systemd.volatile=yes on the kernel cmdline will do) with the one
exception of a populated /usr and systemd will create all the basic
mount points and symlinks needed to make the system boot.

That said, that only works if / is writable. Which is not a given.

Lennart

--
Lennart Poettering, Berlin
___
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

Re: Orphaning/retiring 3 Java packages

[Miro Hrončok]

On 23. 07. 19 16:08, Mikolaj Izdebski wrote:

On Tue, Jul 23, 2019 at 1:50 PM Miro Hrončok  wrote:

On 23. 07. 19 13:27, Mikolaj Izdebski wrote:

Soon after Fedora 31 branching I intend to retire java-packaging-howto
package and orphan byaccj and javapackages-tools packages. The reason
is that I intend to maintain these packages as part of modules.

I will continue to maintain non-modular packages through lifecycles of
Fedora 29-31, but starting from Fedora 32 I will maintain modular
versions only.


Do you realize that while your decision to move essential bits of Java packaging
to modules might untie your hands a lot, it is causing everybody else involved
more and more trouble?


Perhaps I don't realize the trouble, could you elaborate? I expect
orphaned packages to be adopted by someone, likely a member of
Stewardship SIG. These two packages are low-maintenance and don't
require much work - they don't have many upstream changes and don't
get many bugs reported. So I don't see that much trouble in this case.


And exactly the Stewardship SIG will need to maintain yet another package, that 
itself depends on others and others, the rabbit hole seems to have no end.



I acknowledge that it is your right to orphan essentially anything you want,
however the motivation here seems a bit... nonempathetic.

Would you mind to reconsider?


Definitely - this is the reason I wrote to the list. Do you have any
proposal what to do with these packages instead of orphaning them?


Keep maintaining them in normal Fedora until modular packages can be used in 
nonmodular builds? CCing contyk, he might have some news about that.


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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Daniel P . Berrangé]

On Tue, Jul 23, 2019 at 08:25:59AM -0400, Solomon Peachy wrote:
> On Tue, Jul 23, 2019 at 11:05:59AM +0200, Kevin Kofler wrote:
> > assume. And if you ask me, we should just stick to SSE2 as the baseline. 
> 
> Ie the status quo.
> 
> > What are the big gains to be had from SSE3, SSSE3, SSE4.1, and SSE4.2? 
> 
> Each of those individually, and from a general system library 
> persepective, I'd wager not a whole lot.  But in aggregate, there are a 
> lot of Clear Linux benchmarks showing a sizeable bump in general purpose 
> performance.
> 
> That said -- A reasonable argument can be made to bump the baseline to 
> require SSE3, because all non-AMD x86_64 CPUs support it, and on the AMD 
> side, anything beyond their 1st-gen single-core K8s supports it.  
> (We're talking April 2005 here, versus the September 2003 introduction 
> of the very first x86_64 processor)

FWIW, in order to maintain historical guest ABI compatibility qemu
defaults to a CPU model, qemu64, that lacks sse3 support.

Most apps using libvirt (virt-install, virt-manager, OpenStack, oVirt,
etc) will override this historical default with something more modern.
So the QEMU default is only an issue for people who manually launch
QEMU without giving an explicit "-cpu" arg to pick something better.

Fortunately some work in QEMU upstream stands a good chance of letting us
move to a default CPU model that is more useful/modern in the not too
distant future (hopefully < 12 months)

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

Re: ownership of /proc and /sys

[Adam Jackson]

On Tue, 2019-07-23 at 11:01 +0200, Miroslav Suchý wrote:
> Hi,
> directories /proc/ and /sys/ are owned by filesystem package. This worked in 
> past where we needed those directories to
> exist so we can mount the procfs and sysfs.
> 
> However this cause issues in containers:
> https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> and during building where hacks are needed:
> https://github.com/rpm-software-management/mock/pull/234/commits/d7e0b413c83bec00fd1ed75ee15122a9cc6db62e
> 
> I have bunch of ideas, but all of them ugly (e.g., not own that file and 
> create that directories in scriptlet). Do you
> have any ideas about this situation?

Make systemd create them? It has to manage them anyway.

- ajax
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Andrew Lutomirski]

On Mon, Jul 22, 2019 at 11:52 AM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See [
> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].
>
> Along with AVX2, it makes sense to enable certain other CPU features
> which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
> earlier vector extensions such as SSE 4.2.  Details are still being
> worked out.
>
>
In the interest of a productive discussion, could we maybe focus on what
the benefits are, both of changing the baseline in general and of enabling
any particular features? As I see it, there are a few classes of relevant
features:

Features like SSE2: enabling SSE2 as the basic floating point mechanism
changes the ABI drastically.  But x86_64 already requires SSE2, so this is
irrelevant.

Things like SSSE3, SSE3, SSE4, AVX1, AVX2, FMA, etc: for the most part,
these accelerate existing algorithms.  I'm sure that someone somewhere has
written an algorithm that requires FMA for enhanced precision, but
otherwise pretty much any code that benefits from any of these features
would work just fine, if slower, without the features.

Things like CMPXCHG16B that change the set of things that can be done on
the CPU.  I could easily imagine programs that use algorithms that
fundamentally depend on CMPXCHG16B.  There is no drop-in replacement.

Things like FSGSBASE that change the way that software interacts with the
kernel.  Don't even get me started on FSGSBASE on Linux.

So I could see a concrete benefit to Fedora from requiring CMPXCHG16B.  If
FSGSBASE were actually supported and widely used, I could see that, too,
but FSGSBASE is not a credible requirement for Fedora since IIRC it's not
supported on Sandy Bridge.  Even Intel seems to consider Sandy Bridge to be
an important CPU to support.

As for the vector features, they're always a moving target.  Even if Fedora
did require AVX2, performance would be left on the table by not using
AVX-512 where avaiable.  (And AVX2 isn't such a great thing anyway given
certain microarchitectures' latency and power issues.)

I think that, for vector extensions, Fedora shouldn't require anything
beyond SSE2 for basic functionality.  Instead, Fedora should figure out
where there are material benefits to using them and find ways to make it
easier for packagers to make them available.  Ideally this would all be
figured out at runtime, but install-time choices could make sense, too.
___
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

Re: Fedora 31 Self-Contained Change proposal: Add LLD As Update Alternatives Option For LD

[Neal Gompa]

On Tue, Jul 23, 2019 at 10:28 AM Stephen John Smoogen  wrote:
>
>
>
> On Tue, 23 Jul 2019 at 09:33, Ben Cotton  wrote:
>>
>> https://fedoraproject.org/wiki/Changes/Add_LLD_As_Update_Alternatives_Option_For_LD
>>
>>
>> == Dependencies ==
>> N/A (not a System Wide Change)
>>
>
> I am not sure about this. We are looking at making a system-wide change of 
> having /usr/bin/ld be a symlink to /etc/alternatives/ld with all the 
> headaches of where it should work but doesn't for a multitude of little 
> reasons.
>

Isn't it already this way?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning/retiring 3 Java packages

[Mikolaj Izdebski]

On Tue, Jul 23, 2019 at 1:50 PM Miro Hrončok  wrote:
> On 23. 07. 19 13:27, Mikolaj Izdebski wrote:
> > Soon after Fedora 31 branching I intend to retire java-packaging-howto
> > package and orphan byaccj and javapackages-tools packages. The reason
> > is that I intend to maintain these packages as part of modules.
> >
> > I will continue to maintain non-modular packages through lifecycles of
> > Fedora 29-31, but starting from Fedora 32 I will maintain modular
> > versions only.
>
> Do you realize that while your decision to move essential bits of Java 
> packaging
> to modules might untie your hands a lot, it is causing everybody else involved
> more and more trouble?

Perhaps I don't realize the trouble, could you elaborate? I expect
orphaned packages to be adopted by someone, likely a member of
Stewardship SIG. These two packages are low-maintenance and don't
require much work - they don't have many upstream changes and don't
get many bugs reported. So I don't see that much trouble in this case.

> I acknowledge that it is your right to orphan essentially anything you want,
> however the motivation here seems a bit... nonempathetic.
>
> Would you mind to reconsider?

Definitely - this is the reason I wrote to the list. Do you have any
proposal what to do with these packages instead of orphaning them?

--
Mikolaj Izdebski
___
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

Re: Tips to add optional arguments on dnf using plugin

[Marek Blaha]

Hi Fellipe,

if layer in your case means a particular set of repositories, then
Nicolas advice with using distinct prefixes for repositories in each
layer and then passing --repoid=-* to the dnf is probably most
straightforward solution.

If you really need a custom plugin, then there is a problem that
values parsed from command line options are stored only in command
classes. So if you need to use it in the plugin, you must parse
arguments and store values yourself. This example works for me:

class Ghost(dnf.Plugin):
name = 'ghost'

def __init__(self, base, cli):
super(Ghost, self).__init__(base, cli)
cli.optparser.add_argument('--set-layer')
self.myopts, _unused_args = cli.optparser.parse_known_args(sys.argv[1:])

def config(self):
print("Plugin config() set-layer =", self.myopts.set_layer)

Then when I call any dnf command, I can see output from the plugin
with correct value of set-layer option:

$ dnf search --set-layer=helloworld HHH
Plugin config() set-layer = helloworld
Last metadata expiration check: 3:22:10 ago on Út 23. července 2019,
12:20:31 CEST.
No matches found.

Regards,

Marek
--
Marek Blaha 

Red Hat Czech s.r.o.
Software Engineer

On Tue, Jul 23, 2019 at 2:19 PM Fellipe Henrique  wrote:
>
> Hi Marek,
>
> Thanks again for your reply..
>
> I already tried to use __init__ method...  arguments was added without error 
> ( I can get any message when add on optparser), but, dnf still say:  
> unrecognized arguments
>
> I believe it's because plugin is loaded after args was passed inside dnf, so, 
> dnf not recognize the new argument.. only approach I can get global args, is 
> add inside def _main_parser(self):  on option_parser.py  on dnf package.. 
> but, I avoid to change anything from mainstream..
>
> Cheers,
>
> T.·.F.·.A.·. S+F
> Fellipe Henrique P. Soares
>
> e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
> Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
> Blog: http:www.fellipeh.eti.br
> GitHub: https://github.com/fellipeh
> Twitter: @fh_bash
>
>
> On Tue, Jul 23, 2019 at 9:10 AM Marek Blaha  wrote:
>>
>> Hi,
>>
>> there is no supported way how to change global arguments in DNF.
>> However, you can try in __init__ method of your plugin do something
>> like this:
>>
>> class MyPlugin(dnf.Plugin):
>> def __init__(self, base, cli):
>> super(MyPlugin, self).__init__(base, cli)
>> cli.optparser.add_argument('--set-layer')
>>
>> --
>> Marek Blaha 
>>
>> Red Hat Czech s.r.o.
>> Software Engineer
>> On Tue, Jul 23, 2019 at 12:02 PM Fellipe Henrique  wrote:
>> >
>> > Hi Marek,
>> >
>> > First, Thanks very much for you reply...
>> >
>> > I need to add a "global" argument so I can change the layer of a 
>> > repository... For example:
>> >
>> > $ dnf repolist --set-layer=mylayer
>> > $ dnf install -y any_repo --set-layer=mylayer
>> >
>> > So on my plug-in I can change layer in repository to do anything, for that 
>> > running process, to a different layer. (For example)..
>> >
>> > That's the reason I need a "global" argument, not a command, so I can use 
>> > these arg on any dnf command, like "-v" argument..
>> >
>> > I saw your email related to reposync, but reposync use a command, so I 
>> > need to add a command "reposync" and its arguments... As I explain above, 
>> > I need a global argument to work with all dnf commands...
>> >
>> > That's my real problem, I do not know if dnf plug-in give me access to do 
>> > that...
>> >
>> > On yum, I made these using init_hook() def, and setting the args.. But dnf 
>> > doesn't no have init_hook anymore
>> >
>> > Again, thanks for your time and help, any tips will be welcome..
>> >
>> > Cheers!
>> >
>> > Fellipe H.
>> >
>> > Em ter, 23 de jul de 2019 às 03:37, Marek Blaha  
>> > escreveu:
>> >>
>> >> Each DNF command could have static method set_argparser (here is the
>> >> example from reposync plugin:
>> >> https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/reposync.py#L60)
>> >> which can be used for adding command specific arguments. However there
>> >> is no such method for adding global arguments.
>> >> May I ask you to elaborate your use case in more details? What are you
>> >> trying to achieve?
>> >>
>> >> Regards,
>> >>
>> >> Marek
>> >>
>> >> --
>> >> Marek Blaha 
>> >>
>> >> Red Hat Czech s.r.o.
>> >> Software Engineer
>> >>
>> >> On Mon, Jul 22, 2019 at 7:59 PM Fellipe Henrique  
>> >> wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > First of all, thanks for accept me on these mail list.. my first mail 
>> >> > it's about a issue I facing here on my job...
>> >> >
>> >> > I need to add some optional arguments on dnf,  not a command, just a 
>> >> > "global" args.. eg:  $ dnf repolist --my_arg=abcd
>> >> >
>> >> > How can I do these? Can I use plugin with these approach?
>> >> >
>> >> > I already try to override OptionParser from cli inside Plugin class, no 
>> >> > success... I try just parse 

Re: Discussion around app retirements and categorizations by the CPE team

[Jeremy Cline]

On Tue, Jul 23, 2019 at 07:18:56AM -0400, Neal Gompa wrote:
> On Tue, Jul 23, 2019 at 5:47 AM Kevin Kofler  wrote:
> >
> > Alexander Bokovoy wrote:
> > > As I said already, my primary worry is where we would clash our needs
> > > with those of GitLab commercial entity. For example, Kerberos
> > > authentication or SAML SSO for groups, or push rule restrictions are
> > > part of commercial offering but not available in the community edition.
> > > This makes it harder to integrate with existing workflows and existing
> > > dist-git use.
> >
> > Indeed, GitLab's crippleware approach might become a problem.
> >
> > With all those high-profile Free Software projects using GitLab, I wonder
> > whether a fork is in order.
> >
> 
> If a fork is necessary for GitLab to be usable for high-profile FOSS
> projects long-term, then GitLab is a bad fit. The "friendly fork"
> model won't work, because rebasing and integrating upstream with
> downstream concerns will be incredibly difficult. The "hard fork"
> model will fail because GitLab's complexity is incredibly high, making
> it functionally impossible for a community to maintain the fork over
> time. It would be a repeat of the Alioth situation all over again...
> 
> GitLab's CE/EE split model basically makes it impossible for an
> amicable model of community contributions to GitLab, because large
> FOSS projects require what they consider Enterprise features. They can
> and have rejected things based on this in the past, and will continue
> to do so based on that criteria.

On the other hand, large FOSS projects are using it. Perhaps we should
actually talk with the GitLab folks before deciding they will or won't
do something. I've heard they're pretty cool folks.

> 
> Also, for $DAYJOB, I run a GitLab server. If you think maintaining a
> GitLab server is easy, you have another think coming. GitLab's
> development model basically makes it impossible to have any real
> degree of stability, since the codebase churns without concern *very
> frequently*. Heck, for three months (that is, three GitLab releases!),
> they broke merge requests in GitLab last year when they rewrote merge
> requests frontend code in Vuejs... It was that experience that pushed
> me to look at Pagure for my personal servers and start contributing to
> it in the first place...

Sure, sure, but Pagure has regressions too, and plenty of things just
don't work for years at a time because it has a fraction of the
resources.

As a Fedora contributor primary attraction to GitLab to me is that other
communities are using it and we can work together. As a user, GitLab's
user experience is vastly better. I find Pagure's user experience for
code review and CI to be incredibly painful to use.

- Jeremy
___
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

[RFC] target font model on Freedesktop systems

[Nicolas Mailhot via devel]

Hi,

Now that things are starting to move fonts-side[1], I’d like the various 
actors to agree on a common font model target.


Without a a common target, we’ll end up working at odds with one 
another. Upstream font files can not serve as a an officious target. 
They are full of quirks, you end up with a different model per file-set.


My understanding of the state of the art is that OpenType is now 
hegemonic. So it’s useless to target anything not specified in OpenType 
specs. The latest OpenType enhancement is variable fonts.


Therefore, I’d like to propose that the target font model on freedesktop 
systems, is the functional unit defined in variable fonts[2]:



Things, that share a common design, and vary only in
— Optical size
— Slant (Italic axis is some weird legacy way to specify Slant in 
another way)

— Width
— Weight


That’s pretty much the same thing as WWS fonts as OpenType defined them 
10 years ago, with optical size added. Add optical size is not intended 
to be exposed in font selectors, it’s supposed to be auto-applied by 
apps at need. I hoped we could ignore it at first, but we already have 
things like PT Sans caption in Fedora.


Practical consequences of agreeing on a common model:

1. the unit of deployment (in rpm packages and software catalogs) 
becomes all the files contributing to such an ideal font[4]


2. fontconfig strives to hide all the legacy ways to designate different 
parts of this ideal font, and strives to expose a single "font" objet no 
matter what quirks exist in individual font files. We stop exposing lots 
of weird quirky bits right and left, that need manual assembling by 
users, or glue-ing with TEX macros.


No foo variable, foo hebrew, foo narrow, foo caption, just a single foo 
with different available features (full variability or fixed states on 
the default axis, real upstream provided states or fakes generated by 
fontconfig at pango’s request[5], etc)


3. the API between fontconfig and pango manipulates this kind of unit

4. the thing that end up in font selectors is also this unit.


Is this something we can agree on?

If we continue to special-case complex fonts like Noto, and bolt on 
features without any form of master plan, I fear we’ll never get 
anywhere.


If the agreement exists, can it be traced in a short fontconfig 
document, that serves as coordinating references?


Regards,


[1] https://fedoraproject.org/wiki/Changes/VariableNotoFonts

[2]
https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/variable-fonts/
https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg

[4]
https://pagure.io/fork/nim/packaging-committee/commits/fonts-rpm-macros
https://pagure.io/fork/nim/fonts-rpm-macros
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros-noreg/builds/

[5]
https://lists.freedesktop.org/archives/fontconfig/2019-June/006546.html

--
Nicolas Mailhot
___
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

Re: Fedora 31 Self-Contained Change proposal: Add LLD As Update Alternatives Option For LD

[Stephen John Smoogen]

On Tue, 23 Jul 2019 at 09:33, Ben Cotton  wrote:

>
> https://fedoraproject.org/wiki/Changes/Add_LLD_As_Update_Alternatives_Option_For_LD
>
>
> == Dependencies ==
> N/A (not a System Wide Change)
>
>
I am not sure about this. We are looking at making a system-wide change of
having /usr/bin/ld be a symlink to /etc/alternatives/ld with all the
headaches of where it should work but doesn't for a multitude of little
reasons.


-- 
Stephen J Smoogen.
___
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

Re: Request for write permission of menu-cache in Fedora

[Zamir SUN]

Ping for updates.

I've build menu-cach 1.1.0 in Copr and already tested against LXQt.

If you are not willing to grant me write permission, can you build this
in EPEL directly?

https://copr.fedorainfracloud.org/coprs/zsun/epel7/build/948489/

On 7/15/19 1:58 PM, Zamir SUN wrote:
> Ping for updates.
> 
> On Thu, Jul 11, 2019 at 10:59 PM Zamir SUN  wrote:
>>
>> Hi Christoph,
>>
>> I am the current maintainer of Fedora LXQt spin. Recently I am updating
>> LXQt in EPEL and I found that I need menu-cache 1.1.0 in EPEL. I filed a
>> bug there[1] but no updates. I checked and see only LXQt uses menu-cache
>> in EPEL, so can you please grant me write permission of menu-cache, so
>> that I can update it in EPEL myself?
>>
>> Thanks.
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1724495
>> --
>> Zamir SUN
>> Fedora user
>> GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E

-- 
Zamir SUN
Fedora user
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
___
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

Re: Request for write permission of menu-cache in Fedora

[Zamir SUN]

Ping for updates.

I've build menu-cach 1.1.0 in Copr and already tested against LXQt.

If you are not willing to grant me write permission, can you build this
in EPEL directly?

https://copr.fedorainfracloud.org/coprs/zsun/epel7/build/948489/

On 7/15/19 1:58 PM, Zamir SUN wrote:
> Ping for updates.
> 
> On Thu, Jul 11, 2019 at 10:59 PM Zamir SUN  wrote:
>>
>> Hi Christoph,
>>
>> I am the current maintainer of Fedora LXQt spin. Recently I am updating
>> LXQt in EPEL and I found that I need menu-cache 1.1.0 in EPEL. I filed a
>> bug there[1] but no updates. I checked and see only LXQt uses menu-cache
>> in EPEL, so can you please grant me write permission of menu-cache, so
>> that I can update it in EPEL myself?
>>
>> Thanks.
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1724495
>> --
>> Zamir SUN
>> Fedora user
>> GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E

-- 
Zamir SUN
Fedora user
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
___
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

Fedora 31 Self-Contained Change proposal: DeepinDE 15.11

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DeepinDE_15.11

== Summary ==
Update the Deepin Desktop Environment to 15.11 in Fedora.

== Owner ==

* Name: [[User:Zsun|Zamir SUN]] - main coordinator, packager
* Email: zsun#AT#fedoraproject.org
* [[User:cheeselee|Robin 'cheese' Lee]] - main packager
* Email: cheeselee#AT#fedoraproject.org

== Detailed Description ==
Update Deepin Desktop in Fedora to the newest upstream, which is 15.11.

Deepin Desktop in Fedora 30 is based on 15.9 and the changelog for
15.10 and 15.11 are

* https://www.deepin.org/en/2019/04/28/deepin15-10/
* https://www.deepin.org/en/2019/07/19/deepin15-11/

== Benefit to Fedora ==

Fedora stays in sync with upstream and gets the latest features and bug fixes.

== Scope ==
* Proposal owners: Deepin Desktop 15.11 packages packaged and built in
Fedora 31.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
No impact should happen to current users except the bugfixes.

== How To Test ==
Install or update your Deepin Desktop on Fedora, make sure that the
desktop and all apps are usable.

== User Experience ==

There are some improvements.

* The default window manager will be changed to deepin-kwin (known as
dde-kwin in Deepin), which consumes less memory and has better
performance
* The deepin-file-manager will support burn ISO to disks.
* The dock - will show the capacity and the remaining time of battery.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: Not announce the availability of Deepin
Desktop 15.11 in Fedora.
* Contingency deadline: Beta Freeze
* Blocks release? No.
* Blocks product? None.

== Documentation ==
* [https://github.com/FZUG/deepin-desktop The staging git repo of all
spec files].
* [https://www.deepin.org/en/dde/ Deepin Desktop Environment] website.
* [[SIGs/DeepinDE|DeepinDE SIG page]]


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

Fedora 31 Self-Contained Change proposal: Add LLD As Update Alternatives Option For LD

[Ben Cotton]

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

== Summary ==
Allow users to optionally use update-alternatives to make /usr/bin/ld
point to /usr/bin/lld.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 

== Detailed Description ==
Update the lld package %post and %postun steps to configure the system
so that a user can use the update-alternatives tool to create a
symlink from /usr/bin/ld to /usr/bin/lld.  This will effectively allow
lld to act as the system linker and make it easier for users to
integrate lld into their projects.  This same functionality is
currently available with one other non-system linker: gold.

I want to be clear that this proposal is not about making lld the
system linker or using lld during brew builds.  This is simply about
making it easier for end-users to use lld with their own projects.

== Benefit to Fedora ==
This change will make it much easier for users to try out lld in their
projects.  Many build systems and compilers assume that the linker is
/usr/bin/ld, and it is very difficult to seamlessly integrate lld into
existing build systems.  With this proposal a user will be able to
easily switch between ld.bfd and lld without having to make any
modifications to their build systems.

== Scope ==
* Proposal owners: tstellar
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
Tests for this change will be added to the lld package's CI tests.
One test will install lld and verify that /usr/bin/ld.bfd is still the
system linker.  Another test will use update-alternatives to update
/usr/bin/ld to point to /usr/bin/lld and then it will run /usr/bin/ld
--version to verify that this correctly points to lld and then link a
simple program with it.

== User Experience ==
This will greatly enhance the experience for users who want to use
lld.  They will be able to try lld with their projects by simply
running `update-alternatives --set ld /usr/bin/lld` instead of having
to make modifications to existing build systems.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Fedora 31 Self-Contained Change proposal: DeepinDE 15.11

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DeepinDE_15.11

== Summary ==
Update the Deepin Desktop Environment to 15.11 in Fedora.

== Owner ==

* Name: [[User:Zsun|Zamir SUN]] - main coordinator, packager
* Email: zsun#AT#fedoraproject.org
* [[User:cheeselee|Robin 'cheese' Lee]] - main packager
* Email: cheeselee#AT#fedoraproject.org

== Detailed Description ==
Update Deepin Desktop in Fedora to the newest upstream, which is 15.11.

Deepin Desktop in Fedora 30 is based on 15.9 and the changelog for
15.10 and 15.11 are

* https://www.deepin.org/en/2019/04/28/deepin15-10/
* https://www.deepin.org/en/2019/07/19/deepin15-11/

== Benefit to Fedora ==

Fedora stays in sync with upstream and gets the latest features and bug fixes.

== Scope ==
* Proposal owners: Deepin Desktop 15.11 packages packaged and built in
Fedora 31.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
No impact should happen to current users except the bugfixes.

== How To Test ==
Install or update your Deepin Desktop on Fedora, make sure that the
desktop and all apps are usable.

== User Experience ==

There are some improvements.

* The default window manager will be changed to deepin-kwin (known as
dde-kwin in Deepin), which consumes less memory and has better
performance
* The deepin-file-manager will support burn ISO to disks.
* The dock - will show the capacity and the remaining time of battery.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: Not announce the availability of Deepin
Desktop 15.11 in Fedora.
* Contingency deadline: Beta Freeze
* Blocks release? No.
* Blocks product? None.

== Documentation ==
* [https://github.com/FZUG/deepin-desktop The staging git repo of all
spec files].
* [https://www.deepin.org/en/dde/ Deepin Desktop Environment] website.
* [[SIGs/DeepinDE|DeepinDE SIG page]]


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Fedora 31 Self-Contained Change proposal: Ship BerkleyDB backend as a module

[Ben Cotton]

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

== Summary ==
Change the ''openldap-servers'' package so that BDB and HDB backends
are required to be dynamically loaded.

== Owner ==
* Name: [[User:mhonek| Matus Honek]]
* Email: mhonek (at) redhat (dot) com

== Detailed Description ==

So far the BDB and HDB were statically built with the ''slapd'' binary
and merely declaring `database bdb` or `database hdb` would just work.
Change introduces an additional requirement of explicitly declaring to
load the backend's SO file according to the documentation of dynamic
modules. The respective new modules will be shipped similarly to the
rest of the already shipped modules.

This change is directed to conduct a smoother experience before the
backends are removed in a next Fedora release.

== Benefit to Fedora ==

A step on a way to remove unsupported (both by OpenLDAP and BerkleyDB
upstream) piece of software.

== Scope ==
* Proposal owners:
Change the SPEC file accordingly.
* Other developers: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
Server using BDB or HDB backends without modified configuration would
fail to start. See ''User Experience'' section for more information.

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==
If a user is using either BDB or HDB they have two options:
*  migrate to the fully supported MDB backend (preferred)
*  add a `moduleload` configuration declaration (discouraged)

=== Migrating to MDB ===
The steps required to migrate a database are following:
*  Stop the slapd server.
*  Export data to an LDIF file using ''slapcat''.
*  Change the server's configuration replacing the BDB/HDB sections
with its MDB counterparts.
*  Import data to a new database from the LDIF file using ''slapadd''.
*  Start the slapd server.

=== ModuleLoad the BDB/HDB backend ===
Depending on the configuration style and backend type, user should add
a declaration in order to load the backend library: add option
`moduleload` (slapd.conf(5), section ''GLOBAL CONFIGURATION OPTIONS'')
or attribute `olcModuleLoad` (slapd-config(5), section ''DYNAMIC
MODULE OPTIONS'') with value `back_bdb` and/or `back_hdb`.

== Dependencies ==
None.

== Contingency Plan ==
* Contingency mechanism: Revert the change.
* Contingency deadline: Anytime.
* Blocks release? No.
* Blocks product? None.

== Documentation ==
N/A (not a System Wide Change)

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Solomon Peachy]

On Tue, Jul 23, 2019 at 11:05:59AM +0200, Kevin Kofler wrote:
> assume. And if you ask me, we should just stick to SSE2 as the baseline. 

Ie the status quo.

> What are the big gains to be had from SSE3, SSSE3, SSE4.1, and SSE4.2? 

Each of those individually, and from a general system library 
persepective, I'd wager not a whole lot.  But in aggregate, there are a 
lot of Clear Linux benchmarks showing a sizeable bump in general purpose 
performance.

That said -- A reasonable argument can be made to bump the baseline to 
require SSE3, because all non-AMD x86_64 CPUs support it, and on the AMD 
side, anything beyond their 1st-gen single-core K8s supports it.  
(We're talking April 2005 here, versus the September 2003 introduction 
of the very first x86_64 processor)

As another data point, Windows 8.x effectively required SSE3 on 64-bit 
CPUs as the other CPU features they required (LAHF/SAHF, CMPXCHG16B, and 
NX) were only implemented together on SSE3-capable processors.

(And Steam's hardware survey shows that a full 100% of their users have 
 an SSE3-capable processor..)

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

Re: Tips to add optional arguments on dnf using plugin

[Nicolas Mailhot via devel]

Le 2019-07-23 14:09, Stephen John Smoogen a écrit :

On Tue, 23 Jul 2019 at 08:00, Nicolas Mailhot via devel
 wrote:


Le 2019-07-23 12:01, Fellipe Henrique a écrit :

Hi


First, Thanks very much for you reply...

I need to add a "global" argument so I can change the layer of a
repository... For example:

$ dnf repolist --set-layer=mylayer
$ dnf install -y any_repo --set-layer=mylayer


On our setup we approximate this via -repo naming

So dnf commands become dnf --disablerepo * --enablerepo -*


Just for your future use.. I think you can cut that down to "dnf
--repo -*" and it will do the disable* for you.

   --repo=, --repoid=
  Enable  just  specific  repositories  by an id or a
glob. Can be
  used multiple times with accumulative effect. It is
basically  a
  shortcut  for  --disablerepo="*"  --enablerepo=
and  is
  mutually exclusive with the --disablerepo option.


Thanks for the tip, I had missed this dnf enhancement!

Small fixes like that matter, they improve the user experience a lot

Regards,

--
Nicolas Mailhot
___
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

Re: Tips to add optional arguments on dnf using plugin

[Fellipe Henrique]

Hi Marek,

Thanks again for your reply..

I already tried to use __init__ method...  arguments was added without
error ( I can get any message when add on optparser), but, dnf still
say:  unrecognized arguments

I believe it's because plugin is loaded after args was passed inside dnf,
so, dnf not recognize the new argument.. only approach I can get global
args, is add inside *def _main_parser(self)*: * on option_parser.py * on
dnf package.. but, I avoid to change anything from mainstream..

Cheers,

T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
*Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
*
*Blog: *http:www.fellipeh.eti.br
*GitHub: https://github.com/fellipeh *
*Twitter: @fh_bash*


On Tue, Jul 23, 2019 at 9:10 AM Marek Blaha  wrote:

> Hi,
>
> there is no supported way how to change global arguments in DNF.
> However, you can try in __init__ method of your plugin do something
> like this:
>
> class MyPlugin(dnf.Plugin):
> def __init__(self, base, cli):
> super(MyPlugin, self).__init__(base, cli)
> cli.optparser.add_argument('--set-layer')
>
> --
> Marek Blaha 
>
> Red Hat Czech s.r.o.
> Software Engineer
> On Tue, Jul 23, 2019 at 12:02 PM Fellipe Henrique 
> wrote:
> >
> > Hi Marek,
> >
> > First, Thanks very much for you reply...
> >
> > I need to add a "global" argument so I can change the layer of a
> repository... For example:
> >
> > $ dnf repolist --set-layer=mylayer
> > $ dnf install -y any_repo --set-layer=mylayer
> >
> > So on my plug-in I can change layer in repository to do anything, for
> that running process, to a different layer. (For example)..
> >
> > That's the reason I need a "global" argument, not a command, so I can
> use these arg on any dnf command, like "-v" argument..
> >
> > I saw your email related to reposync, but reposync use a command, so I
> need to add a command "reposync" and its arguments... As I explain above, I
> need a global argument to work with all dnf commands...
> >
> > That's my real problem, I do not know if dnf plug-in give me access to
> do that...
> >
> > On yum, I made these using init_hook() def, and setting the args.. But
> dnf doesn't no have init_hook anymore
> >
> > Again, thanks for your time and help, any tips will be welcome..
> >
> > Cheers!
> >
> > Fellipe H.
> >
> > Em ter, 23 de jul de 2019 às 03:37, Marek Blaha 
> escreveu:
> >>
> >> Each DNF command could have static method set_argparser (here is the
> >> example from reposync plugin:
> >>
> https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/reposync.py#L60
> )
> >> which can be used for adding command specific arguments. However there
> >> is no such method for adding global arguments.
> >> May I ask you to elaborate your use case in more details? What are you
> >> trying to achieve?
> >>
> >> Regards,
> >>
> >> Marek
> >>
> >> --
> >> Marek Blaha 
> >>
> >> Red Hat Czech s.r.o.
> >> Software Engineer
> >>
> >> On Mon, Jul 22, 2019 at 7:59 PM Fellipe Henrique 
> wrote:
> >> >
> >> > Hello,
> >> >
> >> > First of all, thanks for accept me on these mail list.. my first mail
> it's about a issue I facing here on my job...
> >> >
> >> > I need to add some optional arguments on dnf,  not a command, just a
> "global" args.. eg:  $ dnf repolist --my_arg=abcd
> >> >
> >> > How can I do these? Can I use plugin with these approach?
> >> >
> >> > I already try to override OptionParser from cli inside Plugin class,
> no success... I try just parse cli args, but dnf still says my argument if
> not recognized..
> >> >
> >> > Anyone, have any tips how to do that?
> >> >
> >> > Best regards,
> >> >
> >> > T.·.F.·.A.·. S+F
> >> > Fellipe Henrique P. Soares
> >> >
> >> > e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \
> 's/(.)/chr(ord($1)-2*3)/ge'
> >> > Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
> >> > Blog: http:www.fellipeh.eti.br
> >> > GitHub: https://github.com/fellipeh
> >> > Twitter: @fh_bash
> >> > ___
> >> > 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
> >> ___
> >> 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:
> 

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Stephen John Smoogen]

On Tue, 23 Jul 2019 at 08:08, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> Hello, Igor Gnatenko.
>
> Tue, 23 Jul 2019 07:34:06 +0200 you wrote:
>
> > * Define new architecture in RPM/libsolv (let's call it "haswell" or
> > "x86_64modern")
>
> I have a better idea: use modules to build special AVX/SSE4 enabled
> versions of some packages.
>
>
You are looking at having to have a module for every package.. because gcc
and glibc are the main target to be enabled in. And once you replace
gcc/glibc.. you might as well do the kernel, and..

I think either a different focus distribution (who needs AVX2 nethack?) or
a different architecture would work better.




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


-- 
Stephen J Smoogen.
___
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

Re: Tips to add optional arguments on dnf using plugin

[Stephen John Smoogen]

On Tue, 23 Jul 2019 at 08:00, Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:

> Le 2019-07-23 12:01, Fellipe Henrique a écrit :
>
> Hi
>
> > First, Thanks very much for you reply...
> >
> > I need to add a "global" argument so I can change the layer of a
> > repository... For example:
> >
> > $ dnf repolist --set-layer=mylayer
> > $ dnf install -y any_repo --set-layer=mylayer
>
> On our setup we approximate this via -repo naming
>
> So dnf commands become dnf --disablerepo * --enablerepo -*
>
>
Just for your future use.. I think you can cut that down to "dnf --repo
-*" and it will do the disable* for you.

   --repo=, --repoid=
  Enable  just  specific  repositories  by an id or a glob. Can
be
  used multiple times with accumulative effect. It is basically
 a
  shortcut  for  --disablerepo="*"  --enablerepo=  and
 is
  mutually exclusive with the --disablerepo option.



-- 
Stephen J Smoogen.
___
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

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
23 of 47 required tests failed, 19 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.universal.i386.64bit - compose.install_repository_http_graphical
MISSING: fedora.universal.i386.64bit - compose.install_scsi_updates_img

Failed openQA tests: 78/147 (x86_64), 1/2 (arm)

Old failures (same test failed in Fedora-Rawhide-20190722.n.1):

ID: 425290  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/425290
ID: 425291  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/425291
ID: 425292  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/425292
ID: 425293  Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/425293
ID: 425299  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/425299
ID: 425301  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/425301
ID: 425302  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/425302
ID: 425303  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/425303
ID: 425304  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/425304
ID: 425305  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/425305
ID: 425319  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/425319
ID: 425323  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/425323
ID: 425324  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/425324
ID: 425325  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/425325
ID: 425326  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/425326
ID: 425338  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/425338
ID: 425339  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/425339
ID: 425340  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/425340
ID: 425341  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/425341
ID: 425342  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/425342
ID: 425343  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/425343
ID: 425344  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/425344
ID: 425356  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/425356
ID: 425366  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/425366
ID: 425368  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/425368
ID: 425369  Test: x86_64 universal install_repository_http_variation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/425369
ID: 425370  Test: x86_64 universal install_repository_http_graphical 
**GATING**
URL: https://openqa.fedoraproject.org/tests/425370
ID: 425371  Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/425371
ID: 425372  Test: x86_64 universal install_delete_pata **GATING**
URL: https://openqa.fedoraproject.org/tests/425372
ID: 425373  Test: x86_64 universal install_delete_pata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/425373
ID: 425374  Test: x86_64 universal install_sata **GATING**
URL: https://openqa.fedoraproject.org/tests/425374
ID: 425375  Test: x86_64 universal install_sata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/425375
ID: 425377  Test: x86_64 universal install_scsi_updates_img **GATING**
URL: https://openqa.fedoraproject.org/tests/425377
ID: 425378  Test: x86_64 universal install_multi **GATING**
URL: https://openqa.fedoraproject.org/tests/425378
ID: 425379  Test: x86_64 universal install_multi@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/425379
ID: 425380  Test: x86_64 universal install_simple_encrypted
URL: 

Re: Orphaning/retiring 3 Java packages

[Miro Hrončok]

On 23. 07. 19 13:27, Mikolaj Izdebski wrote:

Soon after Fedora 31 branching I intend to retire java-packaging-howto
package and orphan byaccj and javapackages-tools packages. The reason
is that I intend to maintain these packages as part of modules.

I will continue to maintain non-modular packages through lifecycles of
Fedora 29-31, but starting from Fedora 32 I will maintain modular
versions only.


Do you realize that while your decision to move essential bits of Java packaging 
to modules might untie your hands a lot, it is causing everybody else involved 
more and more trouble?


I acknowledge that it is your right to orphan essentially anything you want, 
however the motivation here seems a bit... nonempathetic.


Would you mind to reconsider?

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

Re: Tips to add optional arguments on dnf using plugin

[Fellipe Henrique]

Thinking here about these...

If I made a fork from dnf package, and put arguments inside OptionParser
class, on option_parser.py... I get the "global" argument as I needed...
but how can I get these argument value inside my plugin?  Any idea?

cheers


T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
*Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
*
*Blog: *http:www.fellipeh.eti.br
*GitHub: https://github.com/fellipeh *
*Twitter: @fh_bash*


On Tue, Jul 23, 2019 at 8:19 AM Fellipe Henrique  wrote:

> So,
>
> Using dnf plugin, I can't do that, if I understand correctly...  As I
> said  on my last email, I have these coded using yum, like these:
>
> def init_hook(pc):
>'''Initial Hook that configures the repositories'''
>parser = pc.getOptParser()
>if parser:
>   parser.add_option('', '--set-repository-layer',
>   dest='set_repository_layer',
>   action='store', nargs=1)
>
> But, I can't do these using a new plugin approach on dnf, only if I use
> command... but command doesn't work with all dnf commands( repolist,
> install, remove etc..)
>
> Maybe I need to change my approach, as you said @Nicolas
>
>
> Cheers!
>
> T.·.F.·.A.·. S+F
> *Fellipe Henrique P. Soares*
>
> e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \
> 's/(.)/chr(ord($1)-2*3)/ge'
> *Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
> *
> *Blog: *http:www.fellipeh.eti.br
> *GitHub: https://github.com/fellipeh *
> *Twitter: @fh_bash*
>
>
> On Tue, Jul 23, 2019 at 8:11 AM Nicolas Mailhot 
> wrote:
>
>> Le 2019-07-23 12:01, Fellipe Henrique a écrit :
>>
>> Hi
>>
>> > First, Thanks very much for you reply...
>> >
>> > I need to add a "global" argument so I can change the layer of a
>> > repository... For example:
>> >
>> > $ dnf repolist --set-layer=mylayer
>> > $ dnf install -y any_repo --set-layer=mylayer
>>
>> On our setup we approximate this via -repo naming
>>
>> So dnf commands become dnf --disablerepo * --enablerepo -*
>>
>> Tried to play with passing yum/dnf explicit config paths, that didn’t
>> work out so well. (I’ve seen others try to switch personalities via YUMx
>> variables, the result is also quite user unfriendly).
>>
>> Of course that’s some pretty big hammer and that disables the ability to
>> preset repos to on or off within a layer. It would be much nicer if
>> there was a way to define things as part of a configuration set in
>> /etc/yum*, and enable/disable specific configuration sets on the cli.
>>
>> One use case is reposync, since one typically wants the system to use
>> the remote repos once synced, so every repo has one personality for
>> reposync, and another for the system dnf itself.
>>
>> Regards,
>>
>> --
>> Nicolas Mailhot
>>
>
___
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

Orphaning/retiring 3 Java packages

[Mikolaj Izdebski]

Soon after Fedora 31 branching I intend to retire java-packaging-howto
package and orphan byaccj and javapackages-tools packages. The reason
is that I intend to maintain these packages as part of modules.

I will continue to maintain non-modular packages through lifecycles of
Fedora 29-31, but starting from Fedora 32 I will maintain modular
versions only.

--
Mikolaj Izdebski
___
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

Fedora rawhide compose report: 20190723.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190722.n.1
NEW: Fedora-Rawhide-20190723.n.0

= SUMMARY =
Added images:1
Dropped images:  3
Added packages:  3
Dropped packages:1
Upgraded packages:   28
Downgraded packages: 0

Size of added packages:  1.35 MiB
Size of dropped packages:135.18 KiB
Size of upgraded packages:   1.11 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20190723.n.0-sda.raw.xz

= DROPPED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20190722.n.1.iso
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20190722.n.1.iso
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20190722.n.1.iso

= ADDED PACKAGES =
Package: mingw-jansson-2.12-1.fc31
Summary: C library for encoding, decoding and manipulating JSON data
RPMs:mingw32-jansson mingw64-jansson
Size:106.71 KiB

Package: mingw-speexdsp-1.2.0-1.fc31
Summary: A voice compression format (DSP)
RPMs:mingw32-speexdsp mingw64-speexdsp
Size:924.51 KiB

Package: mingw-yaml-cpp-0.6.2-1.fc31
Summary: A YAML parser and emitter for C++
RPMs:mingw32-yaml-cpp mingw64-yaml-cpp
Size:347.61 KiB


= DROPPED PACKAGES =
Package: driconf-0.9.1-30.fc30
Summary: A configuration applet for the Direct Rendering Infrastructure
RPMs:driconf
Size:135.18 KiB


= UPGRADED PACKAGES =
Package:  MUMPS-5.2.1-1.fc31
Old package:  MUMPS-5.1.2-10.fc31
Summary:  A MUltifrontal Massively Parallel sparse direct Solver
RPMs: MUMPS MUMPS-common MUMPS-devel MUMPS-examples MUMPS-mpich 
MUMPS-mpich-devel MUMPS-mpich-examples MUMPS-openmp MUMPS-openmp-devel 
MUMPS-openmp-examples MUMPS-openmpi MUMPS-openmpi-devel MUMPS-openmpi-examples
Size: 79.56 MiB
Size change:  3.78 MiB
Changelog:
  * Sat Jul 20 2019 Antonio Trande  - 5.2.1-1
  - Update to 5.2.1


Package:  asv-0.4.1-2.fc31
Old package:  asv-0.4.1-1.fc31
Summary:  Airspeed Velocity: A simple Python history benchmarking tool
RPMs: asv asv-doc
Size: 6.16 MiB
Size change:  -1019.07 KiB
Changelog:
  * Mon Jul 22 2019 Elliott Sales de Andrade  - 
0.4.1-2
  - Fix tests against latest Chrome webdriver


Package:  cadical-1.0.3-2.fc31
Old package:  cadical-1.0.3-1.fc31
Summary:  Simplified SAT solver
RPMs: cadical cadical-devel cadical-libs
Size: 1.97 MiB
Size change:  4.16 KiB
Changelog:
  * Mon Jul 22 2019 Jerry James  - 1.0.3-2
  - Add ccadical.h to the -devel subpackage (bz 1731887)


Package:  dsniff-2.4-0.29.b1.fc31
Old package:  dsniff-2.4-0.29.b1.fc30
Summary:  Tools for network auditing and penetration testing
RPMs: dsniff
Size: 852.39 KiB
Size change:  126.92 KiB

Package:  electron-cash-4.0.8-1.fc31
Old package:  electron-cash-4.0.7-2.fc31
Summary:  A lightweight Bitcoin Cash client
RPMs: electron-cash
Size: 1.92 MiB
Size change:  150.27 KiB
Changelog:
  * Tue Jun 25 2019 Jonny Heggheim  - 4.0.7-3
  - Added missing dependency on python3-qt5

  * Mon Jul 22 2019 Jonny Heggheim  - 4.0.8-1
  - Updated to version 4.0.8


Package:  glibc-2.29.9000-33.fc31
Old package:  glibc-2.29.9000-32.fc31
Summary:  The GNU libc libraries
RPMs: compat-libpthread-nonshared glibc glibc-all-langpacks 
glibc-benchtests glibc-common glibc-devel glibc-headers glibc-langpack-aa 
glibc-langpack-af glibc-langpack-agr glibc-langpack-ak glibc-langpack-am 
glibc-langpack-an glibc-langpack-anp glibc-langpack-ar glibc-langpack-as 
glibc-langpack-ast glibc-langpack-ayc glibc-langpack-az glibc-langpack-be 
glibc-langpack-bem glibc-langpack-ber glibc-langpack-bg glibc-langpack-bhb 
glibc-langpack-bho glibc-langpack-bi glibc-langpack-bn glibc-langpack-bo 
glibc-langpack-br glibc-langpack-brx glibc-langpack-bs glibc-langpack-byn 
glibc-langpack-ca glibc-langpack-ce glibc-langpack-chr glibc-langpack-cmn 
glibc-langpack-crh glibc-langpack-cs glibc-langpack-csb glibc-langpack-cv 
glibc-langpack-cy glibc-langpack-da glibc-langpack-de glibc-langpack-doi 
glibc-langpack-dsb glibc-langpack-dv glibc-langpack-dz glibc-langpack-el 
glibc-langpack-en glibc-langpack-eo glibc-langpack-es glibc-langpack-et 
glibc-langpack-eu glibc-langpack-fa glibc-langpack-ff glibc-langpack-fi 
glibc-langpack-fil glibc-langpack-fo glibc-langpack-fr glibc-langpack-fur 
glibc-langpack-fy glibc-langpack-ga glibc-langpack-gd glibc-langpack-gez 
glibc-langpack-gl glibc-langpack-gu glibc-langpack-gv glibc-langpack-ha 
glibc-langpack-hak glibc-langpack-he glibc-langpack-hi glibc-langpack-hif 
glibc-langpack-hne glibc-langpack-hr glibc-langpack-hsb glibc-langpack-ht 
glibc-langpack-hu glibc-langpack-hy glibc-langpack-ia glibc-langpack-id 
glibc-langpack-ig glibc-langpack-ik glibc

Re: Tips to add optional arguments on dnf using plugin

[Marek Blaha]

Hi,

there is no supported way how to change global arguments in DNF.
However, you can try in __init__ method of your plugin do something
like this:

class MyPlugin(dnf.Plugin):
def __init__(self, base, cli):
super(MyPlugin, self).__init__(base, cli)
cli.optparser.add_argument('--set-layer')

--
Marek Blaha 

Red Hat Czech s.r.o.
Software Engineer
On Tue, Jul 23, 2019 at 12:02 PM Fellipe Henrique  wrote:
>
> Hi Marek,
>
> First, Thanks very much for you reply...
>
> I need to add a "global" argument so I can change the layer of a 
> repository... For example:
>
> $ dnf repolist --set-layer=mylayer
> $ dnf install -y any_repo --set-layer=mylayer
>
> So on my plug-in I can change layer in repository to do anything, for that 
> running process, to a different layer. (For example)..
>
> That's the reason I need a "global" argument, not a command, so I can use 
> these arg on any dnf command, like "-v" argument..
>
> I saw your email related to reposync, but reposync use a command, so I need 
> to add a command "reposync" and its arguments... As I explain above, I need a 
> global argument to work with all dnf commands...
>
> That's my real problem, I do not know if dnf plug-in give me access to do 
> that...
>
> On yum, I made these using init_hook() def, and setting the args.. But dnf 
> doesn't no have init_hook anymore
>
> Again, thanks for your time and help, any tips will be welcome..
>
> Cheers!
>
> Fellipe H.
>
> Em ter, 23 de jul de 2019 às 03:37, Marek Blaha  escreveu:
>>
>> Each DNF command could have static method set_argparser (here is the
>> example from reposync plugin:
>> https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/reposync.py#L60)
>> which can be used for adding command specific arguments. However there
>> is no such method for adding global arguments.
>> May I ask you to elaborate your use case in more details? What are you
>> trying to achieve?
>>
>> Regards,
>>
>> Marek
>>
>> --
>> Marek Blaha 
>>
>> Red Hat Czech s.r.o.
>> Software Engineer
>>
>> On Mon, Jul 22, 2019 at 7:59 PM Fellipe Henrique  wrote:
>> >
>> > Hello,
>> >
>> > First of all, thanks for accept me on these mail list.. my first mail it's 
>> > about a issue I facing here on my job...
>> >
>> > I need to add some optional arguments on dnf,  not a command, just a 
>> > "global" args.. eg:  $ dnf repolist --my_arg=abcd
>> >
>> > How can I do these? Can I use plugin with these approach?
>> >
>> > I already try to override OptionParser from cli inside Plugin class, no 
>> > success... I try just parse cli args, but dnf still says my argument if 
>> > not recognized..
>> >
>> > Anyone, have any tips how to do that?
>> >
>> > Best regards,
>> >
>> > T.·.F.·.A.·. S+F
>> > Fellipe Henrique P. Soares
>> >
>> > e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 
>> > 's/(.)/chr(ord($1)-2*3)/ge'
>> > Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
>> > Blog: http:www.fellipeh.eti.br
>> > GitHub: https://github.com/fellipeh
>> > Twitter: @fh_bash
>> > ___
>> > 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
>> ___
>> 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
>
> --
> Sent from my iPhone
> ___
> 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
___
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

Re: Tips to add optional arguments on dnf using plugin

[Fellipe Henrique]

So,

Using dnf plugin, I can't do that, if I understand correctly...  As I said
on my last email, I have these coded using yum, like these:

def init_hook(pc):
   '''Initial Hook that configures the repositories'''
   parser = pc.getOptParser()
   if parser:
  parser.add_option('', '--set-repository-layer',
  dest='set_repository_layer',
  action='store', nargs=1)

But, I can't do these using a new plugin approach on dnf, only if I use
command... but command doesn't work with all dnf commands( repolist,
install, remove etc..)

Maybe I need to change my approach, as you said @Nicolas


Cheers!

T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
*Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
*
*Blog: *http:www.fellipeh.eti.br
*GitHub: https://github.com/fellipeh *
*Twitter: @fh_bash*


On Tue, Jul 23, 2019 at 8:11 AM Nicolas Mailhot 
wrote:

> Le 2019-07-23 12:01, Fellipe Henrique a écrit :
>
> Hi
>
> > First, Thanks very much for you reply...
> >
> > I need to add a "global" argument so I can change the layer of a
> > repository... For example:
> >
> > $ dnf repolist --set-layer=mylayer
> > $ dnf install -y any_repo --set-layer=mylayer
>
> On our setup we approximate this via -repo naming
>
> So dnf commands become dnf --disablerepo * --enablerepo -*
>
> Tried to play with passing yum/dnf explicit config paths, that didn’t
> work out so well. (I’ve seen others try to switch personalities via YUMx
> variables, the result is also quite user unfriendly).
>
> Of course that’s some pretty big hammer and that disables the ability to
> preset repos to on or off within a layer. It would be much nicer if
> there was a way to define things as part of a configuration set in
> /etc/yum*, and enable/disable specific configuration sets on the cli.
>
> One use case is reposync, since one typically wants the system to use
> the remote repos once synced, so every repo has one personality for
> reposync, and another for the system dnf itself.
>
> Regards,
>
> --
> Nicolas Mailhot
>
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Vitaly Zaitsev via devel]

Hello, Igor Gnatenko.

Tue, 23 Jul 2019 07:34:06 +0200 you wrote:

> * Define new architecture in RPM/libsolv (let's call it "haswell" or
> "x86_64modern")

I have a better idea: use modules to build special AVX/SSE4 enabled
versions of some packages.

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

Re: Discussion around app retirements and categorizations by the CPE team

[Neal Gompa]

On Tue, Jul 23, 2019 at 5:47 AM Kevin Kofler  wrote:
>
> Alexander Bokovoy wrote:
> > As I said already, my primary worry is where we would clash our needs
> > with those of GitLab commercial entity. For example, Kerberos
> > authentication or SAML SSO for groups, or push rule restrictions are
> > part of commercial offering but not available in the community edition.
> > This makes it harder to integrate with existing workflows and existing
> > dist-git use.
>
> Indeed, GitLab's crippleware approach might become a problem.
>
> With all those high-profile Free Software projects using GitLab, I wonder
> whether a fork is in order.
>

If a fork is necessary for GitLab to be usable for high-profile FOSS
projects long-term, then GitLab is a bad fit. The "friendly fork"
model won't work, because rebasing and integrating upstream with
downstream concerns will be incredibly difficult. The "hard fork"
model will fail because GitLab's complexity is incredibly high, making
it functionally impossible for a community to maintain the fork over
time. It would be a repeat of the Alioth situation all over again...

GitLab's CE/EE split model basically makes it impossible for an
amicable model of community contributions to GitLab, because large
FOSS projects require what they consider Enterprise features. They can
and have rejected things based on this in the past, and will continue
to do so based on that criteria.

Also, for $DAYJOB, I run a GitLab server. If you think maintaining a
GitLab server is easy, you have another think coming. GitLab's
development model basically makes it impossible to have any real
degree of stability, since the codebase churns without concern *very
frequently*. Heck, for three months (that is, three GitLab releases!),
they broke merge requests in GitLab last year when they rewrote merge
requests frontend code in Vuejs... It was that experience that pushed
me to look at Pagure for my personal servers and start contributing to
it in the first place...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Nicolas Mailhot via devel]

Le 2019-07-23 12:48, Peter Robinson a écrit :

On Tue, Jul 23, 2019 at 11:31 AM Nicolas Mailhot via devel
 wrote:


Le 2019-07-23 07:02, drago01 a écrit :

> Please just take back this change and come back at April first if it
> was supposed to be a joke - if not then submit again in about 10
> years.

Fedora used to have the x86 repo for old hardware, and the x86_64 repo
for new hardware. Now that the tech cursor moved enough x86 kernels 
are

being retired, there would be nothing wrong in moving this functional
split at another technical level.


The problem with that is getting someone to do the work. The whole
reason that the i686 kernel was retired was due to people not stepping
up to do the maintenance of the kernel, and the kernel alone.


I’m assuming (perhaps wrongly) that the people proposing the change 
would be ready to maintain the new hardware arch, and shake out the bugs 
associated with the new compiler flags. Because the bulk of us seem 
stuck with older hardware for now.


Regards,

--
Nicolas Mailhot
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Dan Horák]

On Tue, 23 Jul 2019 12:16:45 +0200
Igor Gnatenko  wrote:

> On Tue, Jul 23, 2019 at 12:08 PM Kevin Kofler
>  wrote:
> >
> > Igor Gnatenko wrote:
> > > 1. Lower requirement to something like SSE4 and select other CPU
> > > features which are available in most of CPUs for last decade.
> >
> > Sorry, but -1 to SSE4 too. One of my machines supports only up to
> > SSSE3, and other replies in this thread have also suggested SSSE3
> > as the most we can assume. And if you ask me, we should just stick
> > to SSE2 as the baseline. What are the big gains to be had from
> > SSE3, SSSE3, SSE4.1, and SSE4.2? Especially if you limit it to
> > packages that don't do runtime detection? (Performance-sensitive
> > software SHOULD do runtime detection, and most of it does, e.g.,
> > OpenBLAS.)
> 
> I used SSE4 as an example. Obviously one needs to spend time digging
> into all this and find appropriate set.
> 
> From what I saw, openblas does not do any runtime detection. You
> either compile it with avx2 or not. And in runtime it will check
> whether it was enabled during compilation and use some kind of
> fallback.

openblas can do a runtime CPU detection for x86, aarch64 and Power, if
built accordingly


Dan
___
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

Re: Tips to add optional arguments on dnf using plugin

[Nicolas Mailhot via devel]

Le 2019-07-23 12:01, Fellipe Henrique a écrit :

Hi


First, Thanks very much for you reply...

I need to add a "global" argument so I can change the layer of a
repository... For example:

$ dnf repolist --set-layer=mylayer
$ dnf install -y any_repo --set-layer=mylayer


On our setup we approximate this via -repo naming

So dnf commands become dnf --disablerepo * --enablerepo -*

Tried to play with passing yum/dnf explicit config paths, that didn’t 
work out so well. (I’ve seen others try to switch personalities via YUMx 
variables, the result is also quite user unfriendly).


Of course that’s some pretty big hammer and that disables the ability to 
preset repos to on or off within a layer. It would be much nicer if 
there was a way to define things as part of a configuration set in 
/etc/yum*, and enable/disable specific configuration sets on the cli.


One use case is reposync, since one typically wants the system to use 
the remote repos once synced, so every repo has one personality for 
reposync, and another for the system dnf itself.


Regards,

--
Nicolas Mailhot
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kamil Paral]

On Mon, Jul 22, 2019 at 8:52 PM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> = Detailed Description ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See [
> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].
>

We have 3 test machines in Brno's Fedora QA office, none of which support
AVX2. Both my parents run Fedora on their laptops, none of which support
AVX2. My own desktop machine at home is on the borderline (Haswell).

I consider this proposal a complete no-go.

That said, I think it might be interesting to have a way for newer CPUs to
make use of the new instructions, and people proposed ways to achieve that.
But first, we should gather some performance numbers, whether it's worth it
at all.
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Peter Robinson]

On Tue, Jul 23, 2019 at 11:31 AM Nicolas Mailhot via devel
 wrote:
>
> Le 2019-07-23 07:02, drago01 a écrit :
>
> > Please just take back this change and come back at April first if it
> > was supposed to be a joke - if not then submit again in about 10
> > years.
>
> Fedora used to have the x86 repo for old hardware, and the x86_64 repo
> for new hardware. Now that the tech cursor moved enough x86 kernels are
> being retired, there would be nothing wrong in moving this functional
> split at another technical level.

The problem with that is getting someone to do the work. The whole
reason that the i686 kernel was retired was due to people not stepping
up to do the maintenance of the kernel, and the kernel alone. Having
been one of the few people in the community that's been involved in
and lead arch bring ups and maintained architectures in the bad old
days of secondary koji instances and continue to lead the ARMv7 and
aarch64 architectures I can tell you it's not an insignificant amount
of work, both the initial boot strap and ongoing maintenance. I've
been involved in the alternate architecture projects in Fedora for ~
9.5 years and it's a LOT of work and it's not a do it once and it's
done, it's constant and ongoing.

There needs to be a group of people prepared to put in that level of
effort and from my own personal experience with the various Arm
architectures over the years (armv5, armv7 and aarch64) and the out
come of the i686 project I can tell you there's a lot of people that
demand that there must be something because they need it and just
about no-one who's prepared to actually do the damn well work. People
will quite happily demand you work 24*7 without sleep, complain when
their pet feature doesn't work, or when it fails to boot on their £4
ten year old SD card and insist that it must be fixed yesterday all
while contributing exactly nothing!

Peter
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Igor Gnatenko]

On Tue, Jul 23, 2019 at 12:08 PM Kevin Kofler  wrote:
>
> Igor Gnatenko wrote:
> > 1. Lower requirement to something like SSE4 and select other CPU
> > features which are available in most of CPUs for last decade.
>
> Sorry, but -1 to SSE4 too. One of my machines supports only up to SSSE3, and
> other replies in this thread have also suggested SSSE3 as the most we can
> assume. And if you ask me, we should just stick to SSE2 as the baseline.
> What are the big gains to be had from SSE3, SSSE3, SSE4.1, and SSE4.2?
> Especially if you limit it to packages that don't do runtime detection?
> (Performance-sensitive software SHOULD do runtime detection, and most of it
> does, e.g., OpenBLAS.)

I used SSE4 as an example. Obviously one needs to spend time digging
into all this and find appropriate set.

From what I saw, openblas does not do any runtime detection. You
either compile it with avx2 or not. And in runtime it will check
whether it was enabled during compilation and use some kind of
fallback.

> > 2. Build every package on x86_64 twice (one for compatible set and one
> > for this new-features set), possibly by introducting sub-architecture
> > in koji or using koji-shadow (that's just implementation detail.
> > Produce an official spin which is built from these packages.
>
> That would at least be tolerable, but still, I'm against it. It sounds like
> a huge waste of resources for very little practical gain to me.

Nicolas pointed out that it is possible to add extra arches on package
basis. So if we choose to just build some packages with these settings
enabled, we can do that. But if from the change would benefit most of
the packages, building all of them sounds reasonable.

And after all, it is Fedora resources, so you probably don't have to
care much about it. It is also not some uncommon architecture where 1
server costs billions. So I think if benefit is big, we could find
resources for doing this.

>
> > 3. Invent some mechanism for selecting appropriate feature set in
> > runtime (somebody mentioned fat binaries in this thread).
>
> We already have 2 such mechanisms:
> * several upstream software packages check CPUID directly. See, e.g., how
>   OpenBLAS does it. Or the performance-sensitive parts of Chromium. Etc.

You can't do several things with this, like FMA.

> * you can drop optimized builds of entire shared objects (.so) into an
>   appropriate subdirectory of %{_libdir}. Some profiles such as haswell are
>   already supported. If we need more, they can be added.

You are talking about libraries while I am talking about binaries.

> So I don't see a need for fat binaries.
>
> Kevin Kofler
> ___
> 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
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Peter Robinson]

On Tue, Jul 23, 2019 at 11:09 AM Kevin Kofler  wrote:
>
> Patrik Mattsson wrote:
> > I would take the lowest denominator of features for CPUs of atleast 3
> > years of age considering how long some CPUs are being used in virtualized
> > environments and at a lot of different cloud-providers (I've seen 5+ year
> > old CPUs in at some smaller providers).
>
> At least 10 years!
>
> My notebook is 11 years old and still working. Here in Austria, that makes
> me look weird, but there are countries in this world where such machines are
> much more common place. See, e.g., Zamir Sun's reply about China. And there
> are even poorer countries out there.
>
> So no, 3 years are not sufficient.

I'm still getting complaints from groups when the same team bumped the
i686 compile flags, which I somehow missed the proposal, for newer
processors because their 10+ year old OLPC XO laptops can't run the
newer software.
___
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

Re: Tips to add optional arguments on dnf using plugin

[Fellipe Henrique]

Hi Marek,

First, Thanks very much for you reply...

I need to add a "global" argument so I can change the layer of a
repository... For example:

$ dnf repolist --set-layer=mylayer
$ dnf install -y any_repo --set-layer=mylayer

So on my plug-in I can change layer in repository to do anything, for that
running process, to a different layer. (For example)..

That's the reason I need a "global" argument, not a command, so I can use
these arg on any dnf command, like "-v" argument..

I saw your email related to reposync, but reposync use a command, so I need
to add a command "reposync" and its arguments... As I explain above, I need
a global argument to work with all dnf commands...

That's my real problem, I do not know if dnf plug-in give me access to do
that...

On yum, I made these using *init_hook()* def, and setting the args.. But
dnf doesn't no have init_hook anymore

Again, thanks for your time and help, any tips will be welcome..

Cheers!

Fellipe H.

Em ter, 23 de jul de 2019 às 03:37, Marek Blaha 
escreveu:

> Each DNF command could have static method set_argparser (here is the
> example from reposync plugin:
>
> https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/reposync.py#L60
> )
> which can be used for adding command specific arguments. However there
> is no such method for adding global arguments.
> May I ask you to elaborate your use case in more details? What are you
> trying to achieve?
>
> Regards,
>
> Marek
>
> --
> Marek Blaha 
>
> Red Hat Czech s.r.o.
> Software Engineer
>
> On Mon, Jul 22, 2019 at 7:59 PM Fellipe Henrique 
> wrote:
> >
> > Hello,
> >
> > First of all, thanks for accept me on these mail list.. my first mail
> it's about a issue I facing here on my job...
> >
> > I need to add some optional arguments on dnf,  not a command, just a
> "global" args.. eg:  $ dnf repolist --my_arg=abcd
> >
> > How can I do these? Can I use plugin with these approach?
> >
> > I already try to override OptionParser from cli inside Plugin class, no
> success... I try just parse cli args, but dnf still says my argument if not
> recognized..
> >
> > Anyone, have any tips how to do that?
> >
> > Best regards,
> >
> > T.·.F.·.A.·. S+F
> > Fellipe Henrique P. Soares
> >
> > e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \
> 's/(.)/chr(ord($1)-2*3)/ge'
> > Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
> > Blog: http:www.fellipeh.eti.br
> > GitHub: https://github.com/fellipeh
> > Twitter: @fh_bash
> > ___
> > 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
> ___
> 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
>
-- 
Sent from my iPhone
___
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

Re: Discussion around app retirements and categorizations by the CPE team

[Nicolas Mailhot via devel]

Le 2019-07-23 09:23, Mikolaj Izdebski a écrit :

On Mon, Jul 22, 2019 at 11:20 AM Nicolas Mailhot via devel
 wrote:
Huge Red Hat investments, in the Java ecosystem, that fail to 
translate
into an healthy Fedora Java ecosystem. To the point that when IBM 
wants
its Java guys to join there is absolutely no one Fedora-side to 
provide

an on-boarding path.


There are multiple active Fedora Java package maintainers employed by
Red Hat. I'm among them as full-time packager for RHEL and Fedora,
always ready to help newcomers. We have extensive documentation
covering specifics of Java packaging. There is no problem with
onboarding new Java packagers, other than lack of people to be
onboarded.


That is not true. Search the list archive for Michael Zhang’s questions 
on how to get Open Liberty in Fedora. About 4 months later, can anyone 
do a dnf install open liberty, pointing to a Fedora repo?


Regards,

--
Nicolas Mailhot
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Tom Hughes]

On 23/07/2019 10:40, Peter Robinson wrote:

After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline.  AVX2 support was introduced into CPUs from 2013 to
2015. See 
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].


This is not what I'd call a good idea. I've had to shoot it down
several times on internal mailing lists for RHEL, I think it's even
less a good idea for Fedora.

Skylake Pentium and Celeron models - dating from 2015 - don't have AVX
at all. Why do we want to break them? Has Intel promised they're not
going to pull a trick like that again?

If we really want to chase after Clear Linux benchmarks then fix ld.so
to know that avx2 is a capability (like we could for i686 + sse2).
Moving the baseline like this is far, far too aggressive.


IBM did something to run optimised Power9 binaries on Power8, if I
remember correctly it was IFUNC in glibc, so they could have optimised
paths so I don't see why the same sort of thing couldn't be used for
the AVX2.


It absolutely can, as discussed extensively on IRC last night...

There's a pretty good summary here https://lwn.net/Articles/691932/ but
broadly speaking you can either use the target_clones attribute on a
function to have gcc compile multiple versions for different targets
along with an ifunc to choose one at run time, or if you have your own
hand rolled implementations then mark them with the target attribute
and let gcc create the ifunc.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update - why not FMV?

[Adrian Sevcenco]

On 7/22/19 9:51 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update

Along with AVX2, it makes sense to enable certain other CPU features
which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
earlier vector extensions such as SSE 4.2.  Details are still being
worked out.

And why not use FMV?? the gcc/glibc is new enough, FMV could be 
implemented package by package ... using clear linux make-fmv-patch 
recipe one can adapt the code to various capabilities (and of course the 
patches can be contributed upstream, tweaked and customized)


Adrian



smime.p7s
Description: S/MIME Cryptographic 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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Peter Robinson]

> > After preliminary discussions with CPU vendors, we propose AVX2 as the
> > new baseline.  AVX2 support was introduced into CPUs from 2013 to
> > 2015. See 
> > [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> > CPUs with AVX2].
>
> This is not what I'd call a good idea. I've had to shoot it down
> several times on internal mailing lists for RHEL, I think it's even
> less a good idea for Fedora.
>
> Skylake Pentium and Celeron models - dating from 2015 - don't have AVX
> at all. Why do we want to break them? Has Intel promised they're not
> going to pull a trick like that again?
>
> If we really want to chase after Clear Linux benchmarks then fix ld.so
> to know that avx2 is a capability (like we could for i686 + sse2).
> Moving the baseline like this is far, far too aggressive.

IBM did something to run optimised Power9 binaries on Power8, if I
remember correctly it was IFUNC in glibc, so they could have optimised
paths so I don't see why the same sort of thing couldn't be used for
the AVX2.

If Intel is so determined to make their processors look remotely
competitive again with the likes of Spectre and Meltown maybe they
should look into things like that?

Looking at the Intel x86 devices we're supporting for IoT, even the
latest available, none of them report any form of AVX.
___
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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Nicolas Mailhot via devel]

Le 2019-07-23 07:02, drago01 a écrit :


Please just take back this change and come back at April first if it
was supposed to be a joke - if not then submit again in about 10
years.


Fedora used to have the x86 repo for old hardware, and the x86_64 repo 
for new hardware. Now that the tech cursor moved enough x86 kernels are 
being retired, there would be nothing wrong in moving this functional 
split at another technical level.


Old hardware and new hardware will always exist. Trying to handle both 
in a single arch is just going to clash somewhere.


Regards,

--
Nicolas Mailhot
___
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

Re: Discussion around app retirements and categorizations by the CPE team

[Nicolas Mailhot via devel]

Le 2019-07-23 08:32, Alexander Bokovoy a écrit :

On ma, 22 heinä 2019, Jeremy Cline wrote:

On Mon, Jul 22, 2019 at 06:59:04PM +0300, Alexander Bokovoy wrote:

On ma, 22 heinä 2019, Jeremy Cline wrote:
> On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote:
> > Keycloak is not generally Fedora contributor friendly. Aside from it
> > being written in Java (which is problematic with the Java stack in
> > Fedora slowly imploding...), Keycloak is a lot less flexible and a lot
> > more tied to aspects of RHEL/Fedora that make it annoying to use in
> > other environments.
>
> This sounds more like an issue with Fedora's Java stack. I don't love
> Java anymore than anyone else (I think), but I really don't understand
> why a language plays such a huge role.

It is mostly due to supportability of the packages in Fedora. Java
products tend to be split into smaller packages and an overhead for
maintaining them grows a lot. In 2019 Fedora Java packages got 
dropped
by one of maintainers and that created a havoc as many packages 
depend
on few important ones that were suddenly not supported anymore and 
were

going to be orphaned.


The same is, I think, true of many other languages. I think it's a 
sign
that our approach to packaging is going to have to change. Just 
looking
at the package stats by language at https://libraries.io/ and 
comparing

it to the size of the Fedora repositories is telling.
That or those language libraries' repositories would need to evolve 
too.

After all, not all of them have strong authenticity guarantees and
ability to account for changes on a local installation.


It is unrealistic to expect those repositories to evolve towards 
something easier to deploy in production, when the tooling we use to 
prepare and deploy in production is seen as dated, awkward to use, and 
not keeping up with the times.


The first answer language package upstreams will give (and have already 
been giving for several years) is “fix your own tools and then we'll 
talk. I don’t want to work with your legacy pile of *.”


20 years ago rpm was on the bleeding edge of innovation and projects 
were happy to accommodate its needs to partake in a bright new future. 
It’s not anymore. It didn’t keep up. And that’s not because the people 
who work on rpm are not outstanding contributors, that’s because they’ve 
been tasked to do minimal changes without rocking the boat (and given 
the corresponding resources).


Regards,

--
Nicolas Mailhot
___
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