[Test-Announce] Fedora 40 Branched 20240213.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 40 Branched 20240213.n.1. 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: python-blivet - 20240210.n.1: python-blivet-3.9.0-2.fc40.src, 20240213.n.1: python-blivet-3.9.0-3.fc40.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/40 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_40_Branched_20240213.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240213.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240213.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240213.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240213.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240213.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240213.n.1_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: CMake errors
On Tue, Feb 13, 2024 at 2:39 PM Josef Řídký wrote:
> Hi,
>
> I am trying to build a new version of the jasper package, but I am not able
> to successfully pass the %cmake command. [1]
>
> First issue was about using in-source build, which can be overridden by
> -ALLOW_IN_SOURCE_BUILD. But even though, CMake has problem with finding
> CMAKE_C_COMPILER location.
>
> Currently is used CMAKE_VERSION: 3.28.2
>
> Previous successful build of jasper [2] used CMAKE_VERSION: 3.27.7 and no
> in-source error nor CMAKE_C_COMPILER issue has occurred.
>
> Does anyone have a similar issue? What is a recommended way to deal with this?
>
> [1] https://kojipkgs.fedoraproject.org//work/tasks/9648/113459648/build.log
> [2]
> https://kojipkgs.fedoraproject.org//packages/jasper/4.1.0/3.fc40/data/logs/x86_64/build.log
>
> Best regards
>
> Josef
This works:
%build
%cmake \
-DALLOW_IN_SOURCE_BUILD:BOOL=ON \
-DJAS_ENABLE_DOC:BOOL=OFF
%cmake_build
%install
%cmake_install
# Unpackaged files
rm -f doc/README
rm -f %{buildroot}%{_libdir}/lib*.la
%check
%ctest
Regards,
--
Jerry James
http://www.jamezone.org/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
CMake errors
Hi, I am trying to build a new version of the jasper package, but I am not able to successfully pass the %cmake command. [1] First issue was about using in-source build, which can be overridden by -ALLOW_IN_SOURCE_BUILD. But even though, CMake has problem with finding CMAKE_C_COMPILER location. Currently is used CMAKE_VERSION: 3.28.2 Previous successful build of jasper [2] used CMAKE_VERSION: 3.27.7 and no in-source error nor CMAKE_C_COMPILER issue has occurred. Does anyone have a similar issue? What is a recommended way to deal with this? [1] https://kojipkgs.fedoraproject.org//work/tasks/9648/113459648/build.log [2] https://kojipkgs.fedoraproject.org//packages/jasper/4.1.0/3.fc40/data/logs/x86_64/build.log Best regards Josef -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Does ccache ever help with kernel mock build?
Am 13.02.24 um 16:16 schrieb Gary Buhrmaster: On Tue, Feb 13, 2024 at 9:52 AM Miroslav Suchý wrote: Dne 13. 02. 24 v 9:08 Julian Sikorski napsal(a): Could this be the reason for ccache not working? I wonder whether it is Mock problem, Ccache issue or problem in packaging? Does the ccache speadup the build when you run it with plain rpmbuild and ccache on host? I have lost track of the details (and the version of ccache when the issue was addressed/patched), but ccache at one time included SOURCE_DATE_EPOCH in the default hash, resulting in no cache hits. This appears to have been fixed in ccache-4.2. F36, obsolete as it is, shipped with 4.5.1. Having said that, with current kernel there is this line in the log: + perl -p -i -e 's/^CONFIG_BUILD_SALT.*/CONFIG_BUILD_SALT="6.7.4-200.lacie03.fc39.x86_64"/' .config This would change every build. Best regards, Julian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: do we need CONFIG_UPROBES=y in our kernels?
On 2/12/24 7:15 PM, Marius Schwarz wrote: Hi, I excuse myself if this has been already discussed, bastion ML server was blacklisted (has been removed btw). Short summary(for details use the source link): In a german developer blog article was the topic raised, that with uprobes enabled, userland apps can i.e. circumvent tls security(and other protections), by telling the kernel to probe the function calls with the uprobes api. As this enables i.e. the hosting system of a vm or container, to track activity inside the container, trust is lost i.e. from customer to hoster. To be fair, you need to be root on the host to do this, but as it "wasn't possible before", and it is "now" ( out in a greater public ), it tends to create trust issues, just for being there*. If I am reading this correctly, if I have a VM that's being hosted on a host kernel that has uprobes capabilities and a malicious actor with root access is controlling the host kernel, does it matter what options is the guest using if the host can simply utilize their uprobes? This hypothetical malicious hoster could also just use their own custom kernel if they were relying on Fedora's kernel. And if they are this malicious, they also can just break into your containers via regular container tools. IMO containers are at no level a reliable security sandbox without additional safeguards, this goes both for host and guest. Regards, Jarek As this only works with uprobes enabled and has no use case besides a developer debugging apps, the question is: Do we need this for all others out there enabled by default? If noone can name an app/lib that needs this outside of the C* development process, a change proposal would be wise. maybe adding a kernel boot argument switch? Source: http://blog.fefe.de/?ts=9b3a23b2 *) You may not have a clue, what security auditors tell you about "a vulnerability & it's just there, but inexploitable". I had a case 2 weeks ago, about a missing patch for the ssh-agent CVE vulnerability in fedora's openssh. Trust me, it will create trouble the more the topic is discussed in the pubic. Best regards, Marius Schwarz -- -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: do we need CONFIG_UPROBES=y in our kernels?
> > In a german developer blog article was the topic raised, that with > > uprobes enabled, userland apps can i.e. circumvent tls security(and > > other protections), > > by telling the kernel to probe the function calls with the uprobes api. > > As this enables i.e. the hosting system of a vm or container, to track > > activity inside the container, trust is lost i.e. from customer to > > hoster. To be fair, you need to be root on the host to do this, but as > > it "wasn't possible before", and it is "now" ( out in a greater public > > ), it tends to create trust issues, just for being there*. > > > > As this only works with uprobes enabled and has no use case besides a > > developer debugging apps, the question is: > > > > Do we need this for all others out there enabled by default? > > Both systemtap and bpftrace can use uprobes. Those capabilities have > been important from time to time in my job. That does not mean that > my ability to do my job should outweigh security concerns, of course, > but I think some effort should be made to find out if use of uprobes > via systemtap and bpftrace is common amongst Fedora users. And unfortunately it's not buildable as a module, I suspect there's some form of capabilities around it, I'm not sure if that can be tightened. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Current status of OSTree and its handling RPM scriptlets?
Hi Zdenek, On Mon, Feb 12, 2024 at 4:58 AM Zdenek Dohnal wrote: > > Hi all, > > there was an issue (either due a bug or due design) in the past about > RPM OSTree treating %post scriptlets in SPEC file differently than on > Fedora Linux - IIUC the explanation was %post scriptlets were applied on > the server side of the system with RPM OSTree, thus any configuration > changes like switching symlinks with alternatives were not > applied/usable for normal user. > > Has it got fixed during the time? Or is there a new technology which > would do the trick for Silverblue and Fedora Linux alike? Just a note: I would say "for Silverblue and traditional systems alike" instead. Silverblue is part of Fedora Linux. :) > Because there is a user which was used to setting NOEXEC on /usr/bin/vi > to prevent running shell from vi as a root when using 'sudo vi' - since > the /usr/bin/vi is shell script now and uses exec to spawn the correct > binary, NOEXEC flags breaks 'sudo vi' completely. > > The only possible solution here I see is to use alternatives in %post > scriptlet, but if the situation is the same, the functionality brought > by alternatives (automatic switch from vi -> vim and back if > vim-enhanced is installed without shell restart) won't work in OSTree. So the high-level situation of scriptlets wanting to modify /var content is still problematic. And in fact, we'd like to propose a package change at some point to discourage this (see https://github.com/coreos/fedora-coreos-tracker/issues/1067). The common way to make "image-mode friendly" system state changes is to e.g. use a systemd service or a tmpfiles.d dropin or to bake the migration into the application itself (all these would of course work across OSTree and non-OSTree based variants). Specifically for alternatives, see also https://github.com/fedora-sysv/chkconfig/issues/9 which calls for changing how it's implemented to be more compatible with image-based updates. Specifically for your issue though, it's not clear to me how much it's worth supporting this. Do they also have a way to prevent `sudo vi` from e.g. creating/modifying a systemd unit that can run arbitrary code? > Thank you in advance! Hope that helps! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: do we need CONFIG_UPROBES=y in our kernels?
On Mon, Feb 12, 2024 at 11:16 AM Marius Schwarz wrote: > In a german developer blog article was the topic raised, that with > uprobes enabled, userland apps can i.e. circumvent tls security(and > other protections), > by telling the kernel to probe the function calls with the uprobes api. > As this enables i.e. the hosting system of a vm or container, to track > activity inside the container, trust is lost i.e. from customer to > hoster. To be fair, you need to be root on the host to do this, but as > it "wasn't possible before", and it is "now" ( out in a greater public > ), it tends to create trust issues, just for being there*. > > As this only works with uprobes enabled and has no use case besides a > developer debugging apps, the question is: > > Do we need this for all others out there enabled by default? Both systemtap and bpftrace can use uprobes. Those capabilities have been important from time to time in my job. That does not mean that my ability to do my job should outweigh security concerns, of course, but I think some effort should be made to find out if use of uprobes via systemtap and bpftrace is common amongst Fedora users. -- Jerry James http://www.jamezone.org/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Does ccache ever help with kernel mock build?
On Tue, Feb 13, 2024 at 9:52 AM Miroslav Suchý wrote: > > Dne 13. 02. 24 v 9:08 Julian Sikorski napsal(a): > > Could this be the reason for ccache not working? > > I wonder whether it is Mock problem, Ccache issue or problem in packaging? > Does the ccache speadup the build when you > run it with plain rpmbuild and ccache on host? I have lost track of the details (and the version of ccache when the issue was addressed/patched), but ccache at one time included SOURCE_DATE_EPOCH in the default hash, resulting in no cache hits. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Unresponsive packagers: irina
Hello Roderick, That would be greatly appreciated if Kim van der Riet could assist it. Otherwise I will do it. Thanks in advance,Hirotaka On Tuesday, February 13, 2024 at 07:45:13 PM GMT+9, Roderick Kieley wrote: Hi Hirotaka, Irina recently retired both professionally and from open source activity in general - at least for the moment. She had been working with Kim van der Riet, another packager, for a while so it's likely he could assist but I'll let him chime in directly when he gets a chance. Roddie Kieley On Tue, Feb 13, 2024 at 6:16 AM Hirotaka Wakabayashi via devel wrote: Hello everyone, does someone know how to contact with irina? I would like to ask irina to review the PR[1] against the qpid-proton package that irina maintains. I think the issue is not a critical, but there is no response from her for about a month. I would like to take over the package if irina will not maintain it becauseI would like to become the owner of python-pyngus that depends on qpid-proton. Best Regards, Hirotaka [1] https://src.fedoraproject.org/rpms/qpid-proton/pull-request/5 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 -- Roddie Kieley Manager & Principal Software Engineer AMQ on OpenShift Lead, Messaging Engineering Red Hat Canada || -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [Pierre-Yves Chibon] Unresponsive packagers: nknazeko
On Sun, Feb 11, 2024 at 10:44:18PM +0100, Vit Mojzis wrote: > Hello Pierre, Hi Vit, Sorry for the late reply > Nikola left Red Hat and hence changed the email address in FAS. I'm > guessing that only her Red Hat email was tied to a BZ account. > I'll try and let her know. Do I understand correctly that she just needs > to create a new BZ account using the email address in FAS? That's correct, she either need to create a bugzilla account associated with the email she uses in FAS, or fill in the "bugzilla email" field of her FAS account with the email of her bugzilla account. Thanks for your help! Pierre > On 2/9/24 15:06, Petr Lautrbach wrote: > Good Morning Everyone, > > Since November 1st, we have been emailing daily the following user to notify > that the email they have set in FAS does not correspond to a valid bugzilla > account. > This is a requirement for Fedora packagers. > > Does someone know how to contact nknazeko? > > nknazeko is maintainer of rpms/selinux-policy > > > Thanks for your help, > > Pierre > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > End of forwarded message -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Does ccache ever help with kernel mock build?
Dne 13. 02. 24 v 9:08 Julian Sikorski napsal(a): Could this be the reason for ccache not working? I wonder whether it is Mock problem, Ccache issue or problem in packaging? Does the ccache speadup the build when you run it with plain rpmbuild and ccache on host? -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Unresponsive packagers: irina
Hello everyone, does someone know how to contact with irina? I would like to ask irina to review the PR[1] against the qpid-proton package that irina maintains. I think the issue is not a critical, but there is no response from her for about a month. I would like to take over the package if irina will not maintain it becauseI would like to become the owner of python-pyngus that depends on qpid-proton. Best Regards, Hirotaka [1] https://src.fedoraproject.org/rpms/qpid-proton/pull-request/5 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: do we need CONFIG_UPROBES=y in our kernels?
On 2/12/24 19:15, Marius Schwarz wrote: As this enables i.e. the hosting system of a vm or container, to track activity inside the container, trust is lost i.e. from customer to hoster. To be fair, you need to be root on the host to do this, but as it "wasn't possible before", and it is "now" ( out in a greater public ), it tends to create trust issues, just for being there*. [...] *) You may not have a clue, what security auditors tell you about "a vulnerability & it's just there, but inexploitable". I had a case 2 weeks ago, about a missing patch for the ssh-agent CVE vulnerability in fedora's openssh. Trust me, it will create trouble the more the topic is discussed in the pubic. Auditors are constantly proposing disabling features and making things inconvenient, undebuggable, inefficient and substantially annoying to operate. They should instead learn some basic concepts of security. For example: if you are running a process, even in a VM or container, you have to trust the administrator of the host system. And that's it. Regards. -- Roberto Ragusamail at robertoragusa.it -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Does ccache ever help with kernel mock build?
Am 12.02.24 um 23:01 schrieb Julian Sikorski: Am 12.02.24 um 22:10 schrieb Miroslav Suchý: Dne 12. 02. 24 v 19:29 Julian Sikorski napsal(a): Hello, has anyone successfully managed to get ccache to speed up kernel mockbuilds, be it SRPMS from kernel-ark or from dist-git? I gave it a brief shot but saw no difference, if anything the build was slower. The machine I am building on has 32 GB RAM which is not quite enough to fit everything on a ramdisk, and the drive I am building to is an NVME SSD, "only" PCI Express 3.0. CPU is a Ryzen 5 5600x. A baseonly builds takes about 25 minutes, which is somewhat annoying when one has to bisect something. If ccache can speed this up, how big does it need to be? I understand the default 4 GB is nowhere near enough but what would be needed to actually help? Thanks! Just to be sure - did you configured Mock to use it? https://rpm-software-management.github.io/mock/Plugin-CCache the build from build container cannot see host ccache, so Mock must specially configure it. This is by default off, because in multi user environment you can easily poison the cache and affect different build. This should be enabled only on VM where you trust all users that can run Mock. E.g. your personal developer workstation. I am building with: --enable-plugin=ccache --plugin-option=ccache:max_cache_size='40G' Building with cold cache took 29:29, building with hot cache 29:45, so there appears to be no benefit so far. /var/cache/mock/fedora-36-x86_64/ccache is 9,5G in size, suggesting that size is not the problem. I am down to 21 commits to bisect after the current one, so changes to kernel source tree should be minimal at this point. Do I need to install ccache on the host as well? Best regards, Julian Installing ccache on the host did not help either. If anything, builds are getting slower, last one took 29:15. My guess would be that this is due to cache getting bigger (at 15G now) but no matches getting found. I am down to two commits to test left after the current one so source changes cannot possibly be the reason. Is the kernel version defined across the source perhaps? I am changing the LOCALVERSION from build to build in order to be able to tell the kernels apart, i.e. I have: - kernel-5.19.0-0.rc0.fdaf9a5840ac.200.bs11.fc36.src.rpm - kernel-5.19.0-0.rc0.fdaf9a5840ac.200.bs12.fc36.src.rpm - etc. Even the commit in the SRPM name does not change anymore at this point. Other than that, the build command is the same every single time: - git bisect good/bad - git branch bs12 - git checkout os-build-5.19-alt - git merge bs12 - make LOCALVERSION=".bs12" BUILD=200 dist-srpm - mock --chain --localrepo /mnt/openmediavault/kernel/ -r eol/fedora-36-x86_64 --disable-plugin=tmpfs --enable-plugin=yum_cache --enable-plugin=ccache --plugin-option=ccache:max_cache_size='40G' --kernel-5.19.0-0.rc0.fdaf9a5840ac.200.bs12.fc39.src.rpm --with baseonly Could this be the reason for ccache not working? Best regards, Julian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Does ccache ever help with kernel mock build?
Dne 12. 02. 24 v 23:01 Julian Sikorski napsal(a): Do I need to install ccache on the host as well? No. Mock installs the ccache into buildroot. It is injected as additional Build requires https://github.com/rpm-software-management/mock/blob/main/mock/py/mockbuild/plugins/ccache.py#L35 -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
