Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
20/12/3 03:39(e)an, Dusty Mabe igorleak idatzi zuen: I 100% would like to get to a point where we rebase to the latest Fedora major soon after release. As jlebon mentioned earlier this does mean working harder to get ahead of the curve by adopting a rawhide development stream (not exposed to users) and taking more part in the Changes process. Why should we hide coreos rawhide stream? coreos rawhide should have standard rawhide's same exposition level imo. We don't public links on getfedora.org, but we allow anyone to use it just changing your repos, or directly installing it. Why not allow the same behaviour for coreos rawhide allowing to everyone to rebase to it? What's the benefit of hiding it from the public? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 src.fp.o, could we inject a custom message when someone trys to fetch/clone a master branch via pagure-dist-git ? Something like "this branch is deprecated, more info on https://foo.bar; 20/12/11 08:15(e)an, Pierre-Yves Chibon igorleak idatzi zuen: On Thu, Dec 10, 2020 at 10:29:12AM -0800, Kevin Fenzi wrote: On Thu, Dec 10, 2020 at 10:36:36AM +0100, Robert-André Mauchin wrote: On 12/3/20 4:02 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". The Fedora Community strives to be open and welcoming. Some language around our git repositories is dated and could be more inclusive. Many git repositories currently use "master" as the default branch. This Change will move many repositories (see below) to use a "main" branch as default. This small bit of naming adjustment is in-line with Fedora's vision for free and open source software built by inclusive, welcoming, and open-minded communities. How does it work for the enduser? I have thousand of git repos locally with the master branch, will it rename automatically master to main when I git pull or do I need to run a special command? You will need to reclone or run some commands in those existing checkouts. If you have a clone that has 'master' branch and we delete that, and you 'git pull' you will get: Fetching origin Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was fetched. So you will need to do: git checkout main git branch --set-upstream-to=origin/main main Since the main branch will exist on the remote, you may be able to do: git fetch git checkout main and I think the git branch --set-upstream-to is no longer needed then then git pull. I don't think there's anything we can do on the server side to make that easier. Pingou any ideas? Not at the moment > 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: GitRepos-master-to-main (Self-Contained Change)
Good morning, 20/12/9 23:24(e)an, Kevin Fenzi igorleak idatzi zuen: On Wed, Dec 09, 2020 at 08:02:45AM +0100, Julen Landa Alustiza wrote: 20/12/4 20:42(e)an, Kevin Fenzi igorleak idatzi zuen: On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote: On 12/3/20 4:39 PM, Petr Šabata wrote: On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon wrote: On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote: Since I don't see those on the list, does this impact * rpkg (fedpkg)? Wrapper to git, should not be impacted. The only thing I could think of was: when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M main" directly. That being said, I'm not 100% sure when we creating a project on dist-git today we create them empty. Optionally, they can be empty. $ fedpkg request-repo ... --no-initial-commit This could be anoying if someone then pushes as master branch back up, but I guess we can take those on a case by case basis. This change proposal should cover changing pagure-dist-git's rules so that should be impossible. Indeed, we can add that. Indeed we'll need to be able to opt-in to the new naming on some repos while the rest keeps the old one, so we could temporary need to disable the hardcoded rules and rely on upstream protected branches feature or something similar at least during the transition. I'm not sure what you mean here. Someone pushing while we are changing the repos? I thought there were some rpms namespace repos on phase 0, but that's not true, so nevermind. We can just modify dist-git for full rpms namespace :) src.fp.o has strict rules to avoid to push some tags, this transition must keep those stricts rules in place while transitioning imo Yep. And add master. Will update the change. 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: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
Would be great if we add a deprecation notice (wich could include an EOL for the symbolic-ref) to git's output while operating on master branch :D 20/12/3 16:53(e)an, Daniel P. Berrangé igorleak idatzi zuen: On Thu, Dec 03, 2020 at 10:02:34AM -0500, 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". The Fedora Community strives to be open and welcoming. Some language around our git repositories is dated and could be more inclusive. Many git repositories currently use "master" as the default branch. This Change will move many repositories (see below) to use a "main" branch as default. This small bit of naming adjustment is in-line with Fedora's vision for free and open source software built by inclusive, welcoming, and open-minded communities. snip == Upgrade/compatibility impact == Users with old checkouts will need to update their git configuration or re-clone repositories that have changed before they can see any new changes. Is it possible to enhance pagure to support configuring branch symbolic refs when branches are renamed, so clients don't need to update their checkout ? IIUC, it involves running something approximately like this on the server git repo: git symbolic-ref refs/heads/master refs/heads/main Regards, Daniel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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)
20/12/4 20:42(e)an, Kevin Fenzi igorleak idatzi zuen: On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote: On 12/3/20 4:39 PM, Petr Šabata wrote: On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon wrote: On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote: Since I don't see those on the list, does this impact * rpkg (fedpkg)? Wrapper to git, should not be impacted. The only thing I could think of was: when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M main" directly. That being said, I'm not 100% sure when we creating a project on dist-git today we create them empty. Optionally, they can be empty. $ fedpkg request-repo ... --no-initial-commit This could be anoying if someone then pushes as master branch back up, but I guess we can take those on a case by case basis. This change proposal should cover changing pagure-dist-git's rules so that should be impossible. Indeed we'll need to be able to opt-in to the new naming on some repos while the rest keeps the old one, so we could temporary need to disable the hardcoded rules and rely on upstream protected branches feature or something similar at least during the transition. src.fp.o has strict rules to avoid to push some tags, this transition must keep those stricts rules in place while transitioning imo Regards, 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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
20/9/9 05:30(e)an, Tom Seewald igorleak idatzi zuen: > Has anyone compiled a (non-exhaustive) list of known issues that are specific > to KDE Plasma with Wayland? Are there currently any issues that would block > Wayland from becoming the default if they aren't resolved in time for F34? KDE spin is a blocker edition, so its default installation must pass our release criterias. https://fedoraproject.org/wiki/Fedora_Release_Criteria > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- 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
Re: Gitlab Ask Me Anything - Sept 10th, 13:30 UTC
Hi, > > 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. > > Yep, CPE is part of Fedora, but Fedora is not part of CPE, and has its own change decission process. So my statement continues being valid: Fedora did not decide anything, partly because there is no any proposal to change anything yet. -- 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
Re: Gitlab Ask Me Anything - Sept 10th, 13:30 UTC
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. -- 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
Re: CPE Git Forge Decision
20/4/6 12:29(e)an, Leigh Griffin igorleak idatzi zuen: > Around 10 tickets a month is the average I believe for infra to deal > with / handle from direct pings. > Where? https://pagure.io/fedora-infrastructure/issues?status=all=src.fp.o=pagure=0_status= lists 50 tickets for the last year and some of them are not actually pagure issues and some others have attached fixes from the community. -- 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
Re: CPE Git Forge Decision
20/4/3 10:06(e)an, Michal Konecny igorleak idatzi zuen: > > > On 02/04/2020 23:51, Björn Persson wrote: >> Paul Frields wrote: >>> That statement rings hollow for me, when Github is arguably the single >>> biggest vendor of open source in the world, no part of itself is open >>> source, and thanks to its pervasiveness, open source has won the war >>> of how development should work. >> Github shows that *proprietary centralized services* are winning the war >> of how development should work. Gitlab is a smaller, competing, >> proprietary centralized service. >> >> This trend is not in any way unique to software development. Pretty much >> everything is being consolidated into centralized services governed by a >> small number of corporate behemoths. Every new thing is launched as a >> proprietary service that captures the market before anyone has a chance >> to develop a decentralized competitor. Even those decentralized networks >> that have existed since the Internet was young are now degenerating into >> centralized services. The smaller players will continue to be bought by >> bigger competitors until there are only one or two services in the world >> for doing whatever you want to do. > There is plenty of decentralized open source solutions for plenty of > services [0]. Unfortunately not for git forge. > > Michal > > [0] - https://fediverse.party/ But there is an initiative to federate git forges, and they plan to implement it on gitlab. Oh sorry, I meant on pagure :) https://forgefed.peers.community/ Pagure's decentralized PR workflow capabilities are great for this. >> I speak only for myself but it seems to me that concern over this >> ongoing centralization is why people are objecting to moving to Github >> or Gitlab. >> >> Björn Persson >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > -- > Role: Fedora CPE Team - Software Engineer > IRC: mkonecny > FAS: zlopez > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- 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
Re: CPE Git Forge Decision
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 > -- 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
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
20/3/30 13:43(e)an, Leigh Griffin igorleak idatzi zuen: > > > On Mon, Mar 30, 2020 at 12:24 PM Iñaki Ucar <mailto:iu...@fedoraproject.org>> wrote: > > On Mon, 30 Mar 2020 at 13:10, Leigh Griffin <mailto:lgrif...@redhat.com>> wrote: > > > > On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar > mailto:iu...@fedoraproject.org>> wrote: > >> > >> So I was also waiting for those open discussions about the > >> requirements gathered. > > > > We had several threads on them from the Fedora perspective on both > devel and council lists. > > Yet again: threads on requirements gathering, not on the merits of the > final User Story list. > > > A merits based discussion whereby multiple stakeholders have a totally > different view and use case for a Forge is impossible to facilitate. > What is valuable to you and your use case might not be valuable to other > users and vice versa. I'm happy to have a conversation about any > individual requirements but the reality is any that made the list are > valid requirements from a stakeholder perspective and it's not up to me > or anyone to challenge that assertion. As I asked before on this thread, I would like to know how are you planning to fullfill the SLA requirement while the SLE from CPE for the services like AAA that the forge will require to function is lower than the required SLA for the forge itself. > > > That's what several of us were expecting. I > don't think it's too hard too understand. You can say "no, that wasn't > part of the process", but then, sorry, you didn't communicate that > effectively. > > > I'm sorry this is disappointing but even reading the analysis by > Neal it is looking at the merit of the requirement and not looking > at the fact that it is valuable to somebody. Each stakeholder group > had their own means to discuss and debate the merits and had them > rolled into CPE who in turn analysed them and published the full > story list. > > Two things are obvious here: 1) not all the requirements can be met > (you already stated this), and 2) not all requirements have the same > importance. So yes, of course Neal is looking at the merit of every > single requirement, and that's your job too. What if I say that is > valuable to me that the GitHub logo is on top of the interface? Is > that something that should be taken into account just because it's > valuable to somebody? > > > If that came up as a UI requirement then yes we would have taken it on > board, would have documented it and would have presented it in the final > list of unique user stories we gathered. Would it be weighed equally > with a more core functional requirement? The answer is of course no but > we would have respected that request. > > The Fedora specific requirements (as I am on the Fedora lists here) had > very few unique needs such that both Gitlab and Pagure would have > satisfied their desire. Either Forge would have been satisfied the > requirements we received and we ultimately opted for Gitlab based on a > more holistic view of the stakeholder needs. > > > Iñaki > ___ > devel mailing list -- devel@lists.fedoraproject.org > <mailto:devel@lists.fedoraproject.org> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > <mailto:devel-le...@lists.fedoraproject.org> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > -- > > Leigh Griffin > > Engineering Manager > > Red Hat Waterford <https://www.redhat.com/> > > Communications House > > Cork Road, Waterford City > > lgrif...@redhat.com <mailto:lgrif...@redhat.com> > M: +353877545162 IM: lgriffin > > @redhatjobs <https://twitter.com/redhatjobs> redhatjobs > <https://www.facebook.com/redhatjobs> @redhatjobs > <https://instagram.com/redhatjobs> > <https://red.ht/sig> > > > _______ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > http
Re: CPE Git Forge Decision
20/3/30 12:04(e)an, Leigh Griffin igorleak idatzi zuen: > > > On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar <mailto:iu...@fedoraproject.org>> wrote: > > Hi Leigh, > > On Mon, 30 Mar 2020 at 11:30, Leigh Griffin <mailto:lgrif...@redhat.com>> wrote: > > > > Hi everyone, > > > > Thank you for your patience while the CPE Team worked through an > incredible number of requirements from multiple stakeholder sources. > On Friday evening we announced on the Community Blog our decision to > adopt Gitlab as our Git Forge and to retain pagure.io > <http://pagure.io> to ultimately hand over to the Community to > maintain. It wasn't an easy decision by any stretch of the > imagination and we hope that the compromise that we are striking > will help to allow Pagure flourish and to give a choice of Forges > for your usage. I'm happy to field any questions or comments about > this decision. > > My question is, where's the open conversation about the requirements > gathered that you promised in the initial thread? > > > Hey Iñaki, we have had several rounds of open conversation facilitated > via the Council threads on it to arrive on what the requirements were > for the Fedora Project. This ultimately concluded with the formal > requirements received from the Fedora Council which were shaped by the > Community. Do you mean https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/ ? I can't find anything else. Sincelery, after reading the initial announcement, I was expecting a more visible and open to the community discussion scenario. > > For transparency, we have published the full User Story list which is > linked within the blog and for ease of searching is > here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 > > This thread is also part of the open conversation on the decision. No, this is a post decision conversation, not the promised open and live discussions *during* the process. > > > Thanks, > Iñaki > ___ > devel mailing list -- devel@lists.fedoraproject.org > <mailto:devel@lists.fedoraproject.org> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > <mailto:devel-le...@lists.fedoraproject.org> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > -- > > Leigh Griffin > > Engineering Manager > > Red Hat Waterford <https://www.redhat.com/> > > Communications House > > Cork Road, Waterford City > > lgrif...@redhat.com <mailto:lgrif...@redhat.com> > M: +353877545162 IM: lgriffin > > @redhatjobs <https://twitter.com/redhatjobs> redhatjobs > <https://www.facebook.com/redhatjobs> @redhatjobs > <https://instagram.com/redhatjobs> > <https://red.ht/sig> > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- 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
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
20/3/30 11:27(e)an, Iñaki Ucar igorleak idatzi zuen: > On Mon, 30 Mar 2020 at 09:15, Julen Landa Alustiza > wrote: >> >> 20/3/30 08:40(e)an, James Cassell igorleak idatzi zuen: >>> >>> On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote: >>>> On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney wrote: >>>>> >>>>> ### Other Updates >>>>> >>>>> GitForge Decision >>>>> * After evaluating over 300 user stories from multiple stakeholders we >>>>> have aligned on a decision for the Gitforge that CPE will operate for >>>>> the coming years. We are opting for Gitlab for our dist git and >>>>> project hosting and will continue to run pagure.io with community >>>>> assistance. >>>>> * Check out our GitForge decision on the Fedora Community blog >>>>> https://communityblog.fedoraproject.org/ >>>>> * And at the CentOS blog page >>>>> https://blog.centos.org/2020/03/git-forge-decision/ >>>>> * Keep an eye out for mails in the coming months to the devel lists as >>>>> we plan transitions and next steps with GitLab >>>>> * We would like to express our sincere thank you to all who >>>>> contributed requirements to us! >>>>> >>>>> >>>> >>>> I'm going to start with the delivery of this decision sucked. If I >>>> hadn't been alerted to look for this by other folks due to my advocacy >>>> and community building work around Pagure, I would *not* have known >>>> that the decision had been made. This is in contrast to the *big deal* >>>> that was made about starting this "decision process". I don't know if >>> >>> Indeed, it seems like the lead got buried. I, too, had missed the >>> announcement. I guess I'll make more effort to read these weekly status >>> updates. > > I missed that too! This is not a way to communicate such a big > decision. Plus we went from requirements gathering to the final > decision? Where's the rest of the process? > >> From the original blow post: >> https://communityblog.fedoraproject.org/git-forge-requirements/ >> >>> How will information be gathered and disseminated? >>> >>> It is recommended that both Fedora Council and CentOS Board gather >> input and present their concerns in a manner that is consistent with how >> their communities work. The RHEL and CPE requirements will be gathered >> through Red Hat communication mechanisms and presented publicly via a >> HackMD file to ensure transparency in their source. This will be >> published and distributed in due course. Additionally, a live video call >> and associated IRC meetings will be held and advertised in advance to >> discuss the requirements, talk about concerns and address any questions. >>> We want transparency to be at the heart of this decision. >> >> Good promise, where are all those? No discussion, no advances, no proper >> information dissemination, nothing :( >> >> This announcement is not even on the first position on communityblog. I >> was expecting at least the same announcement visibility level for the >> final announcement that we had for the initial one: first position on >> communityblog blog + exclusive threads on the mailing lists. >> >> Well, actually I was waiting for those live discussions > > Moreover, Leigh Griffin said in the previous devel thread: > >> And if the requirements are stated we can have an open conversation about >> what does suit it. > > So I was also waiting for those open discussions about the > requirements gathered. I was really looking forward to reading what > Neal (as he's doing now) and others had to say about the requirements > *before* any decision was taken, and how each tool covers them or not, > and what kind of effort would require to cover it in the latter case. > This is *very* disappointing. > > In the final announcement in the Community Blog, this is listed as a > requirement: > >> 24/7 availability in an SLA model and not hosted by the CPE team freeing >> up resourcing and removing the need to staff a dedicated team for a git >> forge SLA which would necessitate a follow-the-sun ops model and a >> heavy investment in stability and observability of the Pagure solution. > > Ok, so I suppose that's it, check mate. I recall that several people > in the initial thread argued that self-hosting was important to avoid > depending on third-parties. Obviously this requiremen
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
o that I do not need manual intervention >> >> So... Mergify then? This is not *currently* a GitLab feature, and >> Mergify does not support GitLab, last I checked. Only GitHub.com. It's >> been on my bucket for a while to look at extending Mergify to support >> Pagure for this, as it's a really nice feature... >> >> I want to take a moment to reflect on something that has been on my >> mind for a while now: Fedora has not done a good job being an umbrella >> organization. As an organization, we have done a huge disservice to >> all Fedora-affiliated projects by not allocating any community >> development effort or marketing effort. I know that Matthew Miller >> feels Fedora should evolve to being an operating systems factory[1] >> and to some extent that isn't a bad thought. But the Fedora Project >> was always intended to be more than just the Fedora Linux >> distribution. It has always been intended to be a home for Free and >> Open Source innovation. In a Hacker News thread last year[2], I had >> reflected on how proud I have been to be part of Fedora because we, as >> a community, weren't willing to just give up like so many others do. >> When FOSS solutions were inadequate, we built better ones. We've >> invented things that didn't exist before, and jump-started >> conversations about concepts that people didn't think of before. But >> there has been a bit of a dark side to this for Fedora. We've rarely >> given our projects an opportunity to grow beyond us. Off the top of my >> head, the *only* project that technically *started* in Fedora and >> became successful was Ansible. And if I'm being totally brutally >> honest, it was only successful because the engineers who were >> passionate about it had to quit Red Hat and create AnsibleWorks to >> push it to success. It was successful *despite* Fedora. Maybe soon >> we'll be able to add HyperKitty and Postorius to that, as I've been >> seeing deployments of that come online over the past few months. It's >> taken a while, but HyperKitty is finally taking off. There was one >> person I talked to who told me that HyperKitty made mailing lists >> enjoyable and she didn't know the project came from Fedora originally. >> Again, seeing success despite Fedora. >> >> When I talk to folks in other communities and show them some of the >> infrastructure projects we've developed as part of trying to build >> communities around them, I've literally had people tell me that they >> wish they had known we made them before, because it solved all their >> problems they were struggling with. That's both amazingly uplifting >> and terribly depressing at the same time. I'm not even putting in a >> lot of effort and we get so much more out of it. It didn't take a lot >> for me to get openSUSE interested in our new AAA solution and >> contributing. That tells me that we're just not trying. And really, >> that's obvious. Even a simple comparison of the Fedora and openSUSE >> project landing pages show that Fedora gives zero attention to the >> projects that exist under its umbrella. When you look at the openSUSE >> landing page, the distribution and major software projects under the >> umbrella are all broadcasted there. It makes it so much easier to >> discover and generate interest. I'm not saying I love every aspect of >> the openSUSE marketing. Far from it! But this is one thing they do >> right that we do terribly wrong. And then we sit back and wonder why >> our projects fail to generate interest beyond a few folks in Fedora >> itself. It's a self-fulfilling prophecy. This is something we need to >> fix for *all* our projects: present and future. >> >> In the end, I think the biggest disappointment of this process is that >> it feels like it demonstrates that Fedora leadership and management is >> not as committed to its mission and vision[3] as I hoped it was. I >> realize that I should not be surprised by this. Most of the leadership >> and management are no longer the idealistic people they were when they >> first became involved. And it's even harder to be idealistic when it's >> so easy to give in when you work for "open source company" that >> increasingly uses proprietary software to manage its workflow (to be >> fair, I think at this point virtually all major companies do this, >> which more or less demonstrates the amoral nature of these entities). >> Maybe I'm just an old remnant of a bygone era, but I personally remain >> somewhat idealistic, even as I have progressed over the years. I also >> remain hopeful that other members of the community
Re: Bugzilla Spammers
From https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OM7XMMQ57CI6YJUGLPHAYISABIBFBLLD/#VKU3C5JTUTN74VJG3UV6DMQYV2AI2LJI You can report on bugzilla-ow...@redhat.com Regards, 20/2/11 14:38(e)an, Michael Cronenworth igorleak idatzi zuen: Who / Where is the best place to report spammers in Bugzilla? I think this is the first (maybe for me) I've seen spam comments in the Red Hat Bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=1056436 Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Late Fedora 32 Self-Contained Change proposal: ARM Release Criteria Changes
Heya, 20/2/10 14:46(e)an, Ben Cotton igorleak idatzi zuen: FESCo is considering[1] the late Change proposal[2] below. == Summary == Proposed changes to the Desktop release criteria for ARM and AArch64 in Fedora 32: * drop Xfce on 32-bit ARM from release blocking desktops * add Workstation on AArch64 to release blocking desktops == Owner == * Name: [[User:pwhalen| Paul Whalen]] * Email: pwha...@fedoraproject.org * Responsible WG: ARM SIG == Detailed Description == In Fedora 32 we will have a couple new additions to release blocking deliverables including IoT and CoreOS. In order to reduce the overall test coverage and release blocking desktops we propose no longer blocking on the 32-Bit ARM Xfce Desktop spin, and adding Workstation on AArch64 as a release blocking desktop. The AArch64 Workstation image has been available for a number of Fedora releases and contains the same package set as x86_64 where it is heavily tested. I don't see nor coreos nor iot on https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking . Shouldn't they be already listed there to be blocker deliverables in Fedora 32? Release blocking image changes: * Drop: Spins/armhfp/images/Fedora-Xfce-armhfp-_RELEASE_MILESTONE_-sda.raw.xz * Add: Workstation/aarch64/images/Fedora-Workstation-aarch64-_RELEASE_MILESTONE_-sda.raw.xz == Benefit to Fedora == This change will reduce the release blocking desktops and potential for blocker bugs. == Scope == * Proposal owners: Changes to the Wiki including testing templates, release criteria and deliverables. * Other developers: N/A (not a System Wide Change) * Release engineering: Small tweaks to the pungi config to make the compose fail on AArch64 Workstation and not fail on armhfp Xfce. The AArch64 Workstation spin has been available for a number of years. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == N/A (not a System Wide Change) == User Experience == The same Desktop experience enjoyed on x86_64. The Armhfp Xfce Desktop spin will still be produced and tested to ensure functionality. == Dependencies == N/A (not a System Wide Change) == Documentation == This change will require some updates to Release Criteria, release blocking deliverables lists and testing matrices. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: new maintainer for tmuxinator
https://pagure.io/pagure/blob/master/f/pagure/templates/repo_info.html#_77 PRs are welcome ( for this and any other fix :D ) 2020(e)ko otsailaren 6(a) 13:01:26 (CET)-(e)an, Fabio Valentini -(e)k hau idatzi zuen: >On Thu, Feb 6, 2020, 12:47 David Sommerseth wrote: > >> On 06/02/2020 09:19, Miro Hrončok wrote: >> > On 06. 02. 20 4:21, Dusty Mabe wrote: >> >> It was orphaned recently. Anybody care to pick it up? :) >> >> >> >> https://src.fedoraproject.org/rpms/tmuxinator >> > >> > To clarify: It was retired recently. >> > >> > (I've noticed people confuse the terms all the time and was >wondering >> what to >> > do about it without changing them.) >> >> Looking at the URL above, seeing "Maintained by orphan" ... that >certainly >> does not help clear up any confusion ;-) >> > >I guess that would be a good, simple, contribution to pagure >(-dist-git?): > >if maintainer == "orphan": > return "Package currently not maintained" >else: > return "Maintained by " + maintainer > >Fabio > > >> >> -- >> kind regards, >> >> David Sommerseth >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> -- 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
Re: [Retired] gstreamer & gstreamer-plugins-base
We don't have any problem to retire open source packages that works because they don't move to python 3 for example, but at the same time we hold dead old libraries due to proprietary software. It looks unfair at least ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Git Forge Requirements: Please see the Community Blog
20/1/29 18:19(e)an, Clement Verna igorleak idatzi zuen: > > Things that I would in my opinion improve Pagure PRs : > > * In the PR diff should start from the correct line number, not always > 1. (https://pagure.io/pagure/issue/724) > * Every time a branch is forced pushed you loose the comments from the > diff view. (somewhat related to https://pagure.io/pagure/issue/751) > * It should be possible to display a few lines of code before or after > the diff to help having more context when making the review > > Things that would be really nice to have > * Have a way to suggest changes directly while reviewing PRs > > Some unrelated to PRs improvement: > > * Being able to rename, move projects > * Being able to move a ticket between projects > (https://pagure.io/pagure/issue/737) > * Full Text search projects, users, groups > * Code search (https://pagure.io/pagure/issue/539) > * Support GPG signing commit (https://pagure.io/pagure/issue/751) > * Be able to select which event you want to send on the webhook, ie > everything or nothing > > A lot of these a not necessary things we *really* *really* need to have, > but they would make using Pagure much better in my opinion. > > Yeah, I agree, pagure needs a better code reviewing UI -- 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
Re: Git Forge Requirements: Please see the Community Blog
2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna -(e)k hau idatzi zuen: >On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza > >wrote: > >> (snip) >> >> 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen: >> > To me that's the all point of this >> > process, let's put down what we *really* *really* need and then >look at >> > the different options. >> > >> >> Do we *really* *really* need to compete with other full featured git >> forges on features? The ODF says that this is one of the problem. >Well, >> imo we don't *really* *really* need to compete with them. >> > >It depends on the use case, doing development work projects hosted on >pagure.io is not great in my opinion. In particular working with pull >requests. > I don't have excesive problems with pagure on PR workflows. Right now for me centos-ci is a much bigger problem for PR workflows on pagure.io than pagure itself for example. >In terms of issue trackers, it is missing the ability to visualize >issues >in a board for example. >Again this my opinion and maybe these are maybe not *really* *really* >needed. Is a great forge the beste solution for this? Or are there other solutions for issue tracking/kanban/boards etc that could better suit this use cases? > > >> Actually we already have the features that we *really* *really* need. >> Otherwise we could not release fedora using pagure as we are using, >> could we? :) >> > >I personally don't think we can release Fedora without people across >the >project doing heroics and a crazy amount of hours which seems to have >become a norm rather than an exception. > +1. But is this a git forge problem? We are again on the same place: we have different use cases hosted on pagure. Some of them could need a big effort on pagure side to compete with other options (on technical features), some others could benefit of migrating to other solutions, and some others could not have a better solution than our own custom one -- 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
Re: Git Forge Requirements: Please see the Community Blog
Per git ref acls is not a common thing on git forges. If this is a final requirement, we should start analyzing the viability of implementing and maintain it on the different forges (and it should be feasible with all of the rest of our strange ACLs on dist-git) On pagure side, now that our downstream instances are not using gitolite, implementing them needs much less work that migrating all our toolings to other solutions. 2020(e)ko urtarrilaren 29(a) 15:37:36 (CET)-(e)an, Neal Gompa -(e)k hau idatzi zuen: >On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon > wrote: >> >> On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote: >> > (snip) >> > >> > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen: >> > >To me that's the all point of this process, let's put down what we >> > >*really* *really* need and then look at the different options. >> > > >> > >> > Do we *really* *really* need to compete with other full featured >git >> > forges on features? The ODF says that this is one of the problem. >> > Well, imo we don't *really* *really* need to compete with them. >> > >> > Actually we already have the features that we *really* *really* >> > need. Otherwise we could not release fedora using pagure as we are >> > using, could we? :) >> >> So let's revert the question, pagure does the what it needs to do and >enough of >> it, otherwise we would not be using it. >> >> What does pagure miss that other solutions have and that could be >considered a >> requirement? >> >> It could be that we don't **need** pagure to do anything more than >what it does >> today, which moves the discussion off a technical ground. >> > >From a Dist-Git perspective, there is are two things I need: >* per-branch ACLs >* the ability to set bugzilla owners without granting commit access. > >The first thing is because I get nervous granting people access to the >Git project who want to build EPEL8 packages but clearly aren't good >at managing Git workflows. I don't want them breaking my workflows >with Fedora packages. > >The second thing is because there are a number of packages that I >maintain where upstream would like to be notified on bugzilla bugs but >not otherwise be involved in packaging. Pagure itself has the ticket >ACL for this, but I don't think this does anything in the Dist-Git >setup. > >From the Git forge perspective, the two big things I need are: >* working self-service CI >* workflow for self-service integration management per-user and >per-repo > >The first item is because the current Pagure CI with CentOS CI Jenkins >is inexcusably bad. Jenkins is often unresponsive and broken, and >configuring it requires manual intervention from the CentOS CI folks. >Part of the reason we have Pagure was to move to more of a >self-service model, and our default offering for CI services fails at >that. > >The second item is because there are an array of third party Free >Software services out there that people should be able to use without >having to talk to the Pagure admin to activate or enable. We do have >webhooks for basic integrations, but doing authentication and >authorization flows for generating app tokens and such is something we >don't have today. Having this would allow far more sophisticated >integrations than what we have now without always having to involve an >admin over it. > > >-- >真実はいつも一つ！/ 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 -- 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
Re: Git Forge Requirements: Please see the Community Blog
(snip) 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen: To me that's the all point of this process, let's put down what we *really* *really* need and then look at the different options. Do we *really* *really* need to compete with other full featured git forges on features? The ODF says that this is one of the problem. Well, imo we don't *really* *really* need to compete with them. Actually we already have the features that we *really* *really* need. Otherwise we could not release fedora using pagure as we are using, could we? :) 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
Re: Git Forge Requirements: Please see the Community Blog
Heya, Currently we have two different pagure instances that hosts different use cases on them, and different use cases means different requirements, so first of all, about what use cases we are talking about? we have src.fp.o for distgit, some pagure.io projects that hosts actual code development repos and some other repos that are used as trackers and documentation containers. For all of them, I agree with mcatanzaro's requirements: #1 self hosted #2 open source IMO, #1 could be a soft requirement, I would be fine with a service provided by an upstream first and open source friendly service provider if it allows us to dump out all our data on a easy way. Now git and github is the mainstream workflow, but previously was sourceforge and svn . We should be able to transfer our data from our current service to a N+1 or N+2 service without losing too much so we should be able to dump all our data on a supported way. I have some more general requirements: #3 privacy friendly. Nowadays js|cookie tracking is huge on the world wide web, I would prefer not being tracked on that way while using a fedora service. bodhi, koji or distgit does not inject any weird tracking javascript or cookies, I love that and since privacy concerns me I would like to continue on this way. #4 Good integration with Fedora infra's core services. This include fas (and it's replacement) and fedora-messaging #5 Easy to onboard and open to any community member, newcomers included. We should avoid the integration problems that we're having with teams.fp.o on this matter for example (see below) This requirements are not just for our git forge, all the fedora services should satisfy with them. Then, we should capture and analyze the different use cases individually. Different use cases, different requirements. They might fit all of them on the same solution or we could move some of them to a different one if the other solution fits better for that case. So let start with distgit. Here we have a bunch of more requirements: #packager.1: technical implementation of our packaking policies and the ability to evolve them as the policies evolve. This means at least support for system-wide commit users (provenpackagers), system-wide restricted branches, systemn-wide protected (non force pushable) refs, system-wide actors that can bypass all this limitations (releng). This should cover orphaning and retaking process too. We lack but we should have ACL branches and admins to support different EPEL|Fedora maintainers on the same repo. #packager.2: Integration with other options|services that we have on our packaking workflows. This could be done on the git repo or we could have a different packager control panel service (I love miro's mockups for example). This includes BZ, bodhi, koji, anitya, BZ overrides... That's for now on distgit. On pagure.io I identify two big groups of repositories: code repos for development of different projects and tracking repos that are mostly used for the ticket system and some documentation. The later ones could fit on teams.fp.o if we can solve the big issues on it: the fas integration is not perfect, and is not open for contributions. Fixing [1] and [2] is a requirement for teams to fulfill the initial general requirements, so it would be a requirement for an hypothetical transfer of this kind of projects from pagure.io to teams.fp.o As general requirements, I have two at least: #tickets.1: ticket|issue system support for usual workflows: tickets, assignees, tags, states, priorities... #tickets.2: some kind of documentation integration. We have some repos on this use case that are just docs + tickets. We could support them on a non git repo solution if we can integrate both docs and tickets on a unique UI. And then we have the code repos. I like the idea of having a unique place to host all the fedora related code projects and I would add a couple of requirements around the homepage about this in case we go with a solution that groups all those code repos on a single place: #dev.1: An attractive homepage that shows where is the activity right now, where we need help, and where newcomers can start to contribute. #dev.2: Good searching capabilities. For the repo itself... this is where we probably diverge more since every single developer has her own workflows so she'll have their own personal requirements. Some of us could just work with a system that allows you to make basic git operations and some others will require complex interactive conflict resolving UIs. On my case, I don't need too much: #dev.3: git support. I'm fine with just ssh support, but https one could benefit newcomers onboarding process. #dev.4: PR workflow support. #dev.5: ticketing system #dev.6: web ui to the code, branches etc. And then I have a soft requirement on a actual pagure feature that I did not use it previously but it means a lot nowadays
Re: moving bugzilla overrides to dist-git
I don't have a strong opinion, so I would start with restricted ACLs and expand if needed: site admins(releng, infra) + main admin. 2019(e)ko abenduaren 9(a) 15:07:07 (CET)-(e)an, Pierre-Yves Chibon -(e)k hau idatzi zuen: >On Mon, Dec 09, 2019 at 08:46:28AM -0500, Neal Gompa wrote: >> On Mon, Dec 9, 2019 at 8:39 AM Karsten Hopp >wrote: >> > >> > Hi, >> > >> > We are currently working on getting rid of the git repo at >fedora-scm-requests [1] which is nowadays only used to store the >overrides of the default assignee in bugzilla (for example to allow >different default assignee for Fedora and EPEL). >> > >> > I am working on porting this mechanism to dist-git itself (much >like we did for the anitya integration a few weeks ago). >> > >> > We are thinking on providing a simple text field to submit FAS >username or email to override the default assignee, the big question is >then, who should be allowed to update this field ? >> > >> > Should the main admin be able to set someone else as assignee ? >> > >> > If there is already an override assignee, who should be allowed to >change that ? >> > >> > If there's no override assignee set, can everyone become it or is >that up to the main admin of the component to decide and set ? >> > >> >> I think in this case, it should be the main admin who can change >this. > >The main admin (and infra/releng) only, or all the admins of the >project? > > >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 -- 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
Re: do not remove arpack package from Fedora
On November 30, 2019 11:46:46 AM GMT+01:00, Felix Schwarz wrote: > >Am 30.11.19 um 07:27 schrieb Chris Adams: >> I think the problem is that unmaintained packages are still >> unmaintained; drive-by changes by provenpackagers are not actual >> maintenance, because that's not a scalable organization (expecting >> provenpackagers to do all maintenance on random packages). > >I agree. One thing that is missing in Fedora is a process to involve >users in >the actual distribution maintenance (and I think this is mostly a >technical/ >tooling problem not a social one). > >For example: >- orphaned packages > - When a package gets orphaned, I think a bot should post a comment to >existing bugzilla issues which explains the situation and asks the >users >to step up (this "call to action" process should come with detailed >step-by-step instructions on how to take care of that orphaned >package). > >- When I have an orphaned package installed I'd like to get a >notification >(desktop/server) so I am aware that this package may not receive >security >updates any longer. (And again "call to action" for regular users to >step > up.) > >- package testing >Manually checking updates-testing is too tedious and usually I don't >want >to install everything in updates-testing right away. But there are some >packages which I like to get as fast as possible/which I can test >easily. > >- So I would like to get some kind of "notification" when such a >package > goes into updates-testing + a reminder to give feedback. >- As an extension we could ask users who use certain applications >regularly >if they want to try an update + ask them for bodhi karma after 1-2 >days. > >- Flag "co-maintainers wanted". As a packager I'd like to mark some >packages >where I'd like see more co-maintainers (e.g. for libraries I maintain >only >because another app uses them). Packagers for dependent projects should >be > be notified that this library is in need of further maintainers. > >But of course all of that requires coding and "someone" to do it :-/ The notification part would need more work, but pagure supports tagging projects and leveraging src.fp.o's theme to list them on the homepage and add a banner on package's view would be actually pretty easy. We could need some modifications for project tagging process though > >Anyway: lowering the bar to contribute to Fedora + integrating with >Fedora >users is something the Fedora project needs to do. > >Felix >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org >Fedora Code of Conduct: >https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >List Archives: >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 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
Re: Encrypted DNS in Fedora
dnsmasq can include the real dns server ips from a external file 19/11/5 12:51(e)an, Sam Varshavchik igorleak idatzi zuen: > Florian Weimer writes: > >> * Michael Cronenworth: >> >> > On 11/4/19 2:17 PM, Florian Weimer wrote: >> >> We are not going to implement this directly in glibc. You should >> talk >> >> to a stub resolver on 127.0.0.1 instead. We do not want to link a >> >> cryptographic library into every process that queries an Internet >> host >> >> name. That also applies to DNSSEC. >> > >> > The transition to DoT/DoH makes the resolv.conf file obsolete. Any >> > discussion on removing it entirely? Default to looking at a local >> > resolver. >> >> This is the default today. The issue is that the defaults for the DNS >> search path and some other options are wrong, and we will need a >> transition to correct that. Then we can probably remove the file, >> unless something else is stored there. > > Where would the dhcp-supplied DNS resolver, and DNS search path, go? > > Ubuntu's default configuration appears to set up a stub resolver on > localhost and dnsmasq. Made it somewhat difficult to do any kind of > diagnostics, sine the real DNS server IP address seems to get stored > entirely within dnsmasq, and not visible anywhere. > > I like plain text files, in well-defined locations. Makes things much > easier to troubleshoot. > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- 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
Re: No longer supporting mailing lists:
I'm curious about discourse's options here... Is quite common on our workflows to have mailing threads that targets a couple of fedora mailing list, another outside mailing list and some third party individuals when we discuss about an specific feature. The xen criteria one for example, it had been cross mailing test@, devel@, xen's third party mailing list and some amazon folks with direct CCs. Is this possible with discourse? 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
Re: Fedora 31: Noninstallable Python 2 packages to be retired just before the beta freeze
You could ask for a freeze exception that covers your case On August 26, 2019 8:14:36 PM GMT+02:00, "Miro Hrončok" wrote: >On 26. 08. 19 11:24, Miro Hrončok wrote: >> In line with the approved Fedora 31 change, packages that fail to >install due to >> missing Python 2 dependencies are to be removed. I plan to retire the >following >> packages (or just drop their python2 subpackages) one day before the >beta freeze >> (2019-08-28), that is on this Wednesday. > >Apparently, the freeze have been moved in the schedule today, possibly >just >correcting a typo: > >https://fedoraproject.org/w/index.php?title=Releases%2F31%2FSchedule=revision=550934=535832 > >This makes it hard, because I can either: > > - retire the packages today (and not give the time I've promised) > - wait for Wednesday and miss the deadline > >At this point I think waiting is better, however should we actually >have the >freeze on the 29th, as other contributors may planed their stuff >according to >the schedule? 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
Re: Rebase option suddenly missing from src.fo.o PRs?
AFAIK, here are two different things, On one hand, since 5.6 you must check the allow rebase checklist button to allow the project owner to rebase your fork branch from where the PR is created. This property had been set to False on the migration from 5.5 to 5.7.4, so the previously existing PRs will not allow the owner to rebase PR. This is a feature. More background on https://pagure.io/pagure/c/e180e7ed38a944f087063a31c51ba6ac12bb715c?branch=master On the other hand, there is a regression around the merge button showing|hiding logic. This part is a bug. 19/8/20 11:26(e)an, Fabio Valentini igorleak idatzi zuen: > On Tue, Aug 20, 2019 at 11:16 AM Miro Hrončok wrote: >> I've recently noticed that src.fo.o PRs no longer let me click "Rebase" under >> the "Merge" button. >> >> Am I the only one impacted? >> >> Is that deliberate or some bug worth reporting? > FWIW, the "Merge" button from the "merge popup" is also gone for me. > I assume this is a regression from updating pagure from 5.5 to 5.7 > that happened a few days ago. > > Fabio > >> -- >> 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 -- 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
Re: Discussion around app retirements and categorizations by the CPE team
Our dist-git stack has a bunch of customization and personalization that are not currently available on gitlab nor any other opensource forge, and some of them will collide with gitlab's CE vs EE edition model, so they'll be hard to get to upstream. Right now we have at least a custom auth provider, unusual ACLs for the standard user, system-wide powerusers, group syncing to the instance, branch ACLs, mass-branching and many more features already implemented that are not going to be easy (or they'll be impossible) to merge on upstream's CE edition. They're working and they're critical on our use case. Almost all the auth privder and ACL things are EE features on gitlab, CE just support basic authentication from providers, no more, and we need a bunch of weird rules there, and we already have them implemented! So, we would have to develop & carry all those things on custom patches, without being able to push them to upstream, so there will not be nor outside contributing to them nor support nor anyone outside fedora will take advantage of our work either, so implementing, maintaing and rebasing all this customization will burden the team again. So, where is the point here? On the other hand, pagure needs a lot of improvement, specially on interface. Internals are decent and they work, we have more problems on UI/API exposition etc. From 400 issues that are right now open on pagure, 200 are RFEs, and the vast majority of them are about UI/API enchancement and similar features. Can we work on this from the community? Would be possible to continue using pagure for dist-git if we go polishing all this things? We don't need a gitlab clone, let the developers host their developing on the forge they want, github, gitlab, event subversion or darcs, it does not matter, our focus should not be cloning gitlab but making a better packaging experience for the packager community, mainly a decent frontend for our packager workflows and there pagure vs cgit is a great improvement. And where is pagure.io with this? Well, if we continue using pagure for dist-git, the development costs of pagure.io should be minimal or zero, since we would be developing it for src.fp.o and other dist-git instances as well, and then we should just have the maintenance costs. Are the pagure.io maintenance costs a big burden for CPE? Let share them with the community. -- 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
Re: Vim and spec template
Although I'm not vim + .spec file user, I'm a big fan of templates and a big hater of autotemplating without my explicit decision in general =) 19/7/18 13:44(e)an, Zdenek Dohnal igorleak idatzi zuen: > Hi all, > > I would like to ask as Vim co-maintainer, do you find useful for Vim to do: > > - when you open new file with .spec suffix, Vim will get you basic spec > file structure? > > Recently I found out someone can find it as bad behavior > https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I consider > changing the default vimrc to tell Vim 'Don't do it'. > > What's your opinion? Is it useful feature of Vim and it should stay as > default, or it needs to be disabled? > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- 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
Re: Langpacks and the packages needed to display/input a language
I don't have a clear opinion on this, yet. In my use case I totally agree with you, I don't really need all this support, just a few thing are enough for me. But I understand that for the general non english speaker, non techie use case, they expect that selecting to install their desired language once they system installs you all the possible support for that language. Could we go with the full metapackage on all general UI (anaconda, DE system settings and similars) and provide a minimal metapackage at the same time? On June 15, 2019 4:12:51 AM GMT+02:00, Sundeep Anand wrote: On Sat, Jun 15, 2019 at 3:47 AM Jason L Tibbitts III wrote: I noticed that my F30 installs are coming out far larger than my F29 installs (by 3GB or so) and did some digging into why. With F30 we switched away from having groups named like "korean-support" that you could install to get input methods and fonts needed to display a language and instead we have metapackages named like "langpacks-ko". These metapackages have (generally) weak dependencies on the fonts and input methods as before. But other packages have reverse weak dependencies on the langpacks, which causes far more to get pulled in than was previously installed. For example, each libreoffice langpack has a "supplements" weak reverse dependency on the base "langpacks" metapackage. All of this seems fine, but my original goal was to be able to properly display, and perhaps input, various languages. But now I get translations and help files and such as well. Not just for libreoffice, but for eclipse, glibc, all of KDE as well. And I also get autocorrection rules, spelling dictionaries, hyphenation rules, and terreract OCR recognition data as well. Some of those aren't small, and the end result is that I need to bump up the size of / quite a bit. Note that turning off install_weak_deps is not an option because for most of the langpacks, _all_ of the langpack are weak. (Some do have hard font dependencies, and I'm not sure if this inconsistency is intentional.) So it seems we lost the simple "here are our suggested Korean fonts and an input method" and instead the only thing you can say is "I want everything possible to be available in Korean". Is there any way to improve the granularity here? Perhaps by having "light" and "heavy" langpacks, or splitting them by usage (translations versus simple display of text)? Agree! We probably need more discussions (I'm quite interested to work on this). This is one of the points for https://pagure.io/flock/issue/164 For now I guess I will simply extract the list of fonts and input methods I want from the langpack specfile and stop installing the actual langpack packages. - J< devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Julen Landa Alustiza 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: how to set passwrod for Fedora LiveCD (Fedora 30)?
What about configuring the dm to autologin with liveuser? On May 31, 2019 7:07:32 AM GMT+02:00, Samuel Sieb wrote: >On 5/30/19 6:45 AM, Globe Trotter via devel wrote: >> Thanks! I posted the kickstart file earlier, but I have no other >lines >> to set the password, but I still get prompted for a password. > >I assume you've tried just pressing enter with no password? > >> So I was wondering if I can explicitly set the password so that I >know >> what to type when it asks for one. > >You can add a line like the following: >user --groups=wheel --name=myuser --password="" >That should create a user with no password. > >> I did not have a problem with this in F29. I was not asked for the >> password. Something changed with regard to permissions in F30 and I >am >> trying to find out what/or how to set the password. > >I don't see anything in the kickstart files that would change that, but > >maybe if you can login as a different user, you can look around and see > >what's happened. Or you could mount the live filesystem and see if you > >can find something. >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org >Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >List Archives: >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Julen Landa Alustiza signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH
If someone is remotely installing with kickstart on a non interactive way I assume they have enough knownledge to modify that ks to either add a pubkey to root or modify sshd_config Anyhow yeah, would be great to help making this easy with a ks default, or macros Stephen John Smoogen igorleak hau idatzi zuen (2019 mai. 17, or. 17:10): > > > On Fri, 17 May 2019 at 10:41, Julen Landa Alustiza > wrote: > >> We are not disabling root access entirely, you can log on local console >> or use su after loging with a normal user. >> >> > So a lot of sites have set up that you remotely kickstart a system and > then ansible in as root with the rest of the configurations. It is the > biggest reason we have been keeping this as active for a long time. You > are breaking all those configs with a 'oh you can just login on a local > console'. That kickstart may not have any of that.. and the last thing a > sysadmin wants when they are building 4000 nodes somewhere is find out that > they need to add another 20 steps to their post.. > > Make it a predefined kickstart thing they can do so all they have to do is > add a line in it that says > > ssh_remote --user= --keyfile= --yesIwantrootandIknowitsbad > > and you have covered your bases. Turning off expected options in the name > of security sounds great and easy.. and the one thing I have learned in > computer security is that is the siren song which dashes your ship on the > rocks of pissed off system administrators. > > > > >> After installing server without the proposed changes (that could be >> great, but not needed) you can log in with the normal user and use su to >> scalate privileges and either change sshd_config or add a pubkey on >> authorized_keys. >> >> Right now we will need a normal user to be able to access as root after a >> remote install, but it does not neccesary need to be part of wheel (I >> believe that su is not restricted) >> >> Just a root user and not a regular one will finish with a box that is not >> accesible remotely and that could be a problem >> >> Stephen Gallagher igorleak hau idatzi zuen (2019 >> mai. 17, or. 16:20): >> >>> On Fri, May 17, 2019 at 8:37 AM Martin Kolman >>> wrote: >>> > >>> > On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote: >>> > > 3) Force Anaconda to require the creation of a non-root user that is >>> a >>> > > member of the `wheel` group, so that this user can be used to SSH in >>> > > and administer the system. Essentially, remove the root user creation >>> > > spoke as an option from the interactive install. >>> > The current policy during ineractive install is, one of (or both) must >>> exists: >>> > - a root account that is not locked >>> > - a user in the wheel group >>> > >>> > This could be tweaked accordingly (eq. always require at least one >>> user in the wheel >>> > group regardless of the state of the root account). >>> > >>> >>> I might not have been clear in my original email. My point was mainly >>> that I want these problems identified, a solution agreed-upon and >>> added to the Change Proposal before it goes to a FESCo vote. I'd be >>> inclined to vote -1 without a plan in place to deal with this. This is >>> indeed probably the least-intrusive change we can make (and aligns us >>> a little closer to how other popular distros are doing things these >>> days), and if Anaconda team is willing to commit to doing that work >>> here, that would be great. >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> 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://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > > > -- > Stephen J Smoogen. > > _
Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH
Sorry, I'm in mobile and I miss send the draft :S I'm not sure if it's clear: we don't really need so many constraints on anaconda. (active root with pass and regular user) or regular user on wheel group would be enough to elevate privileges on a just installed box remotely Julen Landa Alustiza igorleak hau idatzi zuen (2019 mai. 17, or. 16:40): > We are not disabling root access entirely, you can log on local console or > use su after loging with a normal user. > > After installing server without the proposed changes (that could be great, > but not needed) you can log in with the normal user and use su to scalate > privileges and either change sshd_config or add a pubkey on authorized_keys. > > Right now we will need a normal user to be able to access as root after a > remote install, but it does not neccesary need to be part of wheel (I > believe that su is not restricted) > > Just a root user and not a regular one will finish with a box that is not > accesible remotely and that could be a problem > > Stephen Gallagher igorleak hau idatzi zuen (2019 > mai. 17, or. 16:20): > >> On Fri, May 17, 2019 at 8:37 AM Martin Kolman wrote: >> > >> > On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote: >> > > 3) Force Anaconda to require the creation of a non-root user that is a >> > > member of the `wheel` group, so that this user can be used to SSH in >> > > and administer the system. Essentially, remove the root user creation >> > > spoke as an option from the interactive install. >> > The current policy during ineractive install is, one of (or both) must >> exists: >> > - a root account that is not locked >> > - a user in the wheel group >> > >> > This could be tweaked accordingly (eq. always require at least one user >> in the wheel >> > group regardless of the state of the root account). >> > >> >> I might not have been clear in my original email. My point was mainly >> that I want these problems identified, a solution agreed-upon and >> added to the Change Proposal before it goes to a FESCo vote. I'd be >> inclined to vote -1 without a plan in place to deal with this. This is >> indeed probably the least-intrusive change we can make (and aligns us >> a little closer to how other popular distros are doing things these >> days), and if Anaconda team is willing to commit to doing that work >> here, that would be great. >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH
We are not disabling root access entirely, you can log on local console or use su after loging with a normal user. After installing server without the proposed changes (that could be great, but not needed) you can log in with the normal user and use su to scalate privileges and either change sshd_config or add a pubkey on authorized_keys. Right now we will need a normal user to be able to access as root after a remote install, but it does not neccesary need to be part of wheel (I believe that su is not restricted) Just a root user and not a regular one will finish with a box that is not accesible remotely and that could be a problem Stephen Gallagher igorleak hau idatzi zuen (2019 mai. 17, or. 16:20): > On Fri, May 17, 2019 at 8:37 AM Martin Kolman wrote: > > > > On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote: > > > 3) Force Anaconda to require the creation of a non-root user that is a > > > member of the `wheel` group, so that this user can be used to SSH in > > > and administer the system. Essentially, remove the root user creation > > > spoke as an option from the interactive install. > > The current policy during ineractive install is, one of (or both) must > exists: > > - a root account that is not locked > > - a user in the wheel group > > > > This could be tweaked accordingly (eq. always require at least one user > in the wheel > > group regardless of the state of the root account). > > > > I might not have been clear in my original email. My point was mainly > that I want these problems identified, a solution agreed-upon and > added to the Change Proposal before it goes to a FESCo vote. I'd be > inclined to vote -1 without a plan in place to deal with this. This is > indeed probably the least-intrusive change we can make (and aligns us > a little closer to how other popular distros are doing things these > days), and if Anaconda team is willing to commit to doing that work > here, that would be great. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
Roberto Ragusa igorleak hau idatzi zuen (2019 mai. 6, al. 15:34): > On 5/6/19 1:40 PM, Julen Landa Alustiza wrote: > > > We found this bug before releasing, but it is not a release blocking bug > (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this > bug just happens whith continously upgraded systems since fc21 or lower) > > Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?". > Is this a precedent that n-installed is different than n-through-upgrades? > > Regards. > > -- > Roberto Ragusamail at robertoragusa.it Technically speaking and for our releasing criteria yep, we block on fresh fc28/fc29 default installation of blocker package sets upgrades to fc30, previously upgraded fc28/fc29 are out of scope. We do our best to support upgrading from previously upgraded systems, but they're not considered blocker bugs if clean default installations of n or n-1 are not affected https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#Upgrade_requirements > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade to F30 gone wrong
Nicolas Mailhot via devel igorleak hau idatzi zuen (2019 mai. 6, al. 09:59): Le dimanche 05 mai 2019 à 16:14 -0600, Chris Murphy a écrit : > > Right and that's the same with beta testing, which is how bugs like > this can sometimes not even get found until after release. A lot of > tests are done on pristine systems that are throw away. It's entirely > understandable few people want to test Fedora pre-release on their > rock solid 5+ year old Fedora system, but we actually stumbled on > this > in some sense by luck of alternate arch acting like a canary. That's not true, many boot problems are found quite early in the process by rawhide users, but rawhide users feedback is not taken into account by installer folks because they don't look at boot problems before quite late in the cycle, when rawhide users have already moved on manually, and the default solution is always to reinstall from scratch. So problems are found, just not fixed About this specific bug... We found this bug before releasing, but it is not a release blocking bug (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this bug just happens whith continously upgraded systems since fc21 or lower) so QA folks talked with bootloader ones, it was a difficult bug to fix without breaking things/overwriting other bootloaders and there was no time to announce, discuss and decide about policy changes so we went ahead documenting it on common bugs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
I'm really interested on the livet crash, but I can't reproduce it with latest branched compose. Can you provide us with reproduction steps? Hau idatzi du Neal Gompa (ngomp...@gmail.com) erabiltzaileak (2019 api. 10, az. (02:59)): > On Tue, Apr 9, 2019 at 8:35 PM Chris Murphy > wrote: > > > > On Tue, Apr 9, 2019 at 10:07 AM Lennart Poettering > wrote: > > > > > > Heya, > > > > > > today I installed the current Fedora 30 Workstation beta on my new > > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?) > > > crashed five times or so on me, always kicking me out of anaconda > > > again, just because I wanted to undo something). > > > > I haven't seen a single one come across in QA > > > > > 1. multipathd. > > > > I'm pretty sure it gets dragged in by the installer, i.e. the > > installation environment needs it because installing to multipath is > > supported. And since it's on the Workstation LiveOS, it just gets > > copied over along with the installer itself (LiveOS installs use > > rsync). I wonder if it's reasonable to apply more exclude filtering > > during rsync to avoid copying some things needed for Live OS > > environment, but not on the final installed system. But that's sorta > > up to Workstation WG I think. > > > > Not having the rpmdb in sync with what content is on the system is > probably not a good idea. I'd advocate for anaconda being able to run > dnf to clean up stuff instead. > > > > > > 2. dmraid. > > > > Same as above. I'm not sure whether, or when, dmraid stuff is going to > > be dropped by anaconda. For a long time now dmraid is deprecated. The > > two supported ways of doing software raid are managed by mdadm and > > lvm, both of which actually use the md driver in the kernel. > > > > So I think this is a question for the anaconda team. > > > > > > > 4. Similar crond. On my fresh install it's only used by "zfs-fuse", > > >which I really wonder why it even is in the default install? And > > >"mdadm" wants this too. (which would be great if it would just use > > >timer units) > > > > I think zfs-fuse and glusterfs are dragged in by libvirt, which is > > present because of GNOME Boxes. I don't know why any of those want > > crond. > > > > These could be converted to systemd units. There's no reason not to, > really... > > > mdadm scrub and monitoring depends on crond, and then email > > notifications if mismatch count != 0; it's archaic these days I guess, > > but that's how it works. > > > > > > > 5. libvirtd. Why is this running? Can't we make this socket > > >activatable + exit-on-idel? While I am sure it's useful on > > >workstations why run it all the time, given that only very few > > >users probably actually need that, and if they do starting it on > > >demand would be much more appropriate? On my freshly installed > > >system it is running all the time even though there are no VMs or > > >anything around. > > > > Agreed. > > > > > > > > > > Ideally, the top 4 wouldn't be installed at all anymore (in case of > > > the first two at least on the systems which do not need them). But if > > > that's not in the cards, it would be great to at least not enable > > > these services anymore in the default boot so that they are only a > > > "systemctl enable" away for people who need them? > > > > At the least it seems reasonable they can be disabled on the installed > > system, and enabled for Live OS boot if the installer needs them. > > > > -- > > Chris Murphy > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > -- > 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libravatar is in fedorainfracloud!
HSTS redirects from http to https should just elevate security and not redirect to a different subdomain. Altrought it supposes two redirects (http->https and then libravatar -> www.libravatar.org) that's the correct way for HSTS Michal Novotny igorleak hau idatzi zuen (2019 ots. 21, og. 14:51): > On Thu, Feb 21, 2019 at 12:51 PM Till Maas wrote: > > > > On Thu, Feb 21, 2019 at 09:40:16AM +0100, Michal Novotny wrote: > > > > > We, as a libravatar group, are very happy that Fedora Infra provided > > > us with the needed > > > hardware. We will keep the service running by our own effort. > > > > What is the right place report errors in the web server configuration > > regarding the Strict Transport Security HTTP header? There are two > > issues: > > > > - it does not contain includeSubDomains > > - http://libravatar.org odes not redirect directly to > > https://libravatar.org but to the www subdomain instead. > > Till, thank you for checking it! That's very valuable to us > and to me as well. > > I've added IncludeSubDomains directive to HSTS declarations. > Can you take a look? > > I am not sure why http://libravatar.org to https://www.libravatar.org > redirect is bad. Can you, please, explain? > > Thank you > clime > > > > > > Kind regards > > Till > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > 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://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disabled registration from a certain IP due to a limit.
discussion.fedoraproject.org could be self hosted, isn't it? About github, there is a lot of fedora stuff there, imho that should be a bigger and deeper different discussion. Anderson, Charles R On Mon, Dec 17, 2018 at 12:14:18PM -0500, Ben Cotton wrote: > > On Mon, Dec 17, 2018 at 12:01 PM Fabio Valentini > wrote: > > > Important announcements (and RFCs) like this should really be done > somewhere where the most people will see it (probably the devel ML?) > > > > > It was also published to the Community Blog[1], which also > > automatically posts to Fedora Planet. > > > > [1] > https://communityblog.fedoraproject.org/fedoras-strategic-direction-an-update-from-the-council/ > > > > -- > > Ben Cotton > > Fedora Program Manager > > TZ=America/Indiana/Indianapolis > > Can we please make sure this gets sent to the fedora-announce ML now and > in the future? That is the purported purpose of the list. > > Thanks. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
