Comp groups
Hello, all. I've recently learnt that there are two perl-related groups in comps (which allows you to install groups of rpms with the syntax "dnf group install ". These groups are perl and perl-web. They are defined as follows: Group: Perl Development Description: Support for developing programs in the Perl programming language. Mandatory Packages: perl Default Packages: git-cpan-patch perl-CPAN-Uploader perltidy Optional Packages: cpanspec perl-Task-Catalyst vim-perl-support Group: Perl for Web Description: Basic Perl web application support. Mandatory Packages: ImageMagick-perl mod_perl perl perl-App-cpanminus perl-CPAN perl-CPANPLUS perl-DBD-MySQL perl-DBD-SQLite perl-MongoDB Both of these require a pretty significant overhaul, IMHO. Unless someone has any objections, I will file a PR on the fedora-comps repo replacing the contents of the perl group with the following: Mandatory Packages: perl Default Packages: git-cpan-patch perl-CPAN-Uploader perl-Data-Printer perl-Devel-Confess perl-Devel-NYTProf perl-Dist-Zilla perl-Module-Build-Tiny perl-Perl-Critic perl-Pod-Readme perl-Software-License perltidy Optional Packages: cpanspec perl-Code-TidyAll perl-Modern-Perl vim-perl-support Another commit will make perl-web the following group: Mandatory Packages: perl Default Packages: perl-CGI-Formbuilder perl-HTML-FormHandler perl-HTTP-BrowserDetect perl-MIME-Types perl-Plack perl-XML-Atom perl-XML-RSS Optional Packages: perl-Attean perl-Dancer2 perl-Mojolicious perl-Task-Catalyst perl-Template Thoughts? Suggestions? Emmanuel -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 End Of Life in one week
On Tue, May 14, 2024 at 3:57 PM Jan Pazdziora wrote: > > Where did the different date of 2024-05-21 come from and where was > it tracked? It comes from the fact that the EOL date for Fedora Linux N is 4 weeks from the release of the Fedora Linux N+2 final, so it's tracked on the F40 schedule. Because the schedules are maintained as separate files, it's easy to forget to update N-2 when the N release date slips, which is likely what happened here. The EOL dates were not on the Fedora Linux N schedules until F38 for that very reason. At any rate, I've opened https://pagure.io/fedora-pgm/schedule/issue/142 for amoloney to update the F38 schedule. -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 38 End Of Life in one week
On Tue, May 14, 2024 at 11:03:07PM +0530, Samyak Jain wrote: > Hello all, > > Fedora Linux 38 will go end of life for updates and support on > 2024-05-21. This announce comes as a surprise becuase it does not match the https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html schedule which says the EOL should be today. This is also the information that https://endoflife.date/fedora seems to use. Where did the different date of 2024-05-21 come from and where was it tracked? > [1]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule > [2]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades Neither of these have information specific about Fedora 38. -- Jan Pazdziora | OpenShift AI | Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Input Requested] Ending support for i686 builds of Node.js
On Tue, May 14, 2024 at 9:43 PM Stephen Gallagher wrote: > > Do you think that's worth a separate Change from the Node.js 22 Change > I already filed? I can amend that (and ask FESCo to re-vote based on > new information). I think the change is significant enough, yes. Having a separate change would lead to more visibility, but I think just amending the existing Change and having FESCo re-approve would be fine too. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Input Requested] Ending support for i686 builds of Node.js
On Tue, May 14, 2024 at 3:38 PM Fabio Valentini wrote: > > On Tue, May 14, 2024 at 9:33 PM Stephen Gallagher wrote: > > > > On Mon, May 13, 2024 at 8:21 AM Fabio Valentini > > wrote: > > > > > > On Mon, May 13, 2024 at 2:02 PM Stephen Gallagher > > > wrote: > > > > > > > > Upstream Node.js has not supported the i686 architecture officially > > > > since Node.js 10.x (released in 2018). As of Node.js 22, it appears > > > > that v8 will no longer build at all on that architecture. > > > > > > > > I'm not particularly willing to go to any great lengths to keep it > > > > alive on i686, but I want to know if there's anyone out there who is > > > > *desperately* in need of it in Fedora. > > > > > > Most (all?) nodejs "library" packages were retired, right? > > > > > > And even if there are still some of them around, most of them should > > > be "noarch"? In that case, they shouldn't need adaptations, since koji > > > now no longer schedules noarch builds to run on i686. > > > But those nodejs packages that are not noarch (however many of them > > > are still in Fedora) will need ExcludeArch: i686. > > > > > > However, another problem might arched non-nodejs packages that need > > > nodejs at build-time. It looks like there's a bunch of packages that > > > "BuildRequires: nodejs" - among them, chromium, firefox, thunderbird, > > > RStudio, qt?-webengine, tinygo, etc. I'm not sure how many of these > > > still build on i686, but some might not be able to disable the nodejs > > > BR, so they would need to stop building on i686 too. > > > > > > > I've looked through most of these and they generally seem to be either > > noarch or else using one of %nodejs_arches or %java_arches for their > > BuildArch. If I make this change, I'll adapt %nodejs_arches to exclude > > i686 and %java_arches already does so. > > That sounds good to me, but it doesn't really answer my question: > Those packages dropping i686 might cause follow-up issues in *their* > dependent packages, and so on. > If they are leaf packages, that's not an issue, but dropping > architecture support is a breaking change that needs to be > coordinated. > > So what you're *really* saying is that you will drop i686 from %nodejs_arches? > I think that has a big enough (and possibly ill-defined) scope that it > would qualify as a Change. > Do you think that's worth a separate Change from the Node.js 22 Change I already filed? I can amend that (and ask FESCo to re-vote based on new information). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Input Requested] Ending support for i686 builds of Node.js
On Tue, May 14, 2024 at 9:33 PM Stephen Gallagher wrote: > > On Mon, May 13, 2024 at 8:21 AM Fabio Valentini wrote: > > > > On Mon, May 13, 2024 at 2:02 PM Stephen Gallagher > > wrote: > > > > > > Upstream Node.js has not supported the i686 architecture officially > > > since Node.js 10.x (released in 2018). As of Node.js 22, it appears > > > that v8 will no longer build at all on that architecture. > > > > > > I'm not particularly willing to go to any great lengths to keep it > > > alive on i686, but I want to know if there's anyone out there who is > > > *desperately* in need of it in Fedora. > > > > Most (all?) nodejs "library" packages were retired, right? > > > > And even if there are still some of them around, most of them should > > be "noarch"? In that case, they shouldn't need adaptations, since koji > > now no longer schedules noarch builds to run on i686. > > But those nodejs packages that are not noarch (however many of them > > are still in Fedora) will need ExcludeArch: i686. > > > > However, another problem might arched non-nodejs packages that need > > nodejs at build-time. It looks like there's a bunch of packages that > > "BuildRequires: nodejs" - among them, chromium, firefox, thunderbird, > > RStudio, qt?-webengine, tinygo, etc. I'm not sure how many of these > > still build on i686, but some might not be able to disable the nodejs > > BR, so they would need to stop building on i686 too. > > > > I've looked through most of these and they generally seem to be either > noarch or else using one of %nodejs_arches or %java_arches for their > BuildArch. If I make this change, I'll adapt %nodejs_arches to exclude > i686 and %java_arches already does so. That sounds good to me, but it doesn't really answer my question: Those packages dropping i686 might cause follow-up issues in *their* dependent packages, and so on. If they are leaf packages, that's not an issue, but dropping architecture support is a breaking change that needs to be coordinated. So what you're *really* saying is that you will drop i686 from %nodejs_arches? I think that has a big enough (and possibly ill-defined) scope that it would qualify as a Change. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Input Requested] Ending support for i686 builds of Node.js
On Mon, May 13, 2024 at 8:21 AM Fabio Valentini wrote: > > On Mon, May 13, 2024 at 2:02 PM Stephen Gallagher wrote: > > > > Upstream Node.js has not supported the i686 architecture officially > > since Node.js 10.x (released in 2018). As of Node.js 22, it appears > > that v8 will no longer build at all on that architecture. > > > > I'm not particularly willing to go to any great lengths to keep it > > alive on i686, but I want to know if there's anyone out there who is > > *desperately* in need of it in Fedora. > > Most (all?) nodejs "library" packages were retired, right? > > And even if there are still some of them around, most of them should > be "noarch"? In that case, they shouldn't need adaptations, since koji > now no longer schedules noarch builds to run on i686. > But those nodejs packages that are not noarch (however many of them > are still in Fedora) will need ExcludeArch: i686. > > However, another problem might arched non-nodejs packages that need > nodejs at build-time. It looks like there's a bunch of packages that > "BuildRequires: nodejs" - among them, chromium, firefox, thunderbird, > RStudio, qt?-webengine, tinygo, etc. I'm not sure how many of these > still build on i686, but some might not be able to disable the nodejs > BR, so they would need to stop building on i686 too. > I've looked through most of these and they generally seem to be either noarch or else using one of %nodejs_arches or %java_arches for their BuildArch. If I make this change, I'll adapt %nodejs_arches to exclude i686 and %java_arches already does so. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 38 End Of Life in one week
Hello all, Fedora Linux 38 will go end of life for updates and support on 2024-05-21. No more updates of any kind, including security updates or security announcements, will be available for Fedora Linux 38 after the said date. All the updates of Fedora Linux 38 being pushed to stable will be stopped as well. Fedora Linux 39 will continue to receive updates until approximately one month after the release of Fedora Linux 41. The maintenance schedule of Fedora Linux releases is documented on the Fedora Project wiki [1]. The Fedora Project wiki also contains instructions[2] on how to upgrade from a previous release of Fedora Linux to a version receiving updates. This email template is also in https://pagure.io/releng if you wish to propose improvements or changes to it. Regards, Samyak Jain Fedora Release Engineering [1]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule [2]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
Similarly, python-llvmlite requires llvm14, and the upcoming upstream release will require llvm15 (with a medium-term plan to get to llvm17). For complex projects that are tightly coupled to the LLVM implementation like this, there is generally *absolutely nothing* that downstream packagers can do to get upstream support for current LLVM releases to happen faster. This is a well-maintained and responsive package that is, among other things, the basis of the JIT implementation for the very popular numba package, https://numba.pydata.org/. On 5/14/24 9:46 AM, Frantisek Zatloukal wrote: On Mon, May 13, 2024 at 3:42 PM Vít Ondruch wrote: My point is that we can spent time maintaining llvm00 - llvm99 packages or we can spent time adjusting upstream projects to be compatible with the latest llvm. There are many projects that require a fair amount of work to be ported to newer llvm versions, take intel-igc for example ( https://github.com/intel/intel-graphics-compiler ) where there is now more than a year long process to slowly get it to llvm 16 (yeah, that's not a typo). -- Best regards / S pozdravem, František Zatloukal Senior Quality Engineer Red Hat -- ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2024-05-15 from 18:00:00 to 19:00:00 UTC At fedora-meet...@chat.fedoraproject.org The meeting will be about: https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #topic aloha #topic EPEL Issues https://pagure.io/epel/issues * https://pagure.io/epel/issues?tags=meeting=Open #topic Old Business (if needed) #topic General Issues / Open Floor Source: https://calendar.fedoraproject.org//meeting/10780/ -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 38 End Of Life in one week
Hello all, Fedora Linux 38 will go end of life for updates and support on 2024-05-21. No more updates of any kind, including security updates or security announcements, will be available for Fedora Linux 38 after the said date. All the updates of Fedora Linux 38 being pushed to stable will be stopped as well. Fedora Linux 39 will continue to receive updates until approximately one month after the release of Fedora Linux 41. The maintenance schedule of Fedora Linux releases is documented on the Fedora Project wiki [1]. The Fedora Project wiki also contains instructions[2] on how to upgrade from a previous release of Fedora Linux to a version receiving updates. This email template is also in https://pagure.io/releng if you wish to propose improvements or changes to it. Regards, Samyak Jain Fedora Release Engineering [1]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule [2]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is Fedora 38 going EOL?
On Tue, May 14, 2024 at 06:11:15PM GMT, Sérgio Basto wrote: > On Tue, 2024-05-14 at 14:53 +0200, Miro Hrončok wrote: > > Hi, > > > > When is Fedora 38 going EOL? > > > > https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html say > > s today > > https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html say > > next week > > > > Which one is correct? > > Bodhi says: > > The following releases are appoaching End-Of-Life: > > Fedora 38 Containers will go EOL on 2024-05-21 > Fedora 38 Flatpaks will go EOL on 2024-05-21 > Fedora 38 Modular will go EOL on 2024-05-21 > Fedora 38 will go EOL on 2024-05-21 > > Consider that before submitting any update for those release Yes, it should be next week, IMHO. At least release engineering have been planning for it being next week. kevin 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is Fedora 38 going EOL?
On Tue, 2024-05-14 at 14:53 +0200, Miro Hrončok wrote: > Hi, > > When is Fedora 38 going EOL? > > https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html say > s today > https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html say > next week > > Which one is correct? Bodhi says: The following releases are appoaching End-Of-Life: Fedora 38 Containers will go EOL on 2024-05-21 Fedora 38 Flatpaks will go EOL on 2024-05-21 Fedora 38 Modular will go EOL on 2024-05-21 Fedora 38 will go EOL on 2024-05-21 Consider that before submitting any update for those release > > Thanks, > -- > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 14. 05. 24 16:02, Vít Ondruch wrote: Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a): On 13. 05. 24 15:38, Vít Ondruch wrote: And TBH, for me as a Fedora used with no special interest in Python, the current Python versioning sucks hard. How am I supposed to tell what is the current version just looking at e.g. the repository? Is it `python3.12` or is it already `python3.13`? Despite I have spent with Fedora more then a decade, answering such simple question is not trivial for me. I guess that for the user, the easiest way is to look at the RPMs. Users barely look into our repositories. ~~~ $ rpm -q python package python is not installed ~~~ Why? Because it is called python3. $ rpm -q python3 python3-3.12.3-2.fc39.x86_64 I thought this discussion is about python3.12 vs python3.13, not about python vs python3. I supposed the reason it is called python3 and not python is well know at this point (but if it is not, let me know and I'll try to explain). We are in 2024, so I suppose we could rename everything python3 to python now, I just worry that it would be a lot of effort for not much benefit. Even if `# dnf install python` does something, it still won't install `python` package. Well, it installs the python-unverisoned-command package. Which requires python3. So it install python. Why does it matter? What are you trying to demonstrate here? (Don't take me wrong, I always appreciate good criticism, I juts don't understand what are you suggesting we should do.) Do you suggest to rename python-unversioned-command to python? Do you suggest to rename python3 to python? Do you suggest to rename the python3.12 component to python? (As names of the components started this discussion.) Or is it something else? -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning xu4
For many years I have maintained xu4 (https://xu4.sourceforge.net/, https://src.fedoraproject.org/rpms/xu4/), an open source engine which can run the freely available Ultima IV game files. When the original code was subsumed into the ScummVM engine, I was conflicted about what should be done with the package, but now there is a new upstream who is further developing the code in a separate direction from what ScummVM is doing. Unfortunately that new upstream has added a number of new dependencies, including a custom scripting language (Boron) and I simply have not had time to track down all of these dependencies and get them added to the distribution. Upstream appears to fundamentally disagree with the concept of unbundling in any case and I don't really feel like fighting that battle, so I feel it's best to simply let the outdated package I have been maintaining exit the distribution. However, if someone wants to pick it up, it's there for the taking. - J< -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a): On 13. 05. 24 15:38, Vít Ondruch wrote: And TBH, for me as a Fedora used with no special interest in Python, the current Python versioning sucks hard. How am I supposed to tell what is the current version just looking at e.g. the repository? Is it `python3.12` or is it already `python3.13`? Despite I have spent with Fedora more then a decade, answering such simple question is not trivial for me. I guess that for the user, the easiest way is to look at the RPMs. Users barely look into our repositories. ~~~ $ rpm -q python package python is not installed ~~~ Why? Even if `# dnf install python` does something, it still won't install `python` package. Vít OpenPGP_signature.asc Description: OpenPGP digital 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Dne 14. 05. 24 v 2:03 Stephen Gallagher napsal(a): On Mon, May 13, 2024 at 10:09 AM Vít Ondruch wrote: Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a): On 5/13/24 16:09, Vít Ondruch wrote: Dne 13. 05. 24 v 11:39 Florian Festi napsal(a): %patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions. Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented? No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense. Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues. I have no hopes convincing you. But thank you for clarification. This last statement was unnecessarily hostile. You are better than that, Vit. Sorry. What I wanted is just to explain some context and somehow said that while I would like have this possibility, I am not e.g. going to open upstream RFE ticket. I assume that Panu's statement above - "that's the only place where they make sense" - was an unintentional overstatement and should have been read as "that's the only place we could think of where it made sense". You've now provided a reasonable argument for why %check might make sense. To expand on your example a bit, what I think you're saying is that in the case of Ruby, we ship not only the binary bits but also the Ruby tests in the RPMs. For sensible reasons, we want to deliver those unmodified from upstream, but we also want to be able to run them in the %check section which necessitates making some modifications due to the limitations and restrictions present in the Koji build system. By being able to constrain the patch application to the %check section (which, if I remember correctly is run AFTER the creation of the binary RPMs) means that we can package the unmodified sources without having to resort to custom trickery in the specfile (copying all the tests to a new location to modify them before running or some such). Is that a fair restatement of your use-case, Vit? Right, that is fair. Thank you for taking time to make sure my use case is properly understood. Appreciate that. Vít OpenPGP_signature.asc Description: OpenPGP digital 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Dne 14. 05. 24 v 11:26 Tim Landscheidt napsal(a): Vít Ondruch wrote: %patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions. Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented? No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense. Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues. I have no hopes convincing you. But thank you for clarification. This feels like the tests should be patched (and these patches upstreamed) to behave differently depending on some option I don't disagree. I am all for upstreaming. But there are more pros and cons. Vít , and the spec file should then use this option to trigger the correct one. I don't know enough about Ruby to suggest The Way™ to pass this option; but usually environment variables will do. (Other test suites have tags that can be used to select tests that should (not) be run which might be another (upstreamable) solution.) Tim OpenPGP_signature.asc Description: OpenPGP digital 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On Mon, May 13, 2024 at 3:42 PM Vít Ondruch wrote: > > My point is that we can spent time maintaining llvm00 - llvm99 packages > or we can spent time adjusting upstream projects to be compatible with > the latest llvm. > There are many projects that require a fair amount of work to be ported to newer llvm versions, take intel-igc for example ( https://github.com/intel/intel-graphics-compiler ) where there is now more than a year long process to slowly get it to llvm 16 (yeah, that's not a typo). -- Best regards / S pozdravem, František Zatloukal Senior Quality Engineer Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20240514.n.0 changes
OLD: Fedora-Rawhide-20240513.n.0 NEW: Fedora-Rawhide-20240514.n.0 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 6 Dropped packages:1 Upgraded packages: 64 Downgraded packages: 3 Size of added packages: 1.12 MiB Size of dropped packages:1.67 MiB Size of upgraded packages: 4.58 GiB Size of downgraded packages: 4.38 MiB Size change of upgraded packages: 17.94 MiB Size change of downgraded packages: 4.76 KiB = ADDED IMAGES = = DROPPED IMAGES = Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20240513.n.0.x86_64.iso Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20240513.n.0.aarch64.iso = ADDED PACKAGES = Package: python-fortranformat-2.0.0-1.fc41 Summary: FORTRAN format interpreter for Python RPMs:python3-fortranformat Size:65.01 KiB Package: rust-cargo-util-schemas-0.2.0-1.fc41 Summary: Deserialization schemas for Cargo RPMs:rust-cargo-util-schemas+default-devel rust-cargo-util-schemas-devel Size:37.92 KiB Package: rust-gstreamer-allocators-0.22.0-1.fc41 Summary: Rust bindings for GStreamer Allocators library RPMs:rust-gstreamer-allocators+default-devel rust-gstreamer-allocators+v1_16-devel rust-gstreamer-allocators+v1_18-devel rust-gstreamer-allocators+v1_20-devel rust-gstreamer-allocators+v1_22-devel rust-gstreamer-allocators+v1_24-devel rust-gstreamer-allocators-devel Size:96.99 KiB Package: rust-gstreamer-allocators-sys-0.22.0-1.fc41 Summary: FFI bindings to libgstallocators-1.0 RPMs:rust-gstreamer-allocators-sys+default-devel rust-gstreamer-allocators-sys+v1_16-devel rust-gstreamer-allocators-sys+v1_18-devel rust-gstreamer-allocators-sys+v1_20-devel rust-gstreamer-allocators-sys+v1_22-devel rust-gstreamer-allocators-sys+v1_24-devel rust-gstreamer-allocators-sys-devel Size:83.71 KiB Package: rust-sequoia-directories-0.1.0-1.fc41 Summary: Directories used by Sequoia RPMs:rust-sequoia-directories+default-devel rust-sequoia-directories-devel Size:32.12 KiB Package: vdo-8.3.0.70-1.fc41 Summary: Management tools for Virtual Data Optimizer RPMs:vdo vdo-support Size:826.37 KiB = DROPPED PACKAGES = Package: rocm-device-libs-17.2-5.fc41 Summary: AMD ROCm LLVM bit code libraries RPMs:rocm-device-libs Size:1.67 MiB = UPGRADED PACKAGES = Package: ansible-collection-awx-awx-24.3.1-1.fc41 Old package: ansible-collection-awx-awx-24.2.0-1.fc41 Summary: Ansible modules and plugins for working with AWX RPMs: ansible-collection-awx-awx Size: 104.93 KiB Size change: 1.44 KiB Changelog: * Mon May 13 2024 Andrew Heath - 24.3.1-1 - Update to 24.3.1 Package: astral-0.2.1-1.fc41 Old package: astral-0.1.2-7.fc40 Summary: Go calculations for the position of the sun and moon RPMs: astral golang-github-sj14-astral-devel Size: 2.50 MiB Size change: -349 B Changelog: * Mon May 13 2024 Link Dupont - 0.2.1-1 - Update to 0.2.1 (RHBZ#2116189) Package: binutils-2.42.50-11.fc41 Old package: binutils-2.42.50-6.fc41 Summary: A GNU collection of binary utilities RPMs: binutils binutils-devel binutils-gold binutils-gprofng Size: 69.32 MiB Size change: -7.59 KiB Changelog: * Tue Apr 02 2024 Nick Clifton - 2.42.50-7 - Rebase to commit 121a3f4b4f4aac216abe239f6f3bd491b63e5e34 * Mon Apr 15 2024 Nick Clifton - 2.42.50-8 - Rebase to commit a73073dc7f23ab37ae33402fbb38c8314bcbea3e * Mon Apr 29 2024 Nick Clifton - 2.42.50-9 - Rebase to commit 679ad6e126868c462d8339eb837efb5a91a091af * Mon Apr 29 2024 Nick Clifton - 2.42.50-10 - Spec File: Stop %verify(mtime) for ld.bfd. (#2277349) * Mon May 13 2024 Nick Clifton - 2.42.50-11 - Rebase to commit 83b972fc272db31ab48aa5cde84f47c98868d7c8 Package: clang-18.1.4-2.fc41 Old package: clang-18.1.3-2.fc41 Summary: A C language family front-end for LLVM RPMs: clang clang-analyzer clang-devel clang-libs clang-resource-filesystem clang-tools-extra clang-tools-extra-devel git-clang-format python3-clang Size: 248.87 MiB Size change: -7.96 KiB Changelog: * Thu May 02 2024 Tom Stellard - 18.1.4 - 18.1.4 Release Package: compiler-rt-18.1.4-1.fc41 Old package: compiler-rt-18.1.3-2.fc41 Summary: LLVM "compiler-rt" runtime libraries RPMs: compiler-rt Size: 8.69 MiB Size change: -213 B Changelog: * Fri May 03 2024 Tom Stellard - 18.1.4-1 - 18.1.4 Release Package: composer-2.7.6-1.fc41 Old package: composer-2.7.4-1.fc41 Summary: Dependency Manager for PHP RPMs: composer Size: 998.99 KiB Size change: 1.03 KiB Changelog: * Sun May 05 2024 Remi Collet - 2.7.6-1 - update to 2.7.6 Package: cross-binutils-2.41-1.fc41 Old package: cross-binutils-2.40-5.fc40 Summary: A GNU collectio
When is Fedora 38 going EOL?
Hi, When is Fedora 38 going EOL? https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html says today https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html say next week Which one is correct? Thanks, -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling RPM based sysuser handling
On Tue, May 14, 2024 at 02:01:09PM +0300, Panu Matilainen wrote:
> On 5/14/24 13:39, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:
> > > I outlined the migration process last year in
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
> > > but failed to follow-up, so I'm glad to see this getting revisited.
> >
> > I started looking into this, and I think we need to start at the
> > bottom, i.e. in the setup package.
> >
> > It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
> > and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
> > but some of the groups listed in sysusers are not listed in the /etc files.
> > IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
> > automatically, and the file provided by setup will be ignored.
> > (It's specified as %config(noreplace).)
> >
> > Should be drop the static /etc/{passwd,group} from setup?
>
> The static files aren't harmful as long as they're not duplicated in other
> packages.
Harmful — no, but unnecessary and confusing. If we go decide to switch
to the rpm sysusers mechanism, then I think we should go all-in on it.
It doesn't make sense to ship a file in setup that would never be installed.
> I seem to recall seeing systemd-sysusers error out if those files were not
> present, but I might be misremembering and/or it might've changed since
> then. The default mechanism uses useradd/groupadd though, I don't know if
> those support non-existent /etc/{passwd,group}.
There might have been bugs for some specific cases, but in general
sysusers was always intended for starting with empty /etc. We certainly
test that case in our tests.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling RPM based sysuser handling
On 5/14/24 13:39, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:
I outlined the migration process last year in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
but failed to follow-up, so I'm glad to see this getting revisited.
I started looking into this, and I think we need to start at the
bottom, i.e. in the setup package.
It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
but some of the groups listed in sysusers are not listed in the /etc files.
IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
automatically, and the file provided by setup will be ignored.
(It's specified as %config(noreplace).)
Should be drop the static /etc/{passwd,group} from setup?
The static files aren't harmful as long as they're not duplicated in
other packages.
I seem to recall seeing systemd-sysusers error out if those files were
not present, but I might be misremembering and/or it might've changed
since then. The default mechanism uses useradd/groupadd though, I don't
know if those support non-existent /etc/{passwd,group}.
- Panu -
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Debugging fun (wrt C modernization change)
Yesterday, we ran into an issue where some of rpm upstream testcases are suddenly failing on one system. The difference to everybody elses working tests turned out to be Fedora 40, and was easily reproduced elsewhere on F40 then. On a closer look, the failing tests were all complaining about implicit function declarations. Okay, something to do with the C modernization change. The first of the failure cases was supposed to patch the old source against this though, but somehow the patch wasn't getting applied. WTH? There was a bit of a panic rising, are we missing patch applications somehow? And as a result of the C modernization changes? What? Looking closer still, the failing test had this: --- %patchlist hello-1.0-modernize.patch hello-1.0-install.patch %prep %autosetup -N %autopatch 1 %autopatch -m 2 --- Spot the error? Patch and source numbers start from zero, that goes for automatically numbered patches too. So there's an off by one in the application, and the latter %autopatch which is supposed to apply patches >= 2 simply has nothing to do, and falls through silently. That's a bug of course in itself, filed now: https://github.com/rpm-software-management/rpm/issues/3093 The rest of the failures were simply using a common old source from who knows when, relying on implicitly defined printf(). So no hair-rising silent patch application failure bugs, thankfully. We had a pretty good laugh over the whole thing once it unravelled. Cheers for the C modernization change work for unearthing these little buglets. - Panu - -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling RPM based sysuser handling
On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:
> I outlined the migration process last year in
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
> but failed to follow-up, so I'm glad to see this getting revisited.
I started looking into this, and I think we need to start at the
bottom, i.e. in the setup package.
It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
but some of the groups listed in sysusers are not listed in the /etc files.
IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
automatically, and the file provided by setup will be ignored.
(It's specified as %config(noreplace).)
Should be drop the static /etc/{passwd,group} from setup?
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora 41 Rawhide 20240514.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 41 Rawhide 20240514.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pykickstart - 20240510.n.1: pykickstart-3.54-1.fc41.src, 20240514.n.0: pykickstart-3.55-1.fc41.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/41 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240514.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240514.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240514.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240514.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240514.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240514.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240514.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GIMP 3.0 in F41?
On Monday, 13 May 2024 at 23:22, Nils Philippsen wrote:
[...]
> Let me try to clarify: Offering both major versions is mainly to cater
> for existing projects people might have. It’s hardly a maintenance
> burden as long as the dependencies are still available, at some point
> this might change and then the 2.x package will be retired. I have my
> reasons for naming the set of packages ("gimp", "gimp3") rather than
> ("gimp2", "gimp") which you might not find convincing, but in the end
> which package gets the versioned name and which doesn’t is an
> implementation detail – many people use package management software
> which doesn’t display these front and center.
Not moving the "gimp" RPM to 3.x once it's released is arguably contrary
to Fedora principle of being "First". Historically, when some upstream
released a new major version, Fedora packaging followed it and,
sometimes, kept the older version as a separate, version-suffixed
package. This was accompanied by a Change and I think it makes sense to
do a Self-Contained Change upgrading gimp to GIMP 3.0 and introducing
gimp2 for those who need it in F41.
You still have plenty of time (until Jul 16th) to write up and submit
the Change. By that time, GIMP 3.0 will very likely be out already,
so by F41 release, GIMP users will be aware that 3.0 is out. I think
it's both safe and expected to move the main gimp package to 3.0 and
upgrade users automatically in F41.
Do you have any convincing arguments to do otherwise?
Regards,
Dominik
--
Fedora https://fedoraproject.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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
On 5/13/24 17:08, Vít Ondruch wrote: Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a): On 5/13/24 16:09, Vít Ondruch wrote: Dne 13. 05. 24 v 11:39 Florian Festi napsal(a): %patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions. Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented? No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense. Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues. The rpm model is simply that all source preparation is done in %prep, and everything is build around that design. There's no way to enforce that, but things like having %setup and %patch only available there are pretty strong hints at how it wants to be used. I would make a copy of the tests for running purposes and patch that, all in %prep. That way you can also use %autosetup for it all. There will always be special circumstances, but on principle %patch should be considered a legacy construct. Packagers shouldn't have to be bothering with individual patch applications like that. - Panu - -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Vít Ondruch wrote: %patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions. >>> Do I read correctly that we can now use `%patch` in >>> e.g. `%check` section? Interesting. Is this documented? >> No, while %patch and %setup *could* be made available >> elsewhere now, they are still only available in %prep >> because that's the only place where they make sense. > Working with Ruby, which is interpreted language, there are > cases where we want to patch tests, while we want to keep > them in their original form in the package. This might sound > weird, but the thing is that for running tests, we might be > limited by infrastructure. E.g. Koji does not have internet > access, builders are slow, etc. So we might want to apply > some patch to workaround such issues. > I have no hopes convincing you. But thank you for clarification. This feels like the tests should be patched (and these patches upstreamed) to behave differently depending on some option, and the spec file should then use this option to trigger the correct one. I don't know enough about Ruby to suggest The Way™ to pass this option; but usually environment variables will do. (Other test suites have tags that can be used to select tests that should (not) be run which might be another (upstreamable) solution.) Tim -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2264848] perl-Gtk2-1.24993-15.fc41 FTBFS: Can't load 'blib/arch/auto/Gtk2/Gtk2.so' for module Gtk2: blib/arch/auto/Gtk2/Gtk2.so: undefined symbol: SvGdkAtom at /usr/lib64/perl5/DynaLoader.pm line
https://bugzilla.redhat.com/show_bug.cgi?id=2264848 Jitka Plesnikova changed: What|Removed |Added CC||jples...@redhat.com Depends On||2264921 --- Comment #1 from Jitka Plesnikova --- It is related to update pkgconf to version 2.1.0-1.fc40 and issue describe in BZ#2264921 Use of uninitialized value $minor in modulus (%) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 106. Use of uninitialized value $major in numeric le (<=) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 111. Use of uninitialized value $major in numeric le (<=) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 111. Use of uninitialized value $major in numeric le (<=) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 111. Use of uninitialized value $major in numeric le (<=) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 111. Use of uninitialized value $major in numeric le (<=) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 111. Use of uninitialized value $major in numeric le (<=) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 111. Use of uninitialized value $major in numeric le (<=) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 111. Use of uninitialized value $gtk_version[0] in numeric gt (>) at Makefile.PL line 108. Use of uninitialized value $gtk_version[0] in numeric eq (==) at Makefile.PL line 108. Use of uninitialized value $minor in modulus (%) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 106. Use of uninitialized value $major in numeric le (<=) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 111. Use of uninitialized value $major in numeric le (<=) at /usr/lib64/perl5/vendor_perl/Glib/MakeHelper.pm line 111. Including generated API documentation... It will be solved after update pkgconf to 2.2.0. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2264921 [Bug 2264921] pkg-config --modversion 'gnome-vfs-2.0 >= 2' stopped printing a module version -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2264848 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264848%23c1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Stephen Gallagher wrote:
> the %check section
> (which, if I remember correctly is run AFTER the creation of the
> binary RPMs)
No, it runs after %install but before the files are packaged up. It's
possible for %check to make changes to what was staged in %install and
have those changes appear in the package. I think removing that ability
would be an improvement, but that's how it currently is.
Any changes made by %check outside of %{buildroot} should not affect the
binary package though.
Björn Persson
pgp_7oqqyGrq5.pgp
Description: OpenPGP digital signatur
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
