Re: Bodhi API does not list f39 in pending releases
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
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
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?
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)
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)
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)
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)
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
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
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
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
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
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
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
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
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
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)
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
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)
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)
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
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
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
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)
.. 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)
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: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)
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)
... 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)
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)
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
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
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
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
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
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
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?
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
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)
= #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)
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)
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)
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)
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)
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)
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)
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)
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: GitLab AMA Topic: Message Bus
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
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)
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
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
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
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
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
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
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
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)
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)
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
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: docker.io/library/fedora:rawhide outdated vs registry.fp.org/fedora:rawhide
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
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'"
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
Schedule for Wednesday's FESCo Meeting (2020-07-01)
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
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
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
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
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
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
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
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
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
Orphaning python-tgext-crud
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: Help needed with Fedora Python Classroom Lab container image
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
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
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
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
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
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: CPE Weekly: 2020-05-11
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
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
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: bodhi: stuck updates
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
Re: Rawhide update from side tag pending for 2 days
On Wed, 8 Apr 2020 at 13:42, Fabio Valentini wrote: > On Wed, Apr 8, 2020 at 11:58 AM Clement Verna > wrote: > > > > > > > > On Wed, 8 Apr 2020 at 11:38, Fabio Valentini > wrote: > >> > >> On Wed, Apr 8, 2020, 11:27 Richard W.M. Jones > wrote: > >>> > >>> On Tue, Apr 07, 2020 at 05:36:44PM -0400, Mohan Boddu wrote: > >>> > On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones > wrote: > >>> > > > >>> > > > >>> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > >>> > > >>> > I guess it should be a fixed in bodhi. But for now you can remove the > >>> > builds that it's complaining about in the update. > >>> > > >>> > https://github.com/fedora-infra/bodhi/issues/3991 > >>> > >>> So it is complaining: > >>> > >>> "This update cannot be pushed to stable. These builds > >>> brltty-6.0-14.fc33, graphviz-2.42.2-10.fc33 have a more recent build > >>> in koji's f33 tag." > >>> > >>> Those builds could just be removed before pushing. But I don't see a > >>> way to remove the builds from the UI. > >>> > >>> (This update took 3 days of work to create so I _really_ do not want > >>> to have to build the whole thing again.) > >> > >> > >> You should be able to run > >> > >> koji untag f3x-build-side-n offending-nvr > >> > >> for every package that's blocking the update. > > > > > > That will not work, since Bodhi does not react on changes from koji the > update will still be stuck in Pending > > > > You need to edit the update and remove these builds. You can click on > the "edit" button on the left side of the update status, then you will have > a list builds with an "x" on the right side of each build. Clicking on that > 'x' will remove the build from the update (see attached screenshot). > > > > Otherwise you can use the bodhi updates edit --removebuilds command, see > man page > https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates > > Nope, that won't work - you can't edit builds for updates that were > created from side tags - neither from the Web UI (no buttons), nor > from the API / CLI ... - they only have the "from_tag" attribute, but > it's currently impossible (as far as I can tell) to "refresh" those > side tag updates :/ That's why I suggested untagging in koji. But if > bodhi doesn't see those changes, that won't work either > Yeah I skipped the fact that the builds were in the side tag, so indeed that needs to be done in koji, then edit the update and refresh the list of builds from the UI. I don't think the CLI supports that currently. > > Fabio > > >> > >> Fabio > >> > >>> > >>> Rich. > >>> > >>> -- > >>> Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > >>> Read my programming and virtualization blog: http://rwmj.wordpress.com > >>> libguestfs lets you edit virtual machines. Supports shell scripting, > >>> bindings from many languages. http://libguestfs.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 > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines:
Re: Rawhide update from side tag pending for 2 days
On Wed, 8 Apr 2020 at 13:15, Richard W.M. Jones wrote: > On Wed, Apr 08, 2020 at 11:57:27AM +0200, Clement Verna wrote: > > >> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > You need to edit the update and remove these builds. You can click on the > > "edit" button on the left side of the update status, then you will have a > > list builds with an "x" on the right side of each build. Clicking on that > > 'x' will remove the build from the update (see attached screenshot). > > I don't appear to have the "x" (nor the box with "Fedora 33"). > Permissions? > Hum ok sorry, so since the builds are in the side tag you indeed need to remove them from the tag as Fabio pointed out (should have read that more carefully). So koji untag f3x-build-side-n offending-nvr Once the builds are not in the tag, you still need to edit the update and refresh the list of builds (There is a refresh/update button next to the name of the side tag in the edit update from). That will fetch the list of builds in the side tag. Better documentation on how to do this is need :( > > > Otherwise you can use the bodhi updates edit --removebuilds command, see > > man page > > https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates > > $ bodhi updates edit --removebuilds > brltty-6.0-14.fc33,graphviz-2.42.2-10.fc33 FEDORA-2020-d120de33c5 > Cannot find release associated with build: alt-ergo-2.0.0-12.fc33, tags: > ['f33-build-side-20855'] > > (By the way that command failed, but still exited with code 0, which > is something that happens quite a lot across our tooling and causes me > endless trouble with automating things because I have to > "screen-scrape" output to find errors.) > Yes we have https://github.com/fedora-infra/bodhi/issues/3868, contributions welcomed :-) > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Rawhide update from side tag pending for 2 days
On Wed, 8 Apr 2020 at 11:29, Richard W.M. Jones wrote: > On Wed, Apr 08, 2020 at 08:53:38AM +0200, Igor Gnatenko wrote: > > I agree, if this would not happen then everything would just blow up. > > Wouldn't the lower NVR builds simply be ignored? > The merging a side tag is not considering NVRs but the date the build was done. Bodhi just checks if a there is a more recent build in the rawhide buildroot, if that is the case it does not try to be too smart about it and let a human find out what is the best thing to do :-). The logic was taken from how releng is merging side tag, the human part of finding out what needs to be done was then I guess done by a release engineer. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Rawhide update from side tag pending for 2 days
On Wed, 8 Apr 2020 at 11:38, Fabio Valentini wrote: > On Wed, Apr 8, 2020, 11:27 Richard W.M. Jones wrote: > >> On Tue, Apr 07, 2020 at 05:36:44PM -0400, Mohan Boddu wrote: >> > On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones >> wrote: >> > > >> > > >> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 >> > >> > I guess it should be a fixed in bodhi. But for now you can remove the >> > builds that it's complaining about in the update. >> > >> > https://github.com/fedora-infra/bodhi/issues/3991 >> >> So it is complaining: >> >> "This update cannot be pushed to stable. These builds >> brltty-6.0-14.fc33, graphviz-2.42.2-10.fc33 have a more recent build >> in koji's f33 tag." >> >> Those builds could just be removed before pushing. But I don't see a >> way to remove the builds from the UI. >> >> (This update took 3 days of work to create so I _really_ do not want >> to have to build the whole thing again.) >> > > You should be able to run > > koji untag f3x-build-side-n offending-nvr > > for every package that's blocking the update. > That will not work, since Bodhi does not react on changes from koji the update will still be stuck in Pending You need to edit the update and remove these builds. You can click on the "edit" button on the left side of the update status, then you will have a list builds with an "x" on the right side of each build. Clicking on that 'x' will remove the build from the update (see attached screenshot). Otherwise you can use the bodhi updates edit --removebuilds command, see man page https://bodhi.fedoraproject.org/docs/user/man_pages/bodhi.html#updates > Fabio > > >> Rich. >> >> -- >> Richard Jones, Virtualization Group, Red Hat >> http://people.redhat.com/~rjones >> Read my programming and virtualization blog: http://rwmj.wordpress.com >> libguestfs lets you edit virtual machines. Supports shell scripting, >> bindings from many languages. http://libguestfs.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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Rawhide update from side tag pending for 2 days
On Tue, 7 Apr 2020 at 23:38, Mohan Boddu wrote: > I guess it should be a fixed in bodhi. But for now you can remove the > builds that it's complaining about in the update. > > https://github.com/fedora-infra/bodhi/issues/3991 Answered in the ticket, but I think Bodhi is behaving correctly there. When trying to merge the side tag, if Bodhi find a more recent build in the target tag it will push back the update to pending and comment on the update that there are more recent builds in the target tag. Then it is up to the packager to resolve the conflict (either rebuild the conflicting packages or remove them from the update). > > On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones > wrote: > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > > > This one is a Rawhide update from a side tag, submitted on Sunday > > morning which has been in pending for 2 days. (As it's Rawhide it's > > supposed to spend 0 days in testing.) Is there any problem with it, > > or do we just have to wait longer? It is blocking builds of other > > packages. > > > > Rich. > > > > -- > > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > > Read my programming and virtualization blog: http://rwmj.wordpress.com > > virt-df lists disk usage of guests without needing to install any > > software inside the virtual machine. Supports Linux and Windows. > > http://people.redhat.com/~rjones/virt-df/ > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Rawhide update from side tag pending for 2 days
On Tue, 7 Apr 2020 at 14:57, Rex Dieter wrote: > Richard W.M. Jones wrote: > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5 > > > > This one is a Rawhide update from a side tag, submitted on Sunday > > morning which has been in pending for 2 days. (As it's Rawhide it's > > supposed to spend 0 days in testing.) Is there any problem with it, > > or do we just have to wait longer? It is blocking builds of other > > packages. > > I saw the same thing, and submitted a infra ticket about it, > https://pagure.io/fedora-infrastructure/issue/8819 So I started to look at that ticket, and Bodhi had a problem creating the pending-signing and pending-testing tags in koji. I have fixed that and now the update was not pushed to stable because there are builds in the side tag conflicting with builds in the f33 buildroot. You need to edit your update to either include a rebuild of these conflicting packages or just remove them from the update. There is an handy comment on the update that tells you which builds are conflicting. > > > -- Rex > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 Git Forge Decision
On Thu, 2 Apr 2020 at 22:33, Adam Williamson wrote: > On Thu, 2020-04-02 at 21:58 +0200, Clement Verna wrote: > > [evolution is still crashing. sigh. such is life. apologies for > formatting, again] > > > > So yeah, let's discount the releng folks first, because releng has > > > existed all along, and - as I said - my original statement was not > about > > > "people who are organizationally in the same team as the people who > work > > > on Fedora app stuff" but "people who work on Fedora app stuff". So > that > > > lets out Mohan and Tomas. > > > > > > > I don't think this is fair at all, Tomas and Mohan are doing a lot of > > development and trying to improve a lot of the tooling around releng > so > > that we move from a manual heavy process to a more automated or at > least > > tool assisted process. If you consider that releng tooling is not > > application work, then please explain to me what is bodhi, > > release-monitoring, anitya, mdapi etc ... It seems to me that these > > services are 100% release engineering focused. > > I think we've more or less beaten this list thing to death and maybe we > don't actually disagree at all (can we say it actually turns out to be > more or less a wash and move on? I am at this point willing to concede > that my impression that the headcount was *higher* before was > mistaken), but I didn't mean "discount them" in the sense of "discount > their contributions", I meant "discount them from the comparison", > because I didn't include the people working in releng two years ago in > the "before" list. We could add the current releng people to the "now" > list and the previous releng people to the "before" list, but what > would be the point, beyond beating this dead horse even harder? :) > > > Here's Vipul's lists: > > > https://github.com/siddharthvipul > > > https://pagure.io/user/siddharthvipul1 > > > > > > he seems to work exclusively on CentOS CI. Okay, Fedora *uses* > CentOS > > > CI, but presumably back in the 2018 timeframe, someone (whether > that's > > > Vipul or someone else) was working on CentOS CI who wasn't included > in > > > my list, because I only listed people working on Fedora stuff. So > this > > > still seems like a wash. > > > > > > > Vipul and I have done extensive work to add the OSBS aarch64 cluster > in > > staging, and it might comes as a surprise but yes we are working as a > team > > and even sometimes pair programing and sharing knowledge. But you > will find > > some of Vipul's contribution on the ansible repo git logs. Also this > work > > is directly coming as a request from the council to support the IOT > > objective, so I think it is fair to count it as "development" work > even if > > this was mostly operation work and deploying a new OpenShift cluster > for > > OSBS, since this time could have been spend on other application if > that > > was asked by the council. > > Same point: I wasn't meaning to dismiss anyone's contributions, only to > try and keep the *comparison* valid, so it's not valid to include > "people working on CentOS CI" in the 'now' list (as they're now > accounted as part of 'CPE') but not include people who were working on > CentOS CI in the "then" list (because they weren't part of 'Fedora > infra'). But please let's just leave this point now? :) > > > Yeah we are even, and we have 2 new persons joining the team next > week with > > a more sysadmin/operation profile because we really need to support > nirik > > and smooge in that area. I think what you are failing to see is that > for > > roughly the same team, there is much more thing to do. The project > keeps > > adding new things, we now have containers, flatpaks, IoT, silverblue, > > CoreOS and this is good thing but it adds more work on the team for > example > > the releng work that was needed 5 years ago has now triple, same > thing on > > the infra side. On the application development, tools and application > have > > to be adapted to take care of these new deliverables. I am pretty > sure you > > know this very well because that must impact you also on the QA side. > > Yeah, you're right, so I'm certainly not "failing to see" that. But I > think we may have lost track of where this discussion got started. Let > me quote myself from right back at the start: > > "At the very least, if we have somehow reached a point where Red Hat is > no longer willin
Re: CPE Git Forge Decision
On Thu, 2 Apr 2020 at 20:49, Adam Williamson wrote: > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote: > > [up front: apologies for any weird formatting in this email, Evolution > is crashing on me like crazy while I try to edit it, so I'm sending it > from Roundcube which I don't normally do] > > > I'm also not entirely sure about Adam Saleh, but he does not have any > > > infra activity I can find since the end of January and lists himself as > > > working for Exponea on Github and his personal blog. > > > > > > > Adam is working in CPE. CPE isn't entirely about Infra, he is working > > on CI > > improvements at the moment alongside some others > > Okay, well, next time I see him I'll mention he might want to update the > Exponea references :P > > But "CPE isn't entirely about Infra" is sort of the point here: my > initial assertion was that there are fewer people working on > *Fedora-relevant app development* than there were before. I'm happy to > accept that there may be more people in the CPE team than there were at > some point in its past, but that's not what I'm actually interested in > here. CI is great (whichever CI you mean, I lose track sometimes :>) but > someone working on CI is not someone working on the Fedora app > infrastructure, or on sourcing/deploying/integrating/maintaining > outsourced replacements for it, which is the actual problem space here. > > > > If I'm missing anyone, please do correct me. > > > > Other developers in our pool right now are: > > - Ryan Lerch > > I mentioned already that Ryan could go in either list or neither - he > was around at both times but I wasn't sure whether to count him as a > developer or not. But he can't count to one list but not the other, as > he's been here all along. :) > > > - Michal Konecny > > - Mohan Boddu > > - Tomas Hrcka > > - Nils Philippsen > > - Vipul Siddharth > > - James Richardson > > > > We additionally have 2 new Ops folks joining us over the next 2 weeks. > > > > Across them, the majority are working on the Fedora aspects (Infra, > > Dev, > > Releng) of the CPE remit. > > So yeah, let's discount the releng folks first, because releng has > existed all along, and - as I said - my original statement was not about > "people who are organizationally in the same team as the people who work > on Fedora app stuff" but "people who work on Fedora app stuff". So that > lets out Mohan and Tomas. > I don't think this is fair at all, Tomas and Mohan are doing a lot of development and trying to improve a lot of the tooling around releng so that we move from a manual heavy process to a more automated or at least tool assisted process. If you consider that releng tooling is not application work, then please explain to me what is bodhi, release-monitoring, anitya, mdapi etc ... It seems to me that these services are 100% release engineering focused. > > As for the others: so, I didn't count Michal at first as I could not > find any infra-related activity for him, but since you included him I > looked closer, and found he's just hiding himself really well - his > github account name, for some inaccountable reason, is "Zlopez", and his > profile doesn't have his real name in it. So I finally got his logs: > > https://github.com/Zlopez > https://pagure.io/user/zlopez > > ...and yeah, there's some infra activity there, so add him to the list. > > Initially I was just looking at Github logs, as all the infra stuff I > could find was hosted there, and Nils' list is: > > https://github.com/nphilipp > > which was busy up to the end of December but looked extremely empty all > of this year, so I figured he'd switched track or role or something and > didn't count him. But now I look closer, it seems what happened is he's > been working almost exclusively on a thing called rpmautospec, which is > hosted on Pagure: > > https://pagure.io/Fedora-Infra/rpmautospec > > so, he's clearly working hard on something, although I'm not sure it's > directly a part of Fedora app/infra stuff - it's an automatic packaging > thingy, it looks like, I'm not sure what it's being used for. In fact, > it seems like pingou and Adam Saleh are doing quite a bit of work on > this thing too, so it's clearly sucking up quite a lot of developer > time. It's also a fairly new project, which seems interesting given that > "we don't have time to maintain all the projects we have already" is the > recurring refrain here. > This is an effort to improve the packager workflow in order to automate the generation of spec file changelogs and release field. Indeed it is a new project but we considered that improving and automating the packager workflow is something worth investing time in and creating new projects. Here's Vipul's lists: > > https://github.com/siddharthvipul > https://pagure.io/user/siddharthvipul1 > > he seems to work exclusively on CentOS CI. Okay, Fedora *uses* CentOS > CI, but presumably back in the 2018 timeframe, someone (whether that's > Vipul or someone
Re: CPE Git Forge Decision
On Wed, 1 Apr 2020 at 14:40, Stephen John Smoogen wrote: > > > On Wed, 1 Apr 2020 at 08:16, Pierre-Yves Chibon > wrote: > >> On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote: >> >There is also an historical taste to write in house applications for >> >things that don't really seems critical to the Fedora Project, for >> example >> >do we really need a custom calendar application ? or election >> application >> >? It seems that every time we have a problem the solution is let's >> write >> >something to solve that problem, instead of trying to find a >> compromise >> >and reuse existing solutions. >> >> Could please stop this? >> >> > This is me also asking this. > > > >> The continuous theme of "we're building things because we like it" is >> unfair to >> all the people who have been involved in the infrastructure at some point >> in the >> past. >> It is assuming that there was no reasons, that they did not do their >> research, >> that they didn't think it through. >> >> The requirements for applications 3 years ago were vastly different from >> what >> they are today. >> If you don't know the historical reasons for an app, there are a number of >> people around who can answer them, but please let's stop assuming things >> which >> are at the end of the day insulting and demotivating for the people who >> were >> involved then and are still now. >> >> This goes for fedocal, for pagure, for anitya. I've seen this question >> come up >> often enough (here and elsewhere): "Why aren't we using libraries.io >> instead of >> anytia?" >> Well, the simple reason is: because libraries.io *did* *not* *exist* >> when anitya >> was created. So maybe we are not the bad ones that didn't do their >> research. >> >> > I am also sick and tired of this. For many years, a central drive for > Fedora Infra was about building the Free and Open Source tools to allow a > community to work together without using closed source tools. This was a > constant requirement of the community to us at the time with wanting > something to 'compete' against Canonical's forge and Canonicals' other > tools. Things have changed but instead of saying "Good job, thanks for all > that work but we have decided to change.", our efforts are brought up > constantly as a bunch of NIH who wasted time and effort. And it doesn't > matter how many times people are reminded that we had reasons and research > for doing this from 2005 to 2015.. it gets thrown in our faces that we > reinvented the wheel when there were clearly better things to spend our > time on. > > Ok fair and thanks for pointing and raising that point. It is also good to share that historical context to people like me that where not around during that time. Again apologies, this was not at all my intention to point fingers at people. What does NIH stands for ? > > > -- > Stephen J Smoogen. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Git Forge Decision
On Wed, 1 Apr 2020 at 14:16, Pierre-Yves Chibon wrote: > On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote: > >There is also an historical taste to write in house applications for > >things that don't really seems critical to the Fedora Project, for > example > >do we really need a custom calendar application ? or election > application > >? It seems that every time we have a problem the solution is let's > write > >something to solve that problem, instead of trying to find a > compromise > >and reuse existing solutions. > > Could please stop this? > > The continuous theme of "we're building things because we like it" is > unfair to > all the people who have been involved in the infrastructure at some point > in the > past. > It is assuming that there was no reasons, that they did not do their > research, > that they didn't think it through. > > The requirements for applications 3 years ago were vastly different from > what > they are today. > If you don't know the historical reasons for an app, there are a number of > people around who can answer them, but please let's stop assuming things > which > are at the end of the day insulting and demotivating for the people who > were > involved then and are still now. > > This goes for fedocal, for pagure, for anitya. I've seen this question > come up > often enough (here and elsewhere): "Why aren't we using libraries.io > instead of > anytia?" > Well, the simple reason is: because libraries.io *did* *not* *exist* when > anitya > was created. So maybe we are not the bad ones that didn't do their > research. > > > I am not saying that we can't re-evaluate these decision and see if they > still > make sense, but please, please, can we stop assuming the worst? > > I apologize if that came down that way but this is exactly what I was trying to say at the end of my email (see below since it was cut here) . I am 100% sure that decision taken in the past were the best decision at that time and I am honestly not in position to judge or to say anything about it. " Finally, I would like to make clear that I am not blaming anyone, and that decisions made in the past, I am sure were taken with the best intentions. But I think it is also important to recognize that it is legitimate to question these decisions today as something that made sense 10 years ago or 5 years ago might not make sense in today's context. " > > >Now when the CPE team goes and ask for more people because we struggle > >with current situation, I can only guess that these non critical > >applications are mentioned. If I was putting my own money to sponsor a > >team to help building a Linux distribution I would be asking why do we > >have to develop a calendar application or why do we need a custom git > >forge. > > Here as well, what you believe CPE is meant to be is immensely different > than > what the Fedora Infrastructure (Fedora Engineering) team was just a few > years > ago. > So asking these questions and taking this angle may make sense with the new > vision but you would have a much different picture if you were looking at > them > from the old vision, or the one before that, or the next one. > > Let's be aware that Fedora Infra's job hasn't been "Building a linux > distro" > since it's inception, for a long time its goal was much closer to > "building and > supporting the *community* that builds the linux distro". > If you use this mission statement, you can a much different look at badges, > elections or calendaring. > Yeah again agree with that, and I think this is what I was trying to say by mentioning that we should look at these with today's context in mind. Again sorry if I failed to express that point clearly. > > > > Piere > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 Git Forge Decision
On Wed, 1 Apr 2020 at 09:47, Panu Matilainen wrote: > On 3/31/20 8:44 PM, Adam Williamson wrote: > > > I understand there are practical resource considerations and so on > > here, but I still think this merits more high level and serious > > consideration. At the very least, if we have somehow reached a point > > where Red Hat is no longer willing to provide sufficient resources to > > run Fedora on the lines the Fedora community wants it to be run, we > > need to recognize that this is a significant problem that needs to be > > properly aired and discussed and resolved. In this context I'll note > > that the apparent significant headcount reduction of RH people working > > on Fedora infrastructure over the last few years is in itself a > > worrying trend, particularly if you consider it while reading Clement's > > email. > > This. > I don't think this is correct, at least not in CPE, the team has grown over the past year and every person leaving the team has been replaced (even by 2 persons in some cases). The problem in my opinion is that a lot of the people that have setup and written the original services and applications are gone, taking with them most of the knowledge about How, What and Why something was done this way. That leaves people in the team now with a big amount of legacy applications to take care of and not much clue of what is going on. There is also an historical taste to write in house applications for things that don't really seems critical to the Fedora Project, for example do we really need a custom calendar application ? or election application ? It seems that every time we have a problem the solution is let's write something to solve that problem, instead of trying to find a compromise and reuse existing solutions. Now when the CPE team goes and ask for more people because we struggle with current situation, I can only guess that these non critical applications are mentioned. If I was putting my own money to sponsor a team to help building a Linux distribution I would be asking why do we have to develop a calendar application or why do we need a custom git forge. I personally find really great that the different use cases and requirements for the use of Pagure were gathered and I am convinced that people working on this did their very best to find a use case to justify the investment needed in Pagure but it seems that we don't have such a thing. I also appreciate that as a community developing our own solutions is something important and something that seems to matter a lot, but we have to realize that the development and maintenance effort cannot be carried out by the CPE team any more. Maybe this is a opportunity to create a SIG or a working group for people that are interested to carry on this effort. Finally, I would like to make clear that I am not blaming anyone, and that decisions made in the past, I am sure were taken with the best intentions. But I think it is also important to recognize that it is legitimate to question these decisions today as something that made sense 10 years ago or 5 years ago might not make sense in today's context. Disclaimer: I actually have very little insight on how the CPE team budget and headcount is defined, I can only image that if this was my own money this is the type of conversation I would have. Within the team, I think there is a general agreement that we are running and developing to many applications and the effort to slim down that footprint lead us naturally to services that appeared less critical (fedocal, election, etc ..) or easier to replace (Pagure). > > As a user, I wont be shedding a single tear for GitLab over Pagure, BUT. > > There's something very wrong with the picture here, and this forge > business seems more like an abscess that finally burst rather than the > disease itself. I really do not envy being in CPE's pants in this > situation. > > If the problem is lack of funding for Fedora infastructure, shouldn't we > talking about that (finding additional sponsors or something) instead of > which limb to saw off to ensure enough blood for the remaining organs? > > - Panu - > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: CPE Git Forge Decision
On Wed, 1 Apr 2020 at 09:34, Julen Landa Alustiza wrote: > > > 20/4/1 08:42(e)an, Clement Verna igorleak idatzi zuen: > > > > > > On Tue, 31 Mar 2020 at 22:41, Robbie Harwood > <mailto:rharw...@redhat.com>> wrote: > > > > Clement Verna > <mailto:cve...@fedoraproject.org>> writes: > > > > > Neal Gompa mailto:ngomp...@gmail.com>> wrote: > > >> Clement Verna > <mailto:cve...@fedoraproject.org>> wrote: > > >> > > >> As for Pagure itself, I think this is where we fundamentally > > >> disagree. I think it behooves us to own and provide an experience > > >> tailored for our community from beginning to end. That's why we > have > > >> Koji, Bodhi, Dist-Git, and many other tools in that part of the > > >> lifecycle. The packager experience is literally the lifeblood of > the > > >> project, and our contributors are the core of what makes Fedora > > >> successful. Pagure gives us an opportunity to do right by them > that I > > >> *really* don't think we can do with any alternatives. > > > > > > I am not convinced that having a custom git forge is mandatory to > > > provide an great experience to the community. I wasn't really > around > > > the community before Pagure, but I as far as I understand it the > > > experience was better before Pagure and people were able to do more > > > self servicing. I believe that there is an alternative to having > the > > > packager workflow tightly coupled to the git forge, this is also > maybe > > > a good opportunity to rethink some of that workflow and explore > > > different solutions. > > > > Well, this continues to conflate "git forge" and "solution for > > dist-git". > > > > > > Yeah sorry I was not very clear, communication is hard and communication > > via email is awfully hard. Personally I do not think that git hosting is > > a problem. In today's world it is very easy to find solution to host a > > project on a git forge and there are plenty of solution available. Also > > I think it is important to note that the plan is to keep pagure.io > > <http://pagure.io> running as long as there are people willing to do the > > maintenance and based on that thread I don't think that will be a > problem. > > > > > > > > Before pagure, we had a (no-webui) git serving dist-git with other > > services (e.g., pkgdb) stapled on. More self-servicing was possible > > because it was a more mature project. In my opinion, the move to > pagure > > happened prematurely due to lack of feature parity - a problem we're > > still dealing with today, which I think is what your "self > servicing" is > > in reference to. > > > > > > Before pagure, we also had fedorahosted, which was our solution for > > hosting projects, combining trac and a few other things. Migration > was > > *painful*, and there have been many rocky parts along the way, but > the > > experience now is definitely better than fedorahosted. It's far less > > pleasant than a github project, though. > > > > My impression is that most folks on this thread are more worried > about > > dist-git and its integrations than a general git forge, while it > feels > > like all CPE wants to talk about is the git forge. You can't just > use a > > git forge as a dist-git: it takes a lot of integration work, which is > > invisible because right now it's been done and just works™. The > refusal > > to consider that this work exists in the decision worries me . > > > > > > I think this feeling comes from the mixing of git forge and dist-git use > > case that you have pointed out. In CPE there is awareness of the amount > > of work needed for migrating dist-git and all the integration you are > > mentioning. My personal opinion is that this will not be a small or easy > > project but I still think that this is worth it on the long term. I also > > agree with what Kevin Fenzi said earlier in this thread that we should > > take the time to rethink that integration layer around dist-git and > > minimize the dependencies to the git hosting solution, so that git > > hosting would simply be git hosting and it would not really matter if > > this was done by Pagure, GitLab, or any other solution. > > I agree with you that
Re: CPE Git Forge Decision
On Tue, 31 Mar 2020 at 22:41, Robbie Harwood wrote: > Clement Verna writes: > > > Neal Gompa wrote: > >> Clement Verna wrote: > >> > >> As for Pagure itself, I think this is where we fundamentally > >> disagree. I think it behooves us to own and provide an experience > >> tailored for our community from beginning to end. That's why we have > >> Koji, Bodhi, Dist-Git, and many other tools in that part of the > >> lifecycle. The packager experience is literally the lifeblood of the > >> project, and our contributors are the core of what makes Fedora > >> successful. Pagure gives us an opportunity to do right by them that I > >> *really* don't think we can do with any alternatives. > > > > I am not convinced that having a custom git forge is mandatory to > > provide an great experience to the community. I wasn't really around > > the community before Pagure, but I as far as I understand it the > > experience was better before Pagure and people were able to do more > > self servicing. I believe that there is an alternative to having the > > packager workflow tightly coupled to the git forge, this is also maybe > > a good opportunity to rethink some of that workflow and explore > > different solutions. > > Well, this continues to conflate "git forge" and "solution for > dist-git". > Yeah sorry I was not very clear, communication is hard and communication via email is awfully hard. Personally I do not think that git hosting is a problem. In today's world it is very easy to find solution to host a project on a git forge and there are plenty of solution available. Also I think it is important to note that the plan is to keep pagure.io running as long as there are people willing to do the maintenance and based on that thread I don't think that will be a problem. > > Before pagure, we had a (no-webui) git serving dist-git with other > services (e.g., pkgdb) stapled on. More self-servicing was possible > because it was a more mature project. In my opinion, the move to pagure > happened prematurely due to lack of feature parity - a problem we're > still dealing with today, which I think is what your "self servicing" is > in reference to. > > Before pagure, we also had fedorahosted, which was our solution for > hosting projects, combining trac and a few other things. Migration was > *painful*, and there have been many rocky parts along the way, but the > experience now is definitely better than fedorahosted. It's far less > pleasant than a github project, though. > > My impression is that most folks on this thread are more worried about > dist-git and its integrations than a general git forge, while it feels > like all CPE wants to talk about is the git forge. You can't just use a > git forge as a dist-git: it takes a lot of integration work, which is > invisible because right now it's been done and just works™. The refusal > to consider that this work exists in the decision worries me . > I think this feeling comes from the mixing of git forge and dist-git use case that you have pointed out. In CPE there is awareness of the amount of work needed for migrating dist-git and all the integration you are mentioning. My personal opinion is that this will not be a small or easy project but I still think that this is worth it on the long term. I also agree with what Kevin Fenzi said earlier in this thread that we should take the time to rethink that integration layer around dist-git and minimize the dependencies to the git hosting solution, so that git hosting would simply be git hosting and it would not really matter if this was done by Pagure, GitLab, or any other solution. > > So long as it's open and we host it, I don't personally care what we > choose - as long as we can actually use it. > > Thanks, > --Robbie > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Git Forge Decision
On Tue, 31 Mar 2020 at 20:04, Adam Williamson wrote: > On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote: > > On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote: > > > I'm sorry, but I have to agree with Kevin and Michael here to a > > > significant extent. Running our own project on open source code has > > > always been a very big bright line for Fedora. > > > > You don't have to be sorry! I think it's very clear that this is the > general > > community view. > > > > > I think Iñaki's take on the "oh, you contribute to Github projects so > > > no problem right?" angle is correct. > > > > Let me be sorry, though. That wasn't mean to be a "oh you..." statement. > It > > was that other open source projects are not held to this standard, not to > > "gotcha" Michael or anyone else for their contributions elsewhere. > > I mean, held by who? This is a standard we have (more or less) held > ourselves to. Which, if you think about it, means it's a standard > that's in our DNA: we're a group of people who *thought it was > important enough to hold ourselves to that standard*. Would it be > hypocritical for someone outside of Fedora who happily uses software > from other projects that are hosted on Github or whatever to criticize > us if we were to do this? Sure, it would be. But this here is not that, > it's us holding ourselves to our own standards. > > Speaking personally, sure, I contribute to Github-hosted projects. I > maintain one project on Github (because it's extremely adjacent to > another project that's hosted on Github and the maintainers of that > project asked me to have it there, so I did). Hell, I send in fixes for > entirely proprietary things sometimes...because my overriding itch is, > if something is there, at least it had better *work* properly. But I > certainly would not consider hosting work that's a fundamental part of > Fedora on a proprietary system, I've always seen that as a *complete* > non-starter - whether we were considering test automation, result > tracking, event organization, anything like that, the very first rule > has always been, if it's not open source it's just not on the list at > all. And as far as I've noticed, that has been the same for all other > core Fedora stuff, for many years. > To add some nuance to stat statement a quite big chunk of the Fedora Infra apps are hosted on GitHub (https://github.com/fedora-infra), and relatively critical things like Bodhi, FAS, mirrormanager, . As far as I know most of Fedora CoreOS (and Silverblue ?) is also on GitHub. A critical part of our infrastructure the NFS shared storage also run an proprietary software (NetApp). > > So, is it a high standard? Sure. Is it one many other projects don't > try to meet? Sure. But it's one that, as I see it, we have held for a > long time and that in itself creates a context and an expectation that > we can't just dismiss and say "oh, hey, about that? yeah, that doesn't > matter any more." > -- > 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: CPE Git Forge Decision
On Tue, 31 Mar 2020 at 14:57, Neal Gompa wrote: > On Tue, Mar 31, 2020 at 7:10 AM Clement Verna > wrote: > > > > I just want to give a bit of insight from someone who is working day to > day on Fedora's infrastructure, since I believe that might help give a bit > more empathy towards the Why of this decision. > > > > For me the Fedora's Infrastructure is in a very bad shape there is a > fair load of technical debt and trying to change or improve anything > results in a long list of reason why we can do it because services X > depends on service Y which depends on Z. Since I joined the CPE team > (little bit more than 2 years ago) we have not been able to make any kind > of significant progress towards fighting this technical debt. Every year we > fill a white board with what needs to be done : > > > > Python 3 apps migration, > > FAS replacement, > > fedmsg retirement, > > FMN replacement, > > Fedora-packages replacement, > > PDC replacement, > > Porting application to OIDC, > > Improve Releng automation, > > Improving Anitya and the-new-hotness, > > . > > > > Every single year the same items are coming back because we spend most > of our time firefighting services to keep users happy and keep Fedora > release schedule. This has a very demoralizing effect on the people working > in the team, it seems like we will never be able to make any significant > improvement, and our day to day job is to close couple tickets and you keep > watching the pile of tickets growing. There is no feeling of accomplishment > and a general sentiment that whatever we do, it will suck. > > > > A little over a year ago we have expressed our need to drop > applications, this is something we have to do to be able to stay sane and > keep a sustainable life-work balance. From that effort to handover > applications (Elections, Nuancier, Fedocal, Badges) to another group of > people in the community, not much happened mainly because of GDPR and the > legal responsibility of owning such applications, but as far as I know we > don't do much maintenance work on these applications any more since we now > have a few volunteers that are looking after them or helping with finding > an alternative solution. > > > > Now on the list of application we develop and run, I think Pagure is > logical candidate to try and find an alternative to it, but before doing > this it was important to make sure we captured all the use case and feature > needed from a git forge and see if any of these justified spending cycles > in development and maintenance work. My understanding of the decision is > that Pagure does not provide any significant advantage over GitLab. I know > that for many, the fact that Pagure is developed by Fedora is an advantage, > but from my perspective as someone that as to deal with all the other > services in Fedora's Infra this is a major disadvantage. > > > > Overall I think it is important to keep in mind that there is a lot of > work happening behind the scene to provide the people in the Fedora > community a good experience contributing to Fedora. I think we are doing a > good job at it, but that takes us an enormous effort and over the long term > this is not sustainable, also keeping in mind that we keep adding and want > to keep adding new things to Fedora. > > > > I hope that my perspective helps a little. > > > > Clement, > > I want to say thank you for all the hard work you do as a member of > the Fedora community and as a member of the CPE team. You've done > fantastic work for the community and it's always a pleasure to work > with you. And that goes for all the members of the CPE team. I totally > understand where you are coming from. And it *is* very demoralizing to > see the same things over and over again, looking as if you've made no > progress on these things. I've been there with my work at $DAYJOB > before, many times. And as you and others are aware, I've been poking > around throughout infrastructure projects to help with some of these > initiatives over the years, so I'm keenly aware of the size and scope > of many of these. > > However, I think some of this is self-inflicted. I don't want to > entirely rehash my original email with my thoughts on this, so please > read that for more detail[1], but I think we *really* should consider > that the lack of community exposure to to the codebases themselves > (especially as an avenue for contributing to the Fedora Project!) is > an underlying problem here. This has created a persistent cycle of > "community member makes cool project to support Fedora" → "it gets > adopted silently and no one really talks about
Re: CPE Git Forge Decision
On Tue, 31 Mar 2020 at 13:46, Miro Hrončok wrote: > On 31. 03. 20 13:09, Clement Verna wrote: > > On Tue, 31 Mar 2020 at 11:41, Miro Hrončok > <mailto:mhron...@redhat.com>> wrote: > > > > On 31. 03. 20 10:36, Leigh Griffin wrote: > > > I respect that there is disagreement but Gitlab is the choice we > are making. > > > > I always try to assume good intentions, but this is very hard now. I > understand > > this statement as follows: > > > > "After collecting the requirements, we have not discussed the > decision with the > > Fedora community, it was discussed in private. We have decided for > Gitlab and > > only once we have already decided, we have announced our decision to > Fedora. > > Now > > when the people who will be actually using the thing are trying to > participate > > in the discussion, their arguments no longer matter to us, because > the decision > > was already made, whatever you say won't change it, this discussion > is > > pointless." > > > > Am I wrong? > > > > > > I just want to give a bit of insight from someone who is working day to > day on > > Fedora's infrastructure, since I believe that might help give a bit more > empathy > > towards the Why of this decision. > > > > For me the Fedora's Infrastructure is in a very bad shape there is a > fair load > > of technical debt and trying to change or improve anything results in a > long > > list of reason why we can do it because services X depends on service Y > which > > depends on Z. Since I joined the CPE team (little bit more than 2 years > ago) we > > have not been able to make any kind of significant progress towards > fighting > > this technical debt. Every year we fill a white board with what needs to > be done : > > > > * Python 3 apps migration, > > * FAS replacement, > > * fedmsg retirement, > > * FMN replacement, > > * Fedora-packages replacement, > > * PDC replacement, > > * Porting application to OIDC, > > * Improve Releng automation, > > * Improving Anitya and the-new-hotness, > > * . > > > > Every single year the same items are coming back because we spend most > of our > > time firefighting services to keep users happy and keep Fedora release > schedule. > > This has a very demoralizing effect on the people working in the team, > it seems > > like we will never be able to make any significant improvement, and our > day to > > day job is to close couple tickets and you keep watching the pile of > tickets > > growing. There is no feeling of accomplishment and a general sentiment > that > > whatever we do, it will suck. > > > > A little over a year ago we have expressed our need to drop > applications, this > > is something we have to do to be able to stay sane and keep a > sustainable > > life-work balance. From that effort to handover applications (Elections, > > Nuancier, Fedocal, Badges) to another group of people in the community, > not much > > happened mainly because of GDPR and the legal responsibility of owning > such > > applications, but as far as I know we don't do much maintenance work on > these > > applications any more since we now have a few volunteers that are > looking after > > them or helping with finding an alternative solution. > > > > Now on the list of application we develop and run, I think Pagure is > logical > > candidate to try and find an alternative to it, but before doing this it > was > > important to make sure we captured all the use case and feature needed > from a > > git forge and see if any of these justified spending cycles in > development and > > maintenance work. My understanding of the decision is that Pagure does > not > > provide any significant advantage over GitLab. I know that for many, the > fact > > that Pagure is developed by Fedora is an advantage, but from my > perspective as > > someone that as to deal with all the other services in Fedora's Infra > this is a > > major disadvantage. > > > > Overall I think it is important to keep in mind that there is a lot of > work > > happening behind the scene to provide the people in the Fedora community > a good > > experience contributing to Fedora. I think we are doing a good job at > it, but > > that takes us an enormous effort and over the long term this is not > sustainable, > > also keeping in mind that we keep adding and want to keep adding new > things to
Re: CPE Git Forge Decision
On Tue, 31 Mar 2020 at 11:41, Miro Hrončok wrote: > On 31. 03. 20 10:36, Leigh Griffin wrote: > > I respect that there is disagreement but Gitlab is the choice we are > making. > > I always try to assume good intentions, but this is very hard now. I > understand > this statement as follows: > > "After collecting the requirements, we have not discussed the decision > with the > Fedora community, it was discussed in private. We have decided for Gitlab > and > only once we have already decided, we have announced our decision to > Fedora. Now > when the people who will be actually using the thing are trying to > participate > in the discussion, their arguments no longer matter to us, because the > decision > was already made, whatever you say won't change it, this discussion is > pointless." > > Am I wrong? > I just want to give a bit of insight from someone who is working day to day on Fedora's infrastructure, since I believe that might help give a bit more empathy towards the Why of this decision. For me the Fedora's Infrastructure is in a very bad shape there is a fair load of technical debt and trying to change or improve anything results in a long list of reason why we can do it because services X depends on service Y which depends on Z. Since I joined the CPE team (little bit more than 2 years ago) we have not been able to make any kind of significant progress towards fighting this technical debt. Every year we fill a white board with what needs to be done : - Python 3 apps migration, - FAS replacement, - fedmsg retirement, - FMN replacement, - Fedora-packages replacement, - PDC replacement, - Porting application to OIDC, - Improve Releng automation, - Improving Anitya and the-new-hotness, - . Every single year the same items are coming back because we spend most of our time firefighting services to keep users happy and keep Fedora release schedule. This has a very demoralizing effect on the people working in the team, it seems like we will never be able to make any significant improvement, and our day to day job is to close couple tickets and you keep watching the pile of tickets growing. There is no feeling of accomplishment and a general sentiment that whatever we do, it will suck. A little over a year ago we have expressed our need to drop applications, this is something we have to do to be able to stay sane and keep a sustainable life-work balance. From that effort to handover applications (Elections, Nuancier, Fedocal, Badges) to another group of people in the community, not much happened mainly because of GDPR and the legal responsibility of owning such applications, but as far as I know we don't do much maintenance work on these applications any more since we now have a few volunteers that are looking after them or helping with finding an alternative solution. Now on the list of application we develop and run, I think Pagure is logical candidate to try and find an alternative to it, but before doing this it was important to make sure we captured all the use case and feature needed from a git forge and see if any of these justified spending cycles in development and maintenance work. My understanding of the decision is that Pagure does not provide any significant advantage over GitLab. I know that for many, the fact that Pagure is developed by Fedora is an advantage, but from my perspective as someone that as to deal with all the other services in Fedora's Infra this is a major disadvantage. Overall I think it is important to keep in mind that there is a lot of work happening behind the scene to provide the people in the Fedora community a good experience contributing to Fedora. I think we are doing a good job at it, but that takes us an enormous effort and over the long term this is not sustainable, also keeping in mind that we keep adding and want to keep adding new things to Fedora. I hope that my perspective helps a little. > -- > 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
