Re: Bodhi API does not list f39 in pending releases

[Clement Verna]

On Wed, 25 Oct 2023 at 12:55, Tomas Hrcka  wrote:

> This looks like a bug in bodhi.
>
> the web UI lists correct releases pending and current.
>
> On Wed, Oct 25, 2023 at 11:57 AM Pavel Březina 
> wrote:
> >
> > Hi,
> > Fedora 39 stopped showing in pending releases (and is not in current
> > either) when using:
> >
> > curl https://bodhi.fedoraproject.org/releases/?state=pending | jq
> >
> > There is Fedora 39 as flatpak and container, but not with
> id_prefix==FEDORA.
> >
> > Is this because it is now in final freeze or is it a bodhi bug?
>

Yes it's because of the freeze, Fedora 39 is listed in the `frozen` state
to reflect the current release freeze. `curl
https://bodhi.fedoraproject.org/releases/?state=frozen | jq`.

Maybe other F39 releases (container, flatpaks) should also show as frozen.


> >
> > We rely on this information to automatically pick up fedora versions for
> > SSSD PR CI.
> >
> > Thanks.
> > Pavel
> > ___
> > 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
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> --
> Tomas Hrcka
> fas: humaton
> libera.CHAT: jednorozec
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: An update on RHEL moving to issues.redhat.com

[Clement Verna]

On Fri, 15 Sept 2023 at 11:37, Leon Fauster via devel <
devel@lists.fedoraproject.org> wrote:

> Am 15.09.23 um 07:43 schrieb Clement Verna:
>
> > At the risk of being controversial and a voice of the minority, I think
> > using GitHub would be beneficial for the Fedora project. In practice
> > already most of packagers have to use GitHub to collaborate with
> > upstream so it wouldn't  be a tool to learn. But where, GitHub would be
> > really beneficial IMO is for making our work more visible and reachable
> > to attract new contributors. It is also worth to mention that other
> > distros close to Fedora like Alma Linux or Rocky Linux are using GitHub
> > for their development and it doesn't seems to be a problem.
> >
> IIRC, github just get copies of the self-hosted git-instances that are
> based on gitea (https://git.almalinux.org/) or gitlab
> (https://git.rockylinux.org/) ...
>

Ha thanks, that's interesting. I look at both project web page and just saw
the links to GitHub.


>
> --
> Leon
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: An update on RHEL moving to issues.redhat.com

[Clement Verna]

OOn Thu, 14 Sept 2023, 18:01 Adam Williamson, 
wrote:

> On Thu, 2023-09-14 at 14:50 +0200, Fabio Valentini wrote:
> > On Thu, Sep 14, 2023 at 2:42 PM Colin Walters 
> wrote:
> > >
> > > On Wed, Sep 13, 2023, at 1:44 PM, Matthew Miller wrote:
> > > > On Mon, Sep 11, 2023 at 09:20:09AM -0700, Adam Williamson wrote:
> > > > > IIRC it was a condition of that proposal that we wind up on a
> hosted
> > > > > version of the *open source* release of gitlab, which is something
> we
> > > > > managed to talk gitlab into doing for us. IMBW, though, it was a
> while
> > > > > ago.
> > > >
> > > > Short version is: yes, we did talk them into that with an informal
> plan, and
> > > > then someone higher up at gitlab pulled the plug on the idea.
> > >
> > > FWIW I interact with pagure rarely enough that it is somewhat painful
> to context switch each time.  I accept having to deal with both github and
> gitlab, but going from 2 to 3 has a real cost, particularly around things
> like CI systems.
> >
> > Switch GitLab and Pagure in that statement and I could say the exact
> same thing.
> >
> > Personally, I find the Pagure UI (and GitHub) to be much cleaner and
> > easier to navigate than the UX mess that is GitLab ...
> > I even find fully FOSS alternatives like Forgejo (Codeberg) *much*
> > easier to use than GitLab.
>
> UI is one thing, but Colin's not wrong about CI.
>
> Love Github or hate it, Github Actions is a pretty strong CI
> implementation that is very easy to set up. I haven't personally set up
> CI for a Gitlab repo yet, but I believe it's also relatively simple
> there.
>

At the risk of being controversial and a voice of the minority, I think
using GitHub would be beneficial for the Fedora project. In practice
already most of packagers have to use GitHub to collaborate with upstream
so it wouldn't  be a tool to learn. But where, GitHub would be really
beneficial IMO is for making our work more visible and reachable to attract
new contributors. It is also worth to mention that other distros close to
Fedora like Alma Linux or Rocky Linux are using GitHub for their
development and it doesn't seems to be a problem.


> Doing it for a non-dist-git Pagure project is not *terrible*, but it
> involves a lot more finicky steps than doing it on Github, including
> waiting for someone to merge a pull request you have to file halfway
> through:
>
>
> https://fedoraproject.org/wiki/Zuul-based-ci#How_to_attach_a_Pagure_repository_on_Zuul
>
> and you don't have access to something like the Github Actions library
> of setup steps to configure your environment. It would be a significant
> enhancement to Pagure if this experience could be made smoother for
> non-dist-git projects.
>
> On the whole, I do mostly like Pagure's UI too, but it is missing some
> capabilities compared to much more deeply-funded projects (not a
> surprise).
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Issue with Rawhide docker image?

[Clement Verna]

Once https://github.com/docker-library/official-images/pull/14789 merges,
the rawhide image on the DockerHub should be fixed too :-)

Thanks for flagging this up.


On Tue, 6 Jun 2023 at 16:37, Ron Olson  wrote:

> Yep, that worked, thanks!
>
> For folks searching similar info later, I ran:
>
> docker pull registry.fedoraproject.org/fedora:rawhide
>
> On 6 Jun 2023, at 8:34, David Schwörer wrote:
>
> Seems a bit disappointing. I’ve been searching but cannot find any
> info on configuring docker to use Fedora’s repo so I could just ignore
> the issue altogether. :)
>
> You should be able to use a full url:
> podman pull registry.fedoraproject.org/fedora:rawhide
> podman pull quay.io/fedora/fedora:rawhide
> Same should be true for docker, but I haven't tested.
> --
>
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Clement Verna]

I think it's worth to mention that many layered container images are
published directly on the Fedora's Quay.io organisation (
https://quay.io/organization/fedora).
The builds are not happening in OSBS or the Fedora infrastructure but IIRC
it's a GitHub Action that does the build and pushes the container image.
There could be an option to leverage Quay.io build capabilities too.

On Tue, 30 May 2023, 17:02 Owen Taylor,  wrote:

>
>
> On Tue, May 30, 2023 at 9:47 AM Debarshi Ray  wrote:
>
>> Hey Owen,
>>
>> On Mon, 2023-05-29 at 12:39 -0400, Owen Taylor wrote:
>> > On Mon, May 29, 2023 at 8:16 AM Debarshi Ray via devel
>> >  wrote:
>> > >
>> > > My main concern, which I had brought up in the Release Engineering
>> > > tickets before [1,2] is whether the fedora-toolbox images would
>> > > continue to be defined as a Docker/Containerfile.  I am asking
>> > > because the fedora base images are defined as kickstart files [3].
>> > >
>> > > There's some value in continuing to use a Docker/Containerfile
>> > > because it's widely known and leads to a common workflow.  It is
>> > > used for the official Toolbx images for other distributions like
>> > > Arch Linux, RHEL and Ubuntu, and a growing list of third-party
>> > > Toolbx images [4].  A Docker/Containerfile is easy to use with
>> > > 'podman build' as part of the upstream CI, which makes it easier to
>> > > test all the different parts.
>> >
>> > Unfortunately, if we switched to using ImageFactory or pretty much
>> > anything other than OSBS, we'd no longer be able to define the Fedora
>> > toolbox image as a Dockerfile. It certainly is a disadvantage that
>> > it's no longer connected to the way that the other toolbox images are
>> > defined,
>>
>> It's an advantage to have the Fedora images be defined in the same
>> source language as the Arch Linux and Ubuntu images, and certainly the
>> RHEL images.  However, ultimately, I see it only as a convenience.
>> Folks can take the Fedora images as a reference and tweak them to fit
>> their own distribution, or copy paste the files across Git
>> repositories, etc..  If we lose that, then I would learn to live with
>> it.  :)
>>
>
> I guess in this scenario, the Fedora images are no longer the reference
> for creating things for other distributions and something else (RHEL,
> Ubuntu, ...) would have to take over that role. For "tweaking", I'd think
> we'd definitely want to promote "FROM fedora-toolbox:latest".
>
>
>> If we do move away from Container/Dockerfiles, then my main question
>> would be whether it'll still be easy to locally build the images.  Will
>> we need something a lot more elaborate than the simplicity of a 'podman
>> build'?
>>
>
> I haven't actually tried building the Fedora container images locally,
> but  it it looks relatively documented and straightforward, and someone
> could write a shell script to automate it pretty easily. But it is still
> going to require tools (ImageFactory) that people don't have installed and
> probably take a while to run. It seems like more of a "want to contribute
> to the the Fedora toolbox image" thing than a "would do it to run tests
> when contributing to Toolbx" thing.
>
> Toolbx has two parts.  A somewhat distro-agnostic toolbox(1) binary,
>> and an OCI image for a distribution.  Both work together to provide an
>> interactive CLI environment, and hence both should be tested together.
>>
>> If a contributor attempts to change one or both of those two, then it
>> should be easy for them to verify whether both would continue to work
>> together.  Currently, they can do that by doing a local 'podman build'
>> on the image definitions in toolbox.git and try to use them with their
>> modified toolbox(1) binary.  I want to formalize this by making the
>> upstream CI run against both:
>>   (a) images that are currently published on the OCI registries and
>>   (b) images that are built on-the-fly from the sources in toolbox.git
>>
>
> In this scenario the Fedora Toolbx image definition would live in
> fedora-kickstarts, so it doesn't really make sense for me that Toolbox CI
> would *recreate it*, rather than just using the version from the repository.
>
> Ideally, we'd run the Toolbox tests against the newly built Toolbx image
> as part of QE for the Fedora compose.
>
>
>> ... so that it will validate any changes to the image sources in
>> toolbox.git, and alert us to any changes in the underlying distribution
>> (eg., packages, dependencies, base images, etc.) that could break
>> future image rebuilds.
>>
>> Currently, the upstream CI runs only against (a).
>>
>> If we lose the simplicity of a 'podman build' then we lose the testing.
>> That's my main worry.
>>
>> If the new set-up offers a similarly simple way of building the images
>> from source, then I am happy.
>>
>> > but maybe that's bearable if we can substantially improve the
>> > workflow?
>>
>> The phrase "we can substantially improve the workflow" makes me
>> curious.  Any details or pointers?
>>
>

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Clement Verna]

On Tue, 9 May 2023, 17:51 Kevin Fenzi,  wrote:

> Just a general answer/info here at the bottom of the thread...
>
> I realize our container build pipeline is not great, but it's currently
> working and I will keep it working until we replace it.
>
> I agree we should replace it, and there's lots of options, but I don't
> think this thread is the place to go back and forth about them.
>
> I know of at least kiwi, osbuild, some other build systems that don't
> fully exist yet, switching to use quay.io, osbs2 (based on openshift4),
> and probibly others.
>

I also agree that we should replace it but that's not an easy task
unfortunately.
My understanding of osbuild is that it focuses on base images and not
layered images so that probably would not be a good candidate for replacing
OSBS. I might also be wrong :-)

>
> kevin
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Clement Verna]

On Tue, 9 May 2023, 15:42 Debarshi Ray via devel, <
devel@lists.fedoraproject.org> wrote:

> Hey Clement,
>
> On Tue, 2023-05-09 at 09:45 +0200, Clement Verna wrote:
> >
> >
> > On Mon, 8 May 2023 at 22:11, Kevin Fenzi  wrote:
> > > On Mon, May 08, 2023 at 07:57:30PM +, Zbigniew Jędrzejewski-
> > > Szmek wrote:
> > > >
> > > > I think we need some clarity wrt. to the dependency order here.
> > > > Let's say we:
> > > > > In order to do this at branch point, we will need to move
> > > > > building this
> > > > > image into the compose process and mark it blocking.
> > > > OK, so we build things, but then we need to publish to
> > > > registry.fp.o,
> > > > which is asynchrounous (?). When we test the newly built ISOs, do
> > >
> > > No, it happens at the end of the compose (if no blocking
> > > deliverables failed causing the compose to fail)
> >
> > If we do this, we should also make the container base images release
> > blocking since AFAIK they are currently not release blocking.
>
> Yes, that's a good point.
>
> The OCI base images aren't currently listed as release-blocking
> deliverables:
> https://docs.fedoraproject.org/en-US/releases/f39/blocking/
>
> ... but if this Change goes through, then they will implicitly become
> release-blocking deliverables because the fedora-toolbox images are
> based on them.
>
> Should we explicitly mention this in the Change?  Or, something else?
> Or, is it fine as it is?
>

I think mentioning explicitly in this change is good enough :)

>
> Thanks,
> Rishi
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Clement Verna]

On Mon, 8 May 2023 at 22:11, Kevin Fenzi  wrote:

> On Mon, May 08, 2023 at 07:57:30PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > I think we need some clarity wrt. to the dependency order here.
> > Let's say we:
> > > In order to do this at branch point, we will need to move building this
> > > image into the compose process and mark it blocking.
> > OK, so we build things, but then we need to publish to registry.fp.o,
> > which is asynchrounous (?). When we test the newly built ISOs, do
>
> No, it happens at the end of the compose (if no blocking deliverables
> failed causing the compose to fail)
>

If we do this, we should also make the container base images release
blocking since AFAIK they are currently not release blocking.


> > we test them also with the latest image that we get from registry.fp.o?
> > And if we find a bug anywhere in this pipeline, we respin everything?
>
> Good question. I'll note that currently we do not do any specific
> testing after branch point. We freeze things to get a compose to
> complete, but then we move on. It's not like Beta or Final.
>
> > > I'd like to note that making this blocking doesn't waive any kind of
> > > magic wand that makes our infrastructure more reliable. ;)
> > > The container build pipeline is a long collection of fragile things.
> > > It may well result in us slipping more based on things not working. ;(
> >
> > Hmm, quoting from https://pagure.io/releng/issue/11092:
> > >> Also the aarch64 cluster is running on Fedora 33 boxes, so we
> > >> should probably try to do a full redeploy :-(
> > > We can't upgrade it from f33 because docker is no longer in f34+ and
> > > openshift origin / 3.11 doesn't support any newer either.
> >
> > Is this still true? I don't think we want to make the Fedora release
> > process contingent on something that requires F33.
>
> yes, it's still true. Note thats the aarch64 osbs cluster.
> The x86_64 one is rhel7.
>
> So, perhaps it would make sense to only make the x86_64 one blocking?


> kevin
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can't pull fedora rawhide container image

[Clement Verna]

This is fixed now, happy containering :-D

On Thu, 8 Dec 2022 at 13:55, Jun Aruga (he / him)  wrote:

> On Thu, Dec 8, 2022 at 11:02 AM Clement Verna 
> wrote:
> >
> > There is a BZ to track this too
> https://bugzilla.redhat.com/show_bug.cgi?id=2151833
> >
> >
> > On Thu, 8 Dec 2022 at 10:50, Clement Verna 
> wrote:
> >>
> >> The last working build [1] had only the aarch64 image. Since the
> rawhide images are pushed to the registry everyday that probably explain
> why you can't pull rawhide images on non aarch64 arch.
> >>
> >> I ll try to look at why we did not have the other arches builds.
> >>
> >> [1] - https://koji.fedoraproject.org/koji/buildinfo?buildID=2097508
>
> Thanks for the info! I will check and watch the Bugzilla ticket.
>
> --
> Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
> See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
> the timezone.
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can't pull fedora rawhide container image

[Clement Verna]

There is a BZ to track this too
https://bugzilla.redhat.com/show_bug.cgi?id=2151833


On Thu, 8 Dec 2022 at 10:50, Clement Verna  wrote:

> The last working build [1] had only the aarch64 image. Since the rawhide
> images are pushed to the registry everyday that probably explain why you
> can't pull rawhide images on non aarch64 arch.
>
> I ll try to look at why we did not have the other arches builds.
>
> [1] - https://koji.fedoraproject.org/koji/buildinfo?buildID=2097508
>
>
> On Wed, 7 Dec 2022 at 17:40, Jun Aruga (he / him) 
> wrote:
>
>> I am trying to pull the fedora rawhide image from
>> https://registry.fedoraproject.org/ .
>>
>> First, the URL below to print available tags is empty on my browser.
>> https://registry.fedoraproject.org/repo/fedora/tags/
>>
>> But I was able to see the available tags by skopeo. And the "rawhide"
>> tag is included.
>>
>> ```
>> $ rpm -q skopeo
>> skopeo-1.10.0-3.fc37.x86_64
>>
>> $ skopeo list-tags docker://registry.fedoraproject.org/fedora
>> {
>> "Repository": "registry.fedoraproject.org/fedora",
>> "Tags": [
>> "34-aarch64",
>> "34-ppc64le",
>> "34-x86_64",
>> "34",
>> "34-s390x",
>> "34-armhfp",
>> "33-armhfp",
>> "32-armhfp",
>> "35-aarch64",
>> "35-ppc64le",
>> "35-s390x",
>> "35-x86_64",
>> "35",
>> "35-armhfp",
>> "36-aarch64",
>> "36-armhfp",
>> "36-ppc64le",
>> "36-s390x",
>> "36-x86_64",
>> "30-aarch64",
>> "30-ppc64le",
>> "30-s390x",
>> "30-x86_64",
>> "30",
>> "latest",
>> "rawhide",
>> "30-armhfp",
>> "36",
>> "31-aarch64",
>> "31-x86_64",
>> "31",
>> "31-armhfp",
>> "31-s390x",
>> "31-ppc64le",
>> "32-aarch64",
>> "32-ppc64le",
>> "32-s390x",
>> "32-x86_64",
>> "32",
>> "33-aarch64",
>> "33-ppc64le",
>> "33-s390x",
>> "33-x86_64",
>> "33",
>> "37-aarch64",
>> "37-ppc64le",
>> "37-s390x",
>> "37-x86_64",
>> "37",
>> "38-aarch64",
>> "38-ppc64le",
>> "38-s390x",
>> "38-x86_64",
>> "38"
>> ]
>> }
>> ```
>>
>> However I failed to pull the fedora:rawhide, while I was able to pull
>> the fedora:latest. Do you know what's wrong? Thanks.
>>
>> ```
>> $ rpm -q podman
>> podman-4.3.1-1.fc37.x86_64
>>
>> $ podman pull registry.fedoraproject.org/fedora
>> Trying to pull registry.fedoraproject.org/fedora:latest...
>> Getting image source signatures
>> Copying blob 2a0fc6bf62e1 done
>> Copying config 9538a60368 done
>> Writing manifest to image destination
>> Storing signatures
>> 9538a60368f65b52c44a612bbe694a0bfdeb57f081dee4f9888fe7825c6488b9
>>
>> $ podman pull registry.fedoraproject.org/fedora:rawhide
>> Trying to pull registry.fedoraproject.org/fedora:rawhide...
>> Error: choosing an image from manifest list
>> docker://registry.fedoraproject.org/fedora:rawhide: no image found in
>> manifest list for architecture amd64, variant "", OS linux
>> ```
>>
>> --
>> Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
>> See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
>> the timezone.
>> ___
>> 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
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can't pull fedora rawhide container image

[Clement Verna]

The last working build [1] had only the aarch64 image. Since the rawhide
images are pushed to the registry everyday that probably explain why you
can't pull rawhide images on non aarch64 arch.

I ll try to look at why we did not have the other arches builds.

[1] - https://koji.fedoraproject.org/koji/buildinfo?buildID=2097508


On Wed, 7 Dec 2022 at 17:40, Jun Aruga (he / him)  wrote:

> I am trying to pull the fedora rawhide image from
> https://registry.fedoraproject.org/ .
>
> First, the URL below to print available tags is empty on my browser.
> https://registry.fedoraproject.org/repo/fedora/tags/
>
> But I was able to see the available tags by skopeo. And the "rawhide"
> tag is included.
>
> ```
> $ rpm -q skopeo
> skopeo-1.10.0-3.fc37.x86_64
>
> $ skopeo list-tags docker://registry.fedoraproject.org/fedora
> {
> "Repository": "registry.fedoraproject.org/fedora",
> "Tags": [
> "34-aarch64",
> "34-ppc64le",
> "34-x86_64",
> "34",
> "34-s390x",
> "34-armhfp",
> "33-armhfp",
> "32-armhfp",
> "35-aarch64",
> "35-ppc64le",
> "35-s390x",
> "35-x86_64",
> "35",
> "35-armhfp",
> "36-aarch64",
> "36-armhfp",
> "36-ppc64le",
> "36-s390x",
> "36-x86_64",
> "30-aarch64",
> "30-ppc64le",
> "30-s390x",
> "30-x86_64",
> "30",
> "latest",
> "rawhide",
> "30-armhfp",
> "36",
> "31-aarch64",
> "31-x86_64",
> "31",
> "31-armhfp",
> "31-s390x",
> "31-ppc64le",
> "32-aarch64",
> "32-ppc64le",
> "32-s390x",
> "32-x86_64",
> "32",
> "33-aarch64",
> "33-ppc64le",
> "33-s390x",
> "33-x86_64",
> "33",
> "37-aarch64",
> "37-ppc64le",
> "37-s390x",
> "37-x86_64",
> "37",
> "38-aarch64",
> "38-ppc64le",
> "38-s390x",
> "38-x86_64",
> "38"
> ]
> }
> ```
>
> However I failed to pull the fedora:rawhide, while I was able to pull
> the fedora:latest. Do you know what's wrong? Thanks.
>
> ```
> $ rpm -q podman
> podman-4.3.1-1.fc37.x86_64
>
> $ podman pull registry.fedoraproject.org/fedora
> Trying to pull registry.fedoraproject.org/fedora:latest...
> Getting image source signatures
> Copying blob 2a0fc6bf62e1 done
> Copying config 9538a60368 done
> Writing manifest to image destination
> Storing signatures
> 9538a60368f65b52c44a612bbe694a0bfdeb57f081dee4f9888fe7825c6488b9
>
> $ podman pull registry.fedoraproject.org/fedora:rawhide
> Trying to pull registry.fedoraproject.org/fedora:rawhide...
> Error: choosing an image from manifest list
> docker://registry.fedoraproject.org/fedora:rawhide: no image found in
> manifest list for architecture amd64, variant "", OS linux
> ```
>
> --
> Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
> See  for
> the timezone.
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora CoreOS survey

[Clement Verna]

Thanks to everyone that answered the survey. I shared a short summary of
the results
https://discussion.fedoraproject.org/t/fedora-coreos-survey/34408/2

On Wed, 10 Nov 2021 at 12:52, Clement Verna 
wrote:

> Hi,
>
> The Fedora CoreOS Working Group [1] is looking to get feedback on how we
> share our progress with the rest of the Community. The goal being to help
> us understand which communication channel works best and also gather ideas
> about things we could try.
>
> Here is a link to our very short survey where you can give us that
> feedback: https://fedoraproject.limequery.com/865299
>
> If you could take the time (5mins max) to complete it for us it would be
> massively appreciated.
>
> Happy surveying :-)
>
> [1] -
> https://github.com/coreos/fedora-coreos-tracker#fedora-coreos-working-group
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS survey

[Clement Verna]

Hi,

The Fedora CoreOS Working Group [1] is looking to get feedback on how we
share our progress with the rest of the Community. The goal being to help
us understand which communication channel works best and also gather ideas
about things we could try.

Here is a link to our very short survey where you can give us that
feedback: https://fedoraproject.limequery.com/865299

If you could take the time (5mins max) to complete it for us it would be
massively appreciated.

Happy surveying :-)

[1] -
https://github.com/coreos/fedora-coreos-tracker#fedora-coreos-working-group
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora CoreOS stable stream now rebased to Fedora 34

[Clement Verna]

On Thu, 20 May 2021 at 18:14, Ron Olson  wrote:

> If I may, I think the issue is right there in the name: Fedora CoreOS. The
> Fedora name brings some expectations and it seems CoreOS, by its nature,
> can’t be at parity with the other Fedora flavors and that leads to
> confusion. I can attest that I was surprised when I learned Fedora CoreOS
> didn’t support cgroups v2 and that confused me; it’s Fedora, of course it
> would have the latest-n-greatest.
>
> I used CoreOS before it bought by RH, and I could accept whatever
> limitations it had because there were no expectations. Here’s a specialized
> distro that does things in its own way.
>
> I’m guessing this is laughably not possible, but I’m going to suggest
> anyway that maybe it be renamed either back to simply “CoreOS” or something
> new like “Bowler” or whatever that indicates that it is its own special
> thing and expectations can be set accordingly.
>
I understand that having Fedora in the name can bring some expectations and
that changing these might be hard, but I think it is good to remember that
the first FCOS release is not even 2 years old [0]. FCOS has a different
release model than Fedora Linux and I think it is fair to give it time to,
on one hand continue to improve how features are making their way in FCOS,
and on the other hand get people be more familiar with what FCOS is and
what expectations to have about it.

[0] - https://fedoramagazine.org/introducing-fedora-coreos/

> On 20 May 2021, at 2:24, Clement Verna wrote:
>
>
>
> On Wed, 19 May 2021 at 22:48, Joe Doss  wrote:
>
>> On Wed, May 19, 2021 at 2:45 AM Clement Verna
>> >  wrote:
>> >> I think this is the fundamental difference here, Fedora CoreOS does
>> >> not have a version number. It has 3 streams, stable, testing and
>> >> next, these streams are based on a version of Fedora Linux but that
>> >> should just be a detail that most end users should not have to care
>> >> about.
>>
>> I disagree here. Fedora CoreOS has the Fedora name in it and it should
>> have the same fundamental features and changes that ship with each
>> Fedora release. To say it doesn't have a base version and that users
>> shouldn't care about it is pretty dismissive.
>>
>
> Sorry if that sounded dismissive, but that's really how I feel. I
> recognize that I have a bias towards thinking that most FCOS users are
> similar to my profile.
> I am a developer and I don't have a strong interest in the OS, I just
> expect it to work and provide me the tools needed to do my job. To me
> that's the beauty of FCOS, I get a solid, tested OS that get automated
> updates and just works, I honestly don't care to know which version of
> Fedora Linux it is based on or which features it has. I want to spin-up an
> instance make sure that my application works and forget about it.
> I also understand that there are other type of users that will care much
> more about the base OS than me:-).
>
>
>>
>> >> Another difference is that Fedora CoreOS has automatic updates and
>> >> if we want our users to trust these automatic updates we need them
>> >> to be rock solid. This leads to Fedora CoreOS being more
>> >> conservative on how changes are rolled out to users, taking the
>> >> example rolling out cgroups v2 in the Fedora 31 time frame would
>> >> have broken all users that are using Docker to run their containers
>> >> and this was not acceptable :-).
>> >>
>> >> If some users are getting confused and get curious about why there
>> >> are these differences and learn more about how Fedora CoreOS works,
>> >> that's a good thing IMO :-)
>>
>> Confusing and frustrating your users is a bad thing.
>>
>
>> On 5/19/21 6:54 AM, Neal Gompa wrote:
>> > No. This is a cop-out and a bad answer. The reason this happened is
>> > because Fedora CoreOS historically has not participated in the
>> > development of Fedora Linux, including the Changes process, and
>> > generally rolled back features instead of adapting with them during
>> > the development cycle.
>> >
>> > It's not like making changes and breaking upgrades is acceptable in
>> > Fedora Linux either. It's just that the Fedora CoreOS WG has not
>> > participated in the main development process and rolled back changes
>> > instead of adapting to them, which has frustrated pretty much
>> > everyone. The containers team in particular was extremely unhappy to
>> > find out cgroup v1 was still used in FCOS. I was pretty cheesed off
>> > when I discovered the sqlite rpmdb feature was roll

Re: Fedora CoreOS stable stream now rebased to Fedora 34

[Clement Verna]

On Thu, 20 May 2021 at 10:00, Vít Ondruch  wrote:

>
> Dne 20. 05. 21 v 8:54 Clement Verna napsal(a):
>
>
>
> On Wed, 19 May 2021 at 13:55, Neal Gompa  wrote:
>
>> On Wed, May 19, 2021 at 2:45 AM Clement Verna 
>> wrote:
>> >
>> >
>> >
>> > On Wed, 19 May 2021 at 06:50, Tomasz Torcz 
>> wrote:
>> >>
>> >> Dnia Tue, May 18, 2021 at 03:37:27PM -0400, Dusty Mabe napisał(a):
>> >> > Over the next two days we're rolling out the first Fedora 34 based
>> >> > Fedora CoreOS into the `stable` stream.
>> >> >
>> >> > - systemd-resolved is still enabled but not used yet [1]
>> >>
>> >>   This was Fedora 33 feature.
>> >>
>> >> > - Move to cgroup v2 by default [5].
>> >>
>> >>   This was Fedora 31 feature.
>> >>
>> >>   I was wondering: Fedora CoreOS actively undoes distribution-wide
>> >> changes (at least the two above, I remember lagging with iptables-nft
>> >> around Fedora 32).  End user may confused, seeing the list of changes
>> >> for the release X, but receiving only few of them with edition CoreOS
>> X.
>> >>
>> >>   Should such divergence be allowed?  Should Fedora CoreOS use the same
>> >> version number while not containing all the changes from main Fedora
>> Linux?
>> >
>> >
>> > I think this is the fundamental difference here, Fedora CoreOS does not
>> have a version number. It has 3 streams, stable, testing and next, these
>> streams are based on a version of Fedora Linux but that should just be a
>> detail that most end users should not have to care about.
>> > Another difference is that Fedora CoreOS has automatic updates and if
>> we want our users to trust these automatic updates we need them to be rock
>> solid. This leads to Fedora CoreOS being more conservative on how changes
>> are rolled out to users, taking the example rolling out cgroups v2 in the
>> Fedora 31 time frame would have broken all users that are using Docker to
>> run their containers and this was not acceptable :-).
>> >
>> >  If some users are getting confused and get curious about why there are
>> these differences and learn more about how Fedora CoreOS works, that's a
>> good thing IMO :-)
>>
>> No. This is a cop-out and a bad answer.
>
> The reason this happened is
>> because Fedora CoreOS historically has not participated in the
>> development of Fedora Linux, including the Changes process, and
>> generally rolled back features instead of adapting with them during
>> the development cycle.
>>
>
> I don't think it is fair to say that FCOS is not participating in the
> Change process. FCOS is following closely the Change Proposals
> [0][1][2][3]. I agree that we could do a better job at submitting Change
> Proposals and that's something we should improve on.
> One thing I have a hard time to understand tho, if what happens when a
> Change proposals breaks FCOS (like cgroups v2 for example) ? Should that
> just be rejected ?
>
>
> Why not if somebody raises such point? Just briefly looking on
> fedora-devel threads and the related fesco ticket, I don't see FCOS
> mentioned anywhere in this context.
>
Yes, that's maybe something where the FCOS Working Group can be more vocal
:-)


>
> Vít
>
>
> AFAIK not all changes are adopted by every Editions or Spins. What is in
> your opinion the correct way forward ?
>
>
>
>>
>> It's not like making changes and breaking upgrades is acceptable in
>> Fedora Linux either.
>
>
> Breaking or non backward compatible changes are acceptable in Fedora Linux
> tho between major version bump. Again here the cgroups v2 is a good
> example, folks using Docker had to perform some manual steps to switch back
> to cgroups v1 to keep using their workflow working. This is fine when you
> have a major version bump but this does not happen in FCOS.
>
>
>> It's just that the Fedora CoreOS WG has not
>> participated in the main development process and rolled back changes
>> instead of adapting to them, which has frustrated pretty much
>> everyone. The containers team in particular was extremely unhappy to
>> find out cgroup v1 was still used in FCOS. I was pretty cheesed off
>> when I discovered the sqlite rpmdb feature was rolled back in FCOS.
>>
>
>> In general, I'm not pleased with how Fedora CoreOS does this.
>> Hopefully they will do better in the future.
>>
>
> [0] - https://github.com/coreos/fedora-coreos-tracker/

Re: Fedora CoreOS stable stream now rebased to Fedora 34

[Clement Verna]

On Wed, 19 May 2021 at 22:48, Joe Doss  wrote:

> On Wed, May 19, 2021 at 2:45 AM Clement Verna
> >  wrote:
> >> I think this is the fundamental difference here, Fedora CoreOS does
> >> not have a version number. It has 3 streams, stable, testing and
> >> next, these streams are based on a version of Fedora Linux but that
> >> should just be a detail that most end users should not have to care
> >> about.
>
> I disagree here. Fedora CoreOS has the Fedora name in it and it should
> have the same fundamental features and changes that ship with each
> Fedora release. To say it doesn't have a base version and that users
> shouldn't care about it is pretty dismissive.
>

Sorry if that sounded dismissive, but that's really how I feel. I recognize
that I have a bias towards thinking that most FCOS users are similar to my
profile.
I am a developer and I don't have a strong interest in the OS, I just
expect it to work and provide me the tools needed to do my job. To me
that's the beauty of FCOS, I get a solid, tested OS that get automated
updates and just works, I honestly don't care to know which version of
Fedora Linux it is based on or which features it has. I want to spin-up an
instance make sure that my application works and forget about it.
I also understand that there are other type of users that will care much
more about the base OS than me:-).


>
> >> Another difference is that Fedora CoreOS has automatic updates and
> >> if we want our users to trust these automatic updates we need them
> >> to be rock solid. This leads to Fedora CoreOS being more
> >> conservative on how changes are rolled out to users, taking the
> >> example rolling out cgroups v2 in the Fedora 31 time frame would
> >> have broken all users that are using Docker to run their containers
> >> and this was not acceptable :-).
> >>
> >> If some users are getting confused and get curious about why there
> >> are these differences and learn more about how Fedora CoreOS works,
> >> that's a good thing IMO :-)
>
> Confusing and frustrating your users is a bad thing.
>

> On 5/19/21 6:54 AM, Neal Gompa wrote:
> > No. This is a cop-out and a bad answer. The reason this happened is
> > because Fedora CoreOS historically has not participated in the
> > development of Fedora Linux, including the Changes process, and
> > generally rolled back features instead of adapting with them during
> > the development cycle.
> >
> > It's not like making changes and breaking upgrades is acceptable in
> > Fedora Linux either. It's just that the Fedora CoreOS WG has not
> > participated in the main development process and rolled back changes
> > instead of adapting to them, which has frustrated pretty much
> > everyone. The containers team in particular was extremely unhappy to
> > find out cgroup v1 was still used in FCOS. I was pretty cheesed off
> > when I discovered the sqlite rpmdb feature was rolled back in FCOS.
> >
> > In general, I'm not pleased with how Fedora CoreOS does this.
> > Hopefully they will do better in the future.
>
> I'll echo Neal's sentiment here. This is a cop-out and bad answer.
>

> It is frustrating to consume FCOS only to see features that are in the
> current release of Fedora are rolled back. Even in today's FCOS WG
> meeting I brought up adding in zswap to FCOS and it is shelved until
> Kubernetes adds for support swap enabled systems.
>
> The RHCOS and Openshift teams should be back porting these breaking
> changes, so FCOS can look to the future with Fedora. FCOS should not be
> shackled by limits imposed by RHCOS/Openshift/Kubernetes.
>
> Joe
>
>
>
> --
> Joe Doss
> j...@solidadmin.com
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora CoreOS stable stream now rebased to Fedora 34

[Clement Verna]

On Wed, 19 May 2021 at 13:55, Neal Gompa  wrote:

> On Wed, May 19, 2021 at 2:45 AM Clement Verna 
> wrote:
> >
> >
> >
> > On Wed, 19 May 2021 at 06:50, Tomasz Torcz  wrote:
> >>
> >> Dnia Tue, May 18, 2021 at 03:37:27PM -0400, Dusty Mabe napisał(a):
> >> > Over the next two days we're rolling out the first Fedora 34 based
> >> > Fedora CoreOS into the `stable` stream.
> >> >
> >> > - systemd-resolved is still enabled but not used yet [1]
> >>
> >>   This was Fedora 33 feature.
> >>
> >> > - Move to cgroup v2 by default [5].
> >>
> >>   This was Fedora 31 feature.
> >>
> >>   I was wondering: Fedora CoreOS actively undoes distribution-wide
> >> changes (at least the two above, I remember lagging with iptables-nft
> >> around Fedora 32).  End user may confused, seeing the list of changes
> >> for the release X, but receiving only few of them with edition CoreOS X.
> >>
> >>   Should such divergence be allowed?  Should Fedora CoreOS use the same
> >> version number while not containing all the changes from main Fedora
> Linux?
> >
> >
> > I think this is the fundamental difference here, Fedora CoreOS does not
> have a version number. It has 3 streams, stable, testing and next, these
> streams are based on a version of Fedora Linux but that should just be a
> detail that most end users should not have to care about.
> > Another difference is that Fedora CoreOS has automatic updates and if we
> want our users to trust these automatic updates we need them to be rock
> solid. This leads to Fedora CoreOS being more conservative on how changes
> are rolled out to users, taking the example rolling out cgroups v2 in the
> Fedora 31 time frame would have broken all users that are using Docker to
> run their containers and this was not acceptable :-).
> >
> >  If some users are getting confused and get curious about why there are
> these differences and learn more about how Fedora CoreOS works, that's a
> good thing IMO :-)
>
> No. This is a cop-out and a bad answer.

The reason this happened is
> because Fedora CoreOS historically has not participated in the
> development of Fedora Linux, including the Changes process, and
> generally rolled back features instead of adapting with them during
> the development cycle.
>

I don't think it is fair to say that FCOS is not participating in the
Change process. FCOS is following closely the Change Proposals
[0][1][2][3]. I agree that we could do a better job at submitting Change
Proposals and that's something we should improve on.
One thing I have a hard time to understand tho, if what happens when a
Change proposals breaks FCOS (like cgroups v2 for example) ? Should that
just be rejected ? AFAIK not all changes are adopted by every Editions or
Spins. What is in your opinion the correct way forward ?



>
> It's not like making changes and breaking upgrades is acceptable in
> Fedora Linux either.


Breaking or non backward compatible changes are acceptable in Fedora Linux
tho between major version bump. Again here the cgroups v2 is a good
example, folks using Docker had to perform some manual steps to switch back
to cgroups v1 to keep using their workflow working. This is fine when you
have a major version bump but this does not happen in FCOS.


> It's just that the Fedora CoreOS WG has not
> participated in the main development process and rolled back changes
> instead of adapting to them, which has frustrated pretty much
> everyone. The containers team in particular was extremely unhappy to
> find out cgroup v1 was still used in FCOS. I was pretty cheesed off
> when I discovered the sqlite rpmdb feature was rolled back in FCOS.
>

> In general, I'm not pleased with how Fedora CoreOS does this.
> Hopefully they will do better in the future.
>

[0] - https://github.com/coreos/fedora-coreos-tracker/issues/372
[1] - https://github.com/coreos/fedora-coreos-tracker/issues/609
[2] - https://github.com/coreos/fedora-coreos-tracker/issues/704
[3] - https://github.com/coreos/fedora-coreos-tracker/issues/824


>
> --
> 真実はいつも一つ！/ 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Clement Verna]

On Wed, 19 May 2021 at 12:28, Peter Oliver  wrote:

> > IMHO even then we would need the default "fedora" image to be the
> > minimal one, as that's what a casual user will compare, unless they
> > happen to know "fedora-minimal" exists.
>
> I notice that fedora-minimal is absent from Docker Hub, and outdated on
> Quay.io, by the way.
>

Yes pushing to Docker Hub official images is a pain, so we never got to
push fedora-minimal there. It might be worth looking at it again but it
needs someone to spend quite a bit of time setting up everything.

For Quay.io I think it is related to https://pagure.io/releng/issue/9880

Thanks for pointing it out tho :-)


> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora CoreOS stable stream now rebased to Fedora 34

[Clement Verna]

On Wed, 19 May 2021 at 09:24, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Tue, May 18, 2021 at 03:37:27PM -0400, Dusty Mabe wrote:
> > - DNF Count Me support for Fedora CoreOS [6].
>
> Are the count stats visible somewhere?
>

For FCOS this change is not yet enabled, it is coming in a few months (more
info [0]).
But the Count Me support was enabled on Sliverblue and IoT so we should be
able to get better stats for these now :).

The raw data are available here[1] and

[0] -
https://fedoramagazine.org/getting-better-at-counting-rpm-ostree-based-systems/
[1] - https://data-analysis.fedoraproject.org/csv-reports/countme/


> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Clement Verna]

On Mon, 17 May 2021 at 16:40, Frank Ch. Eigler  wrote:

> Daniel P. Berrangé  writes:
>
> > The container runtime in the host OS will have configured most mount
> > points before the container starts. It would be relatively uncommon
> > for processes inside the container image to need to mount additional
> > volumes later.
>
> That's fair, but util-linux contains many other tools that may be useful
> at runtine within a containerized tool (logger, flock, lsmem, rename,
> taskset, whereis, others?).  Some those be moved somewhere else?
>
> /usr/bin/* files from f33's util-linux:
>
> cal chmem choom chrt col colcrt colrm column dmesg eject fallocate
> fincore findmnt flock getopt hardlink hexdump i386 ionice ipcmk ipcrm
> ipcs irqtop isosize kill last lastb linux32 linux64 logger login look
> lsblk lscpu lsipc lsirq lslocks lslogins lsmem lsns mcookie mesg more
> mount mountpoint namei nsenter prlimit raw rename renice rev script
> scriptlive scriptreplay setarch setpriv setsid setterm su taskset ul
> umount uname26 unshare utmpdump uuidgen uuidparse wall wdctl whereis
> write x86_64
>

It is all about tradeoff between what **may** be useful and the size of the
base image. In the container base image space, size is very important (see
how successful is Alpine) and we have to make tradeoff in terms of what
tools are included by default in the image.

To get an idea on how Fedora does compared to some other distros

REPOSITORY TAG  IMAGE ID
 CREATED   SIZE
registry.fedoraproject.org/fedora  rawhide  5e91f1acac7d  47
hours ago  187 MB
registry.fedoraproject.org/fedora-minimal  latest   438d4fec7485  5
days ago119 MB
docker.io/library/debian   latest   4a7a1f401734  7
days ago119 MB
registry.opensuse.org/opensuse/leaplatest   1a798c6c690f  5
days ago108 MB
docker.io/library/ubuntu   latest   7e0aa2d69a15  3
weeks ago   75.1 MB
docker.io/library/alpine   latest   6dbb9cc54074  4
weeks ago   5.88 MB



> - FChE
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Clement Verna]

On Mon, 17 May 2021 at 12:06, Karel Zak  wrote:

> On Thu, Apr 01, 2021 at 02:22:31PM -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/SmallerContainerBase
> >
> > == Summary ==
> > This change proposes to remove 3 packages (sssd-client, util-linux,
> > shadow-utils) from the Container Base Image (including the minimal
> > image). The Fedora Base Image is still quite large compared to other
> > distributions and the tools offered by these packages are not
> > essential in base image.
>
> I do not understand how do you want to use any system without for example
> mount(8), umount(8), ... ;-)
>
> > The installed size of each package is :
> >
> > {| class="wikitable"
> > |-
> > ! Package !! Installed Size
> > |-
> > | util-linux || 13018140
>
> My plan is to create more sub-packages from util-linux and create
> util-linux-core where will be essential tools like mount, losetup,
> blkid, lsblk, findmnt, etc.
>
> The change will be backwardly compatible. The classic util-linux.rpm
> will depend on this small util-linux-core package , so for all
> use-cases where is hardcoded util-linux we will not see a change. For
> use-cases where minimal installation is important will be possible to
> use alone util-linux-core.
>
> I also plan to move some less often used tools, like
>
> mcookie
> mesg
> raw
> isosize
> namei
> hardlink
> fincore
> wall
> readprofile
> ctrlaltdel
> fsck.cramfs
> fsck.minix
> mkfs.cramfs
> mkfs.minix
> fdformat
>
> to util-linux-optional package.
>
> Does it make sense?
>

That sounds good to me, although I am still not sure util-linux-core should
be available in the base image by default. If a user needs these tools
inside a container, it is fairly easy to install the package.


>
>   Karel
>
> --
>  Karel Zak  
>  http://karelzak.blogspot.com
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora CoreOS stable stream now rebased to Fedora 34

[Clement Verna]

On Wed, 19 May 2021 at 06:50, Tomasz Torcz  wrote:

> Dnia Tue, May 18, 2021 at 03:37:27PM -0400, Dusty Mabe napisał(a):
> > Over the next two days we're rolling out the first Fedora 34 based
> > Fedora CoreOS into the `stable` stream.
> >
> > - systemd-resolved is still enabled but not used yet [1]
>
>   This was Fedora 33 feature.
>
> > - Move to cgroup v2 by default [5].
>
>   This was Fedora 31 feature.
>
>   I was wondering: Fedora CoreOS actively undoes distribution-wide
> changes (at least the two above, I remember lagging with iptables-nft
> around Fedora 32).  End user may confused, seeing the list of changes
> for the release X, but receiving only few of them with edition CoreOS X.
>
>   Should such divergence be allowed?  Should Fedora CoreOS use the same
> version number while not containing all the changes from main Fedora Linux?
>

I think this is the fundamental difference here, Fedora CoreOS does not
have a version number. It has 3 streams, stable, testing and next, these
streams are based on a version of Fedora Linux but that should just be a
detail that most end users should not have to care about.
Another difference is that Fedora CoreOS has automatic updates and if we
want our users to trust these automatic updates we need them to be rock
solid. This leads to Fedora CoreOS being more conservative on how changes
are rolled out to users, taking the example rolling out cgroups v2 in the
Fedora 31 time frame would have broken all users that are using Docker to
run their containers and this was not acceptable :-).

 If some users are getting confused and get curious about why there are
these differences and learn more about how Fedora CoreOS works, that's a
good thing IMO :-)


> --
> Tomasz Torcz  “If you try to upissue this patchset I shall be
> seeking
> to...@pipebreaker.pl   an IP-routable hand grenade.”  — Andrew Morton
> (LKML)
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Github Action for discovering active Fedora Releases

[Clement Verna]

On Thu, 15 Apr 2021 at 14:11, Stephen Gallagher  wrote:

> On Thu, Apr 15, 2021 at 6:58 AM Clement Verna 
> wrote:
> >
> >
> >
> > On Wed, 14 Apr 2021 at 20:29, Stephen Gallagher 
> wrote:
> >>
> >> On Wed, Apr 14, 2021 at 1:38 PM Tomasz Torcz 
> wrote:
> >> >
> >> > Dnia Wed, Apr 14, 2021 at 01:12:47PM -0400, Stephen Gallagher
> napisał(a):
> >> > > Since I figured it might be useful to others, I have made it
> available
> >> > > publicly. See the Marketplace link[1] for usage examples.
> >> > >
> >> > > [1] https://github.com/marketplace/actions/get-fedora-releases
> >> >
> >> > #v+
> >> >   name: Get Fedora Releases
> >> >   runs-on: ubuntu-latest
> >> > #v-
> >> >
> >>
> >> Yeah, the irony isn't lost on me, but it's the only Linux container
> >> host Github currently offers.
> >
> >
> > You can actually run containers directly [0] (might still be running on
> ubuntu but hey ). I have also been playing with self-hosted runner on
> Fedora CoreOS[1] a blog post will follow soon :)
> >
>
> Yes, but this particular action is basically just a quick
> python-requests GET and then some almost-trivial data manipulation.
> There's no reason to add the overhead of pulling a container image
> when the host has all the necessary pieces.
>
> If you're curious, `uses:
> sgallagher/get-fedora-releases-action@v1.0.0` would get you the first
> version of it that I wrote. That version did exactly what you suggest
> and pulled down a container (specifically, `python:3`) to run in. It
> took a little over 30s to process, whereas the version that just runs
> on the Ubuntu host takes only 6s.
>

Right, that makes sense :-)


> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Github Action for discovering active Fedora Releases

[Clement Verna]

On Wed, 14 Apr 2021 at 20:29, Stephen Gallagher  wrote:

> On Wed, Apr 14, 2021 at 1:38 PM Tomasz Torcz  wrote:
> >
> > Dnia Wed, Apr 14, 2021 at 01:12:47PM -0400, Stephen Gallagher napisał(a):
> > > Since I figured it might be useful to others, I have made it available
> > > publicly. See the Marketplace link[1] for usage examples.
> > >
> > > [1] https://github.com/marketplace/actions/get-fedora-releases
> >
> > #v+
> >   name: Get Fedora Releases
> >   runs-on: ubuntu-latest
> > #v-
> >
>
> Yeah, the irony isn't lost on me, but it's the only Linux container
> host Github currently offers.
>

You can actually run containers directly [0] (might still be running on
ubuntu but hey ). I have also been playing with self-hosted runner on
Fedora CoreOS[1] a blog post will follow soon :)


[0] -
https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainerimage
[1] - https://github.com/cverna/fcos-actions-runner


> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Clement Verna]

.. snip ...

>
> Based on the feedback received, I will update the change proposal to
> exclude shadow-utils from the packages proposed to be removed. That way we
> should be able to move on and at least remove sssd-client and util-linux ;-)
>


I have updated https://fedoraproject.org/wiki/Changes/SmallerContainerBase
to remove shadow-utils.


>
>
>> ___
>> 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
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Clement Verna]

On Tue, 6 Apr 2021 at 12:58, Peter Robinson  wrote:

> On Tue, Apr 6, 2021 at 11:36 AM Neal Gompa  wrote:
> >
> > On Tue, Apr 6, 2021 at 3:23 AM Clement Verna 
> wrote:
> > >
> > >
> > >
> > > On Mon, 5 Apr 2021 at 20:30, Daniel Walsh  wrote:
> > >>
> > >> On 4/3/21 02:34, Tomasz Torcz wrote:
> > >> > Dnia Fri, Apr 02, 2021 at 05:30:30PM -0400, Neal Gompa napisał(a):
> > >> >> On Fri, Apr 2, 2021 at 5:18 PM Lars Seipel  wrote:
> > >> >>> On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:
> > >> >>>> Unless OpenShift and RKE recently changed so that containers can
> run
> > >> >>>> as root by default (as of yesterday, they didn't), this is
> solidly a
> > >> >>>> bad idea, since it makes it much more unintuitive to set up
> secure
> > >> >>>> containers conforming with the guidelines for these Kubernetes
> > >> >>>> platforms.
> > >> >>> In my experience, containers trying to run stuff from
> shadow-utils in
> > >> >>> their entrypoint/startup scripts tend to be a reason for
> containers to
> > >> >>> *not* run on OpenShift/OKD without additional adjustments.
> > >> >>>
> > >> >>> A related (and more common) issue are images that expect to run
> with a
> > >> >>> particular named user (or UID) determined during the build process
> > >> >>> (again, most likely created using shadow-utils).
> > >> >>>
> > >> >>> I'm not familiar with Rancher but at least for OpenShift, I don't
> think
> > >> >>> the availability of shadow-utils is very useful. At run time, you
> can't
> > >> >>> use the shadow-utils at all and whatever you do with it during
> build
> > >> >>> time is unlikely to be helpful (and actively harmful more often
> than
> > >> >>> not) at run time when OpenShift assigns you an arbitrary UID.
> > >> >> It's basically required for building containers that will work at
> > >> >> runtime where OpenShift assigns an arbitrary UID.
> > >> >>
> > >> >> For example, in my containers, I *build* and create a "runtime
> user"
> > >> >> with the UID 1000, and then set things up to use that context at
> the
> > >> >> end. OpenShift uses that for its dynamic UID assignment.
> > >> >But you do not need shadow-utils for that. Even OpenShift
> > >> > documentation shows simple echo is enough:
> > >> >
> > >> > if ! whoami &> /dev/null; then
> > >> >if [ -w /etc/passwd ]; then
> > >> >echo "${USER_NAME:-default}:x:$(id
> -u):0:${USER_NAME:-default} user:${HOME}:/sbin/nologin" >> /etc/passwd
> > >> >fi
> > >> > fi
> > >> >
> https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html
> > >> > (yeah, I know it's an old and obsolete version of docs)
> > >> >
> > >> What about all of the users of Docker and Podman who do?
> > >>
> > >>
> > >>
> > >> ```
> > >>
> > >> from fedora
> > >>
> > >> run useradd XYZ
> > >>
> > >> user XYZ
> > >>
> > >> ...
> > >>
> > >> ```
> > >>
> > >> Do you just break them out of the box?
> > >
> > >
> > > Yes and that's the point of the Change Proposal (ie make this more
> widely known and allow people to change their Dockerfile). This change
> would only be applied starting from the Fedora 35 base image, I don't think
> it is unreasonable to have breaking change between major version of the
> container base image.
> > >
> >
> > I think it would be unreasonable to break such a commonly established
> > pattern, though. That's enough of a reason for people to stop using
> > the Fedora base container.
>
> We do have the Base container and a Base Minimal, so maybe do it in
> the later and not the former?
>

Yes that's a good suggestion :-), I can probably make another Change for
that tho.

Based on the feedback received, I will update the change proposal to
exclude shadow-utils from the packages proposed to be removed. That way we
should be able to move on and at least remove sssd-client and util-linux ;-)


> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Congrats to Nick Bebout

[Clement Verna]

On Mon, 5 Apr 2021 at 17:48, Kevin Fenzi  wrote:

> Greetings.
>
> I'm happy to announce that Nick Bebout(fas: nb, irc: nb)
> has been added to our sysadmin-main group.
>
> This is the core group of trusted folks that high level access to most
> everything in fedora infrastructure.
>
> Nick has been doing infrastructure tasks for various groups for many
> years in sysadmin-noc, sysadmin-web, and too many other groups to list.
>
> He's proved his dedication, trustworthiness, and ability.
>
> Congrats!
>

Congrats Nick :)


> Use your powers for good! :)
>
> kevin
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Clement Verna]

On Mon, 5 Apr 2021 at 20:30, Daniel Walsh  wrote:

> On 4/3/21 02:34, Tomasz Torcz wrote:
> > Dnia Fri, Apr 02, 2021 at 05:30:30PM -0400, Neal Gompa napisał(a):
> >> On Fri, Apr 2, 2021 at 5:18 PM Lars Seipel  wrote:
> >>> On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:
>  Unless OpenShift and RKE recently changed so that containers can run
>  as root by default (as of yesterday, they didn't), this is solidly a
>  bad idea, since it makes it much more unintuitive to set up secure
>  containers conforming with the guidelines for these Kubernetes
>  platforms.
> >>> In my experience, containers trying to run stuff from shadow-utils in
> >>> their entrypoint/startup scripts tend to be a reason for containers to
> >>> *not* run on OpenShift/OKD without additional adjustments.
> >>>
> >>> A related (and more common) issue are images that expect to run with a
> >>> particular named user (or UID) determined during the build process
> >>> (again, most likely created using shadow-utils).
> >>>
> >>> I'm not familiar with Rancher but at least for OpenShift, I don't think
> >>> the availability of shadow-utils is very useful. At run time, you can't
> >>> use the shadow-utils at all and whatever you do with it during build
> >>> time is unlikely to be helpful (and actively harmful more often than
> >>> not) at run time when OpenShift assigns you an arbitrary UID.
> >> It's basically required for building containers that will work at
> >> runtime where OpenShift assigns an arbitrary UID.
> >>
> >> For example, in my containers, I *build* and create a "runtime user"
> >> with the UID 1000, and then set things up to use that context at the
> >> end. OpenShift uses that for its dynamic UID assignment.
> >But you do not need shadow-utils for that. Even OpenShift
> > documentation shows simple echo is enough:
> >
> > if ! whoami &> /dev/null; then
> >if [ -w /etc/passwd ]; then
> >echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default}
> user:${HOME}:/sbin/nologin" >> /etc/passwd
> >fi
> > fi
> >
> https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html
> > (yeah, I know it's an old and obsolete version of docs)
> >
> What about all of the users of Docker and Podman who do?
>

>
> ```
>
> from fedora
>
> run useradd XYZ
>
> user XYZ
>
> ...
>
> ```
>
> Do you just break them out of the box?
>

Yes and that's the point of the Change Proposal (ie make this more widely
known and allow people to change their Dockerfile). This change would only
be applied starting from the Fedora 35 base image, I don't think it is
unreasonable to have breaking change between major version of the container
base image.


> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Clement Verna]

... snip ...

>
> The only one of these I have a major problem with removing is
> shadow-utils. Without those tools, it's impossible to create and
> modify users, and that's an extremely common pattern for containers. I
> also don't think freeing 4MB on the unpacked rootfs is much of a gain
> for the pain you're about to cause by dropping shadow-utils from the
> base image. The overhead of having to install that makes it
> considerably less attractive to use.
>

Yes this one is a tough one. For me it is all about the balance between the
base image being useful and small. Binaries included in shadow-utils are
indeed useful and often used but what makes me consider dropping the
package from the base image is that these binary are almost always used at
build time and not run time.
IMO if you already have commands to create users in your Dockerfile there
is not much overhead in making sure you include shadow-utils to the list of
package you install in the layered image.


>
> Unless OpenShift and RKE recently changed so that containers can run
> as root by default (as of yesterday, they didn't), this is solidly a
> bad idea, since it makes it much more unintuitive to set up secure
> containers conforming with the guidelines for these Kubernetes
> platforms.
>

Yes, that's a fair point, and that makes me reconsider removing
shadow-utils :-). Waiting to see if I get more feedback on the change
before tho.

Thanks


>
>
>
>
> --
> 真実はいつも一つ！/ 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Summary/Minutes from today's FESCo Meeting (2021-02-24)

[Clement Verna]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-24/fesco.2021-02-24-15.00.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-24/fesco.2021-02-24-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-24/fesco.2021-02-24-15.00.log.html

Meeting summary
---
* init process  (cverna, 15:00:50)

* 2584 - Fedora 34 incomplete changes: 100% complete dealine  (cverna,
  15:04:04)
  * Patches in Forge Macros is still in ASSIGNED  (bcotton, 15:06:42)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1866896
(bcotton, 15:06:48)
  * X.org Utility Deaggregation is still in ASSIGNED  (bcotton,
15:07:56)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1867220
(bcotton, 15:07:58)
  * LINK:

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/109#comment-63117
looks like no redhat-rpm-config person approved at the PR.
(decathorpe, 15:08:57)
  * LINK:

https://bugzilla.redhat.com/buglist.cgi?component=Package%20Review=ajax%40redhat.com=1=substring_id=11712217_format=advanced
and look at the last bunch?  (nirik, 15:11:04)
  * LINK:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/118
(mhroncok, 15:41:01)
  * ACTION: bcotton to talk to eclipseo and go sig about splitting the
forge macros into a separate package  (mhroncok, 15:48:51)

* #2578: Preset Request: google-guest-agent.service
  google-startup-scripts.service google-shutdown-scripts.service
  (cverna, 15:58:45)
  * AGREED: systemd preset request for google-guest-agent.service
google-startup-scripts.service google-shutdown-scripts.service was
approved  (+7, 0, 0)  (cverna, 16:06:28)

* Next week's chair  (cverna, 16:06:47)
  * ACTION: zbyszek to chair next week's meeting  (cverna, 16:07:59)

* Open Floor  (cverna, 16:08:15)
  * The voting season is open on
https://qa.fedoraproject.org/blockerbugs/milestone/34/beta/buglist.
(zbyszek, 16:15:57)

Meeting ended at 16:18:49 UTC.




Action Items

* bcotton to talk to eclipseo and go sig about splitting the forge
  macros into a separate package
* zbyszek to chair next week's meeting




Action Items, by person
---
* bcotton
  * bcotton to talk to eclipseo and go sig about splitting the forge
macros into a separate package
* zbyszek
  * zbyszek to chair next week's meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* cverna (59)
* zbyszek (47)
* bcotton (38)
* mhroncok (30)
* nirik (20)
* zodbot (18)
* decathorpe (18)
* dcantrell (12)
* sgallagh (10)
* King_InuYasha (9)
* bcotton_ (2)
* ignatenkobrain (0)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Wednesday's FESCo Meeting (2021-02-24)

[Clement Verna]

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
   http://fedoraproject.org/wiki/UTCHowto

or run:
   date -d '2021-02-24 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

= Followups =

Fedora 34 incomplete changes
https://pagure.io/fesco/issue/2576

Preset Request: google-guest-agent.service google-startup-scripts.service
google-shutdown-scripts.service
https://pagure.io/fesco/issue/2578

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Clement Verna]

On Thu, 11 Feb 2021 at 18:04, Adam Williamson 
wrote:

> On Thu, 2021-02-11 at 09:55 +0100, Clement Verna wrote:
> > >
> > > So, what do folks think? Does this seem like a good idea? Should I go
> > > ahead with trying to get it deployed and onboard things to it? Any
> > > comments, ideas, potential problems? Thanks!
> > >
> >
> >
> > I am pretty sure you did :-) but have you looked at adding the missing
> > information to Bodhi ? Now that we have rawhide in Bodhi we should be
> able
> > to expose most the information needed.
>
> I didn't look at that in any technical detail but conceptually it seems
> kinda wrong to me. The problem with using any existing system is that
> all existing systems are *for* something. Bodhi is for dealing with
> updates. There's no reason why Bodhi would track, for instance, whether
> 34 is under a string freeze, right? Because Bodhi doesn't have anything
> to do with translations. There are a zillion other 'states' that it
> would be useful to have info on which aren't relevant to any *one*
> existing system, and that's why to me it makes sense to have a separate
> thing for that.
>

I was wondering about the 4 Needs bullet points in your original email
which could be in Bodhi but yes if we want to add more and more info a
seperate app makes sense :-)

-- 
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora CoreOS Virtual Meetup this week

[Clement Verna]

On Sun, 7 Feb 2021 at 13:46, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Sat, Feb 06, 2021 at 10:41:16AM +0100, Clement Verna wrote:
> > Recordings are available on Fedora's youtube channel
> >
> > Growing Fedora CoreOS Community :
> > https://www.youtube.com/watch?v=HSuBWeosAvQ
> > Fedora CoreOS as an Official Edition :
> > https://www.youtube.com/watch?v=t5VAw8NRXNc
> >
> > You can also find the discussions notes here :
> > https://github.com/coreos/fedora-coreos-tracker/pull/732/files -
> > Pull-request but that should be merged soon :)
>
> Hi Clement,
>
> thanks for making those available.
>

Thanks for taking the time to watch it and provide feedback :-)


>
> I listened avidly to the discussion, and here's my take on the subject
> of "FCOS as Edition":
>
> in the discussion, you asked whether there should be "FCOS 33", "FCOS
> 34", etc, and the answer was an emphatic "no". My answer is "yes".
>
What do I mean by that?  I think it's fine to have a *goal* of just a
> smooth FCOS stream, i.e. to make the underlying Fedora version
> unimportant to users. But as a practical matter, it'll not be
> achievable and FCOS should instead accept that as long as FCOS is
> based on Fedora, the choices that Fedora "proper" makes and the
> cadence of releases will be visible in FCOS. As mentioned in the
> discussion "the package set is fairly vanilla bodhi stable with a bit
> of delay for the two week promotion timing". Even if FCOS is just a
> subset of those packages, the semiannual jump in package versions and
> configuration choices must be visible to some extent.
>

I think a lot of the work and thoughts that went into designing the stream
release process was to effectively hide
or at least make the semi-annual jump in package versions a non event. The
update barrier approach [0]
that is currently in use is a good example. Currently a user might notice a
Fedora version bump only because of an extra
update and reboot.
IMO having to worry or know which Fedora version is used as a base for FCOS
is defeating the point of FCOS and
automatic updates.



> There seems to be a broad consensus that FCOS should participate more in
> the Fedora Change process: both to monitor announced Changes and to
> announce changes in FCOS using a similar process.
>

I believe that we are already doing a good job at monitoring the announced
changes [1] but
yeah we definitely can do better at announcing changes in FCOS.


>
> But I think FCOS should go a step further, and also *declare* that it
> follows the Fedora schedule. I do *not* mean by that FCOS stable
> stream should by switched on the same day that other Fedora editions
> make a release. The two week delay is quite reasonable. (In fact,
> seasoned users of Fedora "proper" know not to update immediately on
> the release day, and instead wait two or three weeks for wrinkles to
> be ironed out. Since FCOS does updates automatically, I think it's
> totally reasonable to bake such a delay into the plan.) But we should
> be able to say, in the release announcements, that "Workstation,
> Server, etc. release today, and FCOS switch of stable stream will
> follow in two weeks, if no last minute bugs are discovered. Users who
> want to preview the next version, should use the devel stream."
>

So I personally don't agree with that, IMO there is nothing wrong with the
stable stream not
being on the latest version of Fedora as long as it is using a base version
that is supported.
I associate stable with words like slow, solid, robust,etc ... If we
provide support for ~1 year why
not make use of that ? FCOS values stability over new features.
That said I think the goal is to make the switch as soon as possible and
things like having a rawhide
stream [2] will certainly help.
In the case that we want to tightly couple FCOS stable stream to the latest
Fedora version then we should be ready to
delay the GA of other Editions until FCOS as a working stable stream.

About release announcement, I believe that FCOS should follow it's own life
and announce changes
and major features as they happen. This is something we have to improve on
(we already do some announcement [3])
and ideas like having a monthly newsletter are possibilities.
I don't think that making FCOS an edition means that we have to mention it
when
other editions are released.



>
> Matthew said that users should be able to see all editions on
> getfedora.org, and it would be great to also have FCOS there, but it
> means that FCOS stable must be available on a predictable schedule.
>

It is already there in the "Emerging Fedora Editions" sections, the website
is also automatically updated
when new streams are released every 2 weeks.


>

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Clement Verna]

On Wed, 13 Jan 2021 at 18:53, Adam Williamson 
wrote:

> Hi folks!
>
> Before the RH holiday shutdown, I started a new project designed to
> address a long-standing pain point in Fedora: we don't really have a
> good source of truth for release cycle information. I'm thinking of
> situations where something:
>
> * Needs to know what the "current stable" Fedora release(s) are
> * Needs to know if Fedora X is Branched
> * Needs to know whether Fedora X Beta happened yet
> * Needs to know whether Fedora X is frozen
>
> ...etc etc etc. Some of this information is available...sort of...from
> various different systems, with various awkward caveats that I won't
> dive into unless someone asks. But there isn't really a single source
> of truth for it, and some of it just isn't really available in any
> easily machine-consumable way.
>
> So I wrote releasestream:
> https://pagure.io/fedora-qa/releasestream
>
> releasestream is intended to be a system that will let us do this. It
> is a very very simple webapp with three capabilities:
>
> * It can read a simple record ("stream") of "release events" for a
> "release" and produce several static JSON representations of the
> information
> * It can write an entry to one of these streams in response to a
> properly-formatted POST request
> * It can publish a message when a new entry is received
>
> that is all it does. The "releases" and "events" are entirely
> arbitrary; a "release" can be any string, and so can the "state" for a
> given "event". An "event" is defined as a state being either reached or
> left; any number of events for the same state can be present for a
> release.
>
> The JSON outputs are basically "states by release" and "releases by
> state", as you might want either depending on what you're doing. You
> can conveniently look up "what releases are currently in state X?" or
> "what states is release X currently in?".
>
> This all works right now; the main thing that isn't implemented yet is
> any form of authentication. Right now if you can talk to the server you
> can submit events. I wanted to check if there is interest in moving
> forward with this, and discuss various options, before working on that.
> There is a ticket where I sketched out various possible approaches:
> https://pagure.io/fedora-qa/releasestream/issue/2
>
> My idea for using this is basically that we deploy an 'official'
> releasestream instance in infra, and then find things that do the
> actual work of moving Fedora releases into and out of given "states"
> and tack on a bit at the end to tell releasestream about it. So when
> e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a
> "submit 'enter freeze' event to releasestream" to that process somehow
> - ideally something that has to be run as part of the process anyway
> would send the POST, but in a pinch a human could do it too. When
> Fedora 34 is being 'released', we tweak that process to include sending
> a releasestream event POST. And so on.
>
> The thing I like about this design is that there's a low barrier to
> entry, and can easily be adopted piecemeal but still be immediately
> useful for some things - as long as the event your code needs to watch
> for has been "onboarded", you're good. It also allows for the
> implementation details of a state change to change radically - it can
> go from being done by a human to being done by system X to being done
> by system Y, and all that needs to happen is to ensure the same dead
> simple POST request is sent to the same server.
>
> So, what do folks think? Does this seem like a good idea? Should I go
> ahead with trying to get it deployed and onboard things to it? Any
> comments, ideas, potential problems? Thanks!
>


I am pretty sure you did :-) but have you looked at adding the missing
information to Bodhi ? Now that we have rawhide in Bodhi we should be able
to expose most the information needed.



> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
> ___
> rel-eng mailing list -- rel-...@lists.fedoraproject.org
> To unsubscribe send an email to rel-eng-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/rel-...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora CoreOS Virtual Meetup this week

[Clement Verna]

On Thu, 4 Feb 2021 at 15:26, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Thu, Feb 04, 2021 at 02:34:58PM +0100, Clement Verna wrote:
> > On Thu, 4 Feb 2021 at 14:31, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl>
> > wrote:
> >
> > > On Mon, Feb 01, 2021 at 05:27:54PM +0100, Clement Verna wrote:
> > > > Hi all,
> > > >
> > > > We are going to hold a virtual meetup this Thursday (2021-02-04) .
> The
> > > > meetup will cover 2 topics
> > > >
> > > > * Growing Fedora CoreOS Community - from 15:00  to 15:50 UTC [0]
> > > > and
> > > > * Fedora CoreOS as an Official Edition - from 16:00 to 16:50 UTC [1]
> > > >
> > > > The goal is to have an open discussion and come up with a way
> forward for
> > > > both of these topics. If you are interested to listen or contribute
> > > please
> > > > join us here[2]
> > > >
> > > > [0] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9903
> > > > [1] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9904
> > > > [2] - meet.google.com/pqi-epwy-udg
> > >
> > > I'd like to join, especially the second part, but I have a
> > > conflict. Can you make a recording?
> > >
> >
> > Sure :-)
>
> Appreciated.
>

Recordings are available on Fedora's youtube channel

Growing Fedora CoreOS Community :
https://www.youtube.com/watch?v=HSuBWeosAvQ
Fedora CoreOS as an Official Edition :
https://www.youtube.com/watch?v=t5VAw8NRXNc

You can also find the discussions notes here :
https://github.com/coreos/fedora-coreos-tracker/pull/732/files -
Pull-request but that should be merged soon :)


>
> 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
>
___
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 CoreOS Virtual Meetup this week

[Clement Verna]

On Thu, 4 Feb 2021 at 14:31, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Mon, Feb 01, 2021 at 05:27:54PM +0100, Clement Verna wrote:
> > Hi all,
> >
> > We are going to hold a virtual meetup this Thursday (2021-02-04) . The
> > meetup will cover 2 topics
> >
> > * Growing Fedora CoreOS Community - from 15:00  to 15:50 UTC [0]
> > and
> > * Fedora CoreOS as an Official Edition - from 16:00 to 16:50 UTC [1]
> >
> > The goal is to have an open discussion and come up with a way forward for
> > both of these topics. If you are interested to listen or contribute
> please
> > join us here[2]
> >
> > [0] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9903
> > [1] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9904
> > [2] - meet.google.com/pqi-epwy-udg
>
> I'd like to join, especially the second part, but I have a
> conflict. Can you make a recording?
>

Sure :-)


>
> 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
>
___
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 CoreOS Virtual Meetup this week

[Clement Verna]

Hi all,

We are going to hold a virtual meetup this Thursday (2021-02-04) . The
meetup will cover 2 topics

* Growing Fedora CoreOS Community - from 15:00  to 15:50 UTC [0]
and
* Fedora CoreOS as an Official Edition - from 16:00 to 16:50 UTC [1]

The goal is to have an open discussion and come up with a way forward for
both of these topics. If you are interested to listen or contribute please
join us here[2]

[0] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9903
[1] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9904
[2] - meet.google.com/pqi-epwy-udg
___
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: Backwards-incompatible RPM format change in Fedora 34?

[Clement Verna]

On Fri, 22 Jan 2021 at 00:06, Kevin Fenzi  wrote:

> On Thu, Jan 21, 2021 at 08:04:42PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Thu, Jan 21, 2021 at 12:43:35PM +0100, Fabio Valentini wrote:
> > > On Thu, Jan 21, 2021 at 12:39 PM Panu Matilainen 
> wrote:
> > > >
> > > > On 1/21/21 1:27 PM, Fabio Valentini wrote:
> > > > > On Thu, Jan 21, 2021 at 12:22 PM Panu Matilainen <
> pmati...@redhat.com> wrote:
> > > > >>
> > > > >> On 1/21/21 9:56 AM, Florian Weimer wrote:
> > > > >>> With rpm-4.15.1-3.fc32.1.x86_64, I get this error:
> > > > >>>
> > > > >>> $ rpm -qip
> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm
> > > > >>> error: /var/tmp/rpm-tmp.6iU66n: signature hdr data: BAD, no. of
> bytes(88084) out of range
> > > > >>> error:
> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm:
> not an rpm package (or package manifest)
> > > > >>>
> > > > >>> Is this expected?
> > > > >>>
> > > > >>
> > > > >> Certainly not.
> > > > >>
> > > > >>> It seems that rpm-4.16.1.2-1.fc33.x86_64 can parse the RPM just
> fine.
> > > > >>> But rpm-4.14.3-4.el8.x86_64 does not like it, either.
> > > > >>
> > > > >> Based on a quick random sampling, this would appear to be a very
> recent
> > > > >> thing, the only affected packages I could find (which doesn't mean
> > > > >> others couldn't exist) were built in the last few days, such as
> the
> > > > >> above and these:
> > > > >>
> > > > >>
> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/n/net-snmp-debugsource-5.9-4.fc34.aarch64.rpm
> > > > >>
> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/n/NetworkManager-debugsource-1.30.0-0.2.fc34.aarch64.rpm
> > > > >>
> > > > >> ...which were all built on Jan 18th. The only recent change to
> rpm is
> > > > >> the DWARF-5 support but based on changelogs that seems to have
> landed
> > > > >> the day after, so I dunno.
> > >
> > > (snip)
> > >
> > > > > Is it possible that this was triggered by switching on signed RPM
> contents?
> > > > > If I understand the implementation correctly, it messes with the
> RPM headers.
> > > >
> > > > Oh, I wasn't aware the file signing proposal had been approved, much
> > > > less enabled. I thought I raised "some objections" on the enablement
> of
> > > > the feature from rpm maintainer perspective.
> > >
> > > It has *not* been approved (yet). Which is why I grumbled about
> > > enabling the signing in production infra during yesterday's FESCo
> > > meeting.
> >
> > Oh, I didn't fully understand your comment at the time. I automatically
> assumed
> > that "enabled in production" only means that the *code* is there, i.e.
> that
> > the version of rpm has been updated in preparation. Actually enabling
> this
> > while the proposal is being discussed is definitely NOT OK. It makes
> > mockery of the whole Change process and deliberation on fedora-devel and
> > the fesco ticket.
>
> I tried to explain this at the meeting, but I guess I was too terse.
>
> First, let me say that I (and I am pretty sure everyone involved) was
> unaware of the rpm bug. I hope Patrick will chime in, by my
> understanding is that rpm specs said they changed this to 64MB, but the
> commit involved only changed it to 64k. :(
>
> This is unfortunate and I am sorry it happened.
>
> We don't currently have a signing setup in staging that allows testing
> this, and wanting to make sure everything worked we put it in place.
> I did not know that it would cause this issue or I would not have
> allowed it to be deployed. On the other hand, we now know about this
> issue instead of learning about it after the mass rebuild is over.
>

+1 I think we should actually be celebrating the fact that we have enabled
this early and found a problem before the mass rebuild.
That's the whole point behind continuous integration and getting early
feedback.


>
> We can disable it before the mass rebuild if desired easily enough.
>
> Note that in the past we have, multiple times, changed the rpm format in
> ways that are not compatible with the current rhel versions of rpm. We
> have in the past always gotten rpm maintainers to update rhel (at least
> the most recent ones) to accomodate this.
>
> I don't think this is a "mockery" of the change process, I think it's a
> case where early testing caught issues before the item landed.
>
> Anyhow, I accept full blame, please send your pitchforks and torches my
> way...
>
> Now back to trying to get armv7 builders stable before mass rebuild.
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> 

Re: AArch64 support for container and flatpak builds

[Clement Verna]

On Thu, 10 Dec 2020 at 14:12, Jakub Cajka  wrote:

>
>
>
>
> - Original Message -
> > From: "Mark O'Brien" 
> > To: devel-annou...@lists.fedoraproject.org,
> devel@lists.fedoraproject.org
> > Sent: Thursday, December 10, 2020 11:44:14 AM
> > Subject: AArch64 support for container and flatpak builds
> >
> > All,
> > We are very happy to announce that we now have AArch64 support for
> flatpak
> > and container fedpkg builds in production!
> >
> > By default all flatpak and container builds will be built on both
> > architectures from now on.
> >
> > Thanks,
> > Fedora OSBS initiative
> >
>
> Awesome. Thank you and all involved. :)
>
> Is there plan to rebuild containers even for f32(I assume that they got
> rebuild for f33 and rawhide.)? It seems from brief check that some are
> missing for aarch64 and so are breaking further container builds.
>

I think that will be a case by case thing, there is no automated way to
rebuild all the containers.


>
> $ fedpkg container-build
> Created task: 57187318
> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57187318
> Watching tasks (this may be safely interrupted)...
> 57187318 buildContainer (noarch): free
> 57187318 buildContainer (noarch): free -> FAILED: Fault:  'Image build failed. Error in plugin pull_base_image: Base image
> registry.fedoraproject.org/f32/s2i-base:latest not available for arches:
> arm64. OSBS build id: golang-f32-8074d-3'>
>   0 free  0 open  0 done  1 failed
>
> Is there anything that I can do to help with that?
>

If you have a failure you should be able to build any container, so in that
case you can rebuild s2i-base in f32 before doing your other builds.

Hope that helps :)


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

Summary/Minutes from today's FESCo Meeting (2020-12-09)

[Clement Verna]

=
#fedora-meeting-2: FESCO (2020-12-09)
=


Meeting started by cverna at 15:00:20 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-2/2020-12-09/fesco.2020-12-09-15.00.log.html
.



Meeting summary
---
* init process  (cverna, 15:00:42)

* #2508 F34 Change: Route all Audio to PipeWire  (cverna, 15:02:21)
  * https://bodhi.fedoraproject.org/updates/FEDORA-2020-4fbf4c6152
(zbyszek, 15:14:17)
  * https://bodhi.fedoraproject.org/updates/FEDORA-2020-0c6652bbf5
(King_InuYasha, 15:15:01)
  * LINK: https://paste.centos.org/view/01b87346   (nirik, 15:15:46)
  * AGREED: approve the change (but with the contingency dealine moved
to one week before beta) (+5, 0, 0)  (cverna, 15:30:35)
  * ACTION: zbyszek to check if the contingency plan needs to be
activated on 20210216, Tuesday  (zbyszek, 15:30:58)

* Next week's chair  (cverna, 15:32:32)
  * ACTION: decathorpe to chair next meeting  (cverna, 15:36:18)

* Open Floor  (cverna, 15:37:22)

Meeting ended at 15:45:11 UTC.




Action Items

* zbyszek to check if the contingency plan needs to be activated on
  20210216, Tuesday
* decathorpe to chair next meeting




Action Items, by person
---
* decathorpe
  * decathorpe to chair next meeting
* zbyszek
  * zbyszek to check if the contingency plan needs to be activated on
20210216, Tuesday
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* King_InuYasha (50)
* cverna (29)
* zbyszek (24)
* nirik (21)
* zodbot (14)
* decathorpe (12)
* bcotton (3)
* sgallagh (2)
* ignatenkobrain (0)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* dcantrell (0)
* mhroncok (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
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

Schedule for Wednesday's FESCo Meeting (2020-12-09)

[Clement Verna]

Sorry for sending this late :)


Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 onirc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-12-09 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

None

= Followups =

#topic #2508 F34 Change: Route all Audio to PipeWire
https://pagure.io/fesco/issue/2508


= New business =

None

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found
athttps://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue athttps://pagure.io/fesco,
e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Thu, 3 Dec 2020 at 20:42, Adam Williamson 
wrote:

> On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:
> > > >   I think if we don't want to accept a different
> > > > philosophy about release schedule and release engineering we can
> > just
> > > close
> > > > that Change proposal.
> > >
> > > That's not the outcome I intended, but rather that if we want
> > CoreOS to
> > > be an "Edition" but we don't want to require it to conform to the
> > > existing "philosophy", as you put it, we need the scope of this
> > Change
> > > to include thinking through all the consequences of that and
> > deciding
> > > what to do about them.
> > >
> >
> > Happy to do that, is your main concern about communication and the
> > story of
> > what is "Fedora" ? or what are the other consequences ?
>
> For me personally it's mainly about validation and release engineering.
> Specifically, making sure the processes we have in place for deciding
> when to cut a CoreOS release in a stream and when to bump streams
> between releases align with the Fedora-wide release criteria etc, and
> making sure the release criteria express all the requirements we
> actually intend to have for making those choices as regards CoreOS.
> Making sure there's a clear vertically-integrated process, like there
> is for "Fedora", from Edition PRDs to release criteria to validation
> tests to release decisions, and there are all the necessary bits of
> glue in between those layers, so you can pretty easily trace back and
> forth between them.
>
> But I suspect there are various consequences for other teams and other
> parts of the process, if you think about it. If you just look at a
> Fedora release schedule:
>
> https://fedorapeople.org/groups/schedule/f-34/f-34-all-tasks.html
>
> there are a zillion things on there, and they're all aligned to our big
> every-six-month-release-machine somehow. At minimum, it'd be a good
> idea to look through all those and think about whether and how each
> entry would be affected by having an Edition with a completely
> different release process.
>

Ok I think I can improve the Change proposal along these lines, and start
with what is currently done for each FCOS release and also how that fits
within the schedule.


>
> > > More or less, yes - but with a key addition: "...and if so, how?"
> > >
> >
> > I feel that we already have the how, Fedora CoreOS has been releasing
> > fortnightly for more than a year now.
> > So it is a matter of making more widely known how this is done ?
>
> It's a matter of "how" from the perspective of the Fedora project. I
> just meant it as an expression of all the other stuff above.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
> ___
> devel mailing list -- de...@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/de...@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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@lists.fedoraproject.org

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Thu, 3 Dec 2020 at 20:42, Adam Williamson 
wrote:

> On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:
> > > >   I think if we don't want to accept a different
> > > > philosophy about release schedule and release engineering we can
> > just
> > > close
> > > > that Change proposal.
> > >
> > > That's not the outcome I intended, but rather that if we want
> > CoreOS to
> > > be an "Edition" but we don't want to require it to conform to the
> > > existing "philosophy", as you put it, we need the scope of this
> > Change
> > > to include thinking through all the consequences of that and
> > deciding
> > > what to do about them.
> > >
> >
> > Happy to do that, is your main concern about communication and the
> > story of
> > what is "Fedora" ? or what are the other consequences ?
>
> For me personally it's mainly about validation and release engineering.
> Specifically, making sure the processes we have in place for deciding
> when to cut a CoreOS release in a stream and when to bump streams
> between releases align with the Fedora-wide release criteria etc, and
> making sure the release criteria express all the requirements we
> actually intend to have for making those choices as regards CoreOS.
> Making sure there's a clear vertically-integrated process, like there
> is for "Fedora", from Edition PRDs to release criteria to validation
> tests to release decisions, and there are all the necessary bits of
> glue in between those layers, so you can pretty easily trace back and
> forth between them.
>
> But I suspect there are various consequences for other teams and other
> parts of the process, if you think about it. If you just look at a
> Fedora release schedule:
>
> https://fedorapeople.org/groups/schedule/f-34/f-34-all-tasks.html
>
> there are a zillion things on there, and they're all aligned to our big
> every-six-month-release-machine somehow. At minimum, it'd be a good
> idea to look through all those and think about whether and how each
> entry would be affected by having an Edition with a completely
> different release process.
>

Ok I think I can improve the Change proposal along these lines, and start
with what is currently done for each FCOS release and also how that fits
within the schedule.


>
> > > More or less, yes - but with a key addition: "...and if so, how?"
> > >
> >
> > I feel that we already have the how, Fedora CoreOS has been releasing
> > fortnightly for more than a year now.
> > So it is a matter of making more widely known how this is done ?
>
> It's a matter of "how" from the perspective of the Fedora project. I
> just meant it as an expression of all the other stuff above.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Thu, 3 Dec 2020 at 20:32, Adam Williamson 
wrote:

> On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:
>
>
> [big snip]
>
> > To the outside
> > > world, there is a strong impression that the thing called "Fedora" is a
> > > product or set of products with a release number that gets released
> > > every six months. The concept of "Fedora 33 release" or "Fedora 34
> > > release" is a strong concept with all these sort of institutional
> > > ripples.
> > >
> >
> > And why cannot we make this evolve ? Is it bad to have a Fedora that has
> > streams instead of versions ?
>
> We can.
>
> Can I ask that you please read my *whole* emails before writing your
> replies? Or at least if you must reply in-line while reading, please
> after you finish, go back and see if what you wrote earlier still
> applies? All of this stuff up top is irrelevant because it's all based
> on an assumption that I was saying FCOS must at all costs align with
> existing processes and schedules, when I was not saying that at all. I
> was just trying to outline the situation and the factors that need to
> be considered.
>

Sorry if that came down that way, but I was trying to get a better
understanding of your concerns.
I ll try to do better next time :-)


>
> I'll reply to the stuff from lower down, where you actually engaged
> with what I was actually saying, in a separate mail.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
> ___
> devel mailing list -- de...@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/de...@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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@lists.fedoraproject.org

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Thu, 3 Dec 2020 at 20:32, Adam Williamson 
wrote:

> On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:
>
>
> [big snip]
>
> > To the outside
> > > world, there is a strong impression that the thing called "Fedora" is a
> > > product or set of products with a release number that gets released
> > > every six months. The concept of "Fedora 33 release" or "Fedora 34
> > > release" is a strong concept with all these sort of institutional
> > > ripples.
> > >
> >
> > And why cannot we make this evolve ? Is it bad to have a Fedora that has
> > streams instead of versions ?
>
> We can.
>
> Can I ask that you please read my *whole* emails before writing your
> replies? Or at least if you must reply in-line while reading, please
> after you finish, go back and see if what you wrote earlier still
> applies? All of this stuff up top is irrelevant because it's all based
> on an assumption that I was saying FCOS must at all costs align with
> existing processes and schedules, when I was not saying that at all. I
> was just trying to outline the situation and the factors that need to
> be considered.
>

Sorry if that came down that way, but I was trying to get a better
understanding of your concerns.
I ll try to do better next time :-)


>
> I'll reply to the stuff from lower down, where you actually engaged
> with what I was actually saying, in a separate mail.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Clement Verna]

On Thu, 3 Dec 2020 at 21:01, Pierre-Yves Chibon  wrote:

> On Thu, Dec 03, 2020 at 04:56:09PM +0100, Clement Verna wrote:
> >On Thu, 3 Dec 2020 at 16:21, Pierre-Yves Chibon <[1]
> pin...@pingoured.fr>
> >wrote:
> >
> >  On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> >  > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton <[2]bcot...@redhat.com>
> >  wrote:
> >  > >
> >  > > [3]
> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> >  > >
> >  > > == Summary ==
> >  > >
> >  > > This Change will move Fedora git repositories to use "main" as
> the
> >  > > default git branch instead of "master". Specific repositories
> will
> >  be
> >  > > manually moved and default git branch for new projects will be
> set
> >  to
> >  > > use "main".
> >  >
> >  > Is there a reason why "main" is proposed instead of "rawhide" on
> >  src.fp.o?
> >  > For all non-dist-git repositories I am fine with "main", but if
> we are
> >  > changing this anyway, "rawhide" would actually make more sense for
> >  > dist-git repos.
> >
> >  One of the argument was that not every namespace on dist-git has a
> >  rawhide
> >  version, for example containers do not have/use rawhide.
> >
> >There is a fedora:rawhide base image container and I think most
> dockerfile
> >from the master branch are using this image for their base. So
> calling the
> >master branch rawhide would be ok for containers :-)
>
> After looking at the infra and releng issue trackers Kevin managed to
> found back
> the ticket I was thinking about.
> You have my apologies, the namespace that was asking to a different default
> branch and for that branch to not be named "rawhide" was flatpaks.
> They wanted the default branch to be "stable", which would not apply to
> most
> other namespaces. Thus the proposal to go with "main" which works for all
> namespaces and seems to be on its way to become the industry standard.
>

Ah no problem, just wanted to make sure that we did not avoid using rawhide
because of the container namespace :-)


>
>
> 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
>
___
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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Wed, 2 Dec 2020 at 21:22, Adam Williamson 
wrote:

> On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote:
> > >
> > > CoreOS is going to be the same only worse, because it's not even built
> > > the same way as the rest of Fedora. It's not built by Pungi, we don't
> > > get the same messages published when CoreOS builds happen (we don't get
> > > messages published at all, IIRC), the metadata for CoreOS builds is not
> > > in productmd[2] form like the metadata for Pungi builds, the whole
> > > process is entirely different.
> > >
> >
> > Recently messages were added when streams are updated [0][1]. I believe
> > that other messages could be added if needed.
>
> Right, I forgot about that, thanks. I've got a ticket lying around here
> somewhere to make something actually use them...:)
> > >
> > > So to boil this down into a representative question: when we are doing
> > > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> > > whether to release "Fedora CoreOS 34"?
> > >
> > >
> > Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing
> and
> > next, each stream is released every 2 weeks.
> > The Go/No-Go is based on reports coming from each stream, next stream is
> > promoted to testing and testing promoted to stable.
> > If any blockers are found in next or testing the content will not be
> > promoted to stable.
> >
> > I think it is fairly well explained here[2]
> > >
> > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> > > the context of how CoreOS is built and released? What set of bits will
> > > we be deciding to ship or not ship, and how will that have been decided
> > > and communicated? Where will we look to find the test results and
> > > criteria on which we would base that decision?
> > >
> > >
> > To maintain a fortnightly cadence there is a strong reliance on CI, every
> > build is tested and results are inspected during the release process.
> > Currently a release is gated on tests running on AWS, GCP and Openstack,
> > these tests are running on a centos-ci jenkins instance which I think
> > cannot be access without a centos account (I might be wrong), but yeah
> > making these tests and results more transparent could be an improvement.
>
> Right, but - as I think you started to recognize later in your mail -
> we're sort of talking at cross-purposes here. You're talking about a
> process that has been developed kind of in isolation for building and
> releasing a thing which has the name "Fedora CoreOS" but doesn't
> actually really integrate much at all with the processes we have for
> building and releasing all the other things that make up "Fedora".
>

Indeed and this was because the current tools and processes were not
designed to work
with a Fedora releasing every 2 weeks. Being allowed to think outside of
the box
and doing things differently is IMO a good thing and should be encouraged.


>
> This is kind of fine as things stand because the thing with the name
> "Fedora CoreOS" isn't considered to be a core fundamental part of the
> thing with the name "Fedora". But this Change is about making it that.
> Doing that causes all sorts of awkward impedance mismatches. Like,
> saying "Fedora CoreOS 34 does not exist" is awkward, because we still
> have this kind of institutional concept of a "Fedora release" which is
> important to what the thing called "Fedora" is and does.

To the outside
> world, there is a strong impression that the thing called "Fedora" is a
> product or set of products with a release number that gets released
> every six months. The concept of "Fedora 33 release" or "Fedora 34
> release" is a strong concept with all these sort of institutional
> ripples.
>

And why cannot we make this evolve ? Is it bad to have a Fedora that has
streams instead of versions ?
Promoting FCOS to an edition is the opportunity to communicate about this
and say to the outside, hey we
have this new thing in Fedora that has a different model come and check it
out.
Fedora has the reputation of leading innovation and doing things first, I
would like to think that making Fedora CoreOS an edition would match these
values.

Also having a different model allows us to expand and reach out to other
types of users.
For years I have heard "I would like to run Fedora on my server, but there
is no LTS and I don't want to do a major upgrade every year".
Why wouldn't be Fedora CoreOS, a possible answer to that problem ?

I be

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Wed, 2 Dec 2020 at 21:22, Adam Williamson 
wrote:

> On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote:
> > >
> > > CoreOS is going to be the same only worse, because it's not even built
> > > the same way as the rest of Fedora. It's not built by Pungi, we don't
> > > get the same messages published when CoreOS builds happen (we don't get
> > > messages published at all, IIRC), the metadata for CoreOS builds is not
> > > in productmd[2] form like the metadata for Pungi builds, the whole
> > > process is entirely different.
> > >
> >
> > Recently messages were added when streams are updated [0][1]. I believe
> > that other messages could be added if needed.
>
> Right, I forgot about that, thanks. I've got a ticket lying around here
> somewhere to make something actually use them...:)
> > >
> > > So to boil this down into a representative question: when we are doing
> > > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> > > whether to release "Fedora CoreOS 34"?
> > >
> > >
> > Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing
> and
> > next, each stream is released every 2 weeks.
> > The Go/No-Go is based on reports coming from each stream, next stream is
> > promoted to testing and testing promoted to stable.
> > If any blockers are found in next or testing the content will not be
> > promoted to stable.
> >
> > I think it is fairly well explained here[2]
> > >
> > > What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> > > the context of how CoreOS is built and released? What set of bits will
> > > we be deciding to ship or not ship, and how will that have been decided
> > > and communicated? Where will we look to find the test results and
> > > criteria on which we would base that decision?
> > >
> > >
> > To maintain a fortnightly cadence there is a strong reliance on CI, every
> > build is tested and results are inspected during the release process.
> > Currently a release is gated on tests running on AWS, GCP and Openstack,
> > these tests are running on a centos-ci jenkins instance which I think
> > cannot be access without a centos account (I might be wrong), but yeah
> > making these tests and results more transparent could be an improvement.
>
> Right, but - as I think you started to recognize later in your mail -
> we're sort of talking at cross-purposes here. You're talking about a
> process that has been developed kind of in isolation for building and
> releasing a thing which has the name "Fedora CoreOS" but doesn't
> actually really integrate much at all with the processes we have for
> building and releasing all the other things that make up "Fedora".
>

Indeed and this was because the current tools and processes were not
designed to work
with a Fedora releasing every 2 weeks. Being allowed to think outside of
the box
and doing things differently is IMO a good thing and should be encouraged.


>
> This is kind of fine as things stand because the thing with the name
> "Fedora CoreOS" isn't considered to be a core fundamental part of the
> thing with the name "Fedora". But this Change is about making it that.
> Doing that causes all sorts of awkward impedance mismatches. Like,
> saying "Fedora CoreOS 34 does not exist" is awkward, because we still
> have this kind of institutional concept of a "Fedora release" which is
> important to what the thing called "Fedora" is and does.

To the outside
> world, there is a strong impression that the thing called "Fedora" is a
> product or set of products with a release number that gets released
> every six months. The concept of "Fedora 33 release" or "Fedora 34
> release" is a strong concept with all these sort of institutional
> ripples.
>

And why cannot we make this evolve ? Is it bad to have a Fedora that has
streams instead of versions ?
Promoting FCOS to an edition is the opportunity to communicate about this
and say to the outside, hey we
have this new thing in Fedora that has a different model come and check it
out.
Fedora has the reputation of leading innovation and doing things first, I
would like to think that making Fedora CoreOS an edition would match these
values.

Also having a different model allows us to expand and reach out to other
types of users.
For years I have heard "I would like to run Fedora on my server, but there
is no LTS and I don't want to do a major upgrade every year".
Why wouldn't be Fedora CoreOS, a possible answer to that problem ?

I be

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Clement Verna]

On Thu, 3 Dec 2020 at 16:21, Pierre-Yves Chibon  wrote:

> On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > >
> > > == Summary ==
> > >
> > > This Change will move Fedora git repositories to use "main" as the
> > > default git branch instead of "master". Specific repositories will be
> > > manually moved and default git branch for new projects will be set to
> > > use "main".
> >
> > Is there a reason why "main" is proposed instead of "rawhide" on
> src.fp.o?
> > For all non-dist-git repositories I am fine with "main", but if we are
> > changing this anyway, "rawhide" would actually make more sense for
> > dist-git repos.
>
> One of the argument was that not every namespace on dist-git has a rawhide
> version, for example containers do not have/use rawhide.
>

There is a fedora:rawhide base image container and I think most dockerfile
from the master branch are using this image for their base. So calling the
master branch rawhide would be ok for containers :-)


> And having different default branches on different namespaces is not very
> appealing.
>
>
> 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
>
___
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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Wed, 2 Dec 2020 at 19:07, Ben Cotton  wrote:

> On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  wrote:
> >
> > So to boil this down into a representative question: when we are doing
> > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> > whether to release "Fedora CoreOS 34"?
> >
> This question is relevant to my interests.
>
> On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  wrote:
> >
> > Note that if you go to getfedora.org and click on CoreOS *right now*,
> > it offers you a Fedora 32-based CoreOS. This is the kind of thing that
> > is kinda fine so long as it's an Emerging Edition. It would *not*,
> > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
> > months after Fedora 34 is "released", our "stable" CoreOS is still
> > Fedora 33-based, that seems like the sort of thing that would look bad.
>
> I agree. I understand the reasoning, but I'd really like to see FCOS
> align with the rest of the schedule or at least develop a clear and
> succinct explanation of why it's delayed so that the public and the
> tech press can easily understand.
>

It is hard for something that releases every 2 weeks to align with the rest
of the schedule, we have the same struggle with the container images. It
feels odd to have to wait 6 months to introduce changes when you release a
new version every couple weeks.


>
> On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa  wrote:
> >
> > I would personally rather see Fedora CoreOS pulled *back* into the
> > fold more as an Edtion
>
> From a program management perspective, I've largely closed my eyes and
> gone "la la la" when it comes to FCOS, in part because it is so
> separate from what we know as Fedora. Making FCOS work more like what
> we know as Fedora would certainly be helpful from my perspective, but
> at the same time there are technical challenges to that. And maybe
> what FCOS does from a distro-building standpoint is more like what we
> should move toward. Maybe not.
>

> In any case, part of the work to be done here, if the Change is
> approved, is for me to figure out how to include FCOS in some of the
> program management work.
>
> I wonder if it would be better to target this for Fedora 35, with some
> of the work starting now. Given the work it took to get IoT into the
> fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
> feels pretty optimistic here.
>

I am open to moving this to F3X but I currently don't have a clear idea of
what is required to be an Edition. If I could get a list of things that
needs to be done, that would help consider if this is doable or not.


>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Wed, 2 Dec 2020 at 18:27, Adam Williamson 
wrote:

> On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote:
> >
> > == How To Test ==
> > See QA test cases :
> https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
> >
> > We also have regular tests days, for example
> > https://fedoramagazine.org/fedora-coreos-test-day/
>
> So...yeah, that's not really enough to call something a Fedora Edition
> :)
>
> I think this has a lot of the issues we had with IoT, but turned up to
> 11.
>
> We have an entire process for releasing a thing called "Fedora" which
> is based around the idea that all the bits that make up a "Fedora
> release" get built, tested, and signed off together.
>
> IoT stretched this process a bit, because it's not actually built as
> part of the same composes as all the other "Fedora" bits. So we had to
> implement an entire parallel validation process just for IoT composes.
> But at least it's built *the same way* as Fedora, so we could more or
> less just split existing things into two paths and use them, which is
> what we did. We now have both mainline and IoT composes and validation
> events. Even there, the process wasn't perfect for Fedora 33; if you
> look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed
> to be where we go over the status of the bits-to-be-released in great
> detail and decide whether to sign them off, there is precisely one line
> about IoT:
>
> 17:58:36  IoT is also covered -
> https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_General#ISO_Install
>
> ...no-one else said a word about it. So yeah, we clearly don't have
> this whole "releasing from multiple streams" entirely down yet.
>
> CoreOS is going to be the same only worse, because it's not even built
> the same way as the rest of Fedora. It's not built by Pungi, we don't
> get the same messages published when CoreOS builds happen (we don't get
> messages published at all, IIRC), the metadata for CoreOS builds is not
> in productmd[2] form like the metadata for Pungi builds, the whole
> process is entirely different.
>

Recently messages were added when streams are updated [0][1]. I believe
that other messages could be added if needed.


>
> So to boil this down into a representative question: when we are doing
> the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> whether to release "Fedora CoreOS 34"?
>
>
Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and
next, each stream is released every 2 weeks.
The Go/No-Go is based on reports coming from each stream, next stream is
promoted to testing and testing promoted to stable.
If any blockers are found in next or testing the content will not be
promoted to stable.

I think it is fairly well explained here[2]


>
>
> What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> the context of how CoreOS is built and released? What set of bits will
> we be deciding to ship or not ship, and how will that have been decided
> and communicated? Where will we look to find the test results and
> criteria on which we would base that decision?
>
>
To maintain a fortnightly cadence there is a strong reliance on CI, every
build is tested and results are inspected during the release process.
Currently a release is gated on tests running on AWS, GCP and Openstack,
these tests are running on a centos-ci jenkins instance which I think
cannot be access without a centos account (I might be wrong), but yeah
making these tests and results more transparent could be an improvement.


>
> Are any of these silly questions, which would indicate that our release
> process is based on assumptions which need to be fundamentally re-
> examined as part of this Change?
>

So what defines an Edition ? I think if we don't want to accept a different
philosophy about release schedule and release engineering we can just close
that Change proposal.

How do you consider Rawhide for example ?


>
> All of this is stuff we could kind of handwave so long as CoreOS wasn't
> an official Edition; we could *more or less* leave the CoreOS team to
> decide what a CoreOS release looked like and when it would happen and
> when it was good enough to ship, and so on.
>

So this change comes down to Can we have a Fedora Edition that has a
different workflow ?


> But if we're going to call it an Edition, which is one of the primary
> things that defines what Fedora *is*, I don't think we can do that any
> more. We need more groups to think about and decide on the answers to
> questions like the above.
>


[0] - https://github.com/coreos/fedora-coreos-tracker/issues/225
[1] -
https://apps.fedoraproject.org/datagrepper/id?id=2020-81657c3b-9703-431a-8c3c-0b409743fac4_raw=true=extra-large
[2] -
https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#release-streams


> [1]:
> https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-final-go_no_go-meeting.2020-10-22-17.00.log.html
> [2]: 

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Wed, 2 Dec 2020 at 18:27, Adam Williamson 
wrote:

> On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote:
> >
> > == How To Test ==
> > See QA test cases :
> https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
> >
> > We also have regular tests days, for example
> > https://fedoramagazine.org/fedora-coreos-test-day/
>
> So...yeah, that's not really enough to call something a Fedora Edition
> :)
>
> I think this has a lot of the issues we had with IoT, but turned up to
> 11.
>
> We have an entire process for releasing a thing called "Fedora" which
> is based around the idea that all the bits that make up a "Fedora
> release" get built, tested, and signed off together.
>
> IoT stretched this process a bit, because it's not actually built as
> part of the same composes as all the other "Fedora" bits. So we had to
> implement an entire parallel validation process just for IoT composes.
> But at least it's built *the same way* as Fedora, so we could more or
> less just split existing things into two paths and use them, which is
> what we did. We now have both mainline and IoT composes and validation
> events. Even there, the process wasn't perfect for Fedora 33; if you
> look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed
> to be where we go over the status of the bits-to-be-released in great
> detail and decide whether to sign them off, there is precisely one line
> about IoT:
>
> 17:58:36  IoT is also covered -
> https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_General#ISO_Install
>
> ...no-one else said a word about it. So yeah, we clearly don't have
> this whole "releasing from multiple streams" entirely down yet.
>
> CoreOS is going to be the same only worse, because it's not even built
> the same way as the rest of Fedora. It's not built by Pungi, we don't
> get the same messages published when CoreOS builds happen (we don't get
> messages published at all, IIRC), the metadata for CoreOS builds is not
> in productmd[2] form like the metadata for Pungi builds, the whole
> process is entirely different.
>

Recently messages were added when streams are updated [0][1]. I believe
that other messages could be added if needed.


>
> So to boil this down into a representative question: when we are doing
> the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> whether to release "Fedora CoreOS 34"?
>
>
Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and
next, each stream is released every 2 weeks.
The Go/No-Go is based on reports coming from each stream, next stream is
promoted to testing and testing promoted to stable.
If any blockers are found in next or testing the content will not be
promoted to stable.

I think it is fairly well explained here[2]


>
>
> What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> the context of how CoreOS is built and released? What set of bits will
> we be deciding to ship or not ship, and how will that have been decided
> and communicated? Where will we look to find the test results and
> criteria on which we would base that decision?
>
>
To maintain a fortnightly cadence there is a strong reliance on CI, every
build is tested and results are inspected during the release process.
Currently a release is gated on tests running on AWS, GCP and Openstack,
these tests are running on a centos-ci jenkins instance which I think
cannot be access without a centos account (I might be wrong), but yeah
making these tests and results more transparent could be an improvement.


>
> Are any of these silly questions, which would indicate that our release
> process is based on assumptions which need to be fundamentally re-
> examined as part of this Change?
>

So what defines an Edition ? I think if we don't want to accept a different
philosophy about release schedule and release engineering we can just close
that Change proposal.

How do you consider Rawhide for example ?


>
> All of this is stuff we could kind of handwave so long as CoreOS wasn't
> an official Edition; we could *more or less* leave the CoreOS team to
> decide what a CoreOS release looked like and when it would happen and
> when it was good enough to ship, and so on.
>

So this change comes down to Can we have a Fedora Edition that has a
different workflow ?


> But if we're going to call it an Edition, which is one of the primary
> things that defines what Fedora *is*, I don't think we can do that any
> more. We need more groups to think about and decide on the answers to
> questions like the above.
>


[0] - https://github.com/coreos/fedora-coreos-tracker/issues/225
[1] -
https://apps.fedoraproject.org/datagrepper/id?id=2020-81657c3b-9703-431a-8c3c-0b409743fac4_raw=true=extra-large
[2] -
https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#release-streams


> [1]:
> https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-final-go_no_go-meeting.2020-10-22-17.00.log.html
> [2]: 

Re: Fedora packages site down

[Clement Verna]

On Wed, 25 Nov 2020 at 20:26, Brendan Early  wrote:

> On 11/25/20 12:34 PM, Neal Gompa wrote:
> > My understanding is that the -static version cannot update at the same
> > cadence as the content synced out to the mirrors. To me, that's a
> > problem, because then the data is just too stale or wrong because it's
> > not fresh enough.
>
> How often do the mirrors sync? I have been meaning to change the sync
> script to only generate files for version differences, which should
> allow for running it every thirty minutes.
>

The previous solution was listening to this message
https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.prod.mdapi.repo.update=2
to update the database. The message is sent if changes are detected in the
repos. That process is run by a cronjob every hour.

IMO that's acceptable, but curious to hear from others :-)


> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Re: Fedora packages site down

[Clement Verna]

On Tue, 24 Nov 2020 at 23:02, Kevin Fenzi  wrote:

> On Tue, Nov 24, 2020 at 12:18:54PM +0100, Miroslav Suchý wrote:
> > Dne 18. 11. 20 v 2:11 Kevin Fenzi napsal(a):
> > > We are close to replacing this app with a new setup...
> > >
> > > see the 'packages app' thread in this very list. ;)
> >
> > Did we come to conclusion which app (out of these two) we are going to
> deploy?
>
> Well, I personally thought it would be better to go with the community
> maintained one. Less work for you/your team, more respectfull of the
> work they already put into this, and I know you and your team are busy.
> >
> > If that will be the fedora-packages-ng I will be happy to proceed and
> spin up VM in AWS and update playbooks. I just
> > need the green light :)
> > If that helps, I can promise that CPT (aka Copr) team will maintain it.
>
> Thats great, and if that was the only choice I would be very happy...
> however, we have another community maintained/created one. :(
>
> > On 11/24/20 5:18 AM, Miroslav Suchý wrote:
> > > Dne 18. 11. 20 v 2:11 Kevin Fenzi napsal(a):
> > > > We are close to replacing this app with a new setup...
> > > >
> > > > see the 'packages app' thread in this very list. ;)
> > > Did we come to conclusion which app (out of these two) we are going to
> deploy?
> >
> > Timothée and I submitted a solution in April. It would be great if
> > packages-static could be adopted.
> >
> > I have been consistently responding to all discussions on the mailing
> list.
> > I did respond to the thread back in September. Kevin said you were busy
> and
> > suggested -static and -ng be tested. I have submitted an RFR since then.
> I
> > have time to maintain packages-static and I am still looking for a
> favorable
> > decision.
> >
> >
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/SYM6OT4BGDOWF7EGOGG75YG5LOXB7XMF/#YD5TFWZHBITXZBA35KDELKDGXANCH5E6
> >
> > https://pagure.io/fedora-infrastructure/issue/9441
>
> Yeah, I have had no time to work on deploying this, but it should be
> pretty short work for any of the folks who have deployed apps in our
> openshift.
>
> I'd personally go with static, but perhaps thats just me.
>

Yeah I think we should give a chance to the static solution, which seems to
be the easier to maintain and run on the long term.


>
> I would love to hear from more feedback one way or another.
>
> Miroslav: what do you think? would you be ok if we went with static and
> in the event something didn't work there or we needed more functionality
> down the road we could move to ng then and in the mean time less work
> for you?
>
> Please chime in everyone. :)
>
> kevin
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Re: GitLab AMA Topic: Message Bus

[Clement Verna]

On Mon, 23 Nov 2020 at 21:31, Adam Williamson 
wrote:

> On Mon, 2020-11-23 at 15:11 -0500, Neal Gompa wrote:
> > >
> > > I would highly recommend not creating message consumers that rely on
> > > any particular message ordering because they're not going to work
> > > properly, GitLab or not.
> >
> > Too late, pretty much every consumer I'm aware of relies on having
> > chronological order or at least some way to sort them chronologically
> > for processing for messages.
>
> I don't think any consumer I've written does. They all just work on the
> basis "a thing happened; do some things relevant to the thing that
> happened".
>

Honestly my feeling is that most of our consumers fall into that category ,
I can't think of a use case where the chronological order matters (I have
been told CI might, but I don't know the exact use case).
If anyone has a concrete example, I would welcome it very much so that we
can use it as a test case with GitLab.


> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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: GitLab AMA Topic: Message Bus

[Clement Verna]

On Wed, 18 Nov 2020 at 18:30, Fabio Valentini  wrote:

> On Mon, Nov 9, 2020 at 3:05 PM Aoife Moloney  wrote:
> >
> > Hi everyone,
> >
> > I hope you enjoyed the F33 release party this weekend! Getting back to
> > the GitLab topic mail threads, this weeks topic from the GitLab AMA
> > session on September 10th is on Message Bus. As always, here are some
> > links to the resources I have been pulling content from as well:
> > * Questions and Answers hackmd link
> https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> > * Chat log from session
> >
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> > * AMA Blog post
> > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
> > * Here is this email in hackmd if you wish to view it there:
> > https://hackmd.io/tfOqCXNEQtqsGNLAEfZ2zg?view
>
> Sorry for taking so long to respond, the past weeks have been quite busy.
>

Sorry for taking even longer to answer, you know the feeling :P


>
> (snip)
>
> > ## Topic: Message Bus
> > - Question: Fedora uses a message bus to integrate different parts of
> > its infrastructure. How should we onboard GitLab into this message
> > bus?
> > - Answer: Currently we would need to have a service that proxies
> > GitLab’s events to fedora-messaging something similar to
> > github2fedmsg.
> > There were some concerns raised about the order of events sent by
> > GitLab’s webhooks, these will need to be looked after during a Proof
> > of Concept stage.
>
> Do we know if such a proxy would even be theoretically possible for GitLab?
> IIRC, some doubts were raised during the AMA that getting a
> chronologically consistent stream of events out of GitLab would be ∈
> [hard, impossible[.
> What would that mean for fedora? Do services relying on
> fedora-messaging events related to dist-git need them to be consistent
> / chronological?
> What would be the effect of those services not having a reliable
> stream of events from dist-git?
>

I personally don't have a good answer to these questions, and I don't think
we will be able to
have without actually doing a Proof of Concept and see how that would work
and scale.

Regarding the order or messages, I believe that anything related to CI
testing might need to
have the chronological order of messages consistent.
I am not sure if there are any other use cases ?



>
> Fabio
>
> > - Question: How would git push over http work with GitLab? (assuming
> > gitlab does not have Fedora's password since they are stored in FAS)
> > - Answer: GitLab has a good number of authentication options and
> > integrations where the "best" solution usually depends on a team's
> > specific needs and use case. As such,  the best way to know and meet
> > Fedora's needs and use cases is to have a conversation and discuss the
> > options with GitLab. How does git push over HTTP work with FAS right
> > now, and what git push (over HTTP) auth requirements/flow would you
> > like to have for your projects in GitLab?
> >
> > These are the only two questions and answers I could gather relating
> > to message bus from the AMA question sheet, however I know there was a
> > lot of discussion regarding this topic during the AMA session itself,
> > so if you would like to resume/kick off  that conversation again,
> > please feel free to use this email to discuss.
> >
> > A personal note and for full transparency: the weeks seem to be
> > passing in the blink of an eye lately, I assume it's because I'm
> > busy(?) but it might be just the weird 2020 vibe the world is on
> > nowadays. I really don't know. Whatever the reason, there has been no
> > further discussion with GitLab since early October-ish, but we will be
> > returning to the conversation of how this migration could be
> > technically possible soon, so sincerely thank you all again for
> > engaging with us/me here as I found reading the discussion on
> > permission and access much easier to follow and have been taking notes
> > on your expectations to use that feedback in conversations with GitLab
> > when we pick the discussion back up.
> >
> >
> >
> > I hope you all had a good weekend and will talk to you all next week
> > when the topic of Namespace & Issue Tracking is sent!
> >
> >
> > Kindest regards,
> > Aoife
> > --
> > Aoife Moloney
> > Product Owner
> > Community Platform Engineering Team
> > Red Hat EMEA
> > Communications House
> > Cork Road
> > Waterford
> > ___
> > 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
> ___
> 

Re: Schedule for Wednesday's FESCo Meeting (2020-10-28)

[Clement Verna]

Works for me

On Wed, 28 Oct 2020 at 09:05, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Tue, Oct 27, 2020 at 07:08:11PM -0700, Kevin Fenzi wrote:
> > On Tue, Oct 27, 2020 at 09:18:34PM -0400, Neal Gompa wrote:
> > > On Tue, Oct 27, 2020 at 8:52 PM David Cantrell 
> wrote:
> > > >
> > > >
> > > > PROPOSAL: Cancel the 28-Oct-2020 FESCo meeting because we have no
> > > > issues tagged with 'meeting' and no pending issues to discuss in an
> > > > open forum.  I will chair the 04-Nov-2020 meeting.
> > >
> > > Sounds good to me. I'm good with canceling.
> >
> > +1 to cancel.
>
> I wouldn't be able to attend because of the general strike in Poland,
> so +1 to cancelling too.
>
> 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
>
___
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: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

[Clement Verna]

On Fri, 23 Oct 2020 at 19:55, Neal Gompa  wrote:

> On Fri, Oct 23, 2020 at 1:07 PM Clement Verna 
> wrote:
> >
> >
> >
> > On Fri, 23 Oct 2020 at 17:20, Miro Hrončok  wrote:
> >>
> >> On 10/23/20 2:45 PM, Aleksandra Fedorova wrote:
> >> > Sorry, but you just need to accept the fact that some _early
> >> > development_ work in Fedora can happen without your decision on it.
> >>
> >> I except (and accept) that most of the development work in Fedora
> happens
> >> without my decision on it.
> >>
> >> I would like you on the other hand to accept that major changes in
> Fedora are
> >> coordinated trough the change process and ELN is part of Fedora.
> >
> >
> > This for me highlights the fact that our change process is not adapted
> to all parts of Fedora, in particular parts that need to move faster than
> the 6 month releases. I have in mind the Container base image, Fedora
> CoreOS and ELN, IMO these artefact depends more on the content (the set of
> packages included in them) rather then knowing which version of Fedora
> release they are based on.
> > The Container base image and Fedora CoreOS are releasing every couple
> weeks, ELN is just a rolling release, I think it is unfair to ask to follow
> a change request system that is design for release that happen every 6
> months.
> >
> > I think we either need a new change request system that is light enough
> to allow these group to iterate and make changes every week or so, or we
> need to trust the people involved in these groups to make the best
> decisions for the Fedora they care about and to also notify anyone that
> would be impacted by these changes.
> >
>
> I think you're missing the point. When ELN was approved, the intent
> was to build Rawhide in a RHEL-ish configuration continuously.


I agree that I missed that point because honestly it does not interest me.
What I am seeing is that we have a group of people that are interested in
experimenting and doing things differently in Fedora (The ELN SIG) and so
far every time their trials are met with a lot of push back. I personally
don't care if ELN is not what was communicated originally as long as it
brings value to the people working on it, and it does not make other people
live worse.

There is so much energy spent pointing fingers at each other, it is really
demoralizing :(, Personally If I was in the ELN SIG I would feel unwelcome
and unwanted in Fedora, and would really consider just quitting trying to
do anything new in this community.

This
> particular plan defeats what ELN was communicated as because now
> there's a major deviation where people can't really participate and
> it's not much benefit for everyone else. Moreover, GCC 11 *will* land
> in Rawhide, so why not just push it there now?

A Change proposal for
> GCC 11 still makes sense because it's *for* Fedora in the end too.
>
> > I also would like to point out that the Fedora's project mission
> statement is to explicitly allow such group to be empowered to make their
> decisions, at least this is what I understand in the following
> >
> > ```
> > Fedora creates an innovative platform for hardware, clouds, and
> containers that enables software developers and community members to build
> tailored solutions for their users.
> > ```
> >
>
>
>
>
> --
> 真実はいつも一つ！/ 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
>
___
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: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

[Clement Verna]

On Fri, 23 Oct 2020 at 17:20, Miro Hrončok  wrote:

> On 10/23/20 2:45 PM, Aleksandra Fedorova wrote:
> > Sorry, but you just need to accept the fact that some _early
> > development_ work in Fedora can happen without your decision on it.
>
> I except (and accept) that most of the development work in Fedora happens
> without my decision on it.
>
> I would like you on the other hand to accept that major changes in Fedora
> are
> coordinated trough the change process and ELN is part of Fedora.
>

This for me highlights the fact that our change process is not adapted to
all parts of Fedora, in particular parts that need to move faster than the
6 month releases. I have in mind the Container base image, Fedora CoreOS
and ELN, IMO these artefact depends more on the content (the set of
packages included in them) rather then knowing which version of Fedora
release they are based on.
The Container base image and Fedora CoreOS are releasing every couple
weeks, ELN is just a rolling release, I think it is unfair to ask to follow
a change request system that is design for release that happen every 6
months.

I think we either need a new change request system that is light enough to
allow these group to iterate and make changes every week or so, or we need
to trust the people involved in these groups to make the best decisions for
the Fedora they care about and to also notify anyone that would be impacted
by these changes.

I also would like to point out that the Fedora's project mission statement
is to explicitly allow such group to be empowered to make their decisions,
at least this is what I understand in the following

```
*Fedora creates an innovative platform for hardware, clouds, and containers
that enables software developers and community members to build tailored
solutions for their users.*
*```*


> I would also like to you to tone it down with the personal accusations you
> are
> repeatedly making towards me. If you don't, this discussion is not
> productive.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

[Clement Verna]

On Thu, 22 Oct 2020 at 14:28, Aleksandra Fedorova 
wrote:

> Hi, all,
>
> this is the informational message, no action required.
>
> Upon agreement between gcc maintainers and ELN SIG we would like to
> switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
>
> Though ELN is defined as the buildroot where Fedora Rawhide code is
> rebuilt into EL-like environment, in the ELN proposal we also
> mentioned that ELN can be used to test certain buildroot-related
> features on the side so it doesn't block Fedora Rawhide development.
>
> We think that GCC11 is one such feature, where we can benefit from
> testing it first on a small subset of the Fedora content in a separate
> environment.
>

I think this is one of the great benefits of having ELN and being able to
use it to start integrating such changes. I am looking forward, seeing if
that makes it easier for GCC11 to land in rawhide, I would be nice if you
could share the issues that were caught during that work in ELN.

Thanks for driving this effort


>
> We would like to invite everyone to join this effort.
>
> The work is currently tracked on Github:
> https://github.com/fedora-eln/eln/issues/8
>
> Once GCC11 is merged to the eln tag in koji, one would be able to use
> it via, for example, mock or container environment:
> quay.io/fedoraci/fedora:eln-x86_64
>
> For more info on ELN please refer to ELN Docs (as soon as I update
> them, which hopefully happens later today):
>
> https://docs.fedoraproject.org/en-US/eln/
>
> --
> Aleksandra Fedorova
> bookwar at #fedora-devel and #fedora-ci
> ___
> 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: Schedule for Wednesday's FESCo Meeting (2020-10-14) + Proposal to Cancel

[Clement Verna]

On Tue, 13 Oct 2020 at 21:49, Neal Gompa  wrote:

> On Tue, Oct 13, 2020 at 3:01 PM Fabio Valentini 
> wrote:
> >
> > Since there are no open tickets that are tagged with "meeting" and no new
> > tickets are in need of synchronous discussion IMO, I propose to cancel
> > tomorrow's meeting, and would chair next week's meeting instead.
> >
> > The usual (empty) schedule and announcements are listed below.
> >
>
> I'm fine with that.
>
>
>
Works for me too


> --
> 真実はいつも一つ！/ 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
>
___
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: CPE Weekly: 2020-09-20

[Clement Verna]

On Mon, 12 Oct 2020 at 22:10, Aoife Moloney  wrote:

>
>
> On Mon, Oct 12, 2020 at 2:58 PM Clement Verna 
> wrote:
>
>>
>>
>> On Mon, 12 Oct 2020 at 10:09, Fabio Valentini 
>> wrote:
>>
>>> On Sun, Sep 20, 2020 at 10:33 PM Aoife Moloney 
>>> wrote:
>>> >  GitLab
>>> > Thank you so much to everyone for adding your questions to the doc for
>>> > the GitLab AMA session on Thursday 10th September, and for your
>>> > attendance on the day during the call.
>>> > Here is the full AMA transcript
>>> >
>>> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
>>> > however it is a bit confusing to read so we got a few great
>>> > suggestions to have dedicted topics like Message Bus and Branching,
>>> > etc go out to the devel lists to discuss. I'm happy to start this next
>>> > week, but I will collect the questions related to each topic and
>>> > propose a cadence to send them out first to discuss, so people dont
>>> > miss mails and know the week ending 2nd October will be (for example)
>>> > the topic of Group Permissions - What do you think?
>>> > GitLab have also agreed to answer the questions, we have asked them to
>>> > do so within 2 weeks of the AMA so as soon as this is complete I will
>>> > let you know so you can read through them on the hackmd link.
>>> > The link is here where we asked you to contribute your questions and I
>>> > will be posting answers once we have them underneath
>>> > https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
>>> > I really appreciate your involvement with this as we begin to dig
>>> > deeper into how this might play out next year and what way it should
>>> > for everyone's benefit.
>>>
>>> So ... it's now over a month since the AMA, and none of those things
>>> have actually happened yet?
>>>
>>
>> There is a community blog post coming up, it was supposed to be published
>> last week, but I have not gotten the time to add answers to the hackmd
>>
>
Community blog post was published today :-)
https://communityblog.fedoraproject.org/gitlab-ama-follow-up/


>
>>
>>> No answers from GitLab? No updated hackmd document? No devel list
>>>
>>
>> This is coming after that blog post.
>>
>
> I can share some dates now that things have been updated over the last few
> days.
> The blog post is scheduled for publishing on Friday 16th Oct. We wanted to
> include a link to the completed hackmd in the post too so until that was
> done we needed to hold off. And that's since been worked on by Clement
> (thanks Clement!) who was waiting on GitLab to provide the answers, which
> they finished doing so last week (thanks to the people over there!). Ben
> Cotton has put the blog together (thanks Ben!) and has been waiting on me
> to add my piece to it yet. Its been on my todo so sorry for the delay here.
> Then next Friday, 23rd October, I would like to start sending a weekly
> 'topic' to the devel lists with the grouped questions and answers from the
> hackmd doc for more specific discussion.
> I hope that makes sense to everyone. That way posts and emails are not
> lost if they come out in a staggered format.
>
>>
>>
>>> posts for dedicated topics?
>>> I can't say I'm surprised, but I'm disappointed. Again.
>>>
>>
>> Sorry if that is taking to much time and does not meet your expectations.
>>
>
> I can only echo Clements statement here. We are all only human and trying
> our best. I do understand it can be frustrating though, I totally
> acknowledge that, so thank you for your patience as it is appreciated.
>
>>
>>
>>>
>>> Fabio
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct:
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>>
>> ___
>> 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/

Re: bodhi updates stuck in "pending" state

[Clement Verna]

On Tue, 13 Oct 2020 at 11:34, Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> Il 12/10/20 19:54, Kevin Fenzi ha scritto:
> >
> >> Please see my post from a couple of weeks ago:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DHLKVLQV2IIB3AGURZ5V37Y2AK2YWSTH/
> >>
> >> Many of those stuck updates have no builds associated, therefore they
> are stuck.
> >> They should have been purged by a celery task, but it seems it doesn't
> run or it fails:
> >> https://github.com/fedora-infra/bodhi/issues/4121
> >>
> >> I have no access to bodhi backend and I cannot check logs to see what's
> going on there.
> > Yeah, I am not sure either... we can definitely get you access to look
> > though.
> >
> > kevin
> > --
> >
> Should I file a request to fedora-infrastructure for that?
>

Once this [0] is merged and deployed you should have access ;-)

[0] - https://pagure.io/fedora-infra/ansible/pull-request/284


> BTW, all updates listed in Bodhi with the alias in place of build names
> are empty (without any build associated). They could be safely unpushed
> manually by CLI, but I did not do that because they should be set
> obsoleted by the aforesaid celery task.
>
> Mattia
>
> ___
> 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: CPE Weekly: 2020-09-20

[Clement Verna]

On Mon, 12 Oct 2020 at 10:09, Fabio Valentini  wrote:

> On Sun, Sep 20, 2020 at 10:33 PM Aoife Moloney 
> wrote:
> >  GitLab
> > Thank you so much to everyone for adding your questions to the doc for
> > the GitLab AMA session on Thursday 10th September, and for your
> > attendance on the day during the call.
> > Here is the full AMA transcript
> >
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> > however it is a bit confusing to read so we got a few great
> > suggestions to have dedicted topics like Message Bus and Branching,
> > etc go out to the devel lists to discuss. I'm happy to start this next
> > week, but I will collect the questions related to each topic and
> > propose a cadence to send them out first to discuss, so people dont
> > miss mails and know the week ending 2nd October will be (for example)
> > the topic of Group Permissions - What do you think?
> > GitLab have also agreed to answer the questions, we have asked them to
> > do so within 2 weeks of the AMA so as soon as this is complete I will
> > let you know so you can read through them on the hackmd link.
> > The link is here where we asked you to contribute your questions and I
> > will be posting answers once we have them underneath
> > https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> > I really appreciate your involvement with this as we begin to dig
> > deeper into how this might play out next year and what way it should
> > for everyone's benefit.
>
> So ... it's now over a month since the AMA, and none of those things
> have actually happened yet?
>

There is a community blog post coming up, it was supposed to be published
last week, but I have not gotten the time to add answers to the hackmd


> No answers from GitLab? No updated hackmd document? No devel list
>

This is coming after that blog post.


> posts for dedicated topics?
> I can't say I'm surprised, but I'm disappointed. Again.
>

Sorry if that is taking to much time and does not meet your expectations.


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

Summary/Minutes from today's FESCo Meeting (2020-09-16)

[Clement Verna]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-16/fesco.2020-09-16-14.00.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-16/fesco.2020-09-16-14.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-16/fesco.2020-09-16-14.00.log.html


Meeting summary
---
* init process  (cverna, 14:00:43)
  * LINK:

https://fedoraproject.org/w/index.php?title=Changes/rpm_level_auto_release_and_changelog_bumping=history
(mhroncok, 14:06:09)
  * ACTION: cverna to tagged #2441 as stalled  (cverna, 14:14:24)
  * ACTION: zbyszek to draft spins/flavors/variants policy based on
https://pagure.io/fesco/issue/2418#comment-667545 with announce
notices for orphaned spins/flavors/variants similar to orphaned
packages  (cverna, 14:34:23)
  * ACTION: cverna to tag #2409 stalled  (cverna, 14:38:46)
  * LINK: https://pagure.io/fesco/issues   (cverna, 14:40:30)
  * ACTION: cverna to close #2020  (cverna, 14:43:57)

* Next week's chair  (cverna, 14:46:33)
  * ACTION: mhroncok to chair next meeting  (cverna, 14:48:44)

* Open Floor  (cverna, 14:48:51)

Meeting ended at 14:56:31 UTC.




Action Items

* cverna to tagged #2441 as stalled
* zbyszek to draft spins/flavors/variants policy based on
  https://pagure.io/fesco/issue/2418#comment-667545 with announce
  notices for orphaned spins/flavors/variants similar to orphaned
  packages
* cverna to tag #2409 stalled
* cverna to close #2020
* mhroncok to chair next meeting
___
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

Schedule for Wednesday's FESCo Meeting (2020-09-16)

[Clement Verna]

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-09-16 14:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =
#2469 F34 Self-Contained Change: Python Upstream Architecture Names
https://pagure.io/fesco/issue/2469
APPROVED (+5, 0, 0)

#2466 Nonresponsive maintainer: Jon Disnard parasense
https://pagure.io/fesco/issue/2466
APPROVED (+4, 0, 0)

= Followups =

= New business =

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
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: Gitlab Ask Me Anything - Sept 10th, 13:30 UTC

[Clement Verna]

On Wed, 9 Sep 2020 at 10:30, Julen Landa Alustiza 
wrote:

>
>
> 20/9/4 17:27(e)an, Aoife Moloney igorleak idatzi zuen:
>
> >
> > - A discussion on forum.gitlab.com at:
> >
> https://forum.gitlab.com/t/fedora-migration-to-gitlab-ask-me-anything-ama-thursday-september-10-2020/41971
> >
>
> Er, The Tell me more part on that post says: "On March 27, 2020, Fedora
> announced its decision to use GitLab as its git-forge (see announcement
> here 11). This announcement was met with mixed reactions because it
> meant a move away from Pagure, Fedora’s current home-grown git-forge tool."
>
> This is not true. CPE made (an announced) its decision, not Fedora.
> Fedora does not have yet a system wide change process to even discuss it.
>

That's my bad, I reviewed this and that looked good to me, but yeah maybe
the wording could have been better even though CPE is part of Fedora afaik.


>
> --
> Julen Landa Alustiza 
> ___
> 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: Freeze Break Request (Fix 2factor on builders)

[Clement Verna]

+1

On Fri, Aug 28, 2020, 23:58 Neal Gompa  wrote:

> On Fri, Aug 28, 2020 at 4:29 PM Stephen John Smoogen 
> wrote:
> >
> >
> > Currently the builders are trying to contact os-node boxes on port 8443
> but that is not where fas-all lives.
> >
> > diff --git a/roles/base/templates/iptables/iptables.kojibuilder
> b/roles/base/templates/iptables/iptables.kojibuilder
> > index a3819777c..805cf735f 100644
> > --- a/roles/base/templates/iptables/iptables.kojibuilder
> > +++ b/roles/base/templates/iptables/iptables.kojibuilder
> > @@ -78,10 +78,12 @@
> >  -A OUTPUT -p tcp -m tcp -d 10.3.163.76 --dport 443 -j ACCEPT
> >  -A OUTPUT -p tcp -m tcp -d 10.3.163.77 --dport 80 -j ACCEPT
> >  -A OUTPUT -p tcp -m tcp -d 10.3.163.77 --dport 443 -j ACCEPT
> > -# for 2 facter auth
> > --A OUTPUT -p tcp -m tcp -d 10.3.163.69 --dport 8443 -j ACCEPT
> > --A OUTPUT -p tcp -m tcp -d 10.3.163.70 --dport 8443 -j ACCEPT
> > --A OUTPUT -p tcp -m tcp -d 10.3.163.71 --dport 8443 -j ACCEPT
> > +# for 2 facter auth (fas-all)
> > +-A OUTPUT -p tcp -m tcp -d 10.3.163.74 --dport 8443 -j ACCEPT
> > +-A OUTPUT -p tcp -m tcp -d 10.3.163.75 --dport 8443 -j ACCEPT
> > +-A OUTPUT -p tcp -m tcp -d 10.3.163.76 --dport 8443 -j ACCEPT
> > +-A OUTPUT -p tcp -m tcp -d 10.3.163.77 --dport 8443 -j ACCEPT
> > +
> >
> >  #nfs to vtap-fedora-nfs01.storage.phx2.redhat.com - a little to
> wide-open - but
> >  # kinda necessary
> >
>
> +1 from me.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Re: docker.io/library/fedora:rawhide outdated vs registry.fp.org/fedora:rawhide

[Clement Verna]

On Wed, 19 Aug 2020 at 19:19, Daniel P. Berrangé 
wrote:

> On Wed, Aug 19, 2020 at 05:07:52PM +0200, Clement Verna wrote:
> > On Wed, 19 Aug 2020 at 14:02, Daniel P. Berrangé 
> > wrote:
> >
> > > I have a docker recipe that does not much more than:
> > >
> > >   FROM fedora:rawhide
> > >   RUN dnf -y install ...blah...
> > >
> > >
> > Long story short the docker hub requires a PR to a github repo to update
> > the image,  this PR is reviewed and merged by a person (more context [0])
> > so we cannot update the rawhide image nightly like we do on
> registry.fp.o.
> > After talking with the Docker folks a weekly cadence would be acceptable
> > for them and I think this is what we should try to do, we *just* need
> > someone to work on that.
> > Most of the release process is automated. We are basically missing some
> > glue to run scripts weekly and have the correct permission etc ... (more
> > info [1])
> >
> > We are trying to restart the container SIG (we have a meeting coming this
> > week [2]) and I think this is the type of work that this group could be
> > helping with so anyone interested to help is more than welcome :-)
> >
> > I Hope that helps and gives a bit more context.
>
> Yes, thank you, that is useful background.  Quite a tedious process
> docker hub requires for frequently changed images :-(
>
> Aside from the plans you mention to do weekly updates in future, I'd
> suggest doing a rawhide image update ASAP, to address the immediate
> pain of "dnf update" not working due to the F33/F34 branching with
> new GPG keys.
>

This is now fixed on Docker Hub


>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: docker.io/library/fedora:rawhide outdated vs registry.fp.org/fedora:rawhide

[Clement Verna]

On Wed, 19 Aug 2020 at 14:02, Daniel P. Berrangé 
wrote:

> I have a docker recipe that does not much more than:
>
>   FROM fedora:rawhide
>   RUN dnf -y install ...blah...
>
>
Long story short the docker hub requires a PR to a github repo to update
the image,  this PR is reviewed and merged by a person (more context [0])
so we cannot update the rawhide image nightly like we do on registry.fp.o.
After talking with the Docker folks a weekly cadence would be acceptable
for them and I think this is what we should try to do, we *just* need
someone to work on that.
Most of the release process is automated. We are basically missing some
glue to run scripts weekly and have the correct permission etc ... (more
info [1])

We are trying to restart the container SIG (we have a meeting coming this
week [2]) and I think this is the type of work that this group could be
helping with so anyone interested to help is more than welcome :-)

I Hope that helps and gives a bit more context.

Also if you want to make sure to pull the image from registry.fp.o you can
use the following `FROM registry.fedoraproject.org/fedora:rawhide` and that
will work on every system.

[0] - https://github.com/docker-library/official-images/issues/7529
[1] - https://pagure.io/releng/issue/8270
[2] - https://pagure.io/ContainerSIG/container-sig/issue/43

>
> If I run this from a Fedora host it works fine, resolving fedora:rawhide
> to registry.fedoraproject.org image ID 23902052bc28
>
> If I run this from a non-Fedora host, such as from GitLab CI, it resolves
> to docker.io/library image ID e6ff04a4b8bd.
>
> The latter image fails when installing RPMs due tpo missing gpg keys
>
> # dnf install numactl
> Fedora 33 openh264 (From Cisco) - x86_64   5.2 kB/s |
> 5.1 kB 00:00
> Fedora - Modular Rawhide - Developmental packages for the next 1.9 MB/s |
> 961 kB 00:00
> Fedora - Rawhide - Developmental packages for the next Fedora   12 MB/s |
> 73 MB 00:06
> Dependencies resolved.
>
> ===
>  Package Architecture  Version
> Repository  Size
>
> ===
> Installing:
>  numactl x86_642.0.12-6.fc33
> rawhide 69 k
> Installing dependencies:
>  numactl-libsx86_642.0.12-6.fc33
> rawhide 30 k
>
> Transaction Summary
>
> ===
> Install  2 Packages
>
> Total download size: 99 k
> Installed size: 238 k
> Is this ok [y/N]: y
> Downloading Packages:
> (1/2): numactl-2.0.12-6.fc33.x86_64.rpm543 kB/s |
> 69 kB 00:00
> (2/2): numactl-libs-2.0.12-6.fc33.x86_64.rpm   207 kB/s |
> 30 kB 00:00
>
> ---
> Total  219 kB/s |
> 99 kB 00:00
> warning:
> /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/numactl-2.0.12-6.fc33.x86_64.rpm:
> Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
> Fedora - Rawhide - Developmental packages for the next Fedora  1.6 MB/s |
> 1.6 kB 00:00
> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
> (0x9570FF31) is already installed
> The GPG keys listed for the "Fedora - Rawhide - Developmental packages for
> the next Fedora release" repository are already installed but they are not
> correct for this package.
> Check that the correct key URLs are configured for this repository..
> Failing package is: numactl-2.0.12-6.fc33.x86_64
>  GPG Keys are configured as:
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
> Public key for numactl-libs-2.0.12-6.fc33.x86_64.rpm is not installed.
> Failing package is: numactl-libs-2.0.12-6.fc33.x86_64
>  GPG Keys are configured as:
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: GPG check FAILED
>
>
> I can see the docker.io image has older packages
>
> #  rpm -q fedora-release-container fedora-gpg-keys
> fedora-release-container-33-0.9.noarch
> fedora-gpg-keys-33-0.8.noarch
>
> than the registry.fedoraproject.org image
>
> # rpm -q fedora-release-container fedora-gpg-keys
> fedora-release-container-33-0.13.noarch
> fedora-gpg-keys-33-0.11.noarch
>
> Looking at https://hub.docker.com/_/fedora?tab=tags  I see the rawhide
> image is over a month out of date.
>
> As a workaround I tried adding
>
>  dnf update -y --nogpgcheck fedora-gpg-keys
>
> and this pulls in fedora-gpg-keys-34-0.1.noarch on docker.io images, and
> does nothing on registry.fedoraproject.org images.
>
> Even after the fedora-gpg-keys update, I still get gpg 

Re: fedpkg update: Could not locate column in row for column 'comments.id'"

[Clement Verna]

On Fri, 14 Aug 2020 at 01:08, Adam Williamson 
wrote:

> On Thu, 2020-08-13 at 18:46 -0400, Chris wrote:
> > Hi guys,
> >
> > I'm going through the typical routine of pushing my repository up to EPEL
> > (fc33, fc32, fc31, and epel8)... all goes smoothly until this command:
> >
> > fedpkg update --type enhancement
> >
> > I get the following returned:
> > Could not execute update: Could not generate update request: Unable to
> > create update.  "Could not locate column in row for column 'comments.id
> '"
> > A copy of the filled in template is saved as bodhi.template.last
>
> I think it's a bug in Bodhi on the server end since we deployed 5.5
> recently. It's also happening on `bodhi updates download`, which I
> filed: https://github.com/fedora-infra/bodhi/issues/4105
> For me it happens about one in every six times.
>

I am away from home this weekend so can't do much but I ll try to
investigate what is happening. I ll be using the following ticket to post
updates

https://pagure.io/fedora-infrastructure/issue/9234


> I've been poking through the commit log but haven't identified a clear-
> cut suspect yet...
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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: Tech debt analysis tool

[Clement Verna]

On Thu, 16 Jul 2020 at 17:14, Michal Konecny  wrote:

> Hi James,
>
> I'm using the LGTM tool on Anitya and I'm pretty happy with it. It scans
> both javascript and python code.
>


We are also using LGTM on Bodhi and I am also pretty happy with it. It
currently runs on every PRs and add some comments about the new "code
smells" found in the PR, it is also possible to have a global view of the
project https://lgtm.com/projects/g/fedora-infra/bodhi/



>
> Didn't tried the other two.
>
> Michal
>
> On 16/07/2020 15:31, James Richardson wrote:
>
> Hi All,
>
> Vipul and I are looking into several different tools that will allow us to
> better analyze our tech debt with any new code that is merged into apps in
> http://github.com/fedora-infra.
>
> Currently, we have looked at the tools below, but we would love any and
> all input from the team and community on this.
>
> SonarCloud
> LGTM
> ShiftLeft
>
> Our goal is to find an open source tool that is easy to integrate as well
> as providing useful and timely feedback.
> So far, SonarCloud has proved to be the one that looks best, but again, we
> are very open to any and all suggestions, and at this early stage, a good
> conversation to arrive at the best solution.
>
> Regards,
>
> James
>
>
> --
>
> James Richardson
>
> Engineering Intern
>
> He | Him | His
>
> Red Hat Waterford 
>
> Communications House
>
> Cork Road, Waterford City
>
> jamri...@redhat.com 
> M: +353851970521 <+353877545162> IM: jamricha
> @redhatjobs    redhatjobs
>  @redhatjobs
> 
> 
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org
>
>
> --
> Role: Fedora CPE Team - Software Engineer
> IRC: mkonecny
> FAS: zlopez
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Re: What is our technical debt?

[Clement Verna]

On Tue, 7 Jul 2020 at 02:28, Ken Dreyer  wrote:

> On Wed, Jul 1, 2020 at 12:57 PM Stephen John Smoogen 
> wrote:
> >
> > On Wed, 1 Jul 2020 at 14:46, Miroslav Suchý  wrote:
> > >
> > > Dne 30. 06. 20 v 9:44 Pierre-Yves Chibon napsal(a):
> > > > What are you talking about here? The Fedora release process? The
> mass-branching
> > > > in dist-git?
> > >
> > > This. And creating new gpg keys, new mock configs, new tags in Koji,
> add release to retrace.f.o, Copr, ... I have a
> > > dream where you just bump up number in - let say - PDC and everything
> else will happen automagically. At right time.
> > >
> >
> > I think choosing the one tool which is so end of life to do it in.. is
> > a sign of why we can't do this. Every release some set of tools in
> > Fedora get added by some team who have been working on their own
> > schedules and their own API without any idea of any other teams
> > working on.
> > We then have to do a lot of integration and make it work
> > before the release deadline to make it work. Then usually after 1 or 2
> > releases that software team is no longer in existence and we have to
> > continue with it waiting for the promised replacement which will do
> > all those things you list above.. but instead get some other tool
> > which has to be shoved in.
>
> This is an excellent summary of the problem over the past couple of years.
>
> I think one of the problems with PDC was that so many teams had to
> adapt all their *giant* tools to it, and this integration effort was
> unsustainable when we have natural contributor turnover. Everything
> ended up tightly coupled together so that it was really difficult to
> remain agile as tools and business requirements (naturally) changed.
> Also we never drew the line and wrote a list of things that PDC was
> *not* going to do, so the Second Syndrome effect just kept growing
> until it collapsed.
>
> Instead of having everything having to talk to PDC to determine its
> configuration, I'm approaching this problem from the other end -
> making Ansible talk to all the services according to each service's
> API. Here are some things I like about this approach:
>
> 1. Ansible is really simple and well-documented.
>
> 2. It's easy to start small and get value incrementally.
>
> 3. The playbooks can (and do) change independently from the APIs. This
>kind of agility is essential because SOPs must be able to change over
>time.
>
> 4. If we haven't completely implemented something in Ansible yet, the
>service itself is not completely broken. The workaround does not
>require multiple teams of developers (like with PDC). The workaround
>is that the administrator simply does the thing they used to do
>manually (and file tickets for the missing RFEs in the Ansible modules)
>
> For the koji-ansible project, we're using it to configure some large
> products internally. Now we have to expand this concept to the rest of
> the pipeline (Bodhi, Pungi configuration, etc.)
>
> Clement started on https://github.com/cverna/bodhi-ansible but I think
> that's abandoned at this point.


Yeah this was more of a proof of concept, but I think it would be
interesting to continue working on it. Being able to manage the bodhi
releases (create, update status, update tags, etc ..) in Ansible would be
quite cool. We also have an example of playbook that is using koji-ansible
[0], I only played with it in staging before the data center move but it
would be cool to actually use this playbook when we branch F33.


[0] -
https://pagure.io/fedora-infra/ansible/blob/master/f/playbooks/manual/releng/koji-release-tags.yml


> I do think this is the way to go,
> though. In some ways this is the point - it should be possible for
> these Ansible modules to be isolated so that when contributor turnover
> happens, the whole system does not fall apart.
>

> - Ken
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Re: What is our technical debt?

[Clement Verna]

On Thu, 25 Jun 2020 at 21:35, Pierre-Yves Chibon 
wrote:

> Good Morning Everyone,
>
> Just like every team we have technical debt in our work.
> I would like your help to try to define what it is for us.
>
> So far, I've come up with the following:
> - python3 support/migration
> - fedora-messaging
> - fedora-messaging schema
> - documentation
> - (unit-)tests
> - OpenID Connect
>
> What else would we want in there?
>

In my opinion the biggest struggle we have is too many code bases and we
don't have the time or interest to make sure that they are all in good
shape. I think that even if we were to spend the next 3 months just
focusing on paying back that debt (updating documentation, dependencies,
tests etc ) we would come back to our current situation in 1 year or so
because we just can't keep up.
In my opinion it would be really good to spend some time looking at all the
applications interactions and look at opportunities to reduce these
interactions and consolidate features in fewer applications. (this is
something that I started when looking at PDC and I still think that ideally
we should try to not replace PDC but enhance existing services to provide
the features we need.)
If anyone can draw a diagram of all the services we have and how they
interact with each other I would be super interested to see that and I
think that would be a great start to look at reducing our technical debt.


>
>
> Looking forward to your thoughts,
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Schedule for Wednesday's FESCo Meeting (2020-07-01)

[Clement Verna]

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-07-01 14:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

F33 System-Wide Change: CMake to do out-of-source builds
https://pagure.io/fesco/issue/2411
APPROVED (+7, 2, -0)

F33 Self-Contained Change: Distribute .repo files for modular repositories
from a separate package
https://pagure.io/fesco/issue/2412
APPROVED (+8, 0, -0)

F33 Self-Contained Change: Default animated background for Fedora
Workstation
https://pagure.io/fesco/issue/2413
APPROVED (+8, 0, -0)

F33 Self-Contained Change: LXQt 0.15.0
https://pagure.io/fesco/issue/2414
APPROVED (+8, 0, -0)

Request to be a provenpackager sponsor/administrator (churchyard)
https://pagure.io/fesco/issue/2404
APPROVED (+6, 0, -0)

= Followups =

#topic #2390 Request to permit module default streams in ELN
https://pagure.io/fesco/issue/2390

#topic #2407 Find a new meeting time slot
https://pagure.io/fesco/issue/2407

= New business =

#topic #2416 Update 3rd party repo policy
https://pagure.io/fesco/issue/2416

#topic #2418 Formalize updated policies for what spins can change without
asking (and what can be changed with FESCo clearance)
https://pagure.io/fesco/issue/2418

#topic #2419 F33 System-Wide Change: LLVM 11
https://pagure.io/fesco/issue/2419

#topic #2420 F33 System-Wide Change: Use %make_build and %make_install
macros
https://pagure.io/fesco/issue/2420

#topic #2421 F33 System-Wide Change: Zanata removal
https://pagure.io/fesco/issue/2421

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
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-minimal container and registry negative feedback

[Clement Verna]

On Mon, 29 Jun 2020 at 16:55, Dridi Boukelmoune 
wrote:

> > The blank pages are flatpaks. We are using the same registry for
> containers and flatpaks and the upstream project[0] used for registry.fp.o
> does not support flatpaks so the page is just blank.
>
> That can't be right, fedora-minimal is a docker/an OCI image, isn't it?
>

The tag page for fedora-minimal seems to be working
https://registry.fedoraproject.org/repo/fedora-minimal/tags/. Do you have a
link of the page that is blank ?


>
> > There has not been much interest in improving registry.fp.o since we
> looked at moving stuff to quay.io.
>
> Noted, being warned of known gotchas would be nice regardless of where
> the images are hosted.
>
> Dridi
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-minimal container and registry negative feedback

[Clement Verna]

On Mon, 29 Jun 2020 at 12:59, Dridi Boukelmoune 
wrote:

> > > microdnf reinstall tzdata
> >
> > There's a bug about this to split out the UTC tzdata into a minimal
> > tzdata so terrible hacks aren't needed to slim things down.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1722233
>
> I'll CC myself to this bug but it doesn't look like anything will happen
> soon.
>
> > > By comparison dockerhub, from which I used to pull fedora images
> > > before moving to fedora-minimal has a nice landing page [3] and
> > > maybe it's also failing to document pitfalls but so far the base image
> > > never surprised me.
> >
> > Anything that's particularly stripped back will always be a compromise
> > of size vs functionality, if the stacked image did what you already
> > needed why change?
>
> I needed to deploy more services on a very constrained box, and this has
> given me enough headroom not to worry for a while. Compromise is fine,
> but finding out through trial is needlessly tedious. Unless of course
> I missed the red tape with "here be dragons", in which case it would have
> been totally on me and that's where I think Fedora's container registry
> could be improved.
>
> I'm wondering whether container pages went blank because something
> went missing during the recent data center move.
>

The blank pages are flatpaks. We are using the same registry for containers
and flatpaks and the upstream project[0] used for registry.fp.o does not
support flatpaks so the page is just blank.

There has not been much interest in improving registry.fp.o since we looked
at moving stuff to quay.io.

[0] - https://github.com/genuinetools/reg

>
> Dridi
> ___
> 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: Bodhi 5.4.0 in production

[Clement Verna]

On Tue, 23 Jun 2020 at 12:32, Vít Ondruch  wrote:

>
> Dne 23. 06. 20 v 9:23 Hans de Goede napsal(a):
> > Hi,
> >
> > On 6/22/20 9:53 AM, Clement Verna wrote:
> >> Hi all,
> >>
> >> I have just deployed Bodhi 5.4.0
> >> (https://github.com/fedora-infra/bodhi/releases) in production. We
> >> were running 5.2.2 so that deployment brings the improvement and bug
> >> fixes from 5.3.0 and 5.4.0 (see release notes)
> >>
> >> One high level feature worth noting :
> >>
> >> * you can now associate BZ tickets to the automatically created
> >> rawhide updates. The bugs mentioned with the format "fix(es)|close(s)
> >> (fedora|epel|rh|rhbz)#BUG_ID"  in the changelog will be associated to
> >> the update and automatically closed.
>
>
> It should also support "Resolves":
>
>
>
> https://github.com/fedora-infra/bodhi/commit/f2f8413ffcb749fff512f226b0bcee9182a969be
>
>
> >> More info
> >>
> https://github.com/fedora-infra/bodhi/blob/develop/docs/user/automatic_updates.rst#associate-bugs-to-automatic-updates
> >
> > I tried using this:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-21cac06005
> >
> > And the bug got associated with the update in bodhi, but the bug
> > did not get closed when the update hit stable ?
>
>
> It does not appear to work:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-08b74be230
>
> The update is not referenced in BZ as the F32 update:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-5dd98b41e7
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1849708#c2


Yeah this is similar to Fabio's case and having a ":"  in the string.


>
>
>
> Vít
>
>
> >
> > Regards,
> >
> > Hans
> > ___
> > 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
>
___
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: Bodhi 5.4.0 in production

[Clement Verna]

On Tue, 23 Jun 2020 at 12:11, Fabio Valentini  wrote:

> On Mon, Jun 22, 2020 at 9:58 AM Clement Verna 
> wrote:
> >
> > Hi all,
> >
> > I have just deployed Bodhi 5.4.0 (
> https://github.com/fedora-infra/bodhi/releases) in production. We were
> running 5.2.2 so that deployment brings the improvement and bug fixes from
> 5.3.0 and 5.4.0 (see release notes)
> >
> > One high level feature worth noting :
> >
> > * you can now associate BZ tickets to the automatically created rawhide
> updates. The bugs mentioned with the format "fix(es)|close(s)
> (fedora|epel|rh|rhbz)#BUG_ID"  in the changelog will be associated to the
> update and automatically closed.
> > More info
> https://github.com/fedora-infra/bodhi/blob/develop/docs/user/automatic_updates.rst#associate-bugs-to-automatic-updates
>
> Uh well, I managed to screw this up at my first try. I guess the regex
> used to detect this doesn't like the ":" in there (which is what most
> projects use for automations like this?) ...
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-0523158a04


Yeah that is not supported (the ":") in the default regex expression if you
look at the documentation you have examples [0]. Supporting that case
should not be too hard tho, we just need to update the config with the
right regex :-)

[0] -
https://github.com/fedora-infra/bodhi/blob/develop/docs/user/automatic_updates.rst#associate-bugs-to-automatic-updates

>
>
> Fabio
>
> > Also there were no changes on the client side.
> >
> > Thanks all
> > Clément
> > ___
> > 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
>
___
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: Bodhi 5.4.0 in production

[Clement Verna]

On Tue, 23 Jun 2020 at 09:24, Hans de Goede  wrote:

> Hi,
>
> On 6/22/20 9:53 AM, Clement Verna wrote:
> > Hi all,
> >
> > I have just deployed Bodhi 5.4.0 (
> https://github.com/fedora-infra/bodhi/releases) in production. We were
> running 5.2.2 so that deployment brings the improvement and bug fixes from
> 5.3.0 and 5.4.0 (see release notes)
> >
> > One high level feature worth noting :
> >
> > * you can now associate BZ tickets to the automatically created rawhide
> updates. The bugs mentioned with the format "fix(es)|close(s)
> (fedora|epel|rh|rhbz)#BUG_ID"  in the changelog will be associated to the
> update and automatically closed.
> > More info
> https://github.com/fedora-infra/bodhi/blob/develop/docs/user/automatic_updates.rst#associate-bugs-to-automatic-updates
>
> I tried using this:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-21cac06005
>
> And the bug got associated with the update in bodhi, but the bug
> did not get closed when the update hit stable ?
>

Hum yeah the closing of bugs is actually done during the daily push for
normal releases, this does not happen for rawhide so that needs to be
integrated in the rawhide workflow. I have opened
https://github.com/fedora-infra/bodhi/issues/4067


>
> Regards,
>
> Hans
>
>
___
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

Bodhi 5.4.0 in production

[Clement Verna]

Hi all,

I have just deployed Bodhi 5.4.0 (
https://github.com/fedora-infra/bodhi/releases) in production. We were
running 5.2.2 so that deployment brings the improvement and bug fixes from
5.3.0 and 5.4.0 (see release notes)

One high level feature worth noting :

* you can now associate BZ tickets to the automatically created rawhide
updates. The bugs mentioned with the format "fix(es)|close(s)
(fedora|epel|rh|rhbz)#BUG_ID"  in the changelog will be associated to the
update and automatically closed.
More info
https://github.com/fedora-infra/bodhi/blob/develop/docs/user/automatic_updates.rst#associate-bugs-to-automatic-updates

Also there were no changes on the client side.

Thanks all
Clément
___
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: Update ejected from the push

[Clement Verna]

On Thu, 18 Jun 2020 at 18:35, Kevin Fenzi  wrote:

> On Thu, Jun 18, 2020 at 07:55:21AM +0200, Alexander Ploumistos wrote:
> > These updates, along with a couple of others I submitted 12h ago, just
> > appeared in my local mirror. Bodhi still shows everything as
> > transitioning from pending to testing and I never got a notification
> > about them having moved to testing. Side effect from the data center
> > move?
>
> Well, yes and no?
>
> The 2 updates you mentioned at the top of the thread were fixed to go in
> the next updates push:
> https://pagure.io/releng/issue/9532#comment-658452
>
> Updates pushes are at 00:14 UTC each day.
>
> So, they went out with those pushes and now have synced to your local
> mirror. :)
>
> The underlying sidetag issues are being worked on.
> I'm not 100% sure of the status...
>

I have deployed bodhi 5.4.0 (https://github.com/fedora-infra/bodhi/releases)
in production today. That should fix the issue with sidetags for normal
releases :-)


>
> kevin
> ___
> 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: Day one of the datacenter service migration

[Clement Verna]

On Tue, 9 Jun 2020 at 16:29, Charalampos Stratakis 
wrote:
 ... snip

>
>
> The elections app seems to be broken for me though, so I can't vote at
> this point.
>

This is now fixed so you should be able to vote :-).


>
> --
> Regards,
>
> Charalampos Stratakis
> Software Engineer
> Python Maintenance Team, Red Hat
> ___
> 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: The future of loopabull

[Clement Verna]

On Mon, 1 Jun 2020 at 15:37, Pierre-Yves Chibon  wrote:

> On Fri, May 29, 2020 at 03:18:58PM +0200, Clement Verna wrote:
> >On Thu, 28 May 2020 at 14:27, Pierre-Yves Chibon <[1]
> pin...@pingoured.fr>
> >wrote:
> >
> >  Good Morning Everyone,
> >
> >  I know this question has already been raised a few times, but I
> think we
> >  should
> >  raise it once more: what do we see as future for loopabull?
> >
> >  It is currently triggered on 4 topics (3 from prod and 1 from stg)
> to do
> >  basically
> >  three actions:
> >  - Flag commit successfully built in koji, in other words it adds
> these
> >  flags
> >to dist-git:
> >
> >  [2]
> https://src.fedoraproject.org/rpms/mingw-filesystem/c/717f2a929bd25b62a0427e8e5c3792a0939dbfce
> >  - Flag when the Fedora CI start testing a PR
> >  - Flag when the Fedora CI finished testing a PR (and thus reports
> >  Pass/Fail)
> >
> >  Upstream released yesterday a 0.0.7 release which brings supports
> for
> >  fedora-messaging (contributed by your servitor).
> >  Looking at the code, it should be python3 compatible, but it
> doesn't say
> >  specifically in the setup.py and I honestly don't remember if I've
> >  tested that
> >  or not.
> >  The package has been orphaned in Fedora for over 10 months and has
> thus
> >  been
> >  retired.
> >
> >  I've had a chat with upstream yesterday and they are still
> interested in
> >  the
> >  project but more as a pet project and their time is just like the
> rest
> >  of us,
> >  limited for pet projects these days.
> >  That being said the code base is really quite small and involves
> >  technologies
> >  we're already using in other places (python-pika, celery, rabbitmq,
> >  ansible...)
> >  so there isn't really anything new there.
> >
> >  One of its limitation currently is with secrets, how to pass/specify
> >  them.
> >  This is something we could circumvent via ansible-vault or so, but
> it
> >  needs a
> >  little investigation.
> >
> >  I basically see three ways forward with this:
> >  - We continue with loopabull and we need to check its python3
> support,
> >  how to
> >deal with secrets, if we can get it to run in openshift & so on.
> >  - We look for something else, similar. The requirements being:
> >- Run a task when seeing a message in our message bus
> >- Handle secrets
> >- Scalable up/down
> >- Runnable in openshift is a bonus
> >- Preferably in a language we can debug (python++, potentially
> rust)
> >  - We write something that fits our needs and requirements
> >
> >There is a PR[0] in fedora-messaging to add a 'run' callback that
> would
> >let you execute any command, I think that might be a nice solution
> and I
> >think it would meet most of the requirements.
> >
> >[0] - [3]https://github.com/fedora-infra/fedora-messaging/pull/163
>
> Isn't that the equivalent of having us write a custom fedora-messaging
> consumer
> for each task we want to automate?
>

Yes but without all the boilerplate needed for each consumer.


> In a way I like this, it's simple(r), really straight forward, constraint
> and
> self-contained. There is no risk that a previous task prevents a following
> one
> to be executed.
> On the other hand it also means that if we move to, say fed-messaging, in
> the
> future, we will have to convert more consumers.
>

> If that's a trade off we're willing to live with, then I'm ok with it as
> well.
>

I don't have a strong opinion here :-)


>
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Orphaning python-tgext-crud

[Clement Verna]

Hi all,

I have just orphaned python-tgext-crud[0], as far as I can tell this
package is not a dependency of any other package.

$ sudo repoquery --whatdepends python3-tgext-crud

There are currently 2 open bz for it [1]

[0] - https://src.fedoraproject.org/rpms/python-tgext-crud
[1] -
https://bugzilla.redhat.com/buglist.cgi?component=python-tgext-crud_id=11106453=Fedora

Thanks
___
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: The future of loopabull

[Clement Verna]

On Thu, 28 May 2020 at 14:27, Pierre-Yves Chibon 
wrote:

> Good Morning Everyone,
>
> I know this question has already been raised a few times, but I think we
> should
> raise it once more: what do we see as future for loopabull?
>
> It is currently triggered on 4 topics (3 from prod and 1 from stg) to do
> basically
> three actions:
> - Flag commit successfully built in koji, in other words it adds these
> flags
>   to dist-git:
>
> https://src.fedoraproject.org/rpms/mingw-filesystem/c/717f2a929bd25b62a0427e8e5c3792a0939dbfce
> - Flag when the Fedora CI start testing a PR
> - Flag when the Fedora CI finished testing a PR (and thus reports
> Pass/Fail)
>
> Upstream released yesterday a 0.0.7 release which brings supports for
> fedora-messaging (contributed by your servitor).
> Looking at the code, it should be python3 compatible, but it doesn't say
> specifically in the setup.py and I honestly don't remember if I've tested
> that
> or not.
> The package has been orphaned in Fedora for over 10 months and has thus
> been
> retired.
>
> I've had a chat with upstream yesterday and they are still interested in
> the
> project but more as a pet project and their time is just like the rest of
> us,
> limited for pet projects these days.
> That being said the code base is really quite small and involves
> technologies
> we're already using in other places (python-pika, celery, rabbitmq,
> ansible...)
> so there isn't really anything new there.
>
> One of its limitation currently is with secrets, how to pass/specify them.
> This is something we could circumvent via ansible-vault or so, but it
> needs a
> little investigation.
>
> I basically see three ways forward with this:
> - We continue with loopabull and we need to check its python3 support, how
> to
>   deal with secrets, if we can get it to run in openshift & so on.
> - We look for something else, similar. The requirements being:
>   - Run a task when seeing a message in our message bus
>   - Handle secrets
>   - Scalable up/down
>   - Runnable in openshift is a bonus
>   - Preferably in a language we can debug (python++, potentially rust)
> - We write something that fits our needs and requirements
>

There is a PR[0] in fedora-messaging to add a 'run' callback that would let
you execute any command, I think that might be a nice solution and I think
it would meet most of the requirements.

[0] - https://github.com/fedora-infra/fedora-messaging/pull/163

>
>
> Would you know something that fits our requirements and that we could just
> run?
> If not, do you have a preferred way between options #1 and #3?
>
>
> Thanks for your thoughts,
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Re: IAD2 datacenter testing/application validation

[Clement Verna]

On Wed, 27 May 2020 at 11:57, Pierre-Yves Chibon 
wrote:

> On Wed, May 27, 2020 at 10:29:20AM +0200, Clement Verna wrote:
> >On Wed, 27 May 2020 at 09:42, Michal Konecny <[1]mkone...@redhat.com>
> >wrote:
> >
> >  I don't see the-new-hotness anywhere. Will it be deployed together
> with
> >  Anitya?
> >
> >I think these 2 apps were in the Minimal Viable Fedora infra so they
> will
> >be deployed but in the second phase when all the hardware is
> available in
> >IAD2.
>
> Were or were not (in the Minimal Viable Fedora)? :)
>

I guess "were not" but I can't be 100% sure about that :P

>
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Re: IAD2 datacenter testing/application validation

[Clement Verna]

On Wed, 27 May 2020 at 09:42, Michal Konecny  wrote:

> I don't see the-new-hotness anywhere. Will it be deployed together with
> Anitya?
>

I think these 2 apps were in the Minimal Viable Fedora infra so they will
be deployed but in the second phase when all the hardware is available in
IAD2.


>
> Michal
>
> On 27/05/2020 00:22, Kevin Fenzi wrote:
>
> Greetings everyone.
>
> We now have most things deployed in our new datacenter (IAD2).
>
> Accordingly, I would like to get some testing and validation started.
>
> Please see the following document:
> https://hackmd.io/op6N_nIaR7aMzw9Ib-sDAQ
>
> Please feel free to ask questions here and add/check off services that
> appear to be running as expected. Application owners (people in
> sysadmin-whatever groups) should check that they have the expected level
> of access as before, that their playbooks run (idempotently!) and the
> logs and any interfaces show the application appears to be running fine.
>
> We have this week and next to get everything in good shape for migration
> week (20202-06-08) when we will moving everything out of phx2.
>
> Thanks for any help. :)
>
> kevin
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org
>
>
> --
> Role: Fedora CPE Team - Software Engineer
> IRC: mkonecny
> FAS: zlopez
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Re: Help needed with Fedora Python Classroom Lab container image

[Clement Verna]

On Wed, 27 May 2020 at 10:09, Miro Hrončok  wrote:

> On 27. 05. 20 9:12, Clement Verna wrote:
> >
> >
> > On Wed, 27 May 2020 at 01:23, Miro Hrončok  > <mailto:mhron...@redhat.com>> wrote:
> >
> > Hello.
> >
> > There is a docker/podman container image part of the Fedora Python
> Classroom
> > Lab:
> >
> > https://labs.fedoraproject.org/en/python-classroom
> >
> > I need help with two main issues:
> >
> >
> > 1) The container doesn't built for Fedora 32:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=45001647
> >
> > But I get an error I don't understand (dnf exited with error, but I
> see no
> > error
> > message).
> >
> >
> > I have built it in rawhide [0][1] and f32 [2][3]
>
> Thank you! Should we bump the rawhide version so it is higher, or it
> doesn't matter?
>

It does not really mater, the release is automatically bumped by OSBS so it
depends of the order of the builds. But in the end it will be available as
registry.fp.o/f33/python-classroom:latest or
registry.fp.o/f32/python-classroom:latest


>
> > 2) I don't know how to get the previous images (namely Fedora 31)
> from the
> > registry. Apparently they have all ever just been in the candidate
> registry and
> > they have been all deleted... ?
> >
> > https://pagure.io/releng/issue/9473
> >
> > An actual user asked about the missing images, hence I don't want to
> stop
> > producing them, OTOH I clearly have no idea what am I doing. If
> somebody is
> > interested in participating, this would be really appreciated. If
> not, I think
> > we should remove the thing from Python Classroom's website.
> >
> >
> > I am happy to help here, I have given myself the commit permission on
> src.fp.o
> > so that I could create the update in bodhi.
>
> Thanks. When the update is pushed to stable, the image will be in the
> regular
> registry?
>

Yes


>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Help needed with Fedora Python Classroom Lab container image

[Clement Verna]

On Wed, 27 May 2020 at 01:23, Miro Hrončok  wrote:

> Hello.
>
> There is a docker/podman container image part of the Fedora Python
> Classroom Lab:
>
>https://labs.fedoraproject.org/en/python-classroom
>
> I need help with two main issues:
>
>
> 1) The container doesn't built for Fedora 32:
>
>https://koji.fedoraproject.org/koji/taskinfo?taskID=45001647
>
> But I get an error I don't understand (dnf exited with error, but I see no
> error
> message).
>

I have built it in rawhide [0][1] and f32 [2][3]


>
>
> 2) I don't know how to get the previous images (namely Fedora 31) from the
> registry. Apparently they have all ever just been in the candidate
> registry and
> they have been all deleted... ?
>
>https://pagure.io/releng/issue/9473
>
> An actual user asked about the missing images, hence I don't want to stop
> producing them, OTOH I clearly have no idea what am I doing. If somebody
> is
> interested in participating, this would be really appreciated. If not, I
> think
> we should remove the thing from Python Classroom's website.
>

I am happy to help here, I have given myself the commit permission on
src.fp.o so that I could create the update in bodhi.


[0] - https://koji.fedoraproject.org/koji/buildinfo?buildID=1516686
[1] -
https://bodhi.fedoraproject.org/updates/FEDORA-CONTAINER-2020-0beba9bad3

[2] - https://koji.fedoraproject.org/koji/buildinfo?buildID=1516687
[3] -
https://bodhi.fedoraproject.org/updates/FEDORA-CONTAINER-2020-1acaf7ced0


>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Re: Help needed with Fedora Python Classroom Lab container image

[Clement Verna]

On Wed, 27 May 2020 at 01:23, Miro Hrončok  wrote:

> Hello.
>
> There is a docker/podman container image part of the Fedora Python
> Classroom Lab:
>
>https://labs.fedoraproject.org/en/python-classroom
>
> I need help with two main issues:
>
>
> 1) The container doesn't built for Fedora 32:
>
>https://koji.fedoraproject.org/koji/taskinfo?taskID=45001647
>
> But I get an error I don't understand (dnf exited with error, but I see no
> error
> message).
>

I have built it in rawhide [0][1] and f32 [2][3]


>
>
> 2) I don't know how to get the previous images (namely Fedora 31) from the
> registry. Apparently they have all ever just been in the candidate
> registry and
> they have been all deleted... ?
>
>https://pagure.io/releng/issue/9473
>
> An actual user asked about the missing images, hence I don't want to stop
> producing them, OTOH I clearly have no idea what am I doing. If somebody
> is
> interested in participating, this would be really appreciated. If not, I
> think
> we should remove the thing from Python Classroom's website.
>

I am happy to help here, I have given myself the commit permission on
src.fp.o so that I could create the update in bodhi.


[0] - https://koji.fedoraproject.org/koji/buildinfo?buildID=1516686
[1] -
https://bodhi.fedoraproject.org/updates/FEDORA-CONTAINER-2020-0beba9bad3

[2] - https://koji.fedoraproject.org/koji/buildinfo?buildID=1516687
[3] -
https://bodhi.fedoraproject.org/updates/FEDORA-CONTAINER-2020-1acaf7ced0


>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> python-devel mailing list -- python-de...@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/python-de...@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: Help needed with Fedora Python Classroom Lab container image

[Clement Verna]

On Wed, 27 May 2020 at 02:28, Adam Williamson 
wrote:

> On Wed, 2020-05-27 at 01:20 +0200, Miro Hrončok wrote:
> > Hello.
> >
> > There is a docker/podman container image part of the Fedora Python
> Classroom Lab:
> >
> >https://labs.fedoraproject.org/en/python-classroom
> >
> > I need help with two main issues:
> >
> >
> > 1) The container doesn't built for Fedora 32:
> >
> >https://koji.fedoraproject.org/koji/taskinfo?taskID=45001647
> >
> > But I get an error I don't understand (dnf exited with error, but I see
> no error
> > message).
>
> Errors seem to be in x86_64.log:
>
> 2020-05-26 09:59:39,727 - atomic_reactor.util - DEBUG - Step 6/11 : RUN
> dnf -y --setopt=install_weak_deps=false --disablerepo rawhide-modular
>  install "@python-classroom" nano openssh-clients vim-enhanced wget man
>  && dnf clean all
> 2020-05-26 09:59:40,900 - atomic_reactor.util - DEBUG - ---> Running in
> 75ba910cc4cc
> 2020-05-26 09:59:42,917 - atomic_reactor.util - DEBUG -  [91mNo repository
> match: rawhide-modular
> 2020-05-26 09:59:42,917 - atomic_reactor.util - DEBUG -  [0m
> 2020-05-26 09:59:43,110 - atomic_reactor.util - DEBUG -
> atomic-reactor-koji-plugin-f32-container-candid 4.1 kB/s | 413  B 00:00
> 2020-05-26 09:59:43,289 - atomic_reactor.util - DEBUG - Fedora 32 openh264
> (From Cisco) - x86_64 34 kB/s | 5.1 kB 00:00
> 2020-05-26 09:59:43,542 - atomic_reactor.util - DEBUG - Fedora Modular 32
> - x86_64   20 MB/s | 4.9 MB 00:00
> 2020-05-26 09:59:44,455 - atomic_reactor.util - DEBUG - Fedora Modular 32
> - x86_64 - Updates6.4 MB/s | 1.6 MB 00:00
> 2020-05-26 10:03:19,281 - atomic_reactor.util - DEBUG - Fedora 32 - x86_64
> - Updates0.0  B/s |   0  B 03:34
> 2020-05-26 10:03:19,282 - atomic_reactor.util - DEBUG -  [91mErrors during
> downloading metadata for repository 'updates':
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirrors.dotsrc.org/fedora-buffet/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirrors.dotsrc.org port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> https://mirror.lzu.edu.cn/fedora/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirror.lzu.edu.cn port 443: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirrors.ircam.fr/pub/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirrors.ircam.fr port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://fedora.cu.be/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to fedora.cu.be port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirror.math.princeton.edu/pub/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirror.math.princeton.edu port 80: Connection
> refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirror.metrocast.net/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirror.metrocast.net port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirrors.chroot.ro/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirrors.chroot.ro port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirror.init7.net/fedora/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirror.init7.net port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://download-ib01.fedoraproject.org/pub/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to download-ib01.fedoraproject.org port 80: Connection
> refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> https://pubmirror1.math.uh.edu/fedora-buffet/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to pubmirror1.math.uh.edu port 443: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> https://fedora.mirror.liteserver.nl/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to fedora.mirror.liteserver.nl port 443: Connection
> refused]
> 2020-05-26 10:03:19,283 - 

Re: Help needed with Fedora Python Classroom Lab container image

[Clement Verna]

On Wed, 27 May 2020 at 02:28, Adam Williamson 
wrote:

> On Wed, 2020-05-27 at 01:20 +0200, Miro Hrončok wrote:
> > Hello.
> >
> > There is a docker/podman container image part of the Fedora Python
> Classroom Lab:
> >
> >https://labs.fedoraproject.org/en/python-classroom
> >
> > I need help with two main issues:
> >
> >
> > 1) The container doesn't built for Fedora 32:
> >
> >https://koji.fedoraproject.org/koji/taskinfo?taskID=45001647
> >
> > But I get an error I don't understand (dnf exited with error, but I see
> no error
> > message).
>
> Errors seem to be in x86_64.log:
>
> 2020-05-26 09:59:39,727 - atomic_reactor.util - DEBUG - Step 6/11 : RUN
> dnf -y --setopt=install_weak_deps=false --disablerepo rawhide-modular
>  install "@python-classroom" nano openssh-clients vim-enhanced wget man
>  && dnf clean all
> 2020-05-26 09:59:40,900 - atomic_reactor.util - DEBUG - ---> Running in
> 75ba910cc4cc
> 2020-05-26 09:59:42,917 - atomic_reactor.util - DEBUG -  [91mNo repository
> match: rawhide-modular
> 2020-05-26 09:59:42,917 - atomic_reactor.util - DEBUG -  [0m
> 2020-05-26 09:59:43,110 - atomic_reactor.util - DEBUG -
> atomic-reactor-koji-plugin-f32-container-candid 4.1 kB/s | 413  B 00:00
> 2020-05-26 09:59:43,289 - atomic_reactor.util - DEBUG - Fedora 32 openh264
> (From Cisco) - x86_64 34 kB/s | 5.1 kB 00:00
> 2020-05-26 09:59:43,542 - atomic_reactor.util - DEBUG - Fedora Modular 32
> - x86_64   20 MB/s | 4.9 MB 00:00
> 2020-05-26 09:59:44,455 - atomic_reactor.util - DEBUG - Fedora Modular 32
> - x86_64 - Updates6.4 MB/s | 1.6 MB 00:00
> 2020-05-26 10:03:19,281 - atomic_reactor.util - DEBUG - Fedora 32 - x86_64
> - Updates0.0  B/s |   0  B 03:34
> 2020-05-26 10:03:19,282 - atomic_reactor.util - DEBUG -  [91mErrors during
> downloading metadata for repository 'updates':
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirrors.dotsrc.org/fedora-buffet/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirrors.dotsrc.org port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> https://mirror.lzu.edu.cn/fedora/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirror.lzu.edu.cn port 443: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirrors.ircam.fr/pub/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirrors.ircam.fr port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://fedora.cu.be/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to fedora.cu.be port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirror.math.princeton.edu/pub/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirror.math.princeton.edu port 80: Connection
> refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirror.metrocast.net/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirror.metrocast.net port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirrors.chroot.ro/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirrors.chroot.ro port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://mirror.init7.net/fedora/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to mirror.init7.net port 80: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> http://download-ib01.fedoraproject.org/pub/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to download-ib01.fedoraproject.org port 80: Connection
> refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> https://pubmirror1.math.uh.edu/fedora-buffet/fedora/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to pubmirror1.math.uh.edu port 443: Connection refused]
> 2020-05-26 10:03:19,283 - atomic_reactor.util - DEBUG - - Curl error (7):
> Couldn't connect to server for
> https://fedora.mirror.liteserver.nl/linux/updates/32/Everything/x86_64/repodata/repomd.xml
> [Failed to connect to fedora.mirror.liteserver.nl port 443: Connection
> refused]
> 2020-05-26 10:03:19,283 - 

Re: wrong info on apps.fedoraproject.org

[Clement Verna]

On Fri, 22 May 2020 at 08:38, Jos de Kloe  wrote:

> Something seems wrong in: https://apps.fedoraproject.org/packages/pyproj
> The header text and upstream point to pyproject-rpm-macros in stead of
> pyproj.
> Does anybody know how to fix this?
>

That application has been in a bad shape for a while now, we have a few
people that started working on a replacement which I hope we will be able
to deploy after the data center move has been completed.

Hope that helps :-)


>
> Jos
> ___
> 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: ansible-review is run on pull requests

[Clement Verna]

On Thu, 14 May 2020 at 19:52, Nils Philippsen  wrote:

> Hi everybody,
>
> since a couple of hours, ansible-review is run on changes submitted
> through pull requests in our Ansible repository on Pagure.
>
> This means: when someone submits a PR to the ansible repo or pushes
> changes into its source branch, a Zuul job is started which, when
> finished, reports whether or not ansible-review finds problems in
> changed playbooks/roles/... as a detailed comment (linking to test
> results) and as a flag in the side bar (see [1] as an example).
>
> Currently this is merely informational, i.e. if the Zuul job hasn't yet
> finished or fails, this won't stop reviewers from merging the change
> into the repository regardless. On the other hand, because we've set up
> ansible-review to just process the changes submitted in the PR, this
> takes relatively little time (think about 2 minutes from push to the
> report coming in), so it should come in early enough unless you're in a
> real rush. ;)
>
> I'd like to thank Pingou, who did the preliminary work and structure
> and especially Fabien Boucher who debugged the trouble we initially had
> with our deployed version of Zuul[2] and contributed a workaround[3,4].
>

This is really cool, thanks to everyone involved 


>
> Ciao,
> Nils
>
> [1]: https://pagure.io/fedora-infra/ansible/pull-request/62
> [2]: https://pagure.io/fedora-infra/ansible/pull-request/54
> [3]: https://pagure.io/fedora-infra/ansible/pull-request/60
> [4]: https://pagure.io/fedora-zuul-jobs/pull-request/60
> --
> Nils Philippsen"Those who would give up Essential Liberty to
> Software Engineer   purchase a little Temporary Safety, deserve neither
> Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
> PGP fingerprint:  D0C1 1576 CDA6 5B6E BBAE  95B2 7D53 7FCA E9F6 395D
> old:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-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/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-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/infrastructure@lists.fedoraproject.org

Re: CPE Weekly: 2020-05-11

[Clement Verna]

On Mon, 11 May 2020 at 12:55, Clement Verna 
wrote:

>
>
> On Mon, 11 May 2020 at 11:03, Fabio Valentini 
> wrote:
>
>> On Mon, May 11, 2020 at 10:42 AM Aoife Moloney 
>> wrote:
>> > ## GitForge Updates
>> > * We are tracking our progress here (nothing new added yet, fyi)
>> > https://fedoraproject.org/wiki/Git_forge_update
>> > * And the council are tracking the community issues in this ticket
>> > https://pagure.io/Fedora-Council/tickets/issue/292
>> > * I have an  Office hours IRC meeting slot on #fedora-meeting-1 @
>> > 1400-1500 UTC every Thursday. Feel free to stop by and say hi! We can
>> > talk about Gitforge, or not :)
>>
>> I'm wondering, is actually anything happening here?
>>
>
> Yes, I am still gathering the "pain points". I am going to open a ticket
> in the GitLab tracker (http://gitlab.com/gitlab-org/gitlab) this week, so
> that all the discussions about what we are asking will be public.
>

Hey so we now have a public issue[0] with GitLab that we are going to use
to drive the conversation. So if you are interested I highly encourage you
to follow that issue. Also this is currently focusing on the very basic
features of dist-git in purpose once we have a better idea on how these
features looks like in GitLab, we will be able to take a look at the rest
of our needs.

Hope that helps

PS: If there is anything that you feel should be mentioned in the ticket,
please feel free to tell me about it so that I can look at editing the
ticket.

[0] - https://gitlab.com/gitlab-org/gitlab/-/issues/217350


>
>
>> The "progress" being tracked in the wiki has been "nothing yet" since
>> the wiki page was announced a few weekly reports ago, and the linked
>> council ticket has not been updated in 2-3 weeks either :/
>>
>
>> Fabio
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
___
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: CPE Weekly: 2020-05-11

[Clement Verna]

On Mon, 11 May 2020 at 11:03, Fabio Valentini  wrote:

> On Mon, May 11, 2020 at 10:42 AM Aoife Moloney 
> wrote:
> > ## GitForge Updates
> > * We are tracking our progress here (nothing new added yet, fyi)
> > https://fedoraproject.org/wiki/Git_forge_update
> > * And the council are tracking the community issues in this ticket
> > https://pagure.io/Fedora-Council/tickets/issue/292
> > * I have an  Office hours IRC meeting slot on #fedora-meeting-1 @
> > 1400-1500 UTC every Thursday. Feel free to stop by and say hi! We can
> > talk about Gitforge, or not :)
>
> I'm wondering, is actually anything happening here?
>

Yes, I am still gathering the "pain points". I am going to open a ticket in
the GitLab tracker (http://gitlab.com/gitlab-org/gitlab) this week, so that
all the discussions about what we are asking will be public.


> The "progress" being tracked in the wiki has been "nothing yet" since
> the wiki page was announced a few weekly reports ago, and the linked
> council ticket has not been updated in 2-3 weeks either :/
>

> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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: CPE WEeekly: 2020-05-02

[Clement Verna]

On Sun, 3 May 2020 at 21:42, clime  wrote:

> On Sun, 3 May 2020 at 19:42, Aoife Moloney  wrote:
> >
> > # CPE Weekly: 2020-05-02
> > ---
> > title: CPE Weekly status email
> > tags: CPE Weekly, email
> > ---
> >
> >
> >
> >
> > Background:
> > The Community Platform Engineering group is the Red Hat team combining
> > IT and release engineering from Fedora and CentOS.Check out our teams
> > info here https://docs.fedoraproject.org/en-US/cpe/
> >
> >
> > ## GitForge Updates
> > * We are tracking our progress here (nothing new added yet, fyi)
> > https://fedoraproject.org/wiki/Git_forge_update
> > *  We are still doing a technical deep-dive with our own team on what
> > we need from GitLab and will have a technical plan developed and
> > publically available in the coming weeks - thanks again for your
> > patience, this will take some time to map out.
>
> Hello,
>
> what about using hackmd.io to track the progress of the plan in an
> open manner where people can contribute?
>

The plan will be tracked in the Fedora wiki using the Change Request
template, everyone is more than welcome to contribute and provide comment
and I expect many iteration on that change proposal :-)


>
> I expected a restart of the git forge process because of the first one
> not being open and community-inclusive.
>
> Thank you
> clime
>
> > * Fedora have also released a blog post
> >
> https://communityblog.fedoraproject.org/fedora-council-and-the-git-forge/and
> > * And the council are tracking the community issues in this ticket
> > https://pagure.io/Fedora-Council/tickets/issue/292
> > * We are looking at ways to engage closer with the community too so I
> > will have an *optional* office hours slot on #fedora-meeting @
> > 1400-1500 UTC every Thursday. Feel free to stop by and say hi! We can
> > talk about Gitforge, or not :)
> >
> >
> > ## Releases!!
> > * F32 released! Congrats to all those who helped make this such an
> > awesome release :)
> > * Lenovo are releasing Fedora as a standard desktop offering!
> > * CentOS 7.8.2003 was released for x86_64, aarch64,ppc64, ppc64le and
> > armhfp architectures, including Cloud images (on
> > https://cloud.centos.org)!
> >
> >
> >
> >
> >
> > ### Data Centre Move
> > * Communishift is still out, est back online 11th May.
> > * Full amended schedule will be published week ending 8th May to
> > hackmd & will be sent to the devel & infra lists.
> > * Connectivity is now in place in IAD2 and should be in place in
> > RDU-CC over the weekend.
> > * In particular, a HUGE shout out to Stephen Smoogen who has been
> > working all the hours in every day for the last few weeks/months to
> > get this phase of the move operatoinal for the Fedora infrastructure -
> > we would not be able to do this without you Smooge :)
> > * This is literally a two man team of Kevin Fenzi and Stephen Smoogen,
> > who are carrying the weight of this infrastructure on their shoulders
> > and are invaluable to the success of this multi-team and multi-month
> > project, so thank you both.
> > * Given the pressures on the Infra folks, a general ask for patience
> > if your ticket / request / ping takes a little bit longer to reply to
> >
> >
> >
> > ### AAA Replacement
> > * The team will work with openSUSE to deploy FreeIPA + Noggin to
> > deploy it in their infra before we do!
> > * This is really exciting and the team are looking forward to seeing
> > how the solution works in another infrastructure!
> > * You can view the teams current, completed and backlog work here
> > https://github.com/orgs/fedora-infra/projects/6
> >
> >
> >
> > ### Sustaining Team
> > * The team are using this dashboard to track their work
> > https://github.com/fedora-infra/mbbox/projects/1
> >
> > * Mbbox Upgrade
> > * Zuul CI set up is done
> > * Koji-hub TLS support added to CR
> > * Set up ReadTheDocs documentation - webhook missing for automatic
> build
> > * Identity container for testing
> > * Koji-builder CRD PR rebase - SSL authentication with koji-hub
> > * Refactor molecule test suite to share tests
> >
> >
> >
> >
> >
> >
> >
> > ## CentOS Updates
> >
> > ### CentOS CI
> > * OpenShift upgrade
> > * OpenStack to OpenNebula migration scripts
> > * Ansible playbooks to manage the creation and bootstrapping of
> > bare metal nodes with RHCOS
> > * Packaging work (fixing dependencies)
> > * Updated ci-user list on efforts we are putting for CI Infrastructure
> >
> > ### CentOS
> > * CentOS 7.8.2003 was released for x86_64, aarch64,ppc64, ppc64le and
> > armhfp architectures. Including Cloud images (on
> > https://cloud.centos.org) -
> > https://blog.centos.org/2020/04/release-centos-linux-7-2003/
> >
> >
> > ### CentOS Stream
> > * Congratulations to Brian Stinson on his excellent session of Ask The
> > Expert, facilitated by Rich Bowen during Red Hat Summit - we hope you
> > caught it, it was really good!
> > * Using CentOS Stream in the CentOS QA group to prep for 8.2
> >
> >
> >
> >
> > As 

Re: Commit access to fedora-cloud / official-images

[Clement Verna]

snip...

>> >> Which repo?
>> > oops, should have added a link
>> > https://github.com/fedora-cloud/official-images/
>> > Thank you for a super fast response Dusty
>>
>> I added Clement to the `fedora-docker-images` group, which has admin access.
>> He will be able to invite you to that same team after accepting the invite.
>>
>> Dusty
>>
Thanks Dusty for helping with that :-)

>
>
>
> -- 
> Vipul Siddharth
> He/His/Him
> Fedora | CentOS CI Infrastructure Team
> Red Hat
> w: vipul.dev
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-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/cloud@lists.fedoraproject.org
>
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-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/cloud@lists.fedoraproject.org

Re: bodhi: stuck updates

[Clement Verna]

On Tue, 28 Apr 2020 at 18:41, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Hi,
>
> Almost a week ago, I built cmpfit and fityk in side tags on F31, F32
> and F33. While the builds for F33 moved directly to stable - as
> expected - the other two got stuck for 4 days. I noticed that I could
> push them manually to testing, which I did a little over two days ago,
> but they seem to be stuck again, transitioning from pending to
> testing. Updates for other packages I built around the same time and
> later are already in testing. These are the updates in question:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-8ee22c621f
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-cc2ae07056
> Some help?
>

Hi,

It looks like Bodhi thinks that the builds were not signed so the update is
not going to be pushed. It looks that there is a bug there since the builds
are correctly tagged in koji.

I will manually fix these update and file a bug upstream so we can look a
fixing this.

Thanks for reporting the problem.


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