Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
> On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
>
> Why isn't this as simple as:
>
> 1) Create an f37-multilib-build build tag with all supported arches + i686,
> and an f37-multilib{,-candidate} build targets to use it (with destination tag
> of f37-updates-candidate);
>
> 2) Drop i686 from f37-build tag;
>
> 3) Maintainers of wine and its deps etc. opt-in to i686 with a package.cfg:
>
> [koji]
> targets = f37-multilib
>
> (Yes, that would have to be updated after branch point, but that could
> possibly be automated.)
>
> 4) Everyone else leaves their spec files alone, no need to add ExcludeArch:
> i686.
>
> Would that work?
That works ok for rpmfusion.
https://koji.rpmfusion.org/koji/taginfo?tagID=483
fedpkg could be adapted as well, see
https://github.com/rpmfusion-infra/rfpkg/blob/master/rfpkg/__init__.py#L187
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
> == Detailed Description ==
>
> Fedora does no longer ship any deliverables for i686, not even RPM
> repositories for i686 are published any longer. The kernel package
> itself also [[Changes/Stop Building i686 Kernels|dropped support for
> i686]] in Fedora 31, so there has not been any way to run Fedora on
> 32-bit x86 systems for years. Only a tiny fraction of all packages
> that are built on i686 are actually used (i.e. "multilib" support for
> Wine, Steam, etc. on x86_64).
Why isn't this as simple as:
1) Create an f37-multilib-build build tag with all supported arches + i686,
and an f37-multilib{,-candidate} build targets to use it (with destination tag
of f37-updates-candidate);
2) Drop i686 from f37-build tag;
3) Maintainers of wine and its deps etc. opt-in to i686 with a package.cfg:
[koji]
targets = f37-multilib
(Yes, that would have to be updated after branch point, but that could
possibly be automated.)
4) Everyone else leaves their spec files alone, no need to add ExcludeArch:
i686.
Would that work?
--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Mar 10, 2022 at 6:41 AM Paul Howarth wrote: > > On Thu, 10 Mar 2022 12:26:54 +0100 > Vitaly Zaitsev via devel wrote: > > > On 10/03/2022 11:55, Alex wrote: > > > May I suggest to leave at least the telnet protocol in curl-minimal > > > for debugging purposes. > > > > Telnet is an extremely vulnerable protocol. It must be disable. > > > > If you need it, you can always install libcurl-full. > > I wonder, do you have the "telnet" program installed on your machine(s)? "netcat" or "nc" is a much better, more scriptable tool than telnet. There is no reason for the telnet binary. And the telnet daemon, itself, is profoundly deprecated. > I'd be surprised if anyone using curl's telnet *client* support wasn't > aware that it was sending plain text over the network, possibly > including any credentials that were being used. A telnet client is, > however, a very useful debugging tool for various other network > protocols, not just the telnet protocol itself. That is, I believe, > what Alex was advocating for, since the curl tool's presence is > well-nigh universal and hence always available for debugging some > network issues. curl rather than netcat is simply not being aware of a better tool. Enjoy. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Wed, Mar 09, 2022 at 09:06:01AM -0600, Chris Adams wrote:
> So I guess this is the part I don't really understand (and I guess why I
> don't see this proposal as a "win") - how is i686 painful to package
> maintainers for non-delivered packages? Maybe I'm just missing
> something, but what causes issues?
>
Some of the Facebook/Meta open source projects I maintain are written with
only 64-bit platforms in mind, and I certainly appreciate the blanket
approval to drop %{ix86} without having to file a tracking bug.
Best regards,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Mar 10, 2022 at 11:55:39AM +0100, Alex wrote: > Hi. > > I have seen in https://lwn.net/Articles/887313/ that you plan to remove the > "telnet" protocol from curl-minimal. > > I use `curl -v telnet://` almost every day for debugging purpose just > because curl is in the most systems by default installed. > I know that there are some other tools like socat, normal telnet, nmap and so > on but this tools need to be installed which is not always possible when > fedora is used as docker image. > > there was also a short presentation about how to use curl telnet for debugging > on a curl up meeting. > https://curl.se/video/curlup-2017/2017-03-18_02_Aleksandar_Lazic_curl_for_network_debugging.mp4 > > May I suggest to leave at least the telnet protocol in curl-minimal for > debugging purposes. The problem is that there's many many debugging tools, and everybody has their own favourites. You like 'curl -v telnet://', I like 'ss' and 'tcpdump', somebody else likes 'lsfd' and so on. I agree that it *can* be very useful to have a debugging tool installed, but it is a very weak argument for adding those tools always by default. In particular, 'bash' is very useful for all kinds of debugging, but if possible, it is very good *not* to have it in minimal containers for the usual reasons (size, dependencies, exposure). The goal of this change is make it possible (ephasize *possible*) to have a smaller curl that is useful for the *very common* (emphasis again) tasks. So sorry, if you want to use curl-telnet for debugging, please just install curl-full. This is status quo, so with the proposed change you'll not be any worse off. That said: depending on how the proposal evolves, I think it make sense to add more virtual provides for each protocol, so that we can handle the cases where something moves from -minimal to -full more gracefully, so e.g. you'd be able to do 'dnf install "curl(protocol/telnet)" or something like that. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[fyi] Folly stack temporarily switched to Clang for Fedora 36+
Dear all, Just a heads-up that Folly and packages built against it are mostly* switched to build using Clang for the time being, when compiled on Fedora 36 and above. * the exception is watchman, which needs some work to get the latest version to build because upstream started porting some functionality to Rust, and wdt, which was archived externally, and now unarchived so we need to sort through half a year's worth of internal changes Internally, Meta uses Clang, so Fedora's GCC-built packages have been useful for surfacing GCC-specific issues, and we still plan to switch back to GCC in a future release once issues compiling it with GCC 11 and 12 are resolved. (GCC 11 issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 ; GCC 12 issue will be filed soon now that I've managed to rebuild the entire stack) F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-737d681400 F36: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5852540ea0 The specs of the packages switched to Clang can be used to easily rebuild with GCC, per the packaging guidelines, using `--without toolchain_clang`, and I plan on doing this to sort out issues. As a bonus, Folly's test suite which we have had to disable when building with GCC builds and runs fine with Clang on x86_64, and we're using this opportunity to start fixing architecture-specific assumptions causing test compile and runtime failures on non-Intel and non-64-bit architectures. We've also onboarded Folly and fb303 in PackIt: - https://github.com/facebook/folly/blob/main/.packit.yaml - https://github.com/facebook/fb303/blob/main/.packit.yaml so every tagged release will trigger CI and we get faster notice of any regression, esp for non-x86_64 which we don't run in-house. If there's any package I miss that also needs to be rebuilt, please let me know, and if the switch triggers some issue, let me know too. Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Pytest 7 coming to rawhide next week
On 04. 03. 22 12:16, Miro Hrončok wrote: Hello Pythonistas, I intent to upgrade pytest in Rawhide to 7.0.x next week. Building it now. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL moving to issues.redhat.com only long term
On Thu, 2022-03-10 at 19:28 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 10 March 2022 at 17:51, Simo Sorce wrote: > [...] > > Also I always resented that I need two separate accounts to deal with > > Fedora packages, > > It's been possible to log in with FAS credentials (automatically if you > have an active Kerberos ticket) into bugzilla for quite some time now. > I still have my old bugzilla account but I'm not sure it's required > anymore. Ah thanks, I missed that change, obviously my experience is now almost 2 decades long since I had to create my account, but I still think that having bugs and code in the same place is a big win for a project like Fedora, it is the same model followed by most upstream projects at this point and seem to be working well. > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL moving to issues.redhat.com only long term
On Thursday, 10 March 2022 at 17:51, Simo Sorce wrote: [...] > Also I always resented that I need two separate accounts to deal with > Fedora packages, It's been possible to log in with FAS credentials (automatically if you have an active Kerberos ticket) into bugzilla for quite some time now. I still have my old bugzilla account but I'm not sure it's required anymore. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Mar 10, 2022 at 11:55:39AM +0100, Alex wrote: > I have seen in https://lwn.net/Articles/887313/ that you plan to remove the > "telnet" protocol from curl-minimal. > I use `curl -v telnet://` almost every day for debugging purpose just > because curl is in the most systems by default installed. > I know that there are some other tools like socat, normal telnet, nmap and so > on but this tools need to be installed which is not always possible when > fedora is used as docker image. Or use bash? $ exec 3<>/dev/tcp/towel.blinkenlights.nl/23 $ cat <&3 -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL moving to issues.redhat.com only long term
On Thu, 2022-03-10 at 09:44 -0500, Colin Walters wrote: > > On Mon, Mar 7, 2022, at 12:44 PM, Josh Boyer wrote: > > Hi Fedora, CentOS, and EPEL Communities! > > > > As part of our continued 3 year major Red Hat Enterprise Linux > > release > > cadence, RHEL 9 development is starting to wrap up with the spring > > 2022 release coming soon. That means planning for the next release > > will start in earnest in the very near future. As some of you may > > know, Red Hat has been using both Bugzilla and Jira via > > issues.redhat.com for RHEL development for several years. Our > > intention is to move to using issues.redhat.com only for the major > > RHEL releases after RHEL 9. > > I think it's unfortunate to replace the FOSS Bugzilla with > proprietary software. I am eternally conflicted about this with > respect to GitHub (xref > https://blog.verbum.org/2020/12/03/still-on-github/ ) but...Jira is > not as compelling of a user experience upgrade. > > A continual challenge related to this I feel is using the same > software to track product bugs with potentially sensitive customer > data in it, and public open development. > > To link these things, I quite commonly move Bugzilla discussion that > has no need to be private to Github, because I know Github is always > public (from our PoV). > > One thing that may help is to at least use different themes (e.g. > blue colors for public CentOS issues, red for RHEL?) on > issues.redhat.com. > > Long term if Bugzilla slowly morphs into only being used by Fedora, > personally I'd prefer to have bugs/issues in gitlab instead. Given how we use bugzilla (we do not really use any big feature there) in Fedora I would give a big +1 to use an issue tracker embedded in the forge we use to store the packages (whether that is pagure, gitlab, github, or something else). Also I always resented that I need two separate accounts to deal with Fedora packages, I think reducing that to host all in the same place with the same authentication will also be a positive factor in fostering collaboration, less barriers. It will also reduce administrative overhead of having to configure components/ownership/etc in multiple places and what not. Finally by having issues and code in the same place it means we can easily connect commits/PRs/MRs to the issues meaning our issue tracker a lot more useful, and will allow us to have better content also in our updates, where today associating an update to an issue (a bz) is not happening as well as it could. HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL moving to issues.redhat.com only long term
On 10. 03. 22 17:33, Ben Cotton wrote: On Thu, Mar 10, 2022 at 9:45 AM Colin Walters wrote: Long term if Bugzilla slowly morphs into only being used by Fedora, personally I'd prefer to have bugs/issues in gitlab instead. I'm not sure how active the use of Red Hat Bugzilla is outside of the distribution space. I have no concerns about Bugzilla being yanked away from underneath us, but this does give us an opportunity to evaluate what we want in a bug tracker and whether or not Bugzilla meets the needs of the Fedora Project in 2022. Later this year, I'll be conducting a survey to see what features we want from a bug tracker so that we can start thinking about what best suits our needs. To be clear: this is not a "we're moving off of Bugzilla next year" statement. It's a "let's use this opportunity to make sure what we're doing works for us" statement. I am not concerned about Red Hat Bugzilla going away in the near- or medium-term. And perhaps not even in the long-term (although nothing lasts forever). I guess what I'm saying for now is let's not spend time speculating about what might happen or making rushed plans to move our bug tracking. I know that's not what Colin is doing, I just want to preempt the discussion. Look for a survey sometime after the F36 final release. Hey Ben, I volunteer to help you review the questions before the survey is actually conducted, if you are interested. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL moving to issues.redhat.com only long term
On Thu, Mar 10, 2022 at 9:45 AM Colin Walters wrote: > > Long term if Bugzilla slowly morphs into only being used by Fedora, > personally I'd prefer to have bugs/issues in gitlab instead. I'm not sure how active the use of Red Hat Bugzilla is outside of the distribution space. I have no concerns about Bugzilla being yanked away from underneath us, but this does give us an opportunity to evaluate what we want in a bug tracker and whether or not Bugzilla meets the needs of the Fedora Project in 2022. Later this year, I'll be conducting a survey to see what features we want from a bug tracker so that we can start thinking about what best suits our needs. To be clear: this is not a "we're moving off of Bugzilla next year" statement. It's a "let's use this opportunity to make sure what we're doing works for us" statement. I am not concerned about Red Hat Bugzilla going away in the near- or medium-term. And perhaps not even in the long-term (although nothing lasts forever). I guess what I'm saying for now is let's not spend time speculating about what might happen or making rushed plans to move our bug tracking. I know that's not what Colin is doing, I just want to preempt the discussion. Look for a survey sometime after the F36 final release. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL moving to issues.redhat.com only long term
On Thu, Mar 10, 2022 at 9:45 AM Colin Walters wrote: > Long term if Bugzilla slowly morphs into only being used by Fedora, > personally I'd prefer to have bugs/issues in gitlab instead. Yes, I personally think gitlab.com would be a good replacement for src.fedoraproject.org and bugzilla.redhat.com. - Ken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
gnome-backgrounds license change to CC-BY-SA from GPLv2
Hi While updating gnome-backgrounds, I realised that all the backgrounds were licensed under CC-BY-SA, rather than the specified GPLv2, and after checking with upstream, I updated the License field accordingly. Cheers -- https://amigadave.com/ signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [CentOS-devel] [EPEL-devel] RHEL moving to issues.redhat.com only long term
On Wed, Mar 9, 2022 at 5:05 PM Davide Cavalca via CentOS-devel wrote: > > On Mon, 2022-03-07 at 12:44 -0500, Josh Boyer wrote: > > Hi Fedora, CentOS, and EPEL Communities! > > > > As part of our continued 3 year major Red Hat Enterprise Linux > > release > > cadence, RHEL 9 development is starting to wrap up with the spring > > 2022 release coming soon. That means planning for the next release > > will start in earnest in the very near future. As some of you may > > know, Red Hat has been using both Bugzilla and Jira via > > issues.redhat.com for RHEL development for several years. Our > > intention is to move to using issues.redhat.com only for the major > > RHEL releases after RHEL 9. > > Thanks for sharing this Josh. Would you be able to expand on why Red > Hat chose to use Jira specifically here, and what benefits do you > forsee this switch will bring to CentOS down the road? Red Hat has long used Jira in various parts of the company, with JBoss and other products being heavy users for quite some time. Within the past few years we've consolidated a number of different instances into the single issues.redhat.com instance. That has enabled us to more easily plan and coordinate across our product portfolio. RHEL's decision is certainly informed by that same overall direction, but also specifically influenced by the limiting factors of using multiple tools to accomplish similar things. We've been using Bugzilla since Red Hat Linux days, and while it has served us well as a defect tracking backend, it was never designed to handle the complexity we have for planning and coordinating the varying scope of work we have. Aligning to a single tool will help us refine our processes internally. As for benefits to CentOS, or any of the other upstream projects we interact with, we'll have to see. I think the intention is to minimize overall impact to start with, and then evolve our workflows to bring further benefit where we can. That being said, we are certainly aware that we need to default to open issues to allow us to collaborate directly in the open source manner we've long held to be fundamental to our communities. I expect that approach to behave very similarly to how Bugzilla is used today. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-36-20220310.n.0 compose check report
No missing expected images. Failed openQA tests: 9/161 (aarch64), 8/229 (x86_64) New failures (same test not failed in Fedora-36-20220309.n.0): ID: 1167927 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1167927 ID: 1167938 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1167938 ID: 1168048 Test: x86_64 universal install_with_swap URL: https://openqa.fedoraproject.org/tests/1168048 ID: 1168076 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/1168076 Old failures (same test failed in Fedora-36-20220309.n.0): ID: 1167850 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1167850 ID: 1167873 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1167873 ID: 1167974 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1167974 ID: 1167980 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1167980 ID: 1168003 Test: x86_64 Workstation-upgrade gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1168003 ID: 1168004 Test: x86_64 Workstation-upgrade apps_startstop URL: https://openqa.fedoraproject.org/tests/1168004 ID: 1168017 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1168017 ID: 1168023 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1168023 ID: 1168026 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1168026 ID: 1168057 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/1168057 ID: 1168058 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1168058 ID: 1168123 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1168123 ID: 1168131 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1168131 Soft failed openQA tests: 2/229 (x86_64), 1/161 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-36-20220309.n.0): ID: 1167880 Test: x86_64 Silverblue-dvd_ostree-iso eog URL: https://openqa.fedoraproject.org/tests/1167880 ID: 1167898 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1167898 ID: 1167989 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1167989 Passed openQA tests: 151/161 (aarch64), 219/229 (x86_64) New passes (same test not passed in Fedora-36-20220309.n.0): ID: 1167947 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1167947 ID: 1167948 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1167948 ID: 1167993 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1167993 ID: 1168015 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1168015 ID: 1168055 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/1168055 ID: 1168056 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1168056 ID: 1168061 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/1168061 ID: 1168078 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/1168078 ID: 1168079 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1168079 ID: 1168080 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1168080 ID: 1168081 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/1168081 ID: 1168095 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/1168095 ID: 1168098 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1168098 ID: 1168099 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1168099 ID: 1168100 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/1168100 ID: 1168109 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/1168109 ID: 1168113 Test: aarch64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/1168113 ID: 1168115 Test: aarch64 universal install_anaconda_text@uefi URL: https://o
Fedora-IoT-36-20220310.0 compose check report
No missing expected images. Failed openQA tests: 3/15 (aarch64), 2/15 (x86_64) New failures (same test not failed in Fedora-IoT-36-20220309.0): ID: 1168236 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1168236 ID: 1168248 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1168248 Old failures (same test failed in Fedora-IoT-36-20220309.0): ID: 1168221 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1168221 ID: 1168233 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1168233 ID: 1168234 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1168234 Passed openQA tests: 13/15 (x86_64), 12/15 (aarch64) Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: Used mem changed from 180 MiB to 199 MiB System load changed from 0.27 to 0.59 Previous test data: https://openqa.fedoraproject.org/tests/1167145#downloads Current test data: https://openqa.fedoraproject.org/tests/1168235#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL moving to issues.redhat.com only long term
On Mon, Mar 7, 2022, at 12:44 PM, Josh Boyer wrote: > Hi Fedora, CentOS, and EPEL Communities! > > As part of our continued 3 year major Red Hat Enterprise Linux release > cadence, RHEL 9 development is starting to wrap up with the spring > 2022 release coming soon. That means planning for the next release > will start in earnest in the very near future. As some of you may > know, Red Hat has been using both Bugzilla and Jira via > issues.redhat.com for RHEL development for several years. Our > intention is to move to using issues.redhat.com only for the major > RHEL releases after RHEL 9. I think it's unfortunate to replace the FOSS Bugzilla with proprietary software. I am eternally conflicted about this with respect to GitHub (xref https://blog.verbum.org/2020/12/03/still-on-github/ ) but...Jira is not as compelling of a user experience upgrade. A continual challenge related to this I feel is using the same software to track product bugs with potentially sensitive customer data in it, and public open development. To link these things, I quite commonly move Bugzilla discussion that has no need to be private to Github, because I know Github is always public (from our PoV). One thing that may help is to at least use different themes (e.g. blue colors for public CentOS issues, red for RHEL?) on issues.redhat.com. Long term if Bugzilla slowly morphs into only being used by Fedora, personally I'd prefer to have bugs/issues in gitlab instead. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Fedora Linux 36 Beta is NO-GO
Due to outstanding blocker bugs[1], we do not have an F36 Beta RC. As a result, F36 Beta is NO-GO by default and today's Go/No-Go meeting is cancelled. The next Fedora Linux 36 Beta Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 17 March in #fedora-meeting. We will aim for the "target date #1" milestone of 22 March. The release schedule[3] has been updated accordingly. This change does not impact the final release date. [1] https://qa.fedoraproject.org/blockerbugs/milestone/36/beta/buglist [2] https://calendar.fedoraproject.org/meeting/10209/ [3] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards (System-Wide Change)
On Mon, Mar 7, 2022 at 4:01 PM Ben Cotton wrote:
(snip)
> == Scope ==
> Change owners
> * we will simiply stop building i686 pkg in rawhide
>
> Other developers
> * may notice the multilib i686 java missing.
> * it is up to them to drop i686 builds or to povide workaround (if possible)
Hm, that sounds potentially risky way to do this. And also just breaks
stuff and leaves it to the package maintainers to fix things.
Did you consider adding a %{java_arches} macro that can be used to
limit builds of noarch Java packages to non-i686 architectures?
Did you check the dependency tree of the non-noarch Java packages? For
example, are there any important, non-Java packages that depend on
architecture-specific Java packages, like JNA?
For example, these packages might be problematic:
- jna ← jline
- jna ← libvirt-java
- jna ← mariadb-java-client
- jna ← scala
- jna ← svnkit
Will package maintainers need to exclude all those packages (and, in
turn, all their dependent packages) from i686?
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Unretiring Icedtea-web
Ah, didn't see that on the page. Thanks! Le jeu. 10 mars 2022, à 09 h 24, Fabio Valentini a écrit : > On Thu, Mar 10, 2022 at 3:20 PM Ben Beasley > wrote: > > > > Since icedtea-web was orphaned for 6+ weeks, it was retired. You must > > therefore follow [1]. Note that: > > > > Retired Fedora packages (rawhide branch retired) require a > > re-review if they are retired for more than eight weeks or if there is > > no previous review of the package. > > > > This package has a previous review[2], but its eight-week retirement > > mark appears to be today exactly, so you’ll probably need it re-reviewed. > > Note that the previous package maintainer gave a reason was supplied > when they orphaned the package: > "Deployment tools have been deprecated for a while now" > > You might want to keep that in mind (or ask them why the package is > considered deprecated, if upstream is still active). > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unretiring Icedtea-web
On Thu, Mar 10, 2022 at 3:20 PM Ben Beasley wrote: > > Since icedtea-web was orphaned for 6+ weeks, it was retired. You must > therefore follow [1]. Note that: > > Retired Fedora packages (rawhide branch retired) require a > re-review if they are retired for more than eight weeks or if there is > no previous review of the package. > > This package has a previous review[2], but its eight-week retirement > mark appears to be today exactly, so you’ll probably need it re-reviewed. Note that the previous package maintainer gave a reason was supplied when they orphaned the package: "Deployment tools have been deprecated for a while now" You might want to keep that in mind (or ask them why the package is considered deprecated, if upstream is still active). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unretiring Icedtea-web
Since icedtea-web was orphaned for 6+ weeks, it was retired. You must therefore follow [1]. Note that: Retired Fedora packages (rawhide branch retired) require a re-review if they are retired for more than eight weeks or if there is no previous review of the package. This package has a previous review[2], but its eight-week retirement mark appears to be today exactly, so you’ll probably need it re-reviewed. – Ben [1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming [2] https://bugzilla.redhat.com/show_bug.cgi?id=691541 On 3/10/22 09:00, Steve Cossette wrote: Good morning all, First, I apologize if dumb questions are in this post -- still wet behind the ears when it comes to packaging. I was wondering what was needed to unretire a package, this one specifically: https://src.fedoraproject.org/rpms/icedtea-web It seems to still be developed (https://github.com/AdoptOpenJDK/IcedTea-Web/releases). I checked the Fedora docs on this: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/ and it says to click a "Take" button on the package sources page, but I see no such thing even after logging in. Just to be clear, I am in the packagers group. Thank you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Thu, Mar 10, 2022 at 9:07 AM Miro Hrončok wrote: Thanks for your feedback! > The word "encourage" is rather weird here. I am not a native speaker, but that > sound to me like we are agitating for active removals. Like we go to the > packagers and ask them: Could oyu please drop i686 from your leaf packages > now? > > Should this better say "allow"? Or "make it normal to". Yeah, I am not a native speaker either, but "encourage" was the best I could come up with at short notice. "Allow" doesn't seem right either, because this has technically always been "allowed". Maybe "simplify" or "prefer" (though I prefer "prefer" out of those two). > > Package maintainers are encouraged to actively stop building... > > Package maintainers are allowed to stop building... without fuzz. Opening > bugzillas or sending announcements is no longer required. Sounds good. I'll adapt the text in the proposal. > The *Detailed Description* section does not say what is changing. I'll add something here. Must have missed it when I filled out the template. > > In particular, stopping to build for i686 could potentially free up almost > half of the existing x86 builder resources in koji. > > This sounds like a goal. Don't mention it. Focus on people instead: In > particular, when packagers drop i686 they have more time to spend with their > children :D Sure. "Almost half" is an aspirational goal. Not the goal of the proposal itself. I'll remove that. Thanks again for your feedback. I sometimes struggle with technical documents as a non-native speaker. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Unretiring Icedtea-web
Good morning all, First, I apologize if dumb questions are in this post -- still wet behind the ears when it comes to packaging. I was wondering what was needed to unretire a package, this one specifically: https://src.fedoraproject.org/rpms/icedtea-web It seems to still be developed ( https://github.com/AdoptOpenJDK/IcedTea-Web/releases). I checked the Fedora docs on this: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/ and it says to click a "Take" button on the package sources page, but I see no such thing even after logging in. Just to be clear, I am in the packagers group. Thank you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 36 compose report: 20220310.n.0 changes
OLD: Fedora-36-20220309.n.0 NEW: Fedora-36-20220310.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 2 Dropped packages:0 Upgraded packages: 23 Downgraded packages: 0 Size of added packages: 142.42 MiB Size of dropped packages:0 B Size of upgraded packages: 1.15 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 19.46 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: SoaS raw-xz aarch64 Path: Spins/aarch64/images/Fedora-SoaS-36-20220309.n.0.aarch64.raw.xz = ADDED PACKAGES = Package: attract-mode-2.6.2-2.fc36 Summary: A graphical front-end for command line emulators RPMs:attract-mode attract-mode-data Size:9.44 MiB Package: pypy3.9-7.3.8-1.3.9.fc36 Summary: Python 3.9 implementation with a Just-In-Time compiler RPMs:pypy3.9 pypy3.9-devel pypy3.9-libs pypy3.9-test Size:132.98 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: anaconda-36.16.2-2.fc36 Old package: anaconda-36.16.2-1.fc36 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 19.82 MiB Size change: -3.12 KiB Changelog: * Mon Feb 21 2022 Martin Kolman - 36.16.2-2 - Do not copy resolv.conf to target system at the end of installation (rvykydal) - Do not copy /etc/resolv.conf to chroot before installation (rvykydal) Package: bcm283x-firmware-20220301-1.f47c013.fc36 Old package: bcm283x-firmware-20220209-1.577aef2.fc36 Summary: Firmware for the Broadcom bcm283x/bcm2711 used in the Raspberry Pi RPMs: bcm2711-firmware bcm2835-firmware bcm283x-firmware bcm283x-overlays Size: 13.75 MiB Size change: 893 B Changelog: * Tue Mar 08 2022 Peter Robinson - 20220301-1.f47c013 - Update to latest firmware - Fix issue on armhfp devices (rhbz #2061440) Package: ffmpeg-5.0-9.fc36 Old package: ffmpeg-5.0-8.fc36 Summary: A complete solution to record, convert and stream audio and video RPMs: ffmpeg-free ffmpeg-free-devel libavcodec-free libavcodec-free-devel libavdevice-free libavdevice-free-devel libavfilter-free libavfilter-free-devel libavformat-free libavformat-free-devel libavutil-free libavutil-free-devel libpostproc-free libpostproc-free-devel libswresample-free libswresample-free-devel libswscale-free libswscale-free-devel Size: 39.15 MiB Size change: 16.09 KiB Changelog: * Tue Mar 08 2022 Neal Gompa - 5.0-9 - Drop ffmpeg chromium support patch (#2061392) Package: kernel-5.17.0-0.rc7.116.fc36 Old package: kernel-5.17.0-0.rc5.102.fc36 Summary: The Linux kernel RPMs: kernel kernel-core kernel-debug kernel-debug-core kernel-debug-devel kernel-debug-devel-matched kernel-debug-modules kernel-debug-modules-extra kernel-debug-modules-internal kernel-devel kernel-devel-matched kernel-doc kernel-lpae kernel-lpae-core kernel-lpae-devel kernel-lpae-devel-matched kernel-lpae-modules kernel-lpae-modules-extra kernel-lpae-modules-internal kernel-modules kernel-modules-extra kernel-modules-internal Size: 678.94 MiB Size change: 2.09 MiB Changelog: * Tue Feb 22 2022 Fedora Kernel Team [5.17-0.rc5.038101e6b2cd.102] - redhat: configs: disable the surface platform (David Arcari) * Wed Feb 23 2022 Fedora Kernel Team [5.17-0.rc5.5c1ee569660d.103] - redhat: configs: Disable CONFIG_MPLS for s390x/zfcpdump (Guillaume Nault) - Fedora 5.17 configs round 1 (Justin M. Forbes) * Thu Feb 24 2022 Fedora Kernel Team [5.17-0.rc5.23d04328444a.104] - configs/process_configs.sh: Remove orig files (Prarit Bhargava) * Fri Feb 25 2022 Fedora Kernel Team [5.17-0.rc5.53ab78cd6d5a.105] - configs: clean up CONFIG_PAGE_TABLE_ISOLATION files (Ondrej Mosnacek) - redhat: configs: enable CONFIG_INTEL_PCH_THERMAL for RHEL x86 (David Arcari) - redhat/Makefile: Fix dist-dump-variables target (Prarit Bhargava) - redhat/configs: Enable DEV_DAX and DEV_DAX_PMEM modules on aarch64 for fedora (D Scott Phillips) - redhat/configs: Enable CONFIG_TRANSPARENT_HUGEPAGE on aarch64 for fedora (D Scott Phillips) * Sat Feb 26 2022 Fedora Kernel Team [5.17-0.rc5.9137eda53752.106] - configs/fedora: Enable the interconnect SC7180 driver built-in (Enric Balletbo i Serra) * Mon Feb 28 2022 Fedora Kernel Team [5.17-0.rc6.108] - redhat: configs: change aarch64 default dma domain to lazy (Jerry Snitselaar) - redhat: configs: disable ATM protocols (Davide Caratti) * Tue Mar 01 2022 Fedora Kernel Team [5.17-0.rc6.719fce7539cd.109] - Build CROS_EC Modules (Jason Montleon) * Wed Mar 02 2022 Fedora Kernel Team [5.17-0.rc6.fb184c4af9b9.110] - redhat: Fix "make dist-release-finish" to use the correct NVR variables (Neal Gompa) [2053836] * Thu Mar 03 2022 Fed
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Mar 10 2022 at 11:55:39 AM +0100, Alex wrote: I have seen in https://lwn.net/Articles/887313/ that you plan to remove the "telnet" protocol from curl-minimal. Next up: I see you're planning to remove the brotli compression support. I think that's actually used along with gzip for HTTP/2. Probably don't want to remove that. The trick is that HTTP/1.1 has ossified, so you can only safely enable it for HTTP/2 and up (where the content encoding is encrypted, so middleboxes can't see it and screw it up). I'm sure curl has thought of all this already. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, 10 Mar 2022 14:10:17 +0100 Vitaly Zaitsev via devel wrote: > On 10/03/2022 13:47, Alex wrote: > > Here a example test. I know that this could be also done with https but > > it's a understandable example, IMHO. > > Better example: > openssl s_client -connect example.org:443 > Agree when openssl is installed. Is openssl s_client installed by default in F37? I understand your position, it was just a question if this small but useful protocol could stay in curl-minimal package. As I don't maintain the code of course I'm fine with the decision of the community and the code maintain Person(s). Regards Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On 10/03/2022 12:41, Paul Howarth wrote: I wonder, do you have the "telnet" program installed on your machine(s)? No. All my services use TLS. openssl s_client -connect example.org:443 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On 10/03/2022 13:47, Alex wrote: Here a example test. I know that this could be also done with https but it's a understandable example, IMHO. Better example: openssl s_client -connect example.org:443 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, 10 Mar 2022 11:41:15 + Paul Howarth wrote: > On Thu, 10 Mar 2022 12:26:54 +0100 > Vitaly Zaitsev via devel wrote: > > > On 10/03/2022 11:55, Alex wrote: > > > May I suggest to leave at least the telnet protocol in curl-minimal > > > for debugging purposes. > > > > Telnet is an extremely vulnerable protocol. It must be disable. > > > > If you need it, you can always install libcurl-full. > > I wonder, do you have the "telnet" program installed on your machine(s)? > > I'd be surprised if anyone using curl's telnet *client* support wasn't > aware that it was sending plain text over the network, possibly > including any credentials that were being used. A telnet client is, > however, a very useful debugging tool for various other network > protocols, not just the telnet protocol itself. That is, I believe, > what Alex was advocating for, since the curl tool's presence is > well-nigh universal and hence always available for debugging some > network issues. Thanks Paul, that's exactly my point. I agree that Telnet should not be offered as a service to the outside world, but for debugging is it very helpfully. Let me try to explain what the "telnet://" means for me. ``` With the telnet protocol in curl is a TCP Socket connection created and therefore can be tested if a TCP connection to a remote destination can be successful created. ``` Here a example test. I know that this could be also done with https but it's a understandable example, IMHO. ``` echo -e 'GET / HTTP/1.1\r\nHost: www.google.com\r\n\r\n'|curl --ipv4 \ -vso /dev/null --ssl --tlsv1.3 telnet://www.google.com:443 * Trying 172.217.19.132:443... * TCP_NODELAY set * Connected to www.google.com (172.217.19.132) port 443 (#0) * Closing connection 0 ``` > Paul. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List > Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Mar 10, 2022 at 7:09 AM Tom Hughes wrote: > > On 10/03/2022 11:51, Neal Gompa wrote: > > On Thu, Mar 10, 2022 at 6:49 AM Daniel P. Berrangé > > wrote: > > > >> Everyone has their own conflicting idea of what is 'minimal'. There's > >> no nice way to solve this problem in Fedora without curl upstream > >> supporting dlopen modules per protoocol, allowing us to package each > >> protocol independantly. > > > > Has anyone asked upstream about that yet? > > There is a brief discussion at https://github.com/curl/curl/issues/349 > where upstream called it an "interesting idea" but it doesn't look like > anybody took it on. > Yeah, it looks like it was accepted as a TODO that someone could contribute: https://github.com/curl/curl/commit/8204844f470f583d5d8e0a3bfa85438a7cc40f2c -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On 10/03/2022 11:51, Neal Gompa wrote: On Thu, Mar 10, 2022 at 6:49 AM Daniel P. Berrangé wrote: Everyone has their own conflicting idea of what is 'minimal'. There's no nice way to solve this problem in Fedora without curl upstream supporting dlopen modules per protoocol, allowing us to package each protocol independantly. Has anyone asked upstream about that yet? There is a brief discussion at https://github.com/curl/curl/issues/349 where upstream called it an "interesting idea" but it doesn't look like anybody took it on. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Fedocal] Reminder meeting : ELN SIG
Dear all, You are kindly invited to the meeting: ELN SIG on 2022-03-11 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/10133/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Mar 10, 2022 at 6:49 AM Daniel P. Berrangé wrote: > > On Thu, Mar 10, 2022 at 12:26:54PM +0100, Vitaly Zaitsev via devel wrote: > > On 10/03/2022 11:55, Alex wrote: > > > May I suggest to leave at least the telnet protocol in curl-minimal for > > > debugging purposes. > > > > Telnet is an extremely vulnerable protocol. It must be disable. > > > > If you need it, you can always install libcurl-full. > > Nicely illustrating the key tension of the libcurl-minimal vs libcurl-full > split. > > If you want to use SFTP which is secure, you have to install libcurl-full, > which brings in support for the horribly insecure Telnet protocol and more, > increasing the attack surface for every application using curl, unless > they set CURLOPT_PROTOCOLS, which most don't :-( > > Everyone has their own conflicting idea of what is 'minimal'. There's > no nice way to solve this problem in Fedora without curl upstream > supporting dlopen modules per protoocol, allowing us to package each > protocol independantly. > Has anyone asked upstream about that yet? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Mar 10, 2022 at 12:26:54PM +0100, Vitaly Zaitsev via devel wrote: > On 10/03/2022 11:55, Alex wrote: > > May I suggest to leave at least the telnet protocol in curl-minimal for > > debugging purposes. > > Telnet is an extremely vulnerable protocol. It must be disable. > > If you need it, you can always install libcurl-full. Nicely illustrating the key tension of the libcurl-minimal vs libcurl-full split. If you want to use SFTP which is secure, you have to install libcurl-full, which brings in support for the horribly insecure Telnet protocol and more, increasing the attack surface for every application using curl, unless they set CURLOPT_PROTOCOLS, which most don't :-( Everyone has their own conflicting idea of what is 'minimal'. There's no nice way to solve this problem in Fedora without curl upstream supporting dlopen modules per protoocol, allowing us to package each protocol independantly. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
Am 10.03.22 um 12:26 schrieb Vitaly Zaitsev via devel: On 10/03/2022 11:55, Alex wrote: May I suggest to leave at least the telnet protocol in curl-minimal for debugging purposes. Telnet is an extremely vulnerable protocol. It must be disable. It should not be used on a regular basis, but disabling in a tool is just non helpful fanatism. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, 10 Mar 2022 12:26:54 +0100 Vitaly Zaitsev via devel wrote: > On 10/03/2022 11:55, Alex wrote: > > May I suggest to leave at least the telnet protocol in curl-minimal > > for debugging purposes. > > Telnet is an extremely vulnerable protocol. It must be disable. > > If you need it, you can always install libcurl-full. I wonder, do you have the "telnet" program installed on your machine(s)? I'd be surprised if anyone using curl's telnet *client* support wasn't aware that it was sending plain text over the network, possibly including any credentials that were being used. A telnet client is, however, a very useful debugging tool for various other network protocols, not just the telnet protocol itself. That is, I believe, what Alex was advocating for, since the curl tool's presence is well-nigh universal and hence always available for debugging some network issues. Paul. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On 10/03/2022 11:55, Alex wrote: May I suggest to leave at least the telnet protocol in curl-minimal for debugging purposes. Telnet is an extremely vulnerable protocol. It must be disable. If you need it, you can always install libcurl-full. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
Hi. I have seen in https://lwn.net/Articles/887313/ that you plan to remove the "telnet" protocol from curl-minimal. I use `curl -v telnet://` almost every day for debugging purpose just because curl is in the most systems by default installed. I know that there are some other tools like socat, normal telnet, nmap and so on but this tools need to be installed which is not always possible when fedora is used as docker image. there was also a short presentation about how to use curl telnet for debugging on a curl up meeting. https://curl.se/video/curlup-2017/2017-03-18_02_Aleksandar_Lazic_curl_for_network_debugging.mp4 May I suggest to leave at least the telnet protocol in curl-minimal for debugging purposes. Best regards Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20220310.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220309.0): ID: 1167584 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1167584 ID: 1167590 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1167590 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-35-20220310.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220309.0): ID: 1167568 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1167568 ID: 1167574 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1167574 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: undefined symbol `__libc_stack_end' in F36/Rawhide
* Ron Olson: > Building swiftlang on F36/Rawhide results in a a failure that, boiled down to > its essence, appears to be: > > /usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32 against > undefined symbol `__libc_stack_end' can not be used when making a shared > object; recompile with -fPIC > > It compiles fine on 35 so I’m guessing glibc has been updated; a bunch of web > searching hasn’t come up with any useful suggestions, the one ancient > Bugzilla ticket I found was not resolved. > > Any suggestions on what to do about this? How is __libc_stack_end declared in the sources? This could be a Clang bug or a bug in the source package. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On 09. 03. 22 18:05, Fabio Valentini wrote: On Wed, Mar 9, 2022 at 5:55 PM Miro Hrončok wrote: (...) OK then, I can +1 that, but please: Make that more obvious in the proposal. Honest question: How do I do that? Do you have a suggestion? > Encourage Dropping Unused / Leaf Packages on i686 The word "encourage" is rather weird here. I am not a native speaker, but that sound to me like we are agitating for active removals. Like we go to the packagers and ask them: Could oyu please drop i686 from your leaf packages now? Should this better say "allow"? Or "make it normal to". > Package maintainers are encouraged to actively stop building... Package maintainers are allowed to stop building... without fuzz. Opening bugzillas or sending announcements is no longer required. The *Detailed Description* section does not say what is changing. > In particular, stopping to build for i686 could potentially free up almost half of the existing x86 builder resources in koji. This sounds like a goal. Don't mention it. Focus on people instead: In particular, when packagers drop i686 they have more time to spend with their children :D > Fedora packages will incrementally drop support for the i686 architecture (32-bit x86), where this support is no longer required. This is intended to reduce resource consumption of build servers. Same thing. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
