Re: RHEL 9 and modularity

[Petr Pisar]

On Fri, Jun 19, 2020 at 05:44:37PM +0100, Daniel P. Berrangé wrote:
> On Fri, Jun 19, 2020 at 11:16:33AM -0400, Stephen Gallagher wrote:
> > On Fri, Jun 19, 2020 at 9:08 AM Martin Jackson  wrote:
> > 
> > 
> > > I use flatpaks on Fedora (Discord and okular), and I've really enjoyed
> > > the experience with them.  I'm not sure how well that would translate to
> > > the server environment though, but that general approach seems to do a
> > > good job of preserving user experience while isolating potentially
> > > troublesome conflicts in a way that doesn't mess up the "base system".
> > >
> > 
> > I love how people hold up "containers" as a solution to these problems
> > without considering for a moment how exactly the container itself gets
> > built. If you were to look into the flatpak build system in Fedora,
> > you'd see that they are using Modularity to construct them.
> >
> > One of the reasons for Modularity is that we agree that containers are
> > one "right" way to handle parallel-installability. But we also know
> > from past experience (SCLs) that having content in unusual locations
> > like /opt means that applications have to be modified. By using
> > modules to put the version of software you want into the standard
> > location and then using a container to isolate it and/or provide
> > parallel-installability, you also get the assurance of knowing the the
> > content in your container is just as trusted as your standard RPM
> > deployments.
> 
> IIUC from the docs, when using Modularity to build Flatpaks, the
> prefix is changed to /app instead of /usr, which makes it much
> closers to SCL:
> 
The relocation to /app brings exactly the same issues as SCL
,
.

-- Petr


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: RHEL 9 and modularity

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 22, 2020 at 04:55:10AM +0200, clime wrote:
> >> > > Hello Josh,
> >> > >
> >> > > you can change the artifact type while keeping interface the same and
> >> > > it would be a _HUGE_ win because it would make modularity finally
> >> > > understandable for mere humans and better maintainable.
> >> > >
> >> > > Namely, modules should become rpms and therefore obey standard rpm 
> >> > > rules.
> >> >
> >> > I'm not sure I entirely understand what you mean, but it sounds like
> >> > you have some interesting ideas.
> >> >
> >> > I'm looking forward to seeing what you and the community can build
> >> > from them, and how they could be brought into RHEL 10+!  That kind of
> >> > collaboration is what makes Fedora great.
> >>
> >> I know this probably won't change anything because this was mentioned
> >> many times (by me at least) and nothing has changed but still...
> >>
> >> Currently, modules are essentially yum sub-repos, they are not really
> >> "modules", instead they are collections of rpms that reinvent rpm-like
> >> relations (obsoletes, requires, build-requires, etc.).
> >>
> >> There is no reason for this wheel-reintervention. Modules (the
> >> collections) can be simply squashed into an rpm by automation and this
> >> resulting rpm can go to the modular repo together with other modules.

I agree with this general idea, even if not with the exact implementation
(comments below). In the past this was stated as "divorcing the build ordering
mechanism from the rpm delivery mechanism". The fact that we have two layers
of dependencies make Modularity conceptually hard and destroy the interaction
with the dependency solver. Also, if we disconnect the build and delivery
mechanisms, we can iterate and improve both separately.
 
> >> That way we don't have two types of objects we complex inter-relations
> >> but only one we well-known behavior.
> >>
> >> I wonder if this is clear to everyone but nobody really cares or
> >> doesn't really want to say it or I don't know.
> >>
> >> Is this clear to everyone? I mean either I am stating an obvious stuff
> >> that nobody really considers worth typing or idk.
> >
> >
> > How would this work when there are optional rpms in the module?
> >
> > You do not need to install every rpm in  eg the php module (different 
> > graphics/database backends) for that module to be useful, but every version 
> > of the module will have the rpm as an option which wont work outside a 
> > module of multiple rpms.
> 
> Glad you ask, I wasn't precise...
> 
> Well, I didn't mean everything always needs to be squashed, instead,
> it would be an optional step in modulemd processing.

So... if it's only optional, that means that the general case where
squashing is not done needs to be solved anyway. And once you have
solved the general case, what would the point of squashing be?
Thus, I don't find squashing useful.

> For some
> use-cases (like delicately compiled postgresql server), you can create
> a single rpm that contains all - postgresql-server, postgresql,
> postgresql-libs compiled in a specific way, optionally with some
> postgresql modules pre-included, so it would be let's say time-series
> optimized postgresql. Here it makes sense to make a single rpm from it
> - you install that and you are all set up for your use-case.
> 
> Then there are language stacks where you might want to build things in
> a specific order - there nothing really needs to be squashed (or
> certain subset can if it makes sense) but you can still use modularity
> to easily batch-build certain rpms. If there are runtime optional
> deps, they can be described by Recommends/Suggests.
> 
> Basically, once a "module" (things that comes from modulemd) is built,
> it should be put into normal repos and the "module" boundary should be
> forgotten (unless it is a single rpm), i.e. "module" is a built-time
> thing, at install-time we just have standard packages with standard
> deps.

Yep.

The unanswered question is what mechanism would be used make sure that
the rpms from the "module" are all installed. One option would be to
somehow mangle rpm names, another option would be to add some kind of
Provides/Requires, etc. But *some* mechanism is needed, because without
that dnf would often pick other rpms.

In Modularity the solution is that the rpms from the module shadow
rpms with the same name from outside. That's probably the single
feature of Modularity that causes the most problems.

> dnf interface could be kept given that we "Stream" rpm property is
> added. This is still a bit rough what I am saying but hopefully it
> makes at least a bit of sense...

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

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Tomáš Popela]

On Sat, Jun 20, 2020 at 11:24 AM Dan Čermák 
wrote:

> Sorry about the empty email, I've hit send too fast…
>
> Anyway, on the topic of parallel builds: what is everyone's opinion on
> adding the %limit_build macro from openSUSE (see:
>
> https://build.opensuse.org/package/view_file/network:chromium/memory-constraints/memory-constraints.macros?expand=1
> )?
>
> tl;dr; %limit_build -m 1500 will set the number of parallel processes so
> that if all of them consume 1500 MB of RAM at most, that they will not
> OOM your worker (especially handy on workers with many cores, but not
> much RAM).
>

We are being hit by this in WebKitGTK and in Firefox/Thunderbird from time
to time. There is an RFE for RPM to solve it -
https://bugzilla.redhat.com/show_bug.cgi?id=1118734.

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

Re: RHEL 9 and modularity

[clime]

On Mon, 22 Jun 2020 at 04:12, Naheem Zaffar  wrote:
>
>
>
> On Mon, 22 Jun 2020, 02:57 clime,  wrote:
>>
>> On Fri, 19 Jun 2020 at 01:59, Josh Boyer  wrote:
>> >
>> > On Thu, Jun 18, 2020 at 5:51 PM clime  wrote:
>> > >
>> > > On Thu, 18 Jun 2020 at 15:25, Josh Boyer  wrote:
>> > > >
>> > > > On Thu, Jun 18, 2020 at 9:05 AM Igor Raits
>> > > >  wrote:
>> > > > >
>> > > > > -BEGIN PGP SIGNED MESSAGE-
>> > > > > Hash: SHA512
>> > > > >
>> > > > > On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote:
>> >
>> > 
>> >
>> > > > > > Hopefully that provides some context and helps FESCo and the wider
>> > > > > > community understand where Red Hat is headed with modularity on the
>> > > > > > Enterprise side.
>> > > > >
>> > > > > Sadly no. It helps to understand your plans, however it does not help
>> > > > > to understand the reasons behind, whether you can't change UX in the
>> > > > > RHEL 9, or you think that technology is good enough for your 
>> > > > > use-cases
>> > > > > or any other reasons.
>> > > >
>> > > > The base requirement is that the UX remain largely the same.  As I
>> > > > said, from a RHEL perspective, we need RHEL 8 and RHEL 9 to have
>> > > > commonality so that our customers are not forced to learn something
>> > > > entirely different to adopt RHEL 9.  Improvements in the underlying
>> > > > functionality are of course welcome and planned, but we are not going
>> > > > to do something like replace modules with a different artifact type,
>> > >
>> > > Hello Josh,
>> > >
>> > > you can change the artifact type while keeping interface the same and
>> > > it would be a _HUGE_ win because it would make modularity finally
>> > > understandable for mere humans and better maintainable.
>> > >
>> > > Namely, modules should become rpms and therefore obey standard rpm rules.
>> >
>> > I'm not sure I entirely understand what you mean, but it sounds like
>> > you have some interesting ideas.
>> >
>> > I'm looking forward to seeing what you and the community can build
>> > from them, and how they could be brought into RHEL 10+!  That kind of
>> > collaboration is what makes Fedora great.
>>
>> I know this probably won't change anything because this was mentioned
>> many times (by me at least) and nothing has changed but still...
>>
>> Currently, modules are essentially yum sub-repos, they are not really
>> "modules", instead they are collections of rpms that reinvent rpm-like
>> relations (obsoletes, requires, build-requires, etc.).
>>
>> There is no reason for this wheel-reintervention. Modules (the
>> collections) can be simply squashed into an rpm by automation and this
>> resulting rpm can go to the modular repo together with other modules.
>>
>> That way we don't have two types of objects we complex inter-relations
>> but only one we well-known behavior.
>>
>> I wonder if this is clear to everyone but nobody really cares or
>> doesn't really want to say it or I don't know.
>>
>> Is this clear to everyone? I mean either I am stating an obvious stuff
>> that nobody really considers worth typing or idk.
>
>
> How would this work when there are optional rpms in the module?
>
> You do not need to install every rpm in  eg the php module (different 
> graphics/database backends) for that module to be useful, but every version 
> of the module will have the rpm as an option which wont work outside a module 
> of multiple rpms.

Glad you ask, I wasn't precise...

Well, I didn't mean everything always needs to be squashed, instead,
it would be an optional step in modulemd processing. For some
use-cases (like delicately compiled postgresql server), you can create
a single rpm that contains all - postgresql-server, postgresql,
postgresql-libs compiled in a specific way, optionally with some
postgresql modules pre-included, so it would be let's say time-series
optimized postgresql. Here it makes sense to make a single rpm from it
- you install that and you are all set up for your use-case.

Then there are language stacks where you might want to build things in
a specific order - there nothing really needs to be squashed (or
certain subset can if it makes sense) but you can still use modularity
to easily batch-build certain rpms. If there are runtime optional
deps, they can be described by Recommends/Suggests.

Basically, once a "module" (things that comes from modulemd) is built,
it should be put into normal repos and the "module" boundary should be
forgotten (unless it is a single rpm), i.e. "module" is a built-time
thing, at install-time we just have standard packages with standard
deps.

dnf interface could be kept given that we "Stream" rpm property is
added. This is still a bit rough what I am saying but hopefully it
makes at least a bit of sense...

clime

>
> ___
> 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/pro

Re: RHEL 9 and modularity

[Naheem Zaffar]

On Mon, 22 Jun 2020, 02:57 clime,  wrote:

> On Fri, 19 Jun 2020 at 01:59, Josh Boyer  wrote:
> >
> > On Thu, Jun 18, 2020 at 5:51 PM clime  wrote:
> > >
> > > On Thu, 18 Jun 2020 at 15:25, Josh Boyer  wrote:
> > > >
> > > > On Thu, Jun 18, 2020 at 9:05 AM Igor Raits
> > > >  wrote:
> > > > >
> > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > Hash: SHA512
> > > > >
> > > > > On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote:
> >
> > 
> >
> > > > > > Hopefully that provides some context and helps FESCo and the
> wider
> > > > > > community understand where Red Hat is headed with modularity on
> the
> > > > > > Enterprise side.
> > > > >
> > > > > Sadly no. It helps to understand your plans, however it does not
> help
> > > > > to understand the reasons behind, whether you can't change UX in
> the
> > > > > RHEL 9, or you think that technology is good enough for your
> use-cases
> > > > > or any other reasons.
> > > >
> > > > The base requirement is that the UX remain largely the same.  As I
> > > > said, from a RHEL perspective, we need RHEL 8 and RHEL 9 to have
> > > > commonality so that our customers are not forced to learn something
> > > > entirely different to adopt RHEL 9.  Improvements in the underlying
> > > > functionality are of course welcome and planned, but we are not going
> > > > to do something like replace modules with a different artifact type,
> > >
> > > Hello Josh,
> > >
> > > you can change the artifact type while keeping interface the same and
> > > it would be a _HUGE_ win because it would make modularity finally
> > > understandable for mere humans and better maintainable.
> > >
> > > Namely, modules should become rpms and therefore obey standard rpm
> rules.
> >
> > I'm not sure I entirely understand what you mean, but it sounds like
> > you have some interesting ideas.
> >
> > I'm looking forward to seeing what you and the community can build
> > from them, and how they could be brought into RHEL 10+!  That kind of
> > collaboration is what makes Fedora great.
>
> I know this probably won't change anything because this was mentioned
> many times (by me at least) and nothing has changed but still...
>
> Currently, modules are essentially yum sub-repos, they are not really
> "modules", instead they are collections of rpms that reinvent rpm-like
> relations (obsoletes, requires, build-requires, etc.).
>
> There is no reason for this wheel-reintervention. Modules (the
> collections) can be simply squashed into an rpm by automation and this
> resulting rpm can go to the modular repo together with other modules.
>
> That way we don't have two types of objects we complex inter-relations
> but only one we well-known behavior.
>
> I wonder if this is clear to everyone but nobody really cares or
> doesn't really want to say it or I don't know.
>
> Is this clear to everyone? I mean either I am stating an obvious stuff
> that nobody really considers worth typing or idk.
>

How would this work when there are optional rpms in the module?

You do not need to install every rpm in  eg the php module (different
graphics/database backends) for that module to be useful, but every version
of the module will have the rpm as an option which wont work outside a
module of multiple rpms.

>
___
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: RHEL 9 and modularity

[clime]

On Fri, 19 Jun 2020 at 01:59, Josh Boyer  wrote:
>
> On Thu, Jun 18, 2020 at 5:51 PM clime  wrote:
> >
> > On Thu, 18 Jun 2020 at 15:25, Josh Boyer  wrote:
> > >
> > > On Thu, Jun 18, 2020 at 9:05 AM Igor Raits
> > >  wrote:
> > > >
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA512
> > > >
> > > > On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote:
>
> 
>
> > > > > Hopefully that provides some context and helps FESCo and the wider
> > > > > community understand where Red Hat is headed with modularity on the
> > > > > Enterprise side.
> > > >
> > > > Sadly no. It helps to understand your plans, however it does not help
> > > > to understand the reasons behind, whether you can't change UX in the
> > > > RHEL 9, or you think that technology is good enough for your use-cases
> > > > or any other reasons.
> > >
> > > The base requirement is that the UX remain largely the same.  As I
> > > said, from a RHEL perspective, we need RHEL 8 and RHEL 9 to have
> > > commonality so that our customers are not forced to learn something
> > > entirely different to adopt RHEL 9.  Improvements in the underlying
> > > functionality are of course welcome and planned, but we are not going
> > > to do something like replace modules with a different artifact type,
> >
> > Hello Josh,
> >
> > you can change the artifact type while keeping interface the same and
> > it would be a _HUGE_ win because it would make modularity finally
> > understandable for mere humans and better maintainable.
> >
> > Namely, modules should become rpms and therefore obey standard rpm rules.
>
> I'm not sure I entirely understand what you mean, but it sounds like
> you have some interesting ideas.
>
> I'm looking forward to seeing what you and the community can build
> from them, and how they could be brought into RHEL 10+!  That kind of
> collaboration is what makes Fedora great.

I know this probably won't change anything because this was mentioned
many times (by me at least) and nothing has changed but still...

Currently, modules are essentially yum sub-repos, they are not really
"modules", instead they are collections of rpms that reinvent rpm-like
relations (obsoletes, requires, build-requires, etc.).

There is no reason for this wheel-reintervention. Modules (the
collections) can be simply squashed into an rpm by automation and this
resulting rpm can go to the modular repo together with other modules.

That way we don't have two types of objects we complex inter-relations
but only one we well-known behavior.

I wonder if this is clear to everyone but nobody really cares or
doesn't really want to say it or I don't know.

Is this clear to everyone? I mean either I am stating an obvious stuff
that nobody really considers worth typing or idk.

Anyway best regards
clime

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

CPE Weekly: 2020-06-21

[Aoife Moloney]

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-06-21

Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers
can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

Please check out our updated initiative timetable for briefing in new
projects to our team
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.

Dont forget to view our taiga board to see the projects we are
currently working on, what we have scoped and whats in our backlog
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null


CPE Product Owner Office Hours
* Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1
* Every second Tuesday @ 1500 UTC on #centos-meeting (next meeting 23rd June)










## Fedora Updates




### Data Centre Move
* We are now officially operating under reduced Fedora services until
est 28th July to facilitate the final shipment of hardware to the new
data centre.
* Most recent update to devel-announce is here
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/5DNRZ4OUUNGSUJONQLEXXP3CKME43SCE/
* A list of affected services is available here
https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA?view
* Details on what this move may mean for you can be found here
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/27U6YT73556KYW2RIFJO6J2HYMYVP22U/
* If an application is not working correctly at all, please check this
list https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA?view before opening a
ticket to make sure its not listed as being moved. If it is being
moved, please wait a day or two, then try again.
* Similarly, please be patient when opening tickets for service issues
in general as we have now reached the critical point in this move and
all of our sys-admins and wider teams will be assisting in the
successful bringup of the reduced Fedora service and facilitation of
the final hardware shipment and move.



### AAA Replacement
* The team are working on the changing application code bases to use
the new solution
* The work required to facilitate multiple contributor agreements
under one account is now complete
* The team have also enabled group attributes during this sprint
* Please feel free to check out the team kanban board for more
information on the features the team are working on and have already
completed here https://github.com/orgs/fedora-infra/projects/6





### Mbbox
* Project Dashboard here https://github.com/fedora-infra/mbbox/projects/1
* Tasks completed in the project currently
* MBS Frontend CRD + documentation
* Staging environment - thanks to CentOS CI team
* MBox shared CRD - certificates and PVCs

* Tasks underway currently
* Staging environment - testing
* MBox shared CRD - tests and polishing





### Gitforge
With the data centre move taking most of the teams focus this week,
discussions with gitlab have been quiet. We are still discussing
technical aspects of the project and these are tracked here:
https://gitlab.com/gitlab-org/gitlab/-/issues/217350
We will keep you up to date with the developments as and when we have
information to share and thank you for your patience.



## CentOS Updates

### CentOS
* CentOS Linux 8.2.2004 Released!!!
https://lists.centos.org/pipermail/centos-announce/2020-June/035756.html

### Centos Other
* OCP4 staging cluster is up and running
* CentOS will have a booth at Open Source Summit starting June 29th -
https://events.linuxfoundation.org/open-source-summit-north-america/


### CentOS Stream
* The team are still working on building packages from the RHEL 8.3
nightly composes



















As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great week ahead!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Dominik 'Rathann' Mierzejewski]

On Saturday, 20 June 2020 at 09:20, Kamil Dudka wrote:
> On Saturday, June 20, 2020 12:17:26 AM CEST Tomasz Kłoczko wrote:
> > All parallel build issues should be treated *as critical bugs*
> >  which should be *ASAP fixed*.
> > 
> > kloczek
> 
> Seriously, are you saying that bugs causing slower build are as important
> as bugs causing data lost or security vulnerabilities at run time?
> 
> If they are so important for you, please help us to get them fixed!
> 
> I tried to parallelize the build of nss and failed:
> 
> https://src.fedoraproject.org/rpms/nss/c/6e689ce0
> https://src.fedoraproject.org/rpms/nss/c/3c27dc24
> 
> I would really appreciate your help on this.

Same for INN:
https://bugzilla.redhat.com/show_bug.cgi?id=1558586

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

[Test-Announce] Fedora 33 Rawhide 20200620.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 33 Rawhide 20200620.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/33

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200620.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200620.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200620.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200620.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200620.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200620.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200620.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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