Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 09, 2020 at 05:23:16PM -0500, Ben Cotton wrote:
> On Thu, Jan 9, 2020 at 5:03 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > 4. This certainly needs to be a "system wide change" with the related
> >additional info required for such changes. We certainly need releng
> >to sign off on this.
> >
> Apart from potential capacity impacts, this seems self-contained.

Changes (in the sense of spec conditionals and such) to some
yet-undefined subset of packages may necessary (for example if the
architecture change has some effect on floating point computations,
this could have a wide impact on packages doing numerical tests). So
there is a potential for interaction with a large number of packagers.

System-wide changes are also more widely announced (for example they
are listed prominently in the release notes), which imo would be
appropriate for something like a new architecture.

Because of those two reasons, I'd argue that the category should be
changed, but if you disagree, let's not discuss this further.

> I'll
> grant that a reduced builder capacity would impact other contributors,
> but that doesn't seem like the kind of case the system-wide change
> definition is designed for.
> 
> The change owner (bookwar) has already opened a ticket with RelEng[1]
> and they will discuss what work is necessary for this at the next
> meeting.
> 
> [1] https://pagure.io/releng/issue/9154

OK, thanks.

Zbyszek
___
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 (late): Enable EarlyOOM

[Lennart Poettering]

On Mi, 08.01.20 12:24, Chris Murphy (li...@colorremedies.com) wrote:

> On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering  
> wrote:
> >
> > - facebook is working on making oomd something that just works for
> >   everyone, they are in the final rounds of canonicalizing the
> >   configuration so that it can just work for all workloads without
> >   tuning. The last bits for this to be deployable are currently being
> >   done on the kernel side ("iocost"), when that's in, they'll submit
> >   oomd (or simplified parts of it) to systemd, so that it's just there
> >   and works. It's their expressive intention to make this something
> >   that also works for desktop stuff and requires no further
> >   tuning. they also will do the systemd work necessary. time frame:
> >   half a year, maybe one year, but no guarantees.
>
> Looks like PSI based oom killing doesn't work without swap. Therefore
> oomd can't be considered a universal solution. Quite a lot of
> developers have workstations with quite a decent amount of RAM,
> ~64GiB, and do not use swap at all. Server baremetal are likewise
> mixed, depending on workloads, and in cloud it's rare for swap to
> exist.
>
> https://github.com/facebookincubator/oomd/issues/80
>
> We think earlyoom can be adjusted to work well for both the swap and
> no swap use cases.

Isn't rearlyoom also watching the swap metrics only?

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: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Aleksandra Fedorova]

Hi, Neal,

On Thu, Jan 9, 2020 at 10:01 PM Neal Gompa  wrote:
>
> On Thu, Jan 9, 2020 at 12:17 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Additional_buildroot_to_test_x86-64_micro-architecture_update
> >
> > == Summary ==
> >
> > Create a dedicated buildroot to test packages built with x86-64
> > micro-architecture update.
> >
> > == Owner ==
> >
> > * Name: [[User:bookwar| Aleksandra Fedorova]]
> > * Email: [mailto:al...@bookwar.info al...@bookwar.info]
> > * Name: [[User:fweimer| Florian Weimer]]
> > * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
> >
> > == Detailed Description ==
> >
> > Fedora currently uses the original K8 micro-architecture (without
> > 3DNow! and other AMD-specific parts) as the baseline for its x86_64
> > architecture. This baseline dates back to 2003 and has not been
> > updated since. As a result, performance of Fedora is not as good as it
> > could be on current CPUs.
> >
> > Changing the main Fedora baseline to new CPUs in place
> > [[Changes/x86-64 micro-architecture update|was rejected]] as the user
> > base for older machines is still large. But we’d like to unblock the
> > development and testing of this feature.
> >
> > == Benefit to Fedora ==
> >
> > * Allow development and verification of the CPU baseline update in
> > Fedora without disrupting users of Fedora on older machines.
> > * Collect real life data on performance improvements, which can help
> > making decision on the baseline update.
> > * As soon as feature is accepted by the community, there will be a
> > smooth process to update baseline in the main Fedora, as all packages
> > will be already verified and tested to work against it.
> > * Until the switch of the main x86_64 architecture, interested parties
> > can install systems from the updated buildroot for performance
> > experiments.
> >
> > == Scope ==
> >
> > * Proposal owners:
> > ** define new disttag for the buildroot
> > ** provide updated gcc package which implements the new compiler
> > flags. It is expected that the new baseline will be implemented in a
> > new GCC -march= option for convenience.
> > ** provide update to rpm-config package which changes default compiler
> > options for the disttag
> > ** setup automation so that for each build submitted to Fedora Rawhide
> > there is a build submitted to the additional buildroot. Result of the
> > build task will be posted to Fedora Messaging and consumed by
> > ResultsDB, so that it appears in Bodhi
> > ** setup automation to run periodic partial composes (via ODCS)
> > without installation media to generate repositories with these
> > packages
> > ** update packaging documentation to mention new disttag and how it can be 
> > used
> > ** create landing page to describe the purpose and usages of the
> > buildroot in Fedora Wiki
> >
>
> Three things I'm concerned about:
>
> 1. Our builder resources are squeezed enough as it is. In doing this,
> are we going to get more machines so that we can have more builders?
> Between modules and this, I worry our resources will get squeezed far
> too tightly for my comfort.

In this change we are looking for x86_64 builders only, and we will
run one additional build for every regular (non-scratch) build in
Fedora rawhide. I think the load it brings should be bearable, but
maybe Releng can provide the estimate.

> 2. This feature does not describe what the new microarchitecture
> baseline will be. I *could* assume it's the crazy new
> microarchitecture that was proposed in the rejected Change, but I
> don't want to make that assumption. Please specify.

The rejected change
https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
is explicitly referenced from the current one. So yes, it is the
architecture update we are looking for.

And I would suggest to avoid calling things weird and crazy just
because you are not interested in them.

> 3. Why is this in the main Koji and require a new disttag? Why not
> just do a shadow Koji and build in an alternate path? Every other
> architecture bringup has required this process, I don't see why this
> one wouldn't too. That would also deal with my concern for (1), since
> a shadow Koji would be required to have its own builder resources
> separate from the main one.

1) There is no new architecture, it is the same x86_64 architecture as
usual, with only the default compiler flags changed.
Thus, unlike with other architectures, there is no need for new
hardware and new koji builders. We can use exactly the same x86_64
koji-builders as usual, which saves resources of Releng and other
teams.

2) Separation of resources is not really a solution for the lack of
capacity. It makes it worse, because separate resources can not be
used by other tasks.
It is usually more effective to have a shared pool of compute(in our
case - build) power, and use it for various tasks, prioritizing them.
In the proposed setup there will be a CI machinery, which will trigger
new builds for ever

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Florian Weimer]

* Neal Gompa:

> 1. Our builder resources are squeezed enough as it is. In doing this,
> are we going to get more machines so that we can have more builders?
> Between modules and this, I worry our resources will get squeezed far
> too tightly for my comfort.

Please send me the required hardware specs and number of machines.

> 2. This feature does not describe what the new microarchitecture
> baseline will be. I *could* assume it's the crazy new
> microarchitecture that was proposed in the rejected Change, but I
> don't want to make that assumption. Please specify.

It's going the be AVX2 with or without VZEROUPPER.  We'll try without
VZEROUPPER first, but if that has too poor performance for legacy
software, we need to build with VZEROUPPER.

> 3. Why is this in the main Koji and require a new disttag? Why not
> just do a shadow Koji and build in an alternate path?

It was the best approach we came up with.  If there better ways to
implement this, that's fine too.

We do not want to change the RPM architecture, so that users still can
install third-party software.  This means that we need to change the
dist tag to avoid confusion.

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

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Nicolas Chauvet]

Le ven. 10 janv. 2020 à 10:29, Florian Weimer  a écrit :
>
> * Neal Gompa:
>
> > 1. Our builder resources are squeezed enough as it is. In doing this,
> > are we going to get more machines so that we can have more builders?
> > Between modules and this, I worry our resources will get squeezed far
> > too tightly for my comfort.
>
> Please send me the required hardware specs and number of machines.
>
> > 2. This feature does not describe what the new microarchitecture
> > baseline will be. I *could* assume it's the crazy new
> > microarchitecture that was proposed in the rejected Change, but I
> > don't want to make that assumption. Please specify.
>
> It's going the be AVX2 with or without VZEROUPPER.  We'll try without
> VZEROUPPER first, but if that has too poor performance for legacy
> software, we need to build with VZEROUPPER.
>
> > 3. Why is this in the main Koji and require a new disttag? Why not
> > just do a shadow Koji and build in an alternate path?
>
> It was the best approach we came up with.  If there better ways to
> implement this, that's fine too.

Why not to use a copr repo for this ?
I don't think you will rebuild the whole distro there, but a selected
set of packages will be a relevant step to provide some numbers.


-- 
-

Nicolas (kwizart)
___
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 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Neal Gompa]

On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer  wrote:
>
> We do not want to change the RPM architecture, so that users still can
> install third-party software.  This means that we need to change the
> dist tag to avoid confusion.
>

Changing the RPM architecture does not necessarily mean that you
wouldn't remain compatible with baseline x86_64. For example,
OpenMandriva's build of the distribution optimized for first
generation AMD Ryzen systems uses the "znver1" RPM architecture, but
the "znver1" architecture is deliberately considered compatible with
x86_64, so packages that are "x86_64" are still installable. There are
numerous examples of this for 32-bit x86, and there's no reason we
couldn't do this for 64-bit x86.


-- 
真実はいつも一つ！/ 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 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Florian Weimer]

* Neal Gompa:

> On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer  wrote:
>>
>> We do not want to change the RPM architecture, so that users still can
>> install third-party software.  This means that we need to change the
>> dist tag to avoid confusion.
>>
>
> Changing the RPM architecture does not necessarily mean that you
> wouldn't remain compatible with baseline x86_64. For example,
> OpenMandriva's build of the distribution optimized for first
> generation AMD Ryzen systems uses the "znver1" RPM architecture, but
> the "znver1" architecture is deliberately considered compatible with
> x86_64, so packages that are "x86_64" are still installable. There are
> numerous examples of this for 32-bit x86, and there's no reason we
> couldn't do this for 64-bit x86.

But the value of %_arch still changes, right?

I believe this will break things, like this:

| F ?= $(shell test ! -e /etc/fedora-release && echo 0; test -e 
/etc/fedora-release && rpm --eval %{fedora})
| ARCH  ?= $(shell test ! -e /etc/fedora-release && uname -m; test -e 
/etc/fedora-release && rpm --eval %{_arch})
| MOCK_CFG  ?= $(shell test -e /etc/fedora-release && echo 
fedora-$(F)-$(ARCH))



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

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Neal Gompa]

On Fri, Jan 10, 2020 at 5:05 AM Florian Weimer  wrote:
>
> * Neal Gompa:
>
> > On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer  wrote:
> >>
> >> We do not want to change the RPM architecture, so that users still can
> >> install third-party software.  This means that we need to change the
> >> dist tag to avoid confusion.
> >>
> >
> > Changing the RPM architecture does not necessarily mean that you
> > wouldn't remain compatible with baseline x86_64. For example,
> > OpenMandriva's build of the distribution optimized for first
> > generation AMD Ryzen systems uses the "znver1" RPM architecture, but
> > the "znver1" architecture is deliberately considered compatible with
> > x86_64, so packages that are "x86_64" are still installable. There are
> > numerous examples of this for 32-bit x86, and there's no reason we
> > couldn't do this for 64-bit x86.
>
> But the value of %_arch still changes, right?
>
> I believe this will break things, like this:
>
> | F ?= $(shell test ! -e /etc/fedora-release && echo 0; test -e 
> /etc/fedora-release && rpm --eval %{fedora})
> | ARCH  ?= $(shell test ! -e /etc/fedora-release && uname -m; test -e 
> /etc/fedora-release && rpm --eval %{_arch})
> | MOCK_CFG  ?= $(shell test -e /etc/fedora-release && echo 
> fedora-$(F)-$(ARCH))
>

It will break _that_ specifically, yes. But it is not okay to make
this muddier than it already is. If we are changing the definition of
x86_64 in Fedora, that's one thing. But you are not proposing that.
Therefore, it needs a different architecture classification.

And as an aside, that particular code would still break even if you
were using just a weird DistTag change, because a separate build root
means a separate mock configuration.


-- 
真実はいつも一つ！/ 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: Let's talk about Fedora in the '20s!

[Tomas Tomecek]

On Tue, Jan 7, 2020 at 1:51 PM Miro Hrončok  wrote:
>
> For me, an ultimate success would be if upstream projects would actually use
> Fedora-family distros in their CI testing. And I don't mean that they would 
> use
> Copr or packit to package RPM packages, or that they deploy their own Jenkins 
> on
> CentOS, I mean that they would use something as easy as Travis CI, but instead
> of ancient Ubuntu, they could choose from a variety of Fedora systems.

Yup, exactly! In packit we're doing it the hard way since we force
them to embrace spec files and RPM packaging format. I wouldn't be
personally too opposed to an idea where upstream projects could start
w/o RPM packaging and just run their tests on Fedora and then, slowly,
ramp up to have an RPM package out of their project up to automate
release into rawhide.

> Unfortunately I don't see this happening without RH partnering up with a major
> CI provider or without significant investment in providing our own public CI
> (sans RPM) - however we are now discontinuing services, not adding new.

We actually had a discussion in December before the break, whether we
would enable a workflow in packit that you would not need spec and
would be able to test your software directly from the git repo - the
same thing as travis or circle does. As far as I recall, the idea is
still on the table.


Tomas
___
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: Upgrading libffi

[Anthony Green]

Anthony Green  writes:
> Kevin Fenzi  writes:
>> I suppose you could also
>> add both old and new libffi source to the libffi package and build them
>> both (old to compat), rebuild in side tag and drop the old
>> sources/compat.

>> Does that make sense?
>
> I like this idea because it seems simple.

I did go this route.  I now have a libffi spec file that installs both
the .6 and .7 versions of the library (I didn't even break out the .6
version into a compat package).  I'm currently doing local mock builds
of the 90+ packages that depend directly on libffi.  Once all of them
build locally, my plan is to commit my franken-package to rawhide and
arrange for those 90+ rawhide packages to be built.  Once those are
rebuilt, I simply clean up the libffi spec, removing the .6 version.

Objections?

AG

-- 
Anthony Green  
___
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 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Chris Adams]

Once upon a time, Aleksandra Fedorova  said:
> The rejected change
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> is explicitly referenced from the current one. So yes, it is the
> architecture update we are looking for.
> 
> And I would suggest to avoid calling things weird and crazy just
> because you are not interested in them.

The premise of the new change request is to ignore all the issues that
led to the original change request being rejected, and just assume that
the original will be accepted in the near future.

AVX2 is not a reasonable requirement as a replacement for the current
Fedora x86_64, as there are CPUs still being made today that don't
support that.  If you want to split x86_64 (along the lines of i386 vs.
i686), then building a shadow copy of the entire distribution is not a
good way forward - you need to do all the actual work required to make a
second x86_64 sub-architecture in the main x86_64 distribution.  Come up
with a name, make the changes to the required packages, etc.

Otherwise, what is the point of the shadow architecture?  What is the
end goal?  Build it in perpetuity and just try to get people to run your
packages instead of the main distribution?

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

Re: This update's test gating status has been changed to, 'greenwave_failed'.

[Pierre-Yves Chibon]

On Tue, Dec 24, 2019 at 12:45:25PM +0100, Ismael Olea wrote:
>On Mon, Oct 7, 2019 at 9:44 AM Pierre-Yves Chibon <[1]pin...@pingoured.fr>
>wrote:
> 
> 
>  It likely was. Bodhi called greenwave to ask about a status of the
>  builds in an
>  update, greenwave calls Koji for more information, that calls returned
>  an error.
>  Greenwave's request returns an error as well.
>  Bodhi is not able to distinguish where the error is coming from and thus
>  set the
>  status to "greenwave_failed".
> 
>So, this mean Bodhi will reject to move the package to updates or not? :-?
>It's happening to me too[1].
>[1] [2]https://bodhi.fedoraproject.org/updates/FEDORA-2019-d9a4a2d770

Sorry for the late reply.
For historical reasons, bodhi treats the "greenwave_failed" status as "passed",
so it will not gate updates if greenwave failed to give it a go/nogo answer.

On the top of that, bodhi checks all un-pushed update when it calls greenwave
which is why we sometime see this toggling.
I have argued in the past that once an update passed greenwave we shouldn't ask
greenwave if it changed its mind but the idea was then turned down.


Pierre
___
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 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Josh Boyer]

On Fri, Jan 10, 2020 at 8:37 AM Chris Adams  wrote:
>
> Once upon a time, Aleksandra Fedorova  said:
> > The rejected change
> > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> > is explicitly referenced from the current one. So yes, it is the
> > architecture update we are looking for.
> >
> > And I would suggest to avoid calling things weird and crazy just
> > because you are not interested in them.
>
> The premise of the new change request is to ignore all the issues that
> led to the original change request being rejected, and just assume that
> the original will be accepted in the near future.

I don't believe that is fair or even true.  The premise of the new
change is to allow alternative experimentation within Fedora proper
without impacting the mainline distribution.  There is no assumption
that the results will magically replace Fedora in the near future.

> AVX2 is not a reasonable requirement as a replacement for the current
> Fedora x86_64, as there are CPUs still being made today that don't
> support that.  If you want to split x86_64 (along the lines of i386 vs.
> i686), then building a shadow copy of the entire distribution is not a
> good way forward - you need to do all the actual work required to make a
> second x86_64 sub-architecture in the main x86_64 distribution.  Come up
> with a name, make the changes to the required packages, etc.

I think we're focusing entirely too much on the initial interest for
this alternative buildroot and being very myopic about it.  Let's take
a step back.

> Otherwise, what is the point of the shadow architecture?  What is the
> end goal?  Build it in perpetuity and just try to get people to run your
> packages instead of the main distribution?

If we look at the additional possibilities this offers outside of CPU
tuning, I find it rather intriguing.  Having infrastructure that
allows for alternative buildroots to be created and leverage mainline
Fedora activities allows for all kinds of experimentation.  Perhaps
it's not CPU tuning, but compiler optimization tuning.  Perhaps it's
building the distro with a different compiler in general.

Fedora is very good at producing a singular distro, and it has been
very poor at providing a way to deviate at scale from that singular
distro.  Copr is good for small scale, but attempting to build the
whole distro there is overly arduous to the point where people don't
even try.  The part of this proposal that interest me is being able to
easily piggyback on day to day Fedora activities to accomplish that
scale.  Koji-shadow is the only way to do this today, and it requires
people to duplicate everything in the infrastructure themselves.  It's
also extremely invasive to merge back into Fedora proper.  If Fedora
had a way to provide that without requiring the investment overhead,
I'd be really curious to see what kind of innovative things could come
from it.

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

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Chris Adams]

Once upon a time, Josh Boyer  said:
> I don't believe that is fair or even true.  The premise of the new
> change is to allow alternative experimentation within Fedora proper
> without impacting the mainline distribution.  There is no assumption
> that the results will magically replace Fedora in the near future.

The detailed description says:

  "Changing the main Fedora baseline to new CPUs in place was rejected
   as the user base for older machines is still large. But we’d like to
   unblock the development and testing of this feature."

What is the point in continuing development of a rejected feature, other
than to hope that it is accepted in the future?

I guess I just don't see the benefit to Fedora to stretch infrastucture
resources even thinner to support somebody's pet project of a feature
that has already been rejected.  It feels like the goal is to prove (for
some value of "prove") that the original change is right (for some value
of "right") and then push it through despite the original objections.
If somebody wants to do that, then IMHO they should handle all the
resources, not put it on Fedora.

There may be other interesting things this expanded infrastucture could
be used for, but nobody is actually proposing that.  What if doing it
for the shadow architecture prevents it being done for anything else
(because there aren't enough resources)?

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

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Aleksandra Fedorova]

Hi, Chris,

On Fri, Jan 10, 2020 at 2:37 PM Chris Adams  wrote:
>
> Once upon a time, Aleksandra Fedorova  said:
> > The rejected change
> > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> > is explicitly referenced from the current one. So yes, it is the
> > architecture update we are looking for.
> >
> > And I would suggest to avoid calling things weird and crazy just
> > because you are not interested in them.
>
> The premise of the new change request is to ignore all the issues that
> led to the original change request being rejected, and just assume that
> the original will be accepted in the near future.

No. Afaik, the main reason the change was rejected is that we are not
ready yet (or don't see yet the reason) for the update of the
architecture. And the benefit of such an update is unclear.

Thus we design this change to be explicitly standalone with no impact
on the current Fedora release. We want to have a separate test
environment where we can experiment with the architecture updates
(compiler flag changes and new features). This test environment is
needed to preview and test the changes ahead of time.

So that in next years, when (and I do believe that there will be such
moment, while it might be that the final configuration flags will be
different from those proposed right now) we decide to update the
baseline, we have much better understanding on what changes are needed
and which benefits we can get from it, and we don't have to squeeze
them into one single mass rebuild in one particular moment in the
release cycle.

> AVX2 is not a reasonable requirement as a replacement for the current
> Fedora x86_64, as there are CPUs still being made today that don't
> support that.  If you want to split x86_64 (along the lines of i386 vs.
> i686), then building a shadow copy of the entire distribution is not a
> good way forward - you need to do all the actual work required to make a
> second x86_64 sub-architecture in the main x86_64 distribution.  Come up
> with a name, make the changes to the required packages, etc.
>
> Otherwise, what is the point of the shadow architecture?  What is the
> end goal?  Build it in perpetuity and just try to get people to run your
> packages instead of the main distribution?

There is no intent to provide those packages to the regular user or
make a separate Fedora Edition out of them. There will be no releases
of repositories or media with such packages. It is only an
experimental test environment linked to the Fedora Rawhide state.

The end goal of this is not to add new architecture but to have a
possibility to move actual Fedora configuration forward, without
breaking it. Which means preparing and testing changes as close as
possible to Fedora mainline, but without disrupting it.

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

-- 
Aleksandra Fedorova
bookwar
___
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 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Chris Adams]

Once upon a time, Aleksandra Fedorova  said:
> No. Afaik, the main reason the change was rejected is that we are not
> ready yet (or don't see yet the reason) for the update of the
> architecture. And the benefit of such an update is unclear.

I disagree that that was the reason - the fact that Fedora would no
longer run on hardware being made and sold today was a big issue, and is
in no way addressed.

> There is no intent to provide those packages to the regular user or
> make a separate Fedora Edition out of them. There will be no releases
> of repositories or media with such packages. It is only an
> experimental test environment linked to the Fedora Rawhide state.

The scope says there will be repositories generated.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Josh Boyer]

On Fri, Jan 10, 2020 at 9:13 AM Chris Adams  wrote:
>
> Once upon a time, Josh Boyer  said:
> > I don't believe that is fair or even true.  The premise of the new
> > change is to allow alternative experimentation within Fedora proper
> > without impacting the mainline distribution.  There is no assumption
> > that the results will magically replace Fedora in the near future.
>
> The detailed description says:
>
>   "Changing the main Fedora baseline to new CPUs in place was rejected
>as the user base for older machines is still large. But we’d like to
>unblock the development and testing of this feature."
>
> What is the point in continuing development of a rejected feature, other
> than to hope that it is accepted in the future?

As an experiment.  To see if it actually has real, tangible benefit.
Plus, the concept here opens other possibilities for different
experiments.  Fedora, despite being a fast-paced and recent
distribution, doesn't really handle experimentation well.  It's
entirely OK to try something and fail, but we simply don't do that.

Also, "future" and "near future" are different, right?  I am confident
the Change proposers believe this is correct for some future version
of Fedora but I do not at all believe they intend to do this and then
switch 2 Fedora releases from now.  This isn't an attempt to subvert a
rejection.

> I guess I just don't see the benefit to Fedora to stretch infrastucture
> resources even thinner to support somebody's pet project of a feature
> that has already been rejected.  It feels like the goal is to prove (for
> some value of "prove") that the original change is right (for some value
> of "right") and then push it through despite the original objections.
> If somebody wants to do that, then IMHO they should handle all the
> resources, not put it on Fedora.

Setting up their own resources is an approach, it's not out-of-hand
incorrect, and it is what Fedora has asked people to do for a while
now.  For net-new architectures (say MIPS or RISC-V), it might even be
the most reasonable approach considering the failures that would be
associated with that kind of bringup.  However, my concern there is
that it encourages people to just do it outside of Fedora entirely
because the cost is the same.  They get no benefit from our community,
and Fedora gets no benefit from the work they're doing.  The ability
to have an alternative buildroot that is targeted at something more
stable and easily accomplished seems like it would benefit Fedora more
in the long run.

> There may be other interesting things this expanded infrastucture could
> be used for, but nobody is actually proposing that.  What if doing it
> for the shadow architecture prevents it being done for anything else
> (because there aren't enough resources)?

What if we never did anything new because it might require work or
resources or change?  Sounds like a great way to become irrelevant
over time in a frog-in-boiling-water kind of way.

I'm not trying to be adversarial here.  I do think it's reasonable to
consider these things.  But to immediately punt on them as the
knee-jerk reaction is a mentality that I think will hurt Fedora far
more than attempting something and having to scale back if it's too
invasive.

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

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Chris Adams]

Once upon a time, Josh Boyer  said:
> As an experiment.  To see if it actually has real, tangible benefit.

I guess my biggest issue with it is the proposal does nothing to address
the harm of the original proposal (namely, that Fedora would no longer
support some brand-new hardware).  To me, it doesn't really matter how
much benefit the original change has to the hardware it does support if
it kills support for hardware on the market today, and that makes the
whole proposal moot.

I feel the way forward is going to be along the lines of the i386/i686
changes back in the day, and any effort should be towards that, not just
throwing out support for current hardware because it'll make Fedora run
faster on a subset of current hardware.  I'd guess that everybody
already accepts that at least some packages would show performance
benefits from changing the baseline, but... so what?  Why go to all this
effort to prove it?
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Aleksandra Fedorova]

On Fri, Jan 10, 2020 at 9:16 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Jan 09, 2020 at 05:23:16PM -0500, Ben Cotton wrote:
> > On Thu, Jan 9, 2020 at 5:03 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > 4. This certainly needs to be a "system wide change" with the related
> > >additional info required for such changes. We certainly need releng
> > >to sign off on this.
> > >
> > Apart from potential capacity impacts, this seems self-contained.
>
> Changes (in the sense of spec conditionals and such) to some
> yet-undefined subset of packages may necessary (for example if the
> architecture change has some effect on floating point computations,
> this could have a wide impact on packages doing numerical tests). So
> there is a potential for interaction with a large number of packagers.
>
> System-wide changes are also more widely announced (for example they
> are listed prominently in the release notes), which imo would be
> appropriate for something like a new architecture.

We are not proposing the new architecture. We are proposing a "staging
environment" for the current architecture. Which can be used for
experiments which currently can not be performed without disrupting
the release and user experience.

And the interaction with the maintainers you mention is not really
part of the Change, it is the continuous workflow, which is enabled by
it.

Note that we try to make it as light-weight as possible:

1) we reuse the infrastructure which is already available, like koji
builders. Because while hardware is costly, the human resources needed
to setup completely new infrastructure from scratch and then maintain
it in sync with the main infra cost way more;
2) we put all the new logic required to for this change (triggers,
feedback loop,..) outside of Fedora RelEng, so that we don't use
releng resources to maintain triggers and composes and the builds
themselves. This part will be maintained by change owners and people
interested in the development of the architecture update.

Thus, apart from raw compute resources, the impact of the change is quite small.

> Because of those two reasons, I'd argue that the category should be
> changed, but if you disagree, let's not discuss this further.

Based on the impact described above, I wouldn't consider the change system-wide.

But I think we touch an interesting topic here: It seems our
definition of Change is quite limited and focused on packaged changes.
And the work we propose doesn't really fit in this framework. I'm
going to start a separate thread on it.

> > I'll
> > grant that a reduced builder capacity would impact other contributors,
> > but that doesn't seem like the kind of case the system-wide change
> > definition is designed for.
> >
> > The change owner (bookwar) has already opened a ticket with RelEng[1]
> > and they will discuss what work is necessary for this at the next
> > meeting.
> >
> > [1] https://pagure.io/releng/issue/9154
>
> OK, thanks.
>

--
Aleksandra Fedorova
bookwar
___
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-20200110.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed, 9 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 6/155 (x86_64), 1/2 (arm)

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

ID: 508667  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/508667
ID: 508732  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/508732
ID: 508809  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/508809
ID: 508813  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/508813

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

ID: 508721  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/508721
ID: 508733  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/508733
ID: 508811  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/508811

Soft failed openQA tests: 16/155 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 508659  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/508659
ID: 508660  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/508660
ID: 508670  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/508670
ID: 508672  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/508672
ID: 508673  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/508673
ID: 508707  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/508707
ID: 508712  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/508712
ID: 508735  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/508735
ID: 508741  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/508741
ID: 508743  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/508743
ID: 508771  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/508771
ID: 508777  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/508777
ID: 508778  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/508778
ID: 508793  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/508793
ID: 508796  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/508796
ID: 508797  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/508797

Passed openQA tests: 110/155 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200109.n.0):

ID: 508698  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/508698
ID: 508699  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/508699
ID: 508725  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/508725
ID: 508730  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/508730
ID: 508742  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/508742
ID: 508753  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/508753
ID: 508759  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/508759
ID: 508768  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/508768
ID: 508807  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/508807
ID: 508810  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/508810

Skipped gating openQA tests: 9/155 (x86_64)

New skipped gating tests (same test not skipped in Fedora-Rawhide-20200109.n.0):

ID: 508674  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/508674
ID: 508675  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/508675
ID: 508681  Test: x86_64 Server-dvd-iso base_syste

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Aleksandra Fedorova]

On Fri, Jan 10, 2020 at 3:56 PM Chris Adams  wrote:
>
> Once upon a time, Aleksandra Fedorova  said:
> > No. Afaik, the main reason the change was rejected is that we are not
> > ready yet (or don't see yet the reason) for the update of the
> > architecture. And the benefit of such an update is unclear.
>
> I disagree that that was the reason - the fact that Fedora would no
> longer run on hardware being made and sold today was a big issue, and is
> in no way addressed.
>
> > There is no intent to provide those packages to the regular user or
> > make a separate Fedora Edition out of them. There will be no releases
> > of repositories or media with such packages. It is only an
> > experimental test environment linked to the Fedora Rawhide state.
>
> The scope says there will be repositories generated.

Yes, repositories and compose are going to be generated as development
snapshots, similarly to Rawhide nightlies. These repositories are
going to be used in tests and CI workflows, but there is no intention
to advertise them for the end-user.

And there will be no branching or releases for them.

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

-- 
Aleksandra Fedorova
bookwar
___
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 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Aleksandra Fedorova]

On Fri, Jan 10, 2020 at 3:56 PM Chris Adams  wrote:
>
> Once upon a time, Aleksandra Fedorova  said:
> > No. Afaik, the main reason the change was rejected is that we are not
> > ready yet (or don't see yet the reason) for the update of the
> > architecture. And the benefit of such an update is unclear.
>
> I disagree that that was the reason - the fact that Fedora would no
> longer run on hardware being made and sold today was a big issue, and is
> in no way addressed.

Similarly to what Josh said, we want to setup an environment for experiments.
It doesn't mean that things we experiment on are going to be merged in
Fedora. And it definitely doesn't mean that whatever we did in the
experimental environment can bypass the approval process.

It is not a backdoor for rejected change, it is a way to safely
iterate on the rejected change to see if we can come up with a version
of it, which won't be rejected.

> > There is no intent to provide those packages to the regular user or
> > make a separate Fedora Edition out of them. There will be no releases
> > of repositories or media with such packages. It is only an
> > experimental test environment linked to the Fedora Rawhide state.
>
> The scope says there will be repositories generated.
> --
> Chris Adams 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
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 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Chris Adams]

Once upon a time, Aleksandra Fedorova  said:
> Similarly to what Josh said, we want to setup an environment for experiments.
> It doesn't mean that things we experiment on are going to be merged in
> Fedora. And it definitely doesn't mean that whatever we did in the
> experimental environment can bypass the approval process.
> 
> It is not a backdoor for rejected change, it is a way to safely
> iterate on the rejected change to see if we can come up with a version
> of it, which won't be rejected.

So... I guess my objections are all based on the proposal as written,
which doesn't sound to me like what you are describing.  What the
proposal says is all about rebuilding Fedora with the rejected baseline
change, and showing that it is better to get the community to accept the
original change.  It also uses the term "older machines" (which is still
misleading).

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

Fedora rawhide compose report: 20200110.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200109.n.0
NEW: Fedora-Rawhide-20200110.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  7
Dropped packages:2
Upgraded packages:   112
Downgraded packages: 0

Size of added packages:  12.94 MiB
Size of dropped packages:316.12 KiB
Size of upgraded packages:   2.96 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   547.89 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20200110.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: diff-pdf-0.4-1.fc32
Summary: A simple tool for visually comparing two PDF files
RPMs:diff-pdf
Size:355.74 KiB

Package: gns3-gui-2.1.20-1.fc32
Summary: GNS3 graphical user interface
RPMs:gns3-gui
Size:4.53 MiB

Package: gns3-net-converter-1.3.0-13.fc32
Summary: Convert old ini-style GNS3 topologies to v1+ JSON format
RPMs:gns3-net-converter
Size:58.51 KiB

Package: gns3-server-2.1.20-1.fc32
Summary: Graphical Network Simulator 3
RPMs:gns3-server gns3-server-doc
Size:1.24 MiB

Package: python-pymeeus-0.3.6-2.fc32
Summary: Python implementation of Jean Meeus astronomical routines
RPMs:python-pymeeus-doc python3-pymeeus
Size:6.61 MiB

Package: python-requests-futures-1.0.0-2.fc32
Summary: Asynchronous Python HTTP Requests
RPMs:python-requests-futures
Size:17.36 KiB

Package: restmbmaster-1-1.fc32
Summary: Rest API gateway to Modbus slaves
RPMs:restmbmaster
Size:141.58 KiB


= DROPPED PACKAGES =
Package: dzen2-0.8.5-24.20100104svn.fc31
Summary: A general purpose messaging and notification program
RPMs:dzen2
Size:302.92 KiB

Package: i3-ipc-0.1.4-15.fc31
Summary: Inter-process communication with i3
RPMs:i3-ipc
Size:13.20 KiB


= UPGRADED PACKAGES =
Package:  ClanLib06-0.6.5-48.fc32
Old package:  ClanLib06-0.6.5-47.fc32
Summary:  Version 0.6 of this Cross platform C++ game library
RPMs: ClanLib06 ClanLib06-devel
Size: 6.39 MiB
Size change:  -1.31 MiB
Changelog:
  * Thu Jan 09 2020 Hans de Goede  - 0.6.5-48
  - Fix ClanLib-0.6 apps crashing on exit


Package:  R-BH-1.72.0.3-1.fc32
Old package:  R-BH-1.72.0.2-1.fc32
Summary:  Boost C++ Header Files for R
RPMs: R-BH-devel
Size: 8.49 MiB
Size change:  39.10 KiB
Changelog:
  * Thu Jan 09 2020 Tom Callaway  - 1.72.0.3-1
  - update to 1.72.0-3


Package:  R-cli-2.0.1-1.fc32
Old package:  R-cli-2.0.0-1.fc32
Summary:  Helpers for Developing Command Line Interfaces
RPMs: R-cli
Size: 401.16 KiB
Size change:  -2.42 KiB
Changelog:
  * Thu Jan 09 2020 Elliott Sales de Andrade  - 
2.0.1-1
  - Update to latest version


Package:  R-errors-0.3.3-1.fc32
Old package:  R-errors-0.3.2-2.fc31
Summary:  Uncertainty Propagation for R Vectors
RPMs: R-errors
Size: 279.61 KiB
Size change:  5.48 KiB
Changelog:
  * Thu Jan 09 2020 I??aki ??car  - 0.3.3-1
  - Update to 0.3.3


Package:  R-fansi-0.4.1-1.fc32
Old package:  R-fansi-0.4.0-4.fc31
Summary:  ANSI Control Sequence Aware String Functions
RPMs: R-fansi
Size: 987.62 KiB
Size change:  20.86 KiB
Changelog:
  * Thu Jan 09 2020 Elliott Sales de Andrade  - 
0.4.1-1
  - Update to latest version


Package:  R-farver-2.0.2-1.fc32
Old package:  R-farver-2.0.1-1.fc32
Summary:  High Performance Colour Space Manipulation
RPMs: R-farver
Size: 6.71 MiB
Size change:  -14.01 KiB
Changelog:
  * Thu Jan 09 2020 Elliott Sales de Andrade  - 
2.0.2-1
  - Update to latest version


Package:  R-geepack-1.3.1-1.fc32
Old package:  R-geepack-1.2.1-7.fc31
Summary:  Generalized Estimating Equation Package
RPMs: R-geepack R-geepack-devel
Size: 2.79 MiB
Size change:  338.02 KiB
Changelog:
  * Tue Jan 07 2020 Elliott Sales de Andrade  - 
1.3.1-1
  - Update to latest version


Package:  R-hms-0.5.3-1.fc32
Old package:  R-hms-0.5.2-1.fc32
Summary:  Pretty Time of Day
RPMs: R-hms
Size: 114.05 KiB
Size change:  -2.48 KiB
Changelog:
  * Thu Jan 09 2020 Elliott Sales de Andrade  - 
0.5.3-1
  - Update to latest version


Package:  R-stringi-1.4.4-1.fc32
Old package:  R-stringi-1.4.3-4.fc32
Summary:  Character String Processing Facilities
RPMs: R-stringi R-stringi-devel
Size: 4.74 MiB
Size change:  3.37 KiB
Changelog:
  * Thu Jan 09 2020 Elliott Sales de Andrade  - 
1.4.4-1
  - Update to latest version


Package:  beaker-27.0-2.fc32
Old package:  beaker-27.0-1.fc32
Summary:  Full-stack software and hardware integration testing system
RPMs: beaker-client beaker-common
Size: 240.61 KiB
Size change:  301 B
Changelog:
  * Thu Jan 09 2020 Zbigniew J??drzejewski-Szmek  - 27.0-2
  - Remove dependency on unittest2 (#1789200)


Package:  buildah-1.14.0-0.13.dev.git4e23b7a.fc32
Old package:  buildah-1.14.0

Ownership announce of retired package Pound

[Breno Brand Fernandes]

Hi all,

Recently, I've sent an email on epel-dev regarding this ownership
request[1].
So, somethings may be repeated for some of you (I'm sorry!).

The package Pound was retired about a year ago. It failed to build and at
that time the maintainer didn't give any feedback on it[2].

Since then, the Pound project was forked and has been maintained[3].

I would like to maintain the package in EPEL.
I've made some tests and I believe I have a working spec file for it[4, 5,
6].

I am now following the Claiming Ownership of a Retired Package procedure[7].

Please, let me know if it is all good for you guys that I'd become the
maintainer.

Thanks.

1 -
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/74GMAJGMWK3VEA4U2D7C6RRNJDFT3H5K/
2 - https://bugzilla.redhat.com/show_bug.cgi?id=1674583
3 - https://github.com/patrodyne/pound
4 - https://src.fedoraproject.org/fork/brandfbb/rpms/Pound/commits/epel8
5 - https://copr.fedorainfracloud.org/coprs/brandfbb/Pound-2.8-patrodyne/
6 - https://koji.fedoraproject.org/koji/taskinfo?taskID=40203731
7 -
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package

- Breno
___
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 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Adam Jackson]

On Fri, 2020-01-10 at 11:05 +0100, Florian Weimer wrote:
> * Neal Gompa:
> 
> > On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer  wrote:
> > > We do not want to change the RPM architecture, so that users still can
> > > install third-party software.  This means that we need to change the
> > > dist tag to avoid confusion.
> > > 
> > 
> > Changing the RPM architecture does not necessarily mean that you
> > wouldn't remain compatible with baseline x86_64. For example,
> > OpenMandriva's build of the distribution optimized for first
> > generation AMD Ryzen systems uses the "znver1" RPM architecture, but
> > the "znver1" architecture is deliberately considered compatible with
> > x86_64, so packages that are "x86_64" are still installable. There are
> > numerous examples of this for 32-bit x86, and there's no reason we
> > couldn't do this for 64-bit x86.
> 
> But the value of %_arch still changes, right?

I don't think that needs to be true. If I'm reading the rpm source
right (always questionable) it looks like %_arch is set from $CANONARCH
in the installplatform script, which treats ia32e and amd64 such that
$CANONARCH is still x86_64.

Granted this does mean you'd need to patch the normal (not the one in
your buildroot) rpm package to know about this architecture too, which
is maybe not ideal, or else require that installing packages from this
buildroot requires using that buildroot's rpm.

- 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: Ownership announce of retired package Pound

[Scott Talbert]

On Fri, 10 Jan 2020, Breno Brand Fernandes wrote:


Hi all,
Recently, I've sent an email on epel-dev regarding this ownership
request[1].
So, somethings may be repeated for some of you (I'm sorry!).

The package Pound was retired about a year ago. It failed to build and at
that time the maintainer didn't give any feedback on it[2].

Since then, the Pound project was forked and has been maintained[3].

I would like to maintain the package in EPEL.
I've made some tests and I believe I have a working spec file for it[4, 5,
6].

I am now following the Claiming Ownership of a Retired Package procedure[7].

Please, let me know if it is all good for you guys that I'd become the
maintainer.


Since the package has been retired for > 8 weeks, you just need to submit 
a package review request (ie, it is almost like this is a new package):

https://fedoraproject.org/wiki/Package_Review_Process

Scott___
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

What would it take to drop release and changelog from our spec files? (and do we want to?)

[Pierre-Yves Chibon]

Good Morning Everyone,

This is not a new idea, it has been presented at flock last year and spoken
about on this very list this fall, so I'd like to push it a little further.

Do we want to drop release and changelog from our spec file?
If we do, how would this work?

The release field would need to be set by koji ignoring whatever is in the spec
file. How do we want to do this?
  - Based on dates?
  - Using an always increasing integer?
  - Using the number of successful builds since the last time the version field 
changed?
  - Another idea?

The third option looks like to be the one closest to our current behavior.


Another question regarding the release field is: how would we deal with
pre-releases and other unsortable versions?
The current doc relies on  etc. in the release field as per:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_unsortable_versions
Would using the tilde to specify pre-releases in the version field be sufficient
(as described in
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde)?
I.e., how can we cater for snapshot releases (e.g. based off a specific git
commit)?


With the changelog it becomes a little bit more tricky.
We currently have 3 changelogs in Fedora with 3 different target audience (this
is how I understand them):
  - One for the files in the git repository, meant to be "consumed" by our
fellow packagers, not meant to leave the Fedora infrastructure
  - One in the spec file describing the changes applied to it. This one is meant
to be accessible to sysadmins who want to know/check what changed in a 
package
  - One in bodhi, meant for end-user consumption and which should give some
explanation as to why the package was updated or where information about the
update can be found

So we need to, somehow, merge two changelogs into one while realizing that some
information in one may not be desirable in the other (for example the world
famous commit message: "oops I've forgot to upload the sources" does not need to
appear in the RPM's changelog).
Would it be easier to merge the git changelog with the spec changelog or the
spec changelog with the bodhi notes?

For the former one easy way to achieve this is to consider all the commits since
the last successful build and have a magic keyword to either include or exclude
a commit message in the changelog.
For the latter, we discussed the idea of using annotated git tags this fall.

Both have their pros and cons, do people have some experience with either and
could share their feedback?
Is there a different approach, e.g. by using towncrier[1] or something
comparable, to track changes outside the spec file?


To give some context to this discussion, the CPE team is moving toward quarterly
planning and for the first months of 2020 a small team of people in the CPE team
is willing to do the work to make this happen, but there are two requirements:
  - The work needs to be scoped and defined by January 20th 2020 (so we can
evaluate whether or not we have the knowledge, resources and time to do it)
  - The work needs to be achievable before March 31st 2020 (cf the quarterly
objectives we're working towards)

Thus our call for input to accept or reject the idea and if the former
scope/define the system.


Thanks in advance for your help,

Pierre


[1] https://github.com/hawkowl/towncrier
___
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

Spins keepalive deadline approaching

[Ben Cotton]

FESco previously approved a requirement that Spin/Labs owners send a
keepalive request in order to keep building the spin or lab. I have
opened Pagure issues[1] for all Spins and Labs listed on the wiki[2].

If you are the owner of one of those spins and labs, please reply in
the appropriate ticket by 22 January 2020 to indicate the spin should
continue to be produced. If there is a spin or lab that does not have
an open ticket, please create one[3].

The reasoning for this is to not ship spins that are not actively
maintained.

[1] https://pagure.io/fedora-project-schedule/issues?status=Open&tags=spins
[2] https://fedoraproject.org/wiki/Releases/32/Spins
[3] https://pagure.io/fedora-project-schedule/new_issue

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

Intention to orphan python-slacker and slack-cleaner

[Raphael Groner]

Hi,

as upstream created an already double forked fork called slack-cleaner2 [¹], I 
decided to orphan two of my python packages, both python-slacker (as a direct 
dependency) as well as slack-cleaner.
Currently, slack-cleaner as in current repository isn't working for me any 
more, maybe due to API changes or whatever. There's no free time for me to join 
development. Never tried to reproduce with slack-cleaner2 as upstream suggests 
in the issues.

There are no known dependencies to worry about in Fedora 30.

Maybe someone is still interested and thinks those packages are useful in 
Fedora. If yes please feel free to pick them.

Regards,
Raphael

[¹] https://github.com/sgratzl/slack_cleaner2
___
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Iñaki Ucar]

On Fri, 10 Jan 2020 at 17:45, Pierre-Yves Chibon  wrote:
>
> With the changelog it becomes a little bit more tricky.
> We currently have 3 changelogs in Fedora with 3 different target audience 
> (this
> is how I understand them):
>   - One for the files in the git repository, meant to be "consumed" by our
> fellow packagers, not meant to leave the Fedora infrastructure
>   - One in the spec file describing the changes applied to it. This one is 
> meant
> to be accessible to sysadmins who want to know/check what changed in a 
> package
>   - One in bodhi, meant for end-user consumption and which should give some
> explanation as to why the package was updated or where information about 
> the
> update can be found
>
> So we need to, somehow, merge two changelogs into one while realizing that 
> some
> information in one may not be desirable in the other (for example the world
> famous commit message: "oops I've forgot to upload the sources" does not need 
> to
> appear in the RPM's changelog).
> Would it be easier to merge the git changelog with the spec changelog or the
> spec changelog with the bodhi notes?
>
> For the former one easy way to achieve this is to consider all the commits 
> since
> the last successful build and have a magic keyword to either include or 
> exclude
> a commit message in the changelog.
> For the latter, we discussed the idea of using annotated git tags this fall.

Most of the time, I end up copying the spec changelog in the commit
message and I don't change the update template, so the bodhi changelog
is also the same. The spec changelog is a pain for me, so I'd vote for
git commit messages + tags (unnanotated; otherwise, I don't see much
benefit).

-- 
Iñaki Úcar
___
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Fabio Valentini]

On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon  wrote:

> Good Morning Everyone,
>
> This is not a new idea, it has been presented at flock last year and spoken
> about on this very list this fall, so I'd like to push it a little further.
>
> Do we want to drop release and changelog from our spec file?
> If we do, how would this work?
>
> The release field would need to be set by koji ignoring whatever is in the
> spec
> file. How do we want to do this?
>   - Based on dates?
>   - Using an always increasing integer?
>   - Using the number of successful builds since the last time the version
> field changed?
>   - Another idea?
>

What about "number of commits since last version update" (possibly tagged
in git)? That should encompass the possibilities you listed above, is
well-defined, and should be most like the current behavior.

The number of successful builds doesn't sound like a well-defined / stable
number to me, since it relies on information outside of git.


> The third option looks like to be the one closest to our current behavior.
>
>
> Another question regarding the release field is: how would we deal with
> pre-releases and other unsortable versions?
> The current doc relies on  etc. in the release field as per:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_unsortable_versions
> Would using the tilde to specify pre-releases in the version field be
> sufficient
> (as described in
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde
> )?
> I.e., how can we cater for snapshot releases (e.g. based off a specific git
> commit)?
>

The tilde notation is not enough for general snapshots, though it works
well for tagged alpha / beta / rc releases (because they are real releases,
not snapshots).

For snapshot builds, I think something like %releaseprefix of 0." (cf.
%distprefix) could be used to indicate a prerelease in the .spec file, and
incorporated in the automatically generated Release tag.


>
> With the changelog it becomes a little bit more tricky.
> We currently have 3 changelogs in Fedora with 3 different target audience
> (this
> is how I understand them):
>   - One for the files in the git repository, meant to be "consumed" by our
> fellow packagers, not meant to leave the Fedora infrastructure
>   - One in the spec file describing the changes applied to it. This one is
> meant
> to be accessible to sysadmins who want to know/check what changed in a
> package
>   - One in bodhi, meant for end-user consumption and which should give some
> explanation as to why the package was updated or where information
> about the
> update can be found
>

I think it would be good to merge git commit messages and the .spec
changelog. This is also how many projects handle this on GitHub. Using
[skip-changelog] in commit messages or something or something similar to
indicate that it should not be mentioned in generated release notes is also
common practice (just like [skip-ci]).

So I think this is very much doable, since there's actually a lot of
precedent for doing this. Also, the two audiences for git commit messages
and RPM changelogs are probably more similar than the audience for bodhi
updates (where I usually put more user-facing information).


Fabio


> So we need to, somehow, merge two changelogs into one while realizing that
> some
> information in one may not be desirable in the other (for example the world
> famous commit message: "oops I've forgot to upload the sources" does not
> need to
> appear in the RPM's changelog).
> Would it be easier to merge the git changelog with the spec changelog or
> the
> spec changelog with the bodhi notes?
>
> For the former one easy way to achieve this is to consider all the commits
> since
> the last successful build and have a magic keyword to either include or
> exclude
> a commit message in the changelog.
> For the latter, we discussed the idea of using annotated git tags this
> fall.
>
> Both have their pros and cons, do people have some experience with either
> and
> could share their feedback?
> Is there a different approach, e.g. by using towncrier[1] or something
> comparable, to track changes outside the spec file?
>
>
> To give some context to this discussion, the CPE team is moving toward
> quarterly
> planning and for the first months of 2020 a small team of people in the
> CPE team
> is willing to do the work to make this happen, but there are two
> requirements:
>   - The work needs to be scoped and defined by January 20th 2020 (so we can
> evaluate whether or not we have the knowledge, resources and time to
> do it)
>   - The work needs to be achievable before March 31st 2020 (cf the
> quarterly
> objectives we're working towards)
>
> Thus our call for input to accept or reject the idea and if the former
> scope/define the system.
>
>
> Thanks in advance for your help,
>
> Pierre
>
>
> [1] https://github.com/hawkowl/towncrier
> __

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Nicolas Mailhot via devel]

Le vendredi 10 janvier 2020 à 17:36 +0100, Pierre-Yves Chibon a écrit :
> Good Morning Everyone,
> 
> This is not a new idea, it has been presented at flock last year and
> spoken
> about on this very list this fall, so I'd like to push it a little
> further.
> 
> Do we want to drop release and changelog from our spec file?
> If we do, how would this work?

Dropping changelog is easy. Since we have a clean separation of spec
repo (src.fedoraproject.org) and project repo (pagure, gitlab or
elsewhere) the spec should just be assembled from all the
src.fedoraproject.org commit messages not present in the previous
generated changelog

(that won't work for thinks ike rehat-rpm-config because it does not
separate the project files in a separate repository but it’s high time
it behaved likea normal project, the non separation is a major PITA to
deal with)

Droping releases is much harder to design for because we don’t have a
linear build history, there are branches that split and then re-merge
at system release time (sometimes, with excursions in copr or another
repo), none of the proposed solutions would accomodate those workflows.

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

reiew request freewrl 4.0

[J. Scheurich]

Hi,

I want to offer a review swap for freewrl 4.0:

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

/I would prefer C/C++ project to review.

so long
MUFTI
/
___
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: Upgrading libffi

[Kevin Fenzi]

On Fri, Jan 10, 2020 at 06:24:35AM -0500, Anthony Green wrote:
> 
> Anthony Green  writes:
> > Kevin Fenzi  writes:
> >> I suppose you could also
> >> add both old and new libffi source to the libffi package and build them
> >> both (old to compat), rebuild in side tag and drop the old
> >> sources/compat.
> 
> >> Does that make sense?
> >
> > I like this idea because it seems simple.
> 
> I did go this route.  I now have a libffi spec file that installs both
> the .6 and .7 versions of the library (I didn't even break out the .6
> version into a compat package).  I'm currently doing local mock builds
> of the 90+ packages that depend directly on libffi.  Once all of them
> build locally, my plan is to commit my franken-package to rawhide and
> arrange for those 90+ rawhide packages to be built.  Once those are
> rebuilt, I simply clean up the libffi spec, removing the .6 version.
> 
> Objections?

Sounds good to me. If you run into any issues let me know. 

kevin


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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Vít Ondruch]

Dne 10. 01. 20 v 18:33 Fabio Valentini napsal(a):
> On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon  > wrote:
>
> Good Morning Everyone,
>
> This is not a new idea, it has been presented at flock last year
> and spoken
> about on this very list this fall, so I'd like to push it a little
> further.
>
> Do we want to drop release and changelog from our spec file?
> If we do, how would this work?
>
> The release field would need to be set by koji ignoring whatever
> is in the spec
> file. How do we want to do this?
>   - Based on dates?
>   - Using an always increasing integer?
>   - Using the number of successful builds since the last time the
> version field changed?
>   - Another idea?
>
>
> What about "number of commits since last version update" (possibly
> tagged in git)? That should encompass the possibilities you listed
> above, is well-defined, and should be most like the current behavior.


That won't work. This assumes that all subpackages have the same version
as the main package, but that might not be true (it is definitely not
true for Ruby neither for Perl AFAIK). If nothing else, there must be
way to override/hint the automation (unless the automation is smart
enough to detect such scenarios, which would be cool).


Vít

___
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: koji / bodhi issues status update

[Sérgio Basto]

On Fri, 2020-01-10 at 08:03 +0100, Igor Gnatenko wrote:
> No, that's not true. Anybody can tag their builds into a
> f31-updates-candidate and such tags.

I have to test it to see, ATM without stupid tests on production which
I don't want to do, I can't test it. 
But if so, is less problematic .

And in case of cancel one koji build but in the end just canceled the
tag-build task ? Can we change the build from completed to failed ? I
think not . Which means we can't built it again .

Thinking loud, maybe the best of two worlds was koji mark build as
failed but let resubmit the failed task and completed the build
successfully .

koji builds marked as completed but with fails tasks should be avoided,
in my opinion , this case is not the only case that I'm thinking, I had
similar problems in past . 

Thanks, 


> On Fri, Jan 10, 2020 at 4:03 AM Sérgio Basto 
> wrote:
> > On Thu, 2020-01-09 at 09:17 +0100, Pierre-Yves Chibon wrote:
> > > On Wed, Jan 08, 2020 at 10:32:42PM +, Sérgio Basto wrote:
> > > > Hi, a little "by the way" , I think if koji fails to tag the
> > > > build
> > > > or
> > > > anything else, the final result should be failed, to avoid
> > > > inconsistencies. I opened an issue on koji [1]
> > > > [1]
> > > > https://pagure.io/koji/issue/1895
> > > 
> > > We'll see how it goes, however I am not enthusiastic about this
> > > idea,
> > > tagging a
> > > build is a much shorter task than doing a full rebuild (think
> > > LibreOffice or
> > > something along those lines that takes 1h+ to build, the tagging
> > > operation is
> > > done in seconds).
> > > I agree that build without tags are harder to debug, especially
> > > if
> > > you do not
> > > know what to look for, but once you do and know how to fix, it's
> > > a
> > > much quicker
> > > solution.
> > 
> > Let me disagree with your arguments, in two points .
> > 
> > - Save time, if we count the times losses and gains, I think we
> > didn't
> > save time. quite the opposite, because we have to review all
> > builds,
> > search for all inconsistencies, etc ...
> > 
> > - Second point is the fix, the fix just can be done by one admin ,
> > i.e.
> > an regular user without admin permissions can't tag the build and
> > the
> > workaround is build another release which is an ugly solution.
> > 
> > Best regards,
> > --
> > Sérgio M. B.
> > ___
> > 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
-- 
Sérgio M. B.
___
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 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Kevin Fenzi]

On Thu, Jan 09, 2020 at 12:16:17PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Additional_buildroot_to_test_x86-64_micro-architecture_update
> 
> == Summary ==
> 
> Create a dedicated buildroot to test packages built with x86-64
> micro-architecture update.

So, a few questions: 

Can packages built in this buildroot be used on the same system with
packages from the normal buildroot?

I assume one of the reasons to do this is that we don't know which
packages benifit from the changes and by how much? 
If we do or could at least have a good idea about this and the normal
packages could be shared on the same systems, how about only
doing those specific packages in the seperate buildroot instead of
everything? That would save a lot of space and also get wider testing
perhaps (if people could just upgrade packages from the normal repo to
test)

Do these builds need to be signed? 

Would there be some kind of initial 'mass build' to populate existing
packages / things that don't rebuild very often?

Would there need to be some kind of bootstrap? Or would this inherit
from the existing normal buildroot?

My main concern here is the storage front. Would we need to keep old
builds? Or could we just keep the last successfull build only?

I guess ideally there will be 0 changes to spec files (just different
macros, etc)? And if there are changes, they would be something we would
want to upstream, so perhaps a bugzilla tracker for any spec changes to
make sure as much as possible they go upstream and go away?

I wonder if in naming and such we could make sure we are doing things
generically. ie, instead of naming anything here avx2 or something we
name it 'altmicro' or 'alternatearch' so we could keep / reuse this for
other things later.

Thanks for the proposal!

kevin


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: Let's talk about Fedora in the '20s!

[Matthew Miller]

On Wed, Jan 08, 2020 at 02:17:40PM -0500, John Florian wrote:
> desired impact, but we should practice what we preach, at minimum:
> make Fedora a selection for the OS in oVirt.  I wind up choosing the
> latest RHEL for all my Fedora VMs but I always have to wonder if
> that's optimal -- and I've lived in the shade of RH since the RHL4.0
> days.  Why do we have to guess at this?  I know oVirt isn't a Fedora
> project, it's a RH one, but this should be one upstream that's the

Yeah, this is a good suggestion and I'm not sure why it's not already the
case!

-- 
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Fabio Valentini]

On Fri, Jan 10, 2020 at 6:52 PM Vít Ondruch  wrote:
>
>
> Dne 10. 01. 20 v 18:33 Fabio Valentini napsal(a):
>
> On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon  wrote:
>>
>> Good Morning Everyone,
>>
>> This is not a new idea, it has been presented at flock last year and spoken
>> about on this very list this fall, so I'd like to push it a little further.
>>
>> Do we want to drop release and changelog from our spec file?
>> If we do, how would this work?
>>
>> The release field would need to be set by koji ignoring whatever is in the 
>> spec
>> file. How do we want to do this?
>>   - Based on dates?
>>   - Using an always increasing integer?
>>   - Using the number of successful builds since the last time the version 
>> field changed?
>>   - Another idea?
>
>
> What about "number of commits since last version update" (possibly tagged in 
> git)? That should encompass the possibilities you listed above, is 
> well-defined, and should be most like the current behavior.

(snip)

> That won't work. This assumes that all subpackages have the same version as 
> the main package, but that might not be true (it is definitely not true for 
> Ruby neither for Perl AFAIK).

It won't work in all cases, true. But in the predominant case where
all produced packages have the same version, it works fine.

> If nothing else, there must be way to override/hint the automation (unless 
> the automation is smart enough to detect such scenarios, which would be cool).

For example: For the handful of special cases like ruby it should be
easy to define a macro to tell the Release tag generator "hey, count
up releases from point X instead" (which could just be a manually
specified git ref).

Fabio

> Vít
>
> ___
> 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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Fabio Valentini]

On Fri, Jan 10, 2020 at 6:36 PM Nicolas Mailhot via devel
 wrote:
>
> Le vendredi 10 janvier 2020 à 17:36 +0100, Pierre-Yves Chibon a écrit :
> > Good Morning Everyone,
> >
> > This is not a new idea, it has been presented at flock last year and
> > spoken
> > about on this very list this fall, so I'd like to push it a little
> > further.
> >
> > Do we want to drop release and changelog from our spec file?
> > If we do, how would this work?
>
> Dropping changelog is easy. Since we have a clean separation of spec
> repo (src.fedoraproject.org) and project repo (pagure, gitlab or
> elsewhere) the spec should just be assembled from all the
> src.fedoraproject.org commit messages not present in the previous
> generated changelog
>
> (that won't work for thinks ike rehat-rpm-config because it does not
> separate the project files in a separate repository but it’s high time
> it behaved likea normal project, the non separation is a major PITA to
> deal with)

(snip)

> Droping releases is much harder to design for because we don’t have a
> linear build history, there are branches that split and then re-merge
> at system release time (sometimes, with excursions in copr or another
> repo), none of the proposed solutions would accomodate those workflows.

You can never expect our tooling to do "magic" (TM) and work "just
right", no matter which Versions and Releases and Epochs of packages
are available from third-party repos and coprs. This has nothing to do
with proposed auto-generated Release tag, and it's definitely not a
new problem. We've basically ignored consistency with third-party
repos until now - and rightly so, IMO - because that's what "dnf
distro-sync" is for. (Even upgrade path from fedora N to N+1 doesn't
have to be "clean" anymore, because system-upgrade operates in
"distro-sync" mode by default now ...)

Fabio

> 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
___
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: Let's talk about Fedora in the '20s!

[Matthew Miller]

On Tue, Jan 07, 2020 at 03:39:41PM +0100, Nicolas Mailhot via devel wrote:
> It would be interesting to analyse all those things, not to plan an rpm
> replacement, but to actually fix the things upstreams are not happy
> about (and, a lot of time, those won't involve rpm, and when they do
> involve rpm fixing rpm will be easier than rewriting it from scratch). 

I can get behind this approach.

To make it work we need to look at the things where 1) upstreams are not
happy and 2) we can provide value for both dev and ops.

-- 
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Nicolas Mailhot via devel]

Le vendredi 10 janvier 2020 à 20:53 +0100, Fabio Valentini a écrit :
> 
> You can never expect our tooling to do "magic" (TM) and work "just
> right", no matter which Versions and Releases and Epochs of packages
> are available from third-party repos and coprs. 

Yes, sure, but the current way we manage releases accomodate those
worklows.

For example:
1. I hit a fontconfig bug while preparing the new font packaging
guidelines,
2. Akira kindly fixed the problem upstream,
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/185
3. it was trivial to build a package matching the Fedora fontconfig
with just the fix added in copr, without breaking the release thread
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/build/1126851/

(it exists just for me in my copre because general availability was not
required to advance on the guidelines proposal; general availability
would have required a push to rawhide and a support commitment by
Akira)

And, it will all converge once FPC finishes its review, Akira releases
fontconfig upstream, and the result is rebuilt for Fedora. Had I waited
for Akira to wrap up an upstream release and build the result rawhide-
side the FPC submission would have been pushed back for months (and
then it would have delayed other Fedora changes, it's a cascading
effect).

The non-linear progression permitted by current manual release setting
allows parallelizing work and getting things done a lot faster within
the project. I don’t see how to manage this with the autogeneration
proposal

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 (late): Enable EarlyOOM

[drago01]

On Wed, Jan 8, 2020 at 8:25 PM Chris Murphy  wrote:
>
> On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering  
> wrote:
> >
> > - facebook is working on making oomd something that just works for
> >   everyone, they are in the final rounds of canonicalizing the
> >   configuration so that it can just work for all workloads without
> >   tuning. The last bits for this to be deployable are currently being
> >   done on the kernel side ("iocost"), when that's in, they'll submit
> >   oomd (or simplified parts of it) to systemd, so that it's just there
> >   and works. It's their expressive intention to make this something
> >   that also works for desktop stuff and requires no further
> >   tuning. they also will do the systemd work necessary. time frame:
> >   half a year, maybe one year, but no guarantees.
>
> Looks like PSI based oom killing doesn't work without swap. Therefore
> oomd can't be considered a universal solution. Quite a lot of
> developers have workstations with quite a decent amount of RAM,
> ~64GiB, and do not use swap at all. Server baremetal are likewise
> mixed, depending on workloads, and in cloud it's rare for swap to
> exist.
>
> https://github.com/facebookincubator/oomd/issues/80
>
> We think earlyoom can be adjusted to work well for both the swap and
> no swap use cases.

How? On a system with 64GB of ram and no swap all it does currently is
reducing the amount of usable memory significantly.
___
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Richard W.M. Jones]

On Fri, Jan 10, 2020 at 05:36:46PM +0100, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> This is not a new idea, it has been presented at flock last year and spoken
> about on this very list this fall, so I'd like to push it a little further.
> 
> Do we want to drop release and changelog from our spec file?
> If we do, how would this work?

OpenSUSE proved years and years ago that dropping %changelog is
possible, easy and desirable.  We should do that IMHO.

I wouldn't personally bother touching the Release header.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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 (late): Enable EarlyOOM

[Chris Murphy]

On-going related discussions on linux-mm@ list

user space unresponsive, followup: lsf/mm congestion
https://marc.info/?t=15784291223&r=1&w=2

Gist here is the kernel is working as expected. The process is asking
for resources that don't exist and the kernel can't really assume
either the workload or the user's intent or wish. Maybe they want the
system to finish the task even if it's unusuable?

OOM killer not nearly agressive enough?
https://marc.info/?t=15784298701&r=1&w=2

Not clear where it's stuck, reclaim or waiting on a lock - more info needed.

---
Chris Murphy
___
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 (late): Enable EarlyOOM

[Chris Murphy]

On Fri, Jan 10, 2020 at 2:05 AM Lennart Poettering  wrote:
>
> On Mi, 08.01.20 12:24, Chris Murphy (li...@colorremedies.com) wrote:
>
> > On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering  
> > wrote:
> > >
> > > - facebook is working on making oomd something that just works for
> > >   everyone, they are in the final rounds of canonicalizing the
> > >   configuration so that it can just work for all workloads without
> > >   tuning. The last bits for this to be deployable are currently being
> > >   done on the kernel side ("iocost"), when that's in, they'll submit
> > >   oomd (or simplified parts of it) to systemd, so that it's just there
> > >   and works. It's their expressive intention to make this something
> > >   that also works for desktop stuff and requires no further
> > >   tuning. they also will do the systemd work necessary. time frame:
> > >   half a year, maybe one year, but no guarantees.
> >
> > Looks like PSI based oom killing doesn't work without swap. Therefore
> > oomd can't be considered a universal solution. Quite a lot of
> > developers have workstations with quite a decent amount of RAM,
> > ~64GiB, and do not use swap at all. Server baremetal are likewise
> > mixed, depending on workloads, and in cloud it's rare for swap to
> > exist.
> >
> > https://github.com/facebookincubator/oomd/issues/80
> >
> > We think earlyoom can be adjusted to work well for both the swap and
> > no swap use cases.
>
> Isn't rearlyoom also watching the swap metrics only?

No, memory free and swap free, as a percentage. Super simplistic. If
there is no swap, then the percent only applies to MemAvailable.

https://pagure.io/fedora-workstation/issue/119#comment-619749


-- 
Chris Murphy
___
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Michael Catanzaro]

On Fri, Jan 10, 2020 at 9:46 pm, Richard W.M. Jones  
wrote:

OpenSUSE proved years and years ago that dropping %changelog is
possible, easy and desirable.  We should do that IMHO.


They still have %changelog at the bottom of each spec file, but as the 
last line of the file. The actual changelog is stored as a separate 
.changes file. That's a *lot* better than what Fedora does now, because 
it makes it way easier to scroll through the spec file. But getting rid 
of the changelog entirely would be even nicer. :)


Michael

___
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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Neal Gompa]

On Fri, Jan 10, 2020 at 8:20 PM Michael Catanzaro  wrote:
>
> On Fri, Jan 10, 2020 at 9:46 pm, Richard W.M. Jones 
> wrote:
> > OpenSUSE proved years and years ago that dropping %changelog is
> > possible, easy and desirable.  We should do that IMHO.
>
> They still have %changelog at the bottom of each spec file, but as the
> last line of the file. The actual changelog is stored as a separate
> .changes file. That's a *lot* better than what Fedora does now, because
> it makes it way easier to scroll through the spec file. But getting rid
> of the changelog entirely would be even nicer. :)
>

openSUSE needs the changes file because the integrated VCS in their
build system is awful. History is not able to be preserved across
submissions to projects, so the only complete artifact of history is
that file. If you want an example of a distribution that completely
eliminated the management of an RPM changelog, look at Mageia (and its
ancestor, Mandriva). Their Dist-SVN system dynamically generated
changelogs from the SVN log.

However, they had two properties that we don't have with Git, and we
need some analogues for that:

* Dist-SVN is still SVN, and that means the log data can be edited
without editing the revision itself. This means the message could be
changed after the fact and the next build would incorporate it.
* Dist-SVN relied on tags of successful builds to track the
checkpoints for changelog generation and did not use branches in any
meaningful capacity, so the history was always fully linear.

I think any successful equivalent of that for Dist-Git will require us
to emulate these two properties somehow. My thinking is that annotated
tags would be the right way to allow for changelogs to be set without
the complexity of figuring out commit filtering. The annotation must
be editable. If not, this won't work. We have to have a way to let
people clean up changelogs. I think we can enforce linear tracking
within a branch for Koji to generate Release values, but it's going to
be tricky, given the contortions to the history that Git allows.



--
真実はいつも一つ！/ 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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Neal Gompa]

On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon  wrote:
>
>
> The release field would need to be set by koji ignoring whatever is in the 
> spec
> file. How do we want to do this?
>   - Based on dates?
>   - Using an always increasing integer?
>   - Using the number of successful builds since the last time the version 
> field changed?
>   - Another idea?
>
> The third option looks like to be the one closest to our current behavior.
>

I always envisioned that we'd use a variant of the third option.

The options I've thought of:

* %{dist}.
* .%{?dist}
* %{dist}..

The first option aligns with our current guidelines suggesting that
such bumps go at the end after the DistTag. I personally have felt
those were ugly, but there you go. The second option is actually what
I use at $DAYJOB for our environment, and I've been pretty pleased
with how that works in practice (our buildsystem builds for all target
distros from the same commit at once, so the EVRs are rather strictly
matched). However, it might not be workable with the whole "Koji and
manual build per target" thing. The third option is how openSUSE Leap
is currently done, primarily to make Leap packages lower than SUSE
Linux Enterprise packages (openSUSE Leap can "upgrade" to SLE). I'm
not a fan of this scheme as it feels rather "weird" to me.

Naturally, there is also an option that would involve enhancing RPM:
extending EVR comparisons to factor in the DistTag as a formal
property (e.g. EVRD). ALT Linux recently started doing this. I will
admit there is some appeal to this, as it makes the distro versioning
aspect a property unto itself. This would require making Koji move
from NVR to NVRD for its uniqueness constraint, which would be an
"interesting" change to implement. This would eliminate the %dist
macro entirely, and remove boilerplate entirely from the Release
field. This would make all the questions and games about sequencing
the values in the Release field to be completely about the unique
build versioning of the package. In practice, I think this is just a
fancier variant of option two above.

>
> Another question regarding the release field is: how would we deal with
> pre-releases and other unsortable versions?
> The current doc relies on  etc. in the release field as per:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_unsortable_versions
> Would using the tilde to specify pre-releases in the version field be 
> sufficient
> (as described in
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde)?
> I.e., how can we cater for snapshot releases (e.g. based off a specific git
> commit)?
>

Pre-releases can use tilde versioning, and starting with Fedora 31, we
can also use carat versions for post-releases.

Carat versioning draft from tibbs from long ago:
https://fedoraproject.org/wiki/User:Tibbs/TildeCaretVersioning


-- 
真実はいつも一つ！/ 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: What would it take to drop release and changelog from our spec files? (and do we want to?)

[Neal Gompa]

On Fri, Jan 10, 2020 at 12:52 PM Vít Ondruch  wrote:
>
>
> Dne 10. 01. 20 v 18:33 Fabio Valentini napsal(a):
>
> On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon  wrote:
>>
>> Good Morning Everyone,
>>
>> This is not a new idea, it has been presented at flock last year and spoken
>> about on this very list this fall, so I'd like to push it a little further.
>>
>> Do we want to drop release and changelog from our spec file?
>> If we do, how would this work?
>>
>> The release field would need to be set by koji ignoring whatever is in the 
>> spec
>> file. How do we want to do this?
>>   - Based on dates?
>>   - Using an always increasing integer?
>>   - Using the number of successful builds since the last time the version 
>> field changed?
>>   - Another idea?
>
>
> What about "number of commits since last version update" (possibly tagged in 
> git)? That should encompass the possibilities you listed above, is 
> well-defined, and should be most like the current behavior.
>
>
> That won't work. This assumes that all subpackages have the same version as 
> the main package, but that might not be true (it is definitely not true for 
> Ruby neither for Perl AFAIK). If nothing else, there must be way to 
> override/hint the automation (unless the automation is smart enough to detect 
> such scenarios, which would be cool).
>

Yes it will, because the source version is predictable. Version
updates would work off the source RPM version, and that isn't affected
by games like that. The query would be something like the following:

$ rpmspec -q --srpm --qf "%{VERSION}-%{RELEASE}\n" foo.spec

That will *always* do the right thing.


-- 
真実はいつも一つ！/ 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: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 01/08/2020 11:28 PM, Miro Hrončok wrote:
> On 08. 01. 20 23:47, Tom Stellard wrote:
>> I suspect that if I can find some way to set the CC and CXX environment
>> variables for all builds, not just ones using autoconf, cmake or meson,
>> that might help cut down on the number of packages that still use gcc.
>> I'm just not quite sure how to implement this yet, but I'm looking into
>> it.
> 
> /usr/lib/rpm/macros has:
> 
> %___build_pre\
>   RPM_SOURCE_DIR=\"%{u2p:%{_sourcedir}}\"\
>   RPM_BUILD_DIR=\"%{u2p:%{_builddir}}\"\
>   RPM_OPT_FLAGS=\"%{optflags}\"\
>   RPM_LD_FLAGS=\"%{?build_ldflags}\"\
>   RPM_ARCH=\"%{_arch}\"\
>   RPM_OS=\"%{_os}\"\
>   RPM_BUILD_NCPUS=\"%{_smp_build_ncpus}\"\
>   export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_LD_FLAGS RPM_ARCH 
> RPM_OS RPM_BUILD_NCPUS RPM_LD_FLAGS\
>   RPM_DOC_DIR=\"%{_docdir}\"\
>   export RPM_DOC_DIR\
>   RPM_PACKAGE_NAME=\"%{NAME}\"\
>   RPM_PACKAGE_VERSION=\"%{VERSION}\"\
>   RPM_PACKAGE_RELEASE=\"%{RELEASE}\"\
>   export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE\
>   LANG=C\
>   export LANG\
>   unset CDPATH DISPLAY ||:\
>   %{?buildroot:RPM_BUILD_ROOT=\"%{u2p:%{buildroot}}\"\
>   export RPM_BUILD_ROOT}\
>   %{?_javaclasspath:CLASSPATH=\"%{_javaclasspath}\"\
>   export CLASSPATH}\
> 
> PKG_CONFIG_PATH=\"${PKG_CONFIG_PATH}:%{_libdir}/pkgconfig:%{_datadir}/pkgconfig\"\
>   export PKG_CONFIG_PATH\
>   CONFIG_SITE=${CONFIG_SITE:-NONE}\
>   export CONFIG_SITE\
>   \
>   %{verbose:set -x}\
>   umask 022\
>   cd \"%{u2p:%{_builddir}}\"\
> 
> 
> You should b able to expand (redefine anywhere else) this macro to set the 
> variables you need or call %set_build_flags.
> 

I did another mass rebuild, this time setting the CC and CXX environment 
variables
in __build_pre as you suggested.  The numbers look a little better now:

Packages Built:4271
Built with clang:  3355
Built with gcc:916

cc or c++ was invoked by about 50 packages.

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