Re: F40 Change Proposal: LLVM 18 (System-Wide)
On 1/5/24 5:18 AM, Stephen Gallagher wrote: > On Fri, Dec 22, 2023 at 8:05 PM Aoife Moloney wrote: >> >> Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18 >> >> This document represents a proposed Change. As part of the Changes >> process, proposals are publicly announced in order to receive >> community feedback. This proposal will only be implemented if approved >> by the Fedora Engineering Steering Committee. >> >> == Summary == >> Update all llvm sub-projects in Fedora Linux to version 18. >> >> >> == Owner == >> * Name: [[User:tstellar| Tom Stellard]] >> * Email: >> >> >> == Detailed Description == >> All llvm sub-projects in Fedora will be updated to version 18, and >> there will be a soname version change for the llvm libraries. >> Compatibility packages clang17, llvm17, and lld17 will be added to >> ensure that packages that currently depend on clang and llvm version >> 17 libraries will continue to work. We may add other compatibility >> packages too if they're determined to be necessary to maintain >> functionality in other RPMS that use llvm/clang. We also plan to >> retire these older compatibility packages (that we own): >> >> * llvm14 >> * llvm15 >> * llvm16 >> * clang14 >> * clang15 >> * clang16 >> * lld14 >> * lld15 >> * lld16 >> >> We will also be asking the maintainers of the following packages to >> retire them if possible: >> >> * llvm7.0 >> * llvm8.0 >> * llvm11 >> * llvm12 >> * llvm13 >> >> Other notable changes: >> >> * clang will emit DWARF-5 by default instead of DWARF-4. This matches >> the upstream default. We have been using DWARF-4 as the default for >> the last few releases due to: >> https://bugzilla.redhat.com/show_bug.cgi?id=2064052 >> * The compatibility packages will now include the same content as the >> main package. In previous releases, the compatibility packages >> contained only libraries and headers, and the binaries and other >> content was stripped out. These packages will be supported for use as >> dependencies for other RPM packages, but not for general purpose usage >> by end users. Fedora users should use Clang/LLVM 18. >> * The compatibility packages added for Fedora 40 will be retired prior >> to the Fedora 41 branch. >> * We will be enabling Fat LTO in redhat-rpm-config if this feature is >> complete in time for the upstream LLVM 18 release. Fat LTO is a >> feature that allows the compiler to produce libraries that contain LTO >> bitcode along side the traditional ELF binary code so that the >> libraries can be linked in both LTO mode and non-LTO mode. gcc also >> supports this feature and has it enabled in Fedora. In Fedora 39 and >> older, with LTO enabled, clang produces binaries with only LTO >> bitcode, so we need to run a post-processing script >> (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code >> so they can be used by other packages. Enabling Fat LTO will allow us >> to remove this script and simplify the build process. >> >> ===LLVM Build Schedule=== >> >> Important Dates >> >> * Jan 26: Upstream: 18.0.0-rc1 Release >> * Feb 6: Fedora: f40 branch created >> * Feb 6: Upstream: 18.0.0-rc2 Release >> * Feb 20: Fedora: f40 Beta Freeze >> * Feb 20: Upstream: 18.0.0-rc3 Release >> * Mar 5: Upstream: 18.0.0 Release >> * Apr 2: Fedora: f40 Final Freeze >> >> Plan >> # Build nightly trunk (LLVM 18) snapshots in >> [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/packages/ >> copr]. >> # Build LLVM 18.0.0-rc1 in COPR. >> # Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji. >> # Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji. >> # Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji. >> # Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji. >> # Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji >> # Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji >> # Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not >> ready) as a Beta Freeze exception. >> # Continue building new release candidates and pushing them to stable >> until the Final Freeze. >> >> We are not planning to push 18.0.0-rc1 into rawhide because the >> library ABI is not stabilized at that point. Typically, the ABI >> stabilizes after -rc3, but there are no guarantees from upstream about >> this. Given the history of minimal ABI changes after -rc3, we feel >> like it's safe to push -rc3 into rawhide. The worst case scenario >> would be an ABI change -rc4 or the final release that we force us to >> patch LLVM to maintain compatibility with the -rc3 ABI. This scenario >> would not require rebuilding LLVM library users in Fedora, so this >> would not require much extra work from our team. >> >> Updates after 18.0.0-rc3 will generally be very small and can be done >> after the Final Freeze is over. If we are late packaging release >> candidates after -rc3 or the final release, we will not ask for a >> Final Freeze exception, unless they contain a fix for a critical >> release block
Planning to unretire rust-libdeflater and rust-libdeflate-sys
As required by the Package Retirement Process[1], this email announces that I plan to unretire the rust-libdeflater and rust-libdeflate-sys packages. Both were retired because they were “no longer needed,” but they will be in the dependency tree of a new python-cramjam package needed for the latest versions of python-fastavro. I have already prepared PR’s that revert the unretirement commits and update each package to the latest version[2][3], and the packages are ready for re-review[4][5]. [1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming [2] https://src.fedoraproject.org/rpms/rust-libdeflater/pull-request/1 [3] https://src.fedoraproject.org/rpms/rust-libdeflate-sys/pull-request/1 [4] https://bugzilla.redhat.com/show_bug.cgi?id=2256974 [5] https://bugzilla.redhat.com/show_bug.cgi?id=2256975 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Planning to update to podofo-0.10.1 + review request for podofo-compat for legacy 0.9.x library
On Fri, Jan 05, 2024 at 06:13:58PM +0100, Sandro Mani wrote: > > On 05.01.24 17:57, Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Dec 17, 2023 at 04:44:36PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Tue, Aug 15, 2023 at 11:56:56PM +0200, Sandro Mani wrote: > > > > Hi > > > > > > > > I'm planning to update to podofo-0.10.1 in rawhide. I did a series of > > > > test > > > > builds here [1], according to which scribus, vfrnav and pdfsign > > > > currently do > > > > not support podofo-0.10.x. To keep these functional, I've prepared a > > > > podofo-compat package with the previous 0.9.x library. The review > > > > request is > > > > here [2]. Happy to review in exchange. > > > Hi, > > > > > > we have the opposite situation with calibre: it builds fine in rawhide > > > with > > > podofo-0.10, but does not compile against podofo-0.9.8 in F39. I just > > > built calibre-7.2.0 in rawhide, and would like to do the same update > > > for F39. Is there any chance you can also push podofo-0.10.x + > > > podofo-compat-0.9.x > > > also to F39? I think that'd be OK, because we can keep the packages that > > > need the old version building, possibly after adjusting some > > > BuildRequires line. > > Bump in the new year. PTAL. > > Hi Zbyszek > > I already took care of this: > https://koji.fedoraproject.org/koji/buildinfo?buildID=2334737 Oh, I missed that. Thanks! 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: Planning to update to podofo-0.10.1 + review request for podofo-compat for legacy 0.9.x library
On 05.01.24 17:57, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Dec 17, 2023 at 04:44:36PM +, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 15, 2023 at 11:56:56PM +0200, Sandro Mani wrote: Hi I'm planning to update to podofo-0.10.1 in rawhide. I did a series of test builds here [1], according to which scribus, vfrnav and pdfsign currently do not support podofo-0.10.x. To keep these functional, I've prepared a podofo-compat package with the previous 0.9.x library. The review request is here [2]. Happy to review in exchange. Hi, we have the opposite situation with calibre: it builds fine in rawhide with podofo-0.10, but does not compile against podofo-0.9.8 in F39. I just built calibre-7.2.0 in rawhide, and would like to do the same update for F39. Is there any chance you can also push podofo-0.10.x + podofo-compat-0.9.x also to F39? I think that'd be OK, because we can keep the packages that need the old version building, possibly after adjusting some BuildRequires line. Bump in the new year. PTAL. Hi Zbyszek I already took care of this: https://koji.fedoraproject.org/koji/buildinfo?buildID=2334737 Sandro -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Planning to update to podofo-0.10.1 + review request for podofo-compat for legacy 0.9.x library
On Sun, Dec 17, 2023 at 04:44:36PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Aug 15, 2023 at 11:56:56PM +0200, Sandro Mani wrote: > > Hi > > > > I'm planning to update to podofo-0.10.1 in rawhide. I did a series of test > > builds here [1], according to which scribus, vfrnav and pdfsign currently do > > not support podofo-0.10.x. To keep these functional, I've prepared a > > podofo-compat package with the previous 0.9.x library. The review request is > > here [2]. Happy to review in exchange. > > Hi, > > we have the opposite situation with calibre: it builds fine in rawhide with > podofo-0.10, but does not compile against podofo-0.9.8 in F39. I just > built calibre-7.2.0 in rawhide, and would like to do the same update > for F39. Is there any chance you can also push podofo-0.10.x + > podofo-compat-0.9.x > also to F39? I think that'd be OK, because we can keep the packages that > need the old version building, possibly after adjusting some BuildRequires > line. Bump in the new year. PTAL. 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-IoT 40 RC 20240105.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 40 RC 20240105.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 Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/40iot 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-IoT_40_RC_20240105.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_40_RC_20240105.0_General 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: f39-candidate ~> f39-build stuck or something?
On Fri, Jan 5, 2024 at 1:01 PM Milan Crha wrote: > Hi again, > with the problem on the rawhide, I managed to build evolution-data- > server update for F39 with no problem, but the chain-build [1] to > wait for the f39-build refresh/update to have the new eds. It waited > for 2 hours, which is quite a lot of time. > > For what it's worth: > > $ koji wait-repo f39-build --build evolution-data-server-3.50.3-1.fc39 > nvr evolution-data-server-3.50.3-1.fc39 is not current in tag f39-build > latest build in f39-build is evolution-data-server-3.50.2-1.fc39 > Yes, this only works for side tags. The previous F39 build, https://koji.fedoraproject.org/koji/taskinfo?taskID=109761881 was done in a side tag as well. Chain builds kinda work without side tags for rawhide, but they take forever to complete because each individual build in the chain build needs to go through bodhi and openqa testing, before it can land in rawhide build root, so each step (after the build has completed) takes more than an hour. With a side tag, chain build is much faster and you can submit everything together to bodhi so that all the new builds are tested as a single unit. So my suggestion would be to use a self service side tag for rawhide as well, not just F39. -- Hope this helps, Kalev -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Non-responsive maintainer check for lcts
Hello! Does anyone know how to contact @lcts, the maintainer of rear? Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2256943 I see no activity in dist-git, Koji or Bugzilla for more than a year. There is currently an urgent bug in rear which must be fixed. Otherwise, the tool is practically unusable on Fedora at the moment: https://bugzilla.redhat.com/show_bug.cgi?id=2254871 Currently, the are also other bugs assigned to lcts including over 100 nextcloud CVE tracking bugs without any response so far. Regards, Lukas -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: rawhide missing xgettext: command not found
On Fri, Jan 5, 2024 at 8:16 AM Martin Gansser wrote:
>
> I'm just wondering why my packages under rawhide suddenly need gettext as a
> dependency ?
>
> should i set an if condition for rawhide ?
>
> %if 0%{?fedora} >= 40
> BuildRequires: gettext
> %endif
This shouldn't be conditional. If you require gettext, you should
`BuildRequires: gettext`.
If it worked before, it was accidental (something else you had a BR on
must have pulled it in). That subsequently changed. You can't rely on
that behavior even to remain in released Fedoras, so just add the
requirement explicitly to your specfile.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: LLVM 18 (System-Wide)
On Fri, Dec 22, 2023 at 8:05 PM Aoife Moloney wrote: > > Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18 > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > Update all llvm sub-projects in Fedora Linux to version 18. > > > == Owner == > * Name: [[User:tstellar| Tom Stellard]] > * Email: > > > == Detailed Description == > All llvm sub-projects in Fedora will be updated to version 18, and > there will be a soname version change for the llvm libraries. > Compatibility packages clang17, llvm17, and lld17 will be added to > ensure that packages that currently depend on clang and llvm version > 17 libraries will continue to work. We may add other compatibility > packages too if they're determined to be necessary to maintain > functionality in other RPMS that use llvm/clang. We also plan to > retire these older compatibility packages (that we own): > > * llvm14 > * llvm15 > * llvm16 > * clang14 > * clang15 > * clang16 > * lld14 > * lld15 > * lld16 > > We will also be asking the maintainers of the following packages to > retire them if possible: > > * llvm7.0 > * llvm8.0 > * llvm11 > * llvm12 > * llvm13 > > Other notable changes: > > * clang will emit DWARF-5 by default instead of DWARF-4. This matches > the upstream default. We have been using DWARF-4 as the default for > the last few releases due to: > https://bugzilla.redhat.com/show_bug.cgi?id=2064052 > * The compatibility packages will now include the same content as the > main package. In previous releases, the compatibility packages > contained only libraries and headers, and the binaries and other > content was stripped out. These packages will be supported for use as > dependencies for other RPM packages, but not for general purpose usage > by end users. Fedora users should use Clang/LLVM 18. > * The compatibility packages added for Fedora 40 will be retired prior > to the Fedora 41 branch. > * We will be enabling Fat LTO in redhat-rpm-config if this feature is > complete in time for the upstream LLVM 18 release. Fat LTO is a > feature that allows the compiler to produce libraries that contain LTO > bitcode along side the traditional ELF binary code so that the > libraries can be linked in both LTO mode and non-LTO mode. gcc also > supports this feature and has it enabled in Fedora. In Fedora 39 and > older, with LTO enabled, clang produces binaries with only LTO > bitcode, so we need to run a post-processing script > (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code > so they can be used by other packages. Enabling Fat LTO will allow us > to remove this script and simplify the build process. > > ===LLVM Build Schedule=== > > Important Dates > > * Jan 26: Upstream: 18.0.0-rc1 Release > * Feb 6: Fedora: f40 branch created > * Feb 6: Upstream: 18.0.0-rc2 Release > * Feb 20: Fedora: f40 Beta Freeze > * Feb 20: Upstream: 18.0.0-rc3 Release > * Mar 5: Upstream: 18.0.0 Release > * Apr 2: Fedora: f40 Final Freeze > > Plan > # Build nightly trunk (LLVM 18) snapshots in > [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/packages/ > copr]. > # Build LLVM 18.0.0-rc1 in COPR. > # Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji. > # Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji. > # Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji. > # Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji. > # Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji > # Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji > # Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not > ready) as a Beta Freeze exception. > # Continue building new release candidates and pushing them to stable > until the Final Freeze. > > We are not planning to push 18.0.0-rc1 into rawhide because the > library ABI is not stabilized at that point. Typically, the ABI > stabilizes after -rc3, but there are no guarantees from upstream about > this. Given the history of minimal ABI changes after -rc3, we feel > like it's safe to push -rc3 into rawhide. The worst case scenario > would be an ABI change -rc4 or the final release that we force us to > patch LLVM to maintain compatibility with the -rc3 ABI. This scenario > would not require rebuilding LLVM library users in Fedora, so this > would not require much extra work from our team. > > Updates after 18.0.0-rc3 will generally be very small and can be done > after the Final Freeze is over. If we are late packaging release > candidates after -rc3 or the final release, we will not ask for a > Final Freeze exception, unless they contain a fix for a critical > release blocking bug. > > == Feedback == > This came in while I was on PTO, so my apologies for the late reply on it. My concern here is with the timing and its inclusion i
Re: rawhide missing xgettext: command not found
I'm just wondering why my packages under rawhide suddenly need gettext as a
dependency ?
should i set an if condition for rawhide ?
%if 0%{?fedora} >= 40
BuildRequires: gettext
%endif
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: intent to hand over or orphan several scientific packages and their build requirements
Hello Dominik, Thank you again. On Fri, Jan 5, 2024 at 10:45 AM Dominik 'Rathann' Mierzejewski wrote: > > On Thursday, 28 December 2023 at 10:27, Alexander Ploumistos wrote: > > Done. I put @scitech_sig as the default bugzilla assignee for EPEL. > Can you change the default assignee for Fedora to yourself? It looks > like it didn't get reset after transferring the project to you. Done. I've left a word for Antonio, in case he wants to maintain the EPEL branches. > > On Wed, Dec 27, 2023 at 11:26 PM Dominik 'Rathann' Mierzejewski > > wrote: > > > > > > chemtool > > > xdrawchem > > I gave you chemtool by mistake, feel free to give it back or orphan it. I can't bring myself to hit the "Orphan" button, all those memories (often of frustration)… Best regards, A. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
f39-candidate ~> f39-build stuck or something?
Hi again,
with the problem on the rawhide, I managed to build evolution-data-
server update for F39 with no problem, but the chain-build [1] to
wait for the f39-build refresh/update to have the new eds. It waited
for 2 hours, which is quite a lot of time.
For what it's worth:
$ koji wait-repo f39-build --build evolution-data-server-3.50.3-1.fc39
nvr evolution-data-server-3.50.3-1.fc39 is not current in tag f39-build
latest build in f39-build is evolution-data-server-3.50.2-1.fc39
$ koji latest-pkg f39-build evolution-data-server
Build Tag Built by
--
evolution-data-server-3.50.2-1.fc39 f39-updates mcrha
$ koji latest-pkg f39-updates-candidate evolution-data-server
Build Tag Built by
- --
evolution-data-server-3.50.3-1.fc39 f39-updates-candidate mcrha
What can I do make it work, please? Or is chain-build supported only on
the side tags these days? I'm pretty sure it worked fine a month ago.
I do not see any f39 repo-rebuild related task between current active
tasks on koji [2].
Bye,
Milan
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321411
[2] https://koji.fedoraproject.org/koji/tasks
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: CMake's check-compiles fails to parse WITH_GZFILEOP
> Dne 05. 01. 24 v 11:10 Milan Crha napsal(a): > > > There certainly were these changes: > > https://github.com/zlib-ng/zlib-ng/commit/0560a3a63dfdd6642724c8fad4db9dc... > > https://github.com/zlib-ng/zlib-ng/commit/6592accb2541aa637844cabef16b7ad... > > > Vít I don't think zlib-ng is the root cause of this, that looks to be setting the pkgconfig flags correctly, since there is no difference between compile definitions and other flags in pkgconfig (unlike CMake which does separate definitions, include paths, etc. into separate variables). What is happening is that CMake is assuming that -DWITH_GZFILEOP is actually a CMake internal variable for try_compile, when it is not. Building EDS with --trace --trace-expand shows it is trying to use the following call to try_compile: /usr/share/cmake/Modules/Internal/CheckSourceCompiles.cmake(101): try_compile(HAVE_GPOWERPROFILEMONITOR SOURCE_FROM_VAR src.c _source COMPILE_DEFINITIONS -DHAVE_GPOWERPROFILEMONITOR LINK_LIBRARIES;-L/usr/lib64;-lxml2;-lsoup-3.0;-lgobject-2.0;-lgio-2.0;-lgmodule-2.0;-pthread;-Wl,--export-dynamic;-lglib-2.0 CMAKE_FLAGS -DCOMPILE_DEFINITIONS:STRING=-I/usr/include/libxml2;-I/usr/include/libsoup-3.0;-I/usr/include/glib-2.0;-I/usr/lib64/glib-2.0/include;-I/usr/include/libmount;-I/usr/include/blkid;-I/usr/include/sysprof-6;-pthread;-DWITH_GZFILEOP -DINCLUDE_DIRECTORIES:STRING=/usr/include/libxml2;/usr/include/libsoup-3.0;/usr/include/glib-2.0;/usr/lib64/glib-2.0/include;/usr/include/libmount;/usr/include/blkid;/usr/include/sysprof-6 OUTPUT_VARIABLE OUTPUT ) Looking further up in the EDS CMake output, EDS itself is passing that inside its CMAKE_REQUIRED_FLAGS variable here: /builddir/build/BUILD/evolution-data-server-3.51.1/CMakeLists.txt(913): set(CMAKE_REQUIRED_FLAGS -I/usr/include/libxml2;-I/usr/include/libsoup-3.0;-I/usr/include/glib-2.0;-I/usr/lib64/glib-2.0/include;-I/usr/include/libmount;-I/usr/include/blkid;-I/usr/include/sysprof-6;-pthread;-DWITH_GZFILEOP ) /builddir/build/BUILD/evolution-data-server-3.51.1/CMakeLists.txt(914): set(CMAKE_REQUIRED_INCLUDES /usr/include/libxml2;/usr/include/libsoup-3.0;/usr/include/glib-2.0;/usr/lib64/glib-2.0/include;/usr/include/libmount;/usr/include/blkid;/usr/include/sysprof-6 ) /builddir/build/BUILD/evolution-data-server-3.51.1/CMakeLists.txt(915): set(CMAKE_REQUIRED_LIBRARIES -L/usr/lib64;-lxml2;-lsoup-3.0;-lgobject-2.0;-lgio-2.0;-lgmodule-2.0;-pthread;-Wl,--export-dynamic;-lglib-2.0 ) / An interesting thing to note about that is that it is using ;-list formatting in CMake for this call, but according to the docs for CheckCSourceCompiles, these CMAKE_REQUIRED_<> variables should have the values space-separated, not as a ;-list (https://cmake.org/cmake/help/latest/module/CheckCSourceCompiles.html), so that should probably be fixed in EDS to see if the problem stays or if it goes away. -Ian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: CMake's check-compiles fails to parse WITH_GZFILEOP
Dne 05. 01. 24 v 11:10 Milan Crha napsal(a): Hi, On Fri, 2024-01-05 at 10:35 +0100, Honza Horak wrote: Not sure whether it's a regression in zlib-ng or something to be changed in evolution-data-server though Neither do I. The eds check uses information from pkg-config output for gio-2.0 gmodule-2.0 libxml-2.0 and libsoup-3.0. It does not reference anything related to the zlib in this test, from which I suppose one of these four .pc files bring the WITH_GZFILEOP in the list. There certainly were these changes: https://github.com/zlib-ng/zlib-ng/commit/0560a3a63dfdd6642724c8fad4db9dc58629f6bf https://github.com/zlib-ng/zlib-ng/commit/6592accb2541aa637844cabef16b7adbb4cec4e1 Vít In any case, if there's anything the eds code or the .spec file should do, just let me know (not that I think it's eds' fault, neither the latest change uncovering any error in the eds CMake file, but I can be wrong). Bye, Milan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 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: Non responsive maintainer check for marxin
On 05-01-2024 01:50, Priscila Gutierres wrote:
I would like to apologize if it seems that I’m being rude asking for a
review in this thread.
It's perfectly fine asking for a review. But that should go into its own
mail to the list or, preferably, to <${package}-maintainers@fp.o>.
Currently, this thread aims to solve the maintainer situation with
regards to pebble. Once that's done, the package will be handed over to
an active maintainer.
Since you appear to be interested in maintaining pebble, you might even
get to be added as a maintainer once the current situation has been solved.
My point of view is that if the package is a dependency and no one is
looking on it, it would be a priority to keep it up to date.
That depends...
I don’t know if merging it would be possible, since the maintainer is not
responding, if not, I can close it.
Leave it open. A proven packager can still merge it or you may get to
merge it yourself once the package has been handed over.
Also, I noticed any maintainer can merge it.
Yes. Anyone with commit rights can merge. But currently there's only one
person enlisted and only that person can add co-maintainers.
I am a new maintainer and I don’t want to create polemics, I am here to
hear and learn, but if I don’t participate in the discussion is more hard
to learn. In any case, I apologize again if I was impolite.
It's all good. This thread is regarding the non-responsive maintainer
check [1]. It shouldn't become a discussion thread. That's all I was/am
concerned about.
[1]
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: CMake's check-compiles fails to parse WITH_GZFILEOP
Hi, On Fri, 2024-01-05 at 10:35 +0100, Honza Horak wrote: > Not sure whether it's a regression in zlib-ng or something to be > changed in evolution-data-server though Neither do I. The eds check uses information from pkg-config output for gio-2.0 gmodule-2.0 libxml-2.0 and libsoup-3.0. It does not reference anything related to the zlib in this test, from which I suppose one of these four .pc files bring the WITH_GZFILEOP in the list. In any case, if there's anything the eds code or the .spec file should do, just let me know (not that I think it's eds' fault, neither the latest change uncovering any error in the eds CMake file, but I can be wrong). Bye, Milan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: intent to hand over or orphan several scientific packages and their build requirements
On Wednesday, 27 December 2023 at 23:26, Dominik 'Rathann' Mierzejewski wrote: > Hello! > I intend to hand over primary maintainership of the following packages > or orphan them if nobody steps up: > arpack > chemtool > cp2k > elpa > inchi > python-colorspacious > python-fypp > python-GridDataFormats > python-gsd > python-kaitaistruct > python-mmtf > python-mrcfile > python-Pympler > tachyon > wxmacmolplt > xdrawchem > > I don't use them anymore, so I'm not a good maintainer for them. > > Most, if not all above, are co-maintained by SciTech SIG already. > Please contact me if you want to take over one of these. Otherwise, > I will orphan them in the first week of the new year. This is done. I gave inchi to Alexander and the rest are up for taking. 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: intent to hand over or orphan several scientific packages and their build requirements
Hello, Alexander. On Thursday, 28 December 2023 at 10:27, Alexander Ploumistos wrote: > Hello Dominik, > > For the time being I will take inchi, if nobody else wants it. I > haven't used EPEL in a very long time, so I'm only interested in the > Fedora branches. Done. I put @scitech_sig as the default bugzilla assignee for EPEL. Can you change the default assignee for Fedora to yourself? It looks like it didn't get reset after transferring the project to you. > On Wed, Dec 27, 2023 at 11:26 PM Dominik 'Rathann' Mierzejewski > wrote: > > > > chemtool > > xdrawchem I gave you chemtool by mistake, feel free to give it back or orphan it. 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: CMake's check-compiles fails to parse WITH_GZFILEOP
Or just latest zlib-ng update -- upstream change https://github.com/zlib-ng/zlib-ng/commit/6592accb2541aa637844cabef16b7adbb4cec4e1 got to fedora with update to 2.1.5 (Dec 27) and koschei started to fail Dec 28: https://koschei.fedoraproject.org/package/evolution-data-server Not sure whether it's a regression in zlib-ng or something to be changed in evolution-data-server though, so CCing Tulio for awareness. Honza On Fri, Jan 5, 2024 at 10:22 AM Vít Ondruch wrote: > zlib-devel-1.2.13-4.fc39.x86_64 vs zlib-ng-compat-devel-2.1.5-1.fc40.x86_64 > > > Just guessing. I might be completely wrong. > > > Vít > > > Dne 05. 01. 24 v 9:59 Milan Crha napsal(a): > > Hi, > > this is new to me. I'm trying to build evolution-data-server in a side > > tag for rawhide and the build [1] fails in the CMake phase with error: > > > > -- Performing Test HAVE_GPOWERPROFILEMONITOR > > CMake Error: Parse error in command line argument: WITH_GZFILEOP > > Should be: VAR:type=value > > CMake Error at > /usr/share/cmake/Modules/Internal/CheckSourceCompiles.cmake:101 > (try_compile): > > Failed to configure test project build system. > > Call Stack (most recent call first): > > /usr/share/cmake/Modules/CheckCSourceCompiles.cmake:52 > (cmake_check_source_compiles) > > CMakeLists.txt:916 (CHECK_C_SOURCE_COMPILES) > > > > I checked the sources and there is no reference to WITH_GZFILEOP, > > neither in the .spec file, thus it comes from some other project. > > > > Exactly the same test [1] passes fine in f39. > > > > Does this sound familiar to anyone? Maybe the library or what, which > > exposes it, should be corrected? > > > > Thanks and bye, > > Milan > > > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321151 > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321411 > > -- > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CMake's check-compiles fails to parse WITH_GZFILEOP
zlib-devel-1.2.13-4.fc39.x86_64 vs zlib-ng-compat-devel-2.1.5-1.fc40.x86_64 Just guessing. I might be completely wrong. Vít Dne 05. 01. 24 v 9:59 Milan Crha napsal(a): Hi, this is new to me. I'm trying to build evolution-data-server in a side tag for rawhide and the build [1] fails in the CMake phase with error: -- Performing Test HAVE_GPOWERPROFILEMONITOR CMake Error: Parse error in command line argument: WITH_GZFILEOP Should be: VAR:type=value CMake Error at /usr/share/cmake/Modules/Internal/CheckSourceCompiles.cmake:101 (try_compile): Failed to configure test project build system. Call Stack (most recent call first): /usr/share/cmake/Modules/CheckCSourceCompiles.cmake:52 (cmake_check_source_compiles) CMakeLists.txt:916 (CHECK_C_SOURCE_COMPILES) I checked the sources and there is no reference to WITH_GZFILEOP, neither in the .spec file, thus it comes from some other project. Exactly the same test [1] passes fine in f39. Does this sound familiar to anyone? Maybe the library or what, which exposes it, should be corrected? Thanks and bye, Milan [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321151 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321411 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 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: Mock Configs v39.3 released - DNF5 used for F40+ builds
On čtvrtek 4. ledna 2024 19:20:46 CET Pavel Raiskup wrote: > On středa 3. ledna 2024 8:46:22 CET Pavel Raiskup wrote: > > I just wanted to give you a quick heads-up that I plan to enable the > > BuildWithDNF5 change in Fedora Copr as soon as the new Rawhide compose > > gets distributed to mirrors. > > This has happened now. Fedora Copr builds F40 (Rawhide) with DNF5 now. > Should you face any issue, please report it. Two more hints: - I noticed that `dnf5` on Fedora Copr builders (F38) was buggy (old version) because the latest update was not yet in the stable repository. This was breaking Rawhide builds in Copr projects with `bootstrap=off` (using dnf5 on host). This is no longer the case, the DNF5 package has been updated to v5.1.10. If you observed a suspicious problem, please consider `bootstrap=on` or at least check that DNF v5.1.10 is used. - DNF5 isn't downloading filelists (resource cost optimization), which in turn means that the packages can not (build)depend on random file paths. So just a small reminder that, per the updated packaging guidelines https://pagure.io/packaging-committee/pull-request/1321 , you MUST NOT do things like `BuildRequires: /some/random/file/name`. Pavel signature.asc Description: This is a digitally signed message part. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
CMake's check-compiles fails to parse WITH_GZFILEOP
Hi, this is new to me. I'm trying to build evolution-data-server in a side tag for rawhide and the build [1] fails in the CMake phase with error: -- Performing Test HAVE_GPOWERPROFILEMONITOR CMake Error: Parse error in command line argument: WITH_GZFILEOP Should be: VAR:type=value CMake Error at /usr/share/cmake/Modules/Internal/CheckSourceCompiles.cmake:101 (try_compile): Failed to configure test project build system. Call Stack (most recent call first): /usr/share/cmake/Modules/CheckCSourceCompiles.cmake:52 (cmake_check_source_compiles) CMakeLists.txt:916 (CHECK_C_SOURCE_COMPILES) I checked the sources and there is no reference to WITH_GZFILEOP, neither in the .spec file, thus it comes from some other project. Exactly the same test [1] passes fine in f39. Does this sound familiar to anyone? Maybe the library or what, which exposes it, should be corrected? Thanks and bye, Milan [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321151 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321411 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
