[Bug 1921955] perl-Test-Output-1.032 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1921955 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|st...@silug.org | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[389-devel] 389 DS nightly 2021-01-29 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/01/29/report-389-ds-base-2.0.2-20210129git90c488370.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Sat, Jan 23, 2021 at 4:29 AM Zbigniew Jędrzejewski-Szmek wrote: > > (One possible direction: one thing I want to explore next is using zram > or zwap based on whether the machine has a physical swap device. Maybe > such a language would be useful then — with additional variables > specifying e.g. the physical swap size…) What about setting vm.swappiness = 120? When set to 100, the bias for reclaiming anonymous pages and file pages is about equal. Setting it lower is predicated on (a) older kernels and (b) spinning drives where the cost for page out and page in is higher than dropping a file page and only reading it back in. With zram based swap, eviction and reclaim of anon pages is unquestionably a lot cheaper now, and even cheaper than the cost of reading in a file page. I'm even thinking it could be pushed higher than 120. I don't think there's a way to make this smart enough to scale this to the swap backing storage performance, which is what we really want. Hence 120 is a compromise in case there's also disk based swap. A down the road enhancement might be, if no disk based swap is detected, push this to 190. This would also allow some time to get some feedback with it set to 120 before pushing harder. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
[EPEL-devel] Re: EPEL9 - thoughts and timings
On Thu, 2021-01-28 at 15:15 -0800, Kevin Fenzi wrote: > On Thu, Jan 28, 2021 at 03:05:16PM -0800, Troy Dawson wrote: > > As we are getting closer to the F34 branching, which means we are > > getting closer to CentOS 9 Stream, which will eventually be turned > > into RHEL9 Beta, and then RHEL9 release. Now seems like a good > > time > > to get ideas flowing about EPEL9. > > > > I'm just throwing ideas around. Nothing I'm saying here is even > > close > > to policy or a final plan. If people have other ideas, feel free > > to > > say them. > > > > epel8-next is getting closer and closer to being in place. > > To me it seems logical to create a epel9-next, pointing at the > > CentOS > > 9 Stream (when it comes). It would need the same setting up as > > epel8-next, all the steps would be the same other than the name and > > where it points for it's repo. > > > > We could also setup some type of signup board for if maintainers > > want > > the EPEL Packaging SIG to automatically bring their packages over. > > > > With epel9-next in place, and good set of EPEL9 packages in it, > > users > > would be able to test RHEL9 much better in it's beta phase. > > > > Also, it would take alot of pressure off when we start getting > > regular > > EPEL9 setup. If it takes a month or two, people wouldn't be as > > concerned, because they could always just grab the packages from > > epel9-next. > > I think that could be workable, but I'll toss out another proposal: > > As soon as centos 9 stream exists, we create epel9-playground and > allow > people to branch/add packages to it. Once rhel9 is GA, we setup epel9 > as > usual and epel9-next and point epel9-next to build against stream and > playground to build against rhel9. epel9-playground acting first as a "Rawhide" for c9s pre-RHEL9 GA and then as a playground for RHEL9 could be a bit confusing? > > The advantages of that would be that epel9-playground is more rawhide > like... it would compose every night and there's no bodhi overhead. > Of course to be confusing we could just treat epel9-stream that way > until GA too I suppose. > Right, using epel9-next but with no Bodhi gating until GA seems like a nice idea. To add another variant to this: we can also start enabling Bodhi but with time-to-stable set to 3 days (like Fedora betas) once RHEL 9 is in beta? i.e. "we think c9s should have stabilized enough by now that we can start gating EPEL packages targeting it". Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: This is a digitally signed message part ___ 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-83ab5bb91b opensmtpd-6.8.0p2-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b68969af8c chromium-88.0.4324.96-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-403074b7e0 seamonkey-2.53.6-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-aadbebf090 monitorix-3.13.1-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing koji-1.23.1-1.el8 libabigail-1.8.1-1.el8 lua-readline-2.9-3.el8 Details about builds: koji-1.23.1-1.el8 (FEDORA-EPEL-2021-f3a1430962) Build system tools Update Information: Update to bugfix release 1.23.1. Fixup compatibility of kojid with koji- hub 1.21 ChangeLog: * Thu Jan 28 2021 Kevin Fenzi - 1.23.1-1 - Update to 1.23.1. Fixes rhbz#1917340 * Sun Jan 17 2021 Igor Raits - 1.23.0-3 - Fixup compatibility of kojid with koji-hub 1.21 * Mon Nov 30 2020 Kevin Fenzi - 1.23.0-2 - Fix 32 bit arm install issue. Fixes bug #1894261 libabigail-1.8.1-1.el8 (FEDORA-EPEL-2021-50207d9969) Set of ABI analysis tools Update Information: Update to upstream fixes up to libabigail-1.8.1 ChangeLog: * Wed Jan 27 2021 Dodji Seketeli - 1.8.1-1 - Update to upstream fixes up to libabigail-1.8.1 This encompasses this fixes, compared to the last 1.8 release: ir: Add better comments to types_have_similar_structure mainpage: Update web page for 1.8 release Bug 26992 - Try harder to resolve declaration-only classes Bug 27204 - potential loss of some aliased ELF function symbols Ignore duplicated functions and those not associated with ELF symbols Bug 27236 - Pointer comparison wrongly fails because of typedef change Bug 27233 - fedabipkgdiff fails on package gnupg2 from Fedora 33 Bug 27232 - fedabipkgdiff fails on gawk from Fedora 33 dwarf-reader: Support fast DW_FORM_line_strp string comparison gen-changelog.py: Update call to subprocess.Popen & cleanup Bug 27255 - fedabipkgdiff fails on nfs-utils on Fedora 33 abidiff: support --dump-diff-tree with --leaf-changes-only ir: Arrays are indirect types for type structure similarity purposes Add qualifier / typedef / array / pointer test abg-ir: Optimize calls to std::string::find() for a single char. abipkgdiff: Address operator precedence warning lua-readline-2.9-3.el8 (FEDORA-EPEL-2021-09f86c8ee8) Lua interface to the readline and history libraries Update Information: Upstream reissued 2.8 with fixed version number. Fixed packaging so on Fedora < 33 and RHEL < 9 it correctly requires `lua(abi)` - Update to 2.8 - Fix the reported version, it was not bumped for 2.8 - Use Fedora-specific linker flags (thanks to Robert Scheck ) - Add basic loadability checks (Robert) - Pull in lua-rpm-macros explicitly on EL <= 7 ChangeLog: * Wed Jan 27 2021 Michel Alexandre Salim - 2.9-3 - Fix lua(abi) logic * Wed Jan 27 2021 Michel Alexandre Salim - 2.9-2 - Add Requires on lua(abi) for older releases * Wed Jan 27 2021 Michel Alexandre Salim - 2.9-1 - Update to 2.9 * Tue Jan 26 2021 Michel Alexandre Salim - 2.8-1 - Update to 2.8 - Fix the reported version, it was not bumped for 2.8 - Use Fedora-specific linker flags (thanks to Robert Scheck ) - Add basic loadability checks (Robert) - Pull in lua-rpm-macros explicitly on EL7 References: [ 1 ] Bug #1914667 - Lack of Fedora-specific linker flags https://bugzilla.redhat.com/show_bug.cgi?id=1914667 [ 2 ] Bug #1914686 - lua-readline-2.8 is available https://bugzilla.redhat.com/show_bug.cgi?id=1914686 [ 3 ] Bug #1920958 - lua-readline-2.9 is available https://bugzilla.redhat.com/show_bug.cgi?id=1920958 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org
[Bug 1922014] New: perlbrew-0.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1922014 Bug ID: 1922014 Summary: perlbrew-0.90 is available Product: Fedora Version: rawhide Status: NEW Component: perlbrew Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.90 Current version/release in rawhide: 0.89-1.fc34 URL: http://search.cpan.org/dist/App-perlbrew/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3552/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1921533] perl-JSON-Path-0.431 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1921533 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-JSON-Path-0.430 is |perl-JSON-Path-0.431 is |available |available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 0.431 Current version/release in rawhide: 0.420-9.fc33 URL: http://search.cpan.org/dist/JSON-Path/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/15651/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1921955] New: perl-Test-Output-1.032 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1921955 Bug ID: 1921955 Summary: perl-Test-Output-1.032 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Output Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.032 Current version/release in rawhide: 1.03.1-12.fc33 URL: http://search.cpan.org/dist/Test-Output/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3408/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: [ELN] Is it really necessary to build a package 100+ times when there is a bootstrap issue?
On 1/28/21 9:58 AM, Miro Hrončok wrote: > This topic was brought up several times already, but I don't think there has > been a satisfactory answer to it yet. So let's try again. > > We have recently updated python-elementpath-2.1.1-2.fc34 and > python-xmlschema-1.4.1-1.fc34 -- it requires a very simple bootstrapping that > can be seen in the git history. > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-eb7554bd39 > > I know that the ELN rebuild tooling cannot handle bootstrapping and I know it > has been told this will eventually be solved. I appreciate that it is planned. > > But in the meantime, is it really necessary to build the packages 100/111 > times? > > https://src.fedoraproject.org/rpms/python-elementpath/c/5de3aa397bda5550047dff85905448c22f844a72?branch=master > > > https://src.fedoraproject.org/rpms/python-xmlschema/c/0c1384c7aaed1d6404bdf96e31044d7ef7671b2b?branch=master > > > Could you please not do that? I realize that sometimes dependency issues are > transient. I sometimes beat packages with a stick until they build as well, > but more than 100 builds in less than two weeks feels a little far fetched. > > Please, make the automation stop and inspect the problem by a human after a > reasonable amount of trials (I'd say 3, possibly 12, but not 100+). > > Alternatively at least slow down the firing rate with time. After two weeks of > failures it might make sense to give it a try every other day, but not every > other hour. > > Thanks. > +1. (And yes I've complained about it before as well). I'm getting spammed many times a day by openmpi/vtk/gdal builds as well. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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
[EPEL-devel] Re: EPEL9 - thoughts and timings
On Thu, Jan 28, 2021 at 03:05:16PM -0800, Troy Dawson wrote: > As we are getting closer to the F34 branching, which means we are > getting closer to CentOS 9 Stream, which will eventually be turned > into RHEL9 Beta, and then RHEL9 release. Now seems like a good time > to get ideas flowing about EPEL9. > > I'm just throwing ideas around. Nothing I'm saying here is even close > to policy or a final plan. If people have other ideas, feel free to > say them. > > epel8-next is getting closer and closer to being in place. > To me it seems logical to create a epel9-next, pointing at the CentOS > 9 Stream (when it comes). It would need the same setting up as > epel8-next, all the steps would be the same other than the name and > where it points for it's repo. > > We could also setup some type of signup board for if maintainers want > the EPEL Packaging SIG to automatically bring their packages over. > > With epel9-next in place, and good set of EPEL9 packages in it, users > would be able to test RHEL9 much better in it's beta phase. > > Also, it would take alot of pressure off when we start getting regular > EPEL9 setup. If it takes a month or two, people wouldn't be as > concerned, because they could always just grab the packages from > epel9-next. I think that could be workable, but I'll toss out another proposal: As soon as centos 9 stream exists, we create epel9-playground and allow people to branch/add packages to it. Once rhel9 is GA, we setup epel9 as usual and epel9-next and point epel9-next to build against stream and playground to build against rhel9. The advantages of that would be that epel9-playground is more rawhide like... it would compose every night and there's no bodhi overhead. Of course to be confusing we could just treat epel9-stream that way until GA too I suppose. In any case as soon as centos 9 stream is ready, I think it would indeed be a great idea to start allowing epel builds against it one way or another. :) kevin signature.asc Description: PGP signature ___ 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
[EPEL-devel] Re: EPEL9 - thoughts and timings
On Thu, Jan 28, 2021 at 03:05:16PM -0800, Troy Dawson wrote: > epel8-next is getting closer and closer to being in place. > To me it seems logical to create a epel9-next, pointing at the CentOS > 9 Stream (when it comes). It would need the same setting up as > epel8-next, all the steps would be the same other than the name and > where it points for it's repo. Makes sense to me! -- Matthew Miller Fedora Project Leader ___ 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
[EPEL-devel] EPEL9 - thoughts and timings
As we are getting closer to the F34 branching, which means we are getting closer to CentOS 9 Stream, which will eventually be turned into RHEL9 Beta, and then RHEL9 release. Now seems like a good time to get ideas flowing about EPEL9. I'm just throwing ideas around. Nothing I'm saying here is even close to policy or a final plan. If people have other ideas, feel free to say them. epel8-next is getting closer and closer to being in place. To me it seems logical to create a epel9-next, pointing at the CentOS 9 Stream (when it comes). It would need the same setting up as epel8-next, all the steps would be the same other than the name and where it points for it's repo. We could also setup some type of signup board for if maintainers want the EPEL Packaging SIG to automatically bring their packages over. With epel9-next in place, and good set of EPEL9 packages in it, users would be able to test RHEL9 much better in it's beta phase. Also, it would take alot of pressure off when we start getting regular EPEL9 setup. If it takes a month or two, people wouldn't be as concerned, because they could always just grab the packages from epel9-next. Troy ___ 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
Fedora-IoT-33-20210128.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-33-20210121.0): ID: 764536 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/764536 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-33-20210121.0): ID: 764520 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/764520 Passed openQA tests: 14/15 (aarch64), 15/16 (x86_64) New passes (same test not passed in Fedora-IoT-33-20210121.0): ID: 764538 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/764538 ID: 764549 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/764549 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
Vít Ondruch writes: > Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a): >> Vít Ondruch writes: >> >>> Thx everybody for their responses and sorry for such controversial >>> topic. I am not going to propose this upstream after all. However I >>> have few takeaways: >>> >>> 1) I see responses of Fedora long timers and I understand that you >>> have polished workflows. But I really think that for newcomers, mock >>> should be the preferred way. I'd love to see documentation adjusted >>> to prefer mock everywhere. >>> >>> 2) I would really love you to stop using VMs for your build/testing. >>> With exception of Kernel and Kernel related issues, the argument of >>> "mock being slow" can't stand. Every VM will be more resources >>> hungry then mock, slowing every your task. >>> >>> 3) The argument of mock being slow can't stand, because in one of my >>> examples I posted elsewhere in this thread, I picked up the simplest >>> package I could and the build took 7 seconds. This is certainly not >>> slow, in this time you can't even switch to your email client to >>> check your emails. >> >> So far on this thread, you've asked feedback on a proposal, and then >> when provided with feedback you didn't like, repeatedly argued with >> our comments and told us we're wrong. This is not a good way to >> engage with feedback. > > > I have provided the numbers here: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/ > > where I tried to point out that I don't perceive build of trivial > package done in 7s to be slow. For nontrivial package the mock overhead > is negligible. Nobody replied (in constructive way). On various places, > I have suggested to use "--no-clean" option for repeated builds. But in > the whole thread, there was no confirmation that anyone would use it. > > Yet I am repetitively told that mock is slow, you repeat it down bellow > once again without any evidence. Your only argument to this discussion > is that mock is slow, because you believe so and other people have said > so. I would really appreciate if I was given some specific > counterargument supported by numbers. I believe you are missing my point. Your original email reads: I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? This is a *request for input*. You explicitly mention wanting to know "sentiment" [1]. I didn't reply because I wanted to complain or argue; I replied to express what my feelings are. Don't ever tell someone that their feelings are wrong. You want to have a technical argument, fine. But an email initiating that looks very different. Here's an example: `fedpkg local` is a burden to maintain because [insert reasons]. I would like to have everyone using mock instead. What improvements do we need to make in order for your workflow to move off `fedpkg local`? This requests concrete data - actionable points, even. It states intentions clearly, and a request for details and data isn't out of scope. Thanks, --Robbie 1: Here's Merriam-Webster on that: https://www.merriam-webster.com/dictionary/sentiment - note that *every single definition* is subjective and/or involves emotion. 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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, Jan 28, 2021 at 2:08 PM Adam Williamson wrote: > > On Thu, 2021-01-28 at 13:46 -0700, Chris Murphy wrote: > > > > OK I'm seeing this problem in a VM with > > Fedora-Workstation-Live-x86_64-Rawhide-20210128.n.0.iso but I'm not > > sure how consistent it is yet. MemTotal is ~3G for a VM that has 4G > > allocated. Something's wrong... > > > > VM 5.11.0-0.rc5.20210127git2ab38c17aac1.136.fc34.x86_64 > > [0.701792] Memory: 3016992K/4190656K available (43019K kernel > > code, 11036K rwdata, 27184K rodata, 5036K init, 31780K bss, 1173408K > > reserved, 0K cma-reserved) > > > > Baremetal 5.10.11-200.fc33.x86_64 > > [0.125875] Memory: 12059084K/12493424K available (14345K kernel > > code, 3465K rwdata, 9704K rodata, 2536K init, 5504K bss, 434080K > > reserved, 0K cma-reserved) > > > > Why is reserved so much higher in the VM case? It clearly sees the 4G > > but is delimiting it to 3G for some reason I don't understand. This is > > well before the zram module is loaded, by the way. > > I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1921923 for > this. zdzichu suggests https://lkml.org/lkml/2021/1/25/701 may be > related. I'm not sure, because Revert "mm: fix initialization of struct page for holes in memory layout" landed in 5.10.11 and I wasn't have any of these memory related issues with 5.10.10. I'm only seeing this so far with the debug kernels. Even rc5 nodebug doesn't exhibit the problem. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, 2021-01-28 at 13:46 -0700, Chris Murphy wrote: > > OK I'm seeing this problem in a VM with > Fedora-Workstation-Live-x86_64-Rawhide-20210128.n.0.iso but I'm not > sure how consistent it is yet. MemTotal is ~3G for a VM that has 4G > allocated. Something's wrong... > > VM 5.11.0-0.rc5.20210127git2ab38c17aac1.136.fc34.x86_64 > [0.701792] Memory: 3016992K/4190656K available (43019K kernel > code, 11036K rwdata, 27184K rodata, 5036K init, 31780K bss, 1173408K > reserved, 0K cma-reserved) > > Baremetal 5.10.11-200.fc33.x86_64 > [0.125875] Memory: 12059084K/12493424K available (14345K kernel > code, 3465K rwdata, 9704K rodata, 2536K init, 5504K bss, 434080K > reserved, 0K cma-reserved) > > Why is reserved so much higher in the VM case? It clearly sees the 4G > but is delimiting it to 3G for some reason I don't understand. This is > well before the zram module is loaded, by the way. I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1921923 for this. zdzichu suggests https://lkml.org/lkml/2021/1/25/701 may be related. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, Jan 28, 2021 at 1:46 PM Chris Murphy wrote: > > VM 5.11.0-0.rc5.20210127git2ab38c17aac1.136.fc34.x86_64 > [0.701792] Memory: 3016992K/4190656K available (43019K kernel > code, 11036K rwdata, 27184K rodata, 5036K init, 31780K bss, 1173408K > reserved, 0K cma-reserved) > > Baremetal 5.10.11-200.fc33.x86_64 > [0.125875] Memory: 12059084K/12493424K available (14345K kernel > code, 3465K rwdata, 9704K rodata, 2536K init, 5504K bss, 434080K > reserved, 0K cma-reserved) OK the problem is happening whenever I boot a Fedora 5.11 debug kernel, going back to at least rc3. If it's not a debug kernel, the problem doesn't happen. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, Jan 28, 2021 at 12:34 PM Alexander Bokovoy wrote: > > On to, 28 tammi 2021, Chris Murphy wrote: > >> >> > ram + zram + in-memory-zwap in the check. > >> >> > >> >> For bare metal IPA uses the python3-psutil call: > >> >> psutil.virtual_memory.available() > >> >> > >> >> I don't know how/if psutil reports zram (or cgroup v1 and v2 for that > >> >> matter). > >> > > >> > psutil (in general) reports data from /proc/meminfo; available come > >> > from MemAvailable: in that file. This is defined in kernel as: > >> > > >> >MemAvailable: An estimate of how much memory is available for starting new > >> > applications, without swapping. Calculated from MemFree, > >> > SReclaimable, the size of the file LRU lists, and the low > >> > watermarks in each zone. > >> > The estimate takes into account that the system needs some > >> > page cache to function well, and that not all reclaimable > >> > slab will be reclaimable, due to items being in use. The > >> > impact of those factors will vary from system to system. > >> > > >> >Notice "without swapping" in second line. Next question, how zram impacts > >> >reporting of MemAvailable by kernel? > >> > >> This is a good note. If zram breaks kernel API promise to user space > >> (/proc/meminfo is one such API), how can it be enabled by default. I > >> also would question enabling zram by default if it does not play along > >> with cgroups. We do depend on cgroups being properly managed by systemd, > >> including resource allocation. > >> > >> In my opinion, zram enablement in Fedora is quite premature. > >> > > > > > >It's the default Fedora wide since Fedora 33. It's been used by default in > >Fedora IoT since the beginning, and in openQA Anaconda tests for even > >longer than that. > > > >What's premature about it? > > I tried to point to my line of thought in the sentence above you quoted. > You might think that is irrelevant which thought I'd accept as an > argument and we can agree to disagree. Speculation is not an adequate explanation for calling the feature premature. /proc/meminfo MemTotal: 12158520 kB With no zram device versus a zram device sized 1:1 that of MemTotal MemAvailable: 11367156 kB MemAvailable: 11309564 kB And CommitLimit: 6079260 kB CommitLimit:18237208 kB You can test this as easily as I can via 'systemctl start/stop swap-create@zram0' and see if it misaligns with expectations. I'm ignoring the cgroups complaint because there are other things that also don't work with cgroups ressource control that we're using in Fedora by default and I don't feel like beating up on those things, because while suboptimal it's also off topic for this problem. > Back to this subthread's topic. Looks like Adam found that something > did reduce a memory available to the system after standard install process > between Jan 24th and Jan 27th. Something did allocate ~120MB of RAM more > than it did previously on Fedora Server but also the kernel reports > ~600MB less RAM available even though in both cases QEMU was configured > with 2048MB RAM. OK I'm seeing this problem in a VM with Fedora-Workstation-Live-x86_64-Rawhide-20210128.n.0.iso but I'm not sure how consistent it is yet. MemTotal is ~3G for a VM that has 4G allocated. Something's wrong... VM 5.11.0-0.rc5.20210127git2ab38c17aac1.136.fc34.x86_64 [0.701792] Memory: 3016992K/4190656K available (43019K kernel code, 11036K rwdata, 27184K rodata, 5036K init, 31780K bss, 1173408K reserved, 0K cma-reserved) Baremetal 5.10.11-200.fc33.x86_64 [0.125875] Memory: 12059084K/12493424K available (14345K kernel code, 3465K rwdata, 9704K rodata, 2536K init, 5504K bss, 434080K reserved, 0K cma-reserved) Why is reserved so much higher in the VM case? It clearly sees the 4G but is delimiting it to 3G for some reason I don't understand. This is well before the zram module is loaded, by the way. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On Thu, Jan 28, 2021 at 12:55 PM Vít Ondruch wrote: > > I have started the thread reflecting on experience of fresh packager > coming to Fedora. First issue was that `fedpkg local` pollutes the work > directory. There is also second issue, that `fedpkg local` is polluting > the whole system with build dependencies (and this is my concern). I > don't think that anybody should have polluted work directory and their > system by packagers work. If experienced packages are fine with that, so > be it. But I am concerned, that these practices are possibly suggested > to fresh coming people. > I've largely been lurking, but my $0.02 worth... I used to use rpmbuild directly all the time, and while I only maintained a few packages having those build deps installed wasn't much of a big deal. However now that I maintain many times more packages, I can say that I never use rpmbuild -ba or fedpkg local, instead I just deal with the little bit of extra time it takes to setup the chroot. That being said I have a Ryzen 5 3600 w/ 32GB of memory and a Samsung 960 EVO m.2 drive so it's not THAT bad for me. If there is a build failure I attempt a fix and use --no-clean which speeds up the following builds quite a bit. So a couple of ways I deal with build failures: 1/ Patches don't apply cleanly I use quilt which works OK but it does not play nice with spec files 100%. It essentially stops at the first patch failure so once I fix that I have to delete the directory and run quilt setup again. This is less than ideal. I also wish it didn't erase the non-patch parts which are often used to put contextual information or github patch info. 2/ Ambiguous build failure error message or segfault. Here I use the shell option to go into to chroot. It has some quirks as well. It drops you into the root so you have to do the whole cd builddir/build/BUILD/... or something like that (I'm at $DAYJOB right now). Could it not take you directly to the build dir? Also useful tools like vim or less need to be explicitly installed and often don't work exactly the same inside the chroot as they do outside. BUT it does allow you to interrogate/troubleshoot binaries and test, etc. I have already withdrew the original proposal, but that does not mean I > am less concerned. > I don't think it's a waste. I agree that we should encourage use of mock/fedpkg mockbuild in the documentation but we could also try to remove/reduce the reasons people use fedpkg local. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, Jan 28, 2021 at 11:52 AM Adam Williamson wrote: > > Probably relevant - we log the output of `free` shortly after system > install. Up to and including Fedora-Rawhide-20210124.n.0 , it looked > approximately like this: > > totalusedfree shared buff/cache > available > Mem:2024132 189668 16094484104 225016 > 1684936 > Swap: 1011708 0 1011708 > > Particularly, "total" memory was reported as around 200 bytes. In > Fedora-Rawhide-20210127.n.1 and Fedora-Rawhide-20210128.n.0, though - > the two most recent composes - it looks like this: > > totalusedfree shared buff/cache > available > Mem:1417856 311908 8528324104 253116 > 944752 > Swap: 1417212 0 1417212 > > "total" memory is now reported as around 140 bytes. Not sure what > caused this to change. I've seen this in the last few weeks but I haven't figured out the pattern. A test system with 12G RAM was transiently reporting 8.5G RAM (using the free command). That is the same fractional difference as you're reporting above - 70% less total memory. That could be a kernel bug. The zram-generator sets the zram device size as a fraction of total memory, it doesn't have a way to affect total memory. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On to, 28 tammi 2021, Chris Murphy wrote: >> > ram + zram + in-memory-zwap in the check. >> >> For bare metal IPA uses the python3-psutil call: >> psutil.virtual_memory.available() >> >> I don't know how/if psutil reports zram (or cgroup v1 and v2 for that >> matter). > > psutil (in general) reports data from /proc/meminfo; available come > from MemAvailable: in that file. This is defined in kernel as: > >MemAvailable: An estimate of how much memory is available for starting new > applications, without swapping. Calculated from MemFree, > SReclaimable, the size of the file LRU lists, and the low > watermarks in each zone. > The estimate takes into account that the system needs some > page cache to function well, and that not all reclaimable > slab will be reclaimable, due to items being in use. The > impact of those factors will vary from system to system. > >Notice "without swapping" in second line. Next question, how zram impacts >reporting of MemAvailable by kernel? This is a good note. If zram breaks kernel API promise to user space (/proc/meminfo is one such API), how can it be enabled by default. I also would question enabling zram by default if it does not play along with cgroups. We do depend on cgroups being properly managed by systemd, including resource allocation. In my opinion, zram enablement in Fedora is quite premature. It's the default Fedora wide since Fedora 33. It's been used by default in Fedora IoT since the beginning, and in openQA Anaconda tests for even longer than that. What's premature about it? I tried to point to my line of thought in the sentence above you quoted. You might think that is irrelevant which thought I'd accept as an argument and we can agree to disagree. Back to this subthread's topic. Looks like Adam found that something did reduce a memory available to the system after standard install process between Jan 24th and Jan 27th. Something did allocate ~120MB of RAM more than it did previously on Fedora Server but also the kernel reports ~600MB less RAM available even though in both cases QEMU was configured with 2048MB RAM. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On Thursday, January 28, 2021 7:55:05 PM CET Vít Ondruch wrote: > Dne 28. 01. 21 v 19:36 Simo Sorce napsal(a): > > On Thu, 2021-01-28 at 19:26 +0100, Vít Ondruch wrote: > >> Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a): > >>> Vít Ondruch writes: > Thx everybody for their responses and sorry for such controversial > topic. I am not going to propose this upstream after all. However I > have > few takeaways: > > 1) I see responses of Fedora long timers and I understand that you > have polished workflows. But I really think that for newcomers, mock > should be the preferred way. I'd love to see documentation adjusted to > prefer mock everywhere. > > 2) I would really love you to stop using VMs for your build/testing. > With exception of Kernel and Kernel related issues, the argument of > "mock being slow" can't stand. Every VM will be more resources hungry > then mock, slowing every your task. > > 3) The argument of mock being slow can't stand, because in one of my > examples I posted elsewhere in this thread, I picked up the simplest > package I could and the build took 7 seconds. This is certainly not > slow, in this time you can't even switch to your email client to check > your emails. > >>> > >>> So far on this thread, you've asked feedback on a proposal, and then > >>> when provided with feedback you didn't like, repeatedly argued with our > >>> comments and told us we're wrong. This is not a good way to engage with > >>> feedback. > >> > >> I have provided the numbers here: > >> > >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o > >> rg/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/ > >> > >> where I tried to point out that I don't perceive build of trivial > >> package done in 7s to be slow. For nontrivial package the mock overhead > >> is negligible. Nobody replied (in constructive way). On various places, > >> I have suggested to use "--no-clean" option for repeated builds. But in > >> the whole thread, there was no confirmation that anyone would use it. > >> > >> Yet I am repetitively told that mock is slow, you repeat it down bellow > >> once again without any evidence. Your only argument to this discussion > >> is that mock is slow, because you believe so and other people have said > >> so. I would really appreciate if I was given some specific > >> counterargument supported by numbers. > > > > That "mock is slow" is just one of the claims, and not the prevalent > > one at that. > > It is also inconvenient. > > Takes disk space and bandwidth I do not care for. > > It is complex to use when what you care is to fit the current running > > systems. > > And in general, for those that do not use it is yet another thing to > > learn to use that I personally do not care for learning as I have no > > need for it. > > > > You are claiming that "fedpkg local" is bad, we are responding it is > > not, we use it and it works better for us. > > > > As for many other things there isn't just one true way, mock works best > > for you, and local works best for others, why is that a problem ? > > I have started the thread reflecting on experience of fresh packager > coming to Fedora. First issue was that `fedpkg local` pollutes the work > directory. There is also second issue, that `fedpkg local` is polluting > the whole system with build dependencies (and this is my concern). I > don't think that anybody should have polluted work directory and their > system by packagers work. If experienced packages are fine with that, so > be it. But I am concerned, that these practices are possibly suggested > to fresh coming people. > > I have already withdrew the original proposal, but that does not mean I > am less concerned. > > > Vít I have never used `fedpkg local` myself. However, what prevents me from doing the following steps? $ fedpkg srpm $ sudo yum builddep ... $ rpmbuild --rebuild ... $ sudo yum install ... The above is my usual workflow when I debug something. Is it also going to be prohibited in some way? Kamil > > Simo. > > > >> Vít > >> > >>> In particular, *numerous* people have told you that mock builds are > >>> slow for us. Instead of telling us that we're wrong about our own > >>> experience because it doesn't match yours, make an effort to understand > >>> what the difference is between them. Or accept it for what it is: > >>> feedback that *you asked for*. > >>> > >>> Thanks, > >>> --Robbie > >> > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > >> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List > >> Archives: > >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject. > >> org
Re: Test failures
On 1/28/21 10:16 AM, Boian Bonev wrote: > Hi, > > I just did a build (new upstream release of iotop-c) and saw a couple > of test errors; they look like segfaults or post errors, so I suppose > that I didn't do some stupid mistake. > > Posting the result here, to keep the relevant team informed; in case > these are known, sorry for the noise :) > > https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/8520/testReport/(root)/tests/ It looks like at least one of the issues is that the package is triggering a fault in abidiff. I've forwarded this issue to Dodji who knows those bits better than anyone. I'd hazard a guess it's dwarf-5 related. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, Jan 28, 2021, 11:11 AM Alexander Bokovoy
wrote:
> On to, 28 tammi 2021, Tomasz Torcz wrote:
> >On Thu, Jan 28, 2021 at 11:04:34AM -0500, Rob Crittenden wrote:
> >> Zbigniew Jędrzejewski-Szmek wrote:
> >> > On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
> >> >> With today's OpenQA tests I can point out that using zram on 2048MB
> RAM
> >> >> VMs actually breaks FreeIPA deployment:
> >> >>
> https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
> >> >>
> >> >> OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
> >> >> FreeIPA deployment with integrated CA and DNS server. Not anymore
> with
> >> >> zram activated:
> >> >>
> >> >> Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating
> unit dev-zram0.swap (/dev/zram0 with 1384MB)
> >> >>
> >> >> which ends up eating 2/3rds of the whole memory budget and FreeIPA
> >> >> installer fails:
> >> >>
> >> >> 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with
> arguments [] and options: {'unattended': True, 'ip_addresses': None,
> 'domain_name': 'test.openqa.fedoraproject.org', 'realm_name': '
> TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
> >> >> 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
> >> >> 2021-01-28T02:18:31Z DEBUG IPA platform fedora
> >> >> 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
> Prerelease)
> >> >> 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
> >> >> ...
> >> >> 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed,
> exception: ScriptError: Less than the minimum 1.2GB of RAM is available,
> 0.77GB available
> >> >> 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is
> available, 0.77GB available
> >> >> 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed.
> See /var/log/ipaserver-install.log for more information
> >> >
> >> > Enabling zram doesn't really "take away memory", because no
> pre-allocation happens.
> >> > If there is no physical swap, then adding zram0 should just shown
> additional
> >> > swap space, so I don't think it could cause the check to fail.
> >> > But if there is physical swap, the zram device is used with higher
> preference
> >> > than the physical swap. So I think the explanation could be that the
> VM has
> >> > a swap partition. Before, some pages would be swapped out to zram,
> and some would
> >> > be swapped out to the "real" swap. The fraction of RAM used for
> compressed zram
> >> > would be on the order of 25% (zram-fraction=0.5 multiplied by typical
> compression 2:1).
> >> >
> >> > But now the kernel sees more zram swap, so it inserts pages there,
> taking away
> >> > more of RAM, instead of saving pages to disk. So more memory (maybe
> 50% RAM) is
> >> > used for the unswappable compressed pages. But this shouldn't break
> things:
> >> > if there is enough pressure, pages would be swapped out to the
> physical swap device
> >> > too.
> >> >
> >> > Assuming that this guess is correct, the check that
> ipa-server-install is
> >> > doing should be adjusted. It should use the total available memory
> (ram + all kinds
> >> > of swap) in the check, and not just available uncompressed pages.
> >> > Or if it wants to ignore disk-based swap for some reason, it should
> use
> >> > ram + zram + in-memory-zwap in the check.
> >>
> >> For bare metal IPA uses the python3-psutil call:
> >> psutil.virtual_memory.available()
> >>
> >> I don't know how/if psutil reports zram (or cgroup v1 and v2 for that
> >> matter).
> >
> > psutil (in general) reports data from /proc/meminfo; available come
> > from MemAvailable: in that file. This is defined in kernel as:
> >
> >MemAvailable: An estimate of how much memory is available for starting new
> > applications, without swapping. Calculated from MemFree,
> > SReclaimable, the size of the file LRU lists, and the low
> > watermarks in each zone.
> > The estimate takes into account that the system needs some
> > page cache to function well, and that not all reclaimable
> > slab will be reclaimable, due to items being in use. The
> > impact of those factors will vary from system to system.
> >
> >Notice "without swapping" in second line. Next question, how zram impacts
> >reporting of MemAvailable by kernel?
>
> This is a good note. If zram breaks kernel API promise to user space
> (/proc/meminfo is one such API), how can it be enabled by default. I
> also would question enabling zram by default if it does not play along
> with cgroups. We do depend on cgroups being properly managed by systemd,
> including resource allocation.
>
> In my opinion, zram enablement in Fedora is quite premature.
>
It's the default Fedora wide since Fedora 33. It's been used by default in
Fedora IoT since the beginning, and in openQA Anaconda tests for even
longer than that.
What's premature about it?
Chris Murphy
Re: Proposal to deprecated `fedpkg local`
Dne 28. 01. 21 v 19:36 Simo Sorce napsal(a): On Thu, 2021-01-28 at 19:26 +0100, Vít Ondruch wrote: Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a): Vít Ondruch writes: Thx everybody for their responses and sorry for such controversial topic. I am not going to propose this upstream after all. However I have few takeaways: 1) I see responses of Fedora long timers and I understand that you have polished workflows. But I really think that for newcomers, mock should be the preferred way. I'd love to see documentation adjusted to prefer mock everywhere. 2) I would really love you to stop using VMs for your build/testing. With exception of Kernel and Kernel related issues, the argument of "mock being slow" can't stand. Every VM will be more resources hungry then mock, slowing every your task. 3) The argument of mock being slow can't stand, because in one of my examples I posted elsewhere in this thread, I picked up the simplest package I could and the build took 7 seconds. This is certainly not slow, in this time you can't even switch to your email client to check your emails. So far on this thread, you've asked feedback on a proposal, and then when provided with feedback you didn't like, repeatedly argued with our comments and told us we're wrong. This is not a good way to engage with feedback. I have provided the numbers here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/ where I tried to point out that I don't perceive build of trivial package done in 7s to be slow. For nontrivial package the mock overhead is negligible. Nobody replied (in constructive way). On various places, I have suggested to use "--no-clean" option for repeated builds. But in the whole thread, there was no confirmation that anyone would use it. Yet I am repetitively told that mock is slow, you repeat it down bellow once again without any evidence. Your only argument to this discussion is that mock is slow, because you believe so and other people have said so. I would really appreciate if I was given some specific counterargument supported by numbers. That "mock is slow" is just one of the claims, and not the prevalent one at that. It is also inconvenient. Takes disk space and bandwidth I do not care for. It is complex to use when what you care is to fit the current running systems. And in general, for those that do not use it is yet another thing to learn to use that I personally do not care for learning as I have no need for it. You are claiming that "fedpkg local" is bad, we are responding it is not, we use it and it works better for us. As for many other things there isn't just one true way, mock works best for you, and local works best for others, why is that a problem ? I have started the thread reflecting on experience of fresh packager coming to Fedora. First issue was that `fedpkg local` pollutes the work directory. There is also second issue, that `fedpkg local` is polluting the whole system with build dependencies (and this is my concern). I don't think that anybody should have polluted work directory and their system by packagers work. If experienced packages are fine with that, so be it. But I am concerned, that these practices are possibly suggested to fresh coming people. I have already withdrew the original proposal, but that does not mean I am less concerned. Vít Simo. Vít In particular, *numerous* people have told you that mock builds are slow for us. Instead of telling us that we're wrong about our own experience because it doesn't match yours, make an effort to understand what the difference is between them. Or accept it for what it is: feedback that *you asked for*. Thanks, --Robbie ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org OpenPGP_signature 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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, 2021-01-28 at 10:18 -0800, Adam Williamson wrote:
> On Thu, 2021-01-28 at 14:16 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
> > > With today's OpenQA tests I can point out that using zram on 2048MB RAM
> > > VMs actually breaks FreeIPA deployment:
> > > https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
> > >
> > > OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
> > > FreeIPA deployment with integrated CA and DNS server. Not anymore with
> > > zram activated:
> > >
> > > Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
> > > dev-zram0.swap (/dev/zram0 with 1384MB)
> > >
> > > which ends up eating 2/3rds of the whole memory budget and FreeIPA
> > > installer fails:
> > >
> > > 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments
> > > [] and options: {'unattended': True, 'ip_addresses': None, 'domain_name':
> > > 'test.openqa.fedoraproject.org', 'realm_name':
> > > 'TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
> > > 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
> > > 2021-01-28T02:18:31Z DEBUG IPA platform fedora
> > > 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
> > > Prerelease)
> > > 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
> > > ...
> > > 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed,
> > > exception: ScriptError: Less than the minimum 1.2GB of RAM is available,
> > > 0.77GB available
> > > 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is
> > > available, 0.77GB available
> > > 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
> > > /var/log/ipaserver-install.log for more information
> >
> > Enabling zram doesn't really "take away memory", because no pre-allocation
> > happens.
> > If there is no physical swap, then adding zram0 should just shown additional
> > swap space, so I don't think it could cause the check to fail.
> > But if there is physical swap, the zram device is used with higher
> > preference
> > than the physical swap. So I think the explanation could be that the VM has
> > a swap partition.
>
> The openQA test in question runs after, and uses the hard disk from, a
> test that runs a default Fedora Server install:
> https://openqa.fedoraproject.org/tests/763650
> which, AIUI, should not be creating a swap partition. The logs from the test -
> https://openqa.fedoraproject.org/tests/763657/file/role_deploy_domain_controller-var_log.tar.gz
> -
> do not show any swaps being activated other than zram ones. So no, I
> don't think there is a swap partition.
Probably relevant - we log the output of `free` shortly after system
install. Up to and including Fedora-Rawhide-20210124.n.0 , it looked
approximately like this:
totalusedfree shared buff/cache available
Mem:2024132 189668 16094484104 225016 1684936
Swap: 1011708 0 1011708
Particularly, "total" memory was reported as around 200 bytes. In
Fedora-Rawhide-20210127.n.1 and Fedora-Rawhide-20210128.n.0, though -
the two most recent composes - it looks like this:
totalusedfree shared buff/cache available
Mem:1417856 311908 8528324104 253116 944752
Swap: 1417212 0 1417212
"total" memory is now reported as around 140 bytes. Not sure what
caused this to change.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On Thu, 2021-01-28 at 19:26 +0100, Vít Ondruch wrote: > Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a): > > Vít Ondruch writes: > > > > > Thx everybody for their responses and sorry for such controversial > > > topic. I am not going to propose this upstream after all. However I have > > > few takeaways: > > > > > > 1) I see responses of Fedora long timers and I understand that you > > > have polished workflows. But I really think that for newcomers, mock > > > should be the preferred way. I'd love to see documentation adjusted to > > > prefer mock everywhere. > > > > > > 2) I would really love you to stop using VMs for your build/testing. > > > With exception of Kernel and Kernel related issues, the argument of > > > "mock being slow" can't stand. Every VM will be more resources hungry > > > then mock, slowing every your task. > > > > > > 3) The argument of mock being slow can't stand, because in one of my > > > examples I posted elsewhere in this thread, I picked up the simplest > > > package I could and the build took 7 seconds. This is certainly not > > > slow, in this time you can't even switch to your email client to check > > > your emails. > > So far on this thread, you've asked feedback on a proposal, and then > > when provided with feedback you didn't like, repeatedly argued with our > > comments and told us we're wrong. This is not a good way to engage with > > feedback. > > I have provided the numbers here: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/ > > where I tried to point out that I don't perceive build of trivial > package done in 7s to be slow. For nontrivial package the mock overhead > is negligible. Nobody replied (in constructive way). On various places, > I have suggested to use "--no-clean" option for repeated builds. But in > the whole thread, there was no confirmation that anyone would use it. > > Yet I am repetitively told that mock is slow, you repeat it down bellow > once again without any evidence. Your only argument to this discussion > is that mock is slow, because you believe so and other people have said > so. I would really appreciate if I was given some specific > counterargument supported by numbers. That "mock is slow" is just one of the claims, and not the prevalent one at that. It is also inconvenient. Takes disk space and bandwidth I do not care for. It is complex to use when what you care is to fit the current running systems. And in general, for those that do not use it is yet another thing to learn to use that I personally do not care for learning as I have no need for it. You are claiming that "fedpkg local" is bad, we are responding it is not, we use it and it works better for us. As for many other things there isn't just one true way, mock works best for you, and local works best for others, why is that a problem ? Simo. > > Vít > > > > In particular, *numerous* people have told you that mock builds are > > slow for us. Instead of telling us that we're wrong about our own > > experience because it doesn't match yours, make an effort to understand > > what the difference is between them. Or accept it for what it is: > > feedback that *you asked for*. > > > > Thanks, > > --Robbie > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a): Vít Ondruch writes: Thx everybody for their responses and sorry for such controversial topic. I am not going to propose this upstream after all. However I have few takeaways: 1) I see responses of Fedora long timers and I understand that you have polished workflows. But I really think that for newcomers, mock should be the preferred way. I'd love to see documentation adjusted to prefer mock everywhere. 2) I would really love you to stop using VMs for your build/testing. With exception of Kernel and Kernel related issues, the argument of "mock being slow" can't stand. Every VM will be more resources hungry then mock, slowing every your task. 3) The argument of mock being slow can't stand, because in one of my examples I posted elsewhere in this thread, I picked up the simplest package I could and the build took 7 seconds. This is certainly not slow, in this time you can't even switch to your email client to check your emails. So far on this thread, you've asked feedback on a proposal, and then when provided with feedback you didn't like, repeatedly argued with our comments and told us we're wrong. This is not a good way to engage with feedback. I have provided the numbers here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/ where I tried to point out that I don't perceive build of trivial package done in 7s to be slow. For nontrivial package the mock overhead is negligible. Nobody replied (in constructive way). On various places, I have suggested to use "--no-clean" option for repeated builds. But in the whole thread, there was no confirmation that anyone would use it. Yet I am repetitively told that mock is slow, you repeat it down bellow once again without any evidence. Your only argument to this discussion is that mock is slow, because you believe so and other people have said so. I would really appreciate if I was given some specific counterargument supported by numbers. Vít In particular, *numerous* people have told you that mock builds are slow for us. Instead of telling us that we're wrong about our own experience because it doesn't match yours, make an effort to understand what the difference is between them. Or accept it for what it is: feedback that *you asked for*. Thanks, --Robbie OpenPGP_signature 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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, 2021-01-28 at 14:16 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
> > With today's OpenQA tests I can point out that using zram on 2048MB RAM
> > VMs actually breaks FreeIPA deployment:
> > https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
> >
> > OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
> > FreeIPA deployment with integrated CA and DNS server. Not anymore with
> > zram activated:
> >
> > Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
> > dev-zram0.swap (/dev/zram0 with 1384MB)
> >
> > which ends up eating 2/3rds of the whole memory budget and FreeIPA
> > installer fails:
> >
> > 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments []
> > and options: {'unattended': True, 'ip_addresses': None, 'domain_name':
> > 'test.openqa.fedoraproject.org', 'realm_name':
> > 'TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
> > 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
> > 2021-01-28T02:18:31Z DEBUG IPA platform fedora
> > 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
> > Prerelease)
> > 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
> > ...
> > 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed,
> > exception: ScriptError: Less than the minimum 1.2GB of RAM is available,
> > 0.77GB available
> > 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is available,
> > 0.77GB available
> > 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
> > /var/log/ipaserver-install.log for more information
>
> Enabling zram doesn't really "take away memory", because no pre-allocation
> happens.
> If there is no physical swap, then adding zram0 should just shown additional
> swap space, so I don't think it could cause the check to fail.
> But if there is physical swap, the zram device is used with higher preference
> than the physical swap. So I think the explanation could be that the VM has
> a swap partition.
The openQA test in question runs after, and uses the hard disk from, a
test that runs a default Fedora Server install:
https://openqa.fedoraproject.org/tests/763650
which, AIUI, should not be creating a swap partition. The logs from the test -
https://openqa.fedoraproject.org/tests/763657/file/role_deploy_domain_controller-var_log.tar.gz
-
do not show any swaps being activated other than zram ones. So no, I
don't think there is a swap partition.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On to, 28 tammi 2021, Chris Murphy wrote:
On Thu, Jan 28, 2021, 6:21 AM Alexander Bokovoy <[1]aboko...@redhat.com>
wrote:
With today's OpenQA tests I can point out that using zram on 2048MB RAM
VMs actually breaks FreeIPA deployment:
[2]https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
FreeIPA deployment with integrated CA and DNS server. Not anymore with
zram activated:
Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
dev-zram0.swap (/dev/zram0 with 1384MB)
Swap on zram isn't recently enabled in Fedora, so why are the tests
recently failing?
Also, the default fraction is 0.5 so the zram device size should be
1024MB. Why is it 1384MB?
I have no idea why. This is Rawhide of today, automatically provisioned
in OpenQA. All logs are available in 'Logs and Artifacts' tab on the
OpenQA page referenced above.
Tests started to fail because we raised the low memory limit in FreeIPA
from 0.7GB to 1.2GB after seeing real world issues with lower memory
pressures.
which ends up eating 2/3rds of the whole memory budget and FreeIPA
installer fails:
That's not possible with default settings. The device size is not the
amount of memory used. The device size is virtual. The real amount used
depends on what's paged out to swap divided by the commission ratio.
If swap is being used at all it means the workload already used ~95% of
memory.
In the OpenQA test there is nothing running on the system yet. This
literally happens when a test runs 'ipa-server-install' and we haven't
yet gone to configure *anything*. This check is one of the earliest in
the installer.
2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments
[] and options: {'unattended': True, 'ip_addresses': None,
'domain_name': '[3]test.openqa.fedoraproject.org', 'realm_name':
'[4]TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
2021-01-28T02:18:31Z DEBUG IPA platform fedora
2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
Prerelease)
2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
...
2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed,
exception: ScriptError: Less than the minimum 1.2GB of RAM is available,
0.77GB available.
We need more info. Something is consuming more memory than the
provisioning expects. If there was no swap, the problem would be worse.
Please look into OpenQA logs. There is a tarball with /var/log/* content
there (and few more things), including a full systemd journal which
might have some additional information.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On to, 28 tammi 2021, Tomasz Torcz wrote:
On Thu, Jan 28, 2021 at 11:04:34AM -0500, Rob Crittenden wrote:
Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
>> With today's OpenQA tests I can point out that using zram on 2048MB RAM
>> VMs actually breaks FreeIPA deployment:
>>
https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
>>
>> OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
>> FreeIPA deployment with integrated CA and DNS server. Not anymore with
>> zram activated:
>>
>> Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
dev-zram0.swap (/dev/zram0 with 1384MB)
>>
>> which ends up eating 2/3rds of the whole memory budget and FreeIPA
>> installer fails:
>>
>> 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments []
and options: {'unattended': True, 'ip_addresses': None, 'domain_name':
'test.openqa.fedoraproject.org', 'realm_name': 'TEST.OPENQA.FEDORAPROJECT.ORG',
'host_name': None, 'ca_cert
>> 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
>> 2021-01-28T02:18:31Z DEBUG IPA platform fedora
>> 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
Prerelease)
>> 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
>> ...
>> 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed, exception:
ScriptError: Less than the minimum 1.2GB of RAM is available, 0.77GB available
>> 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is available,
0.77GB available
>> 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
>
> Enabling zram doesn't really "take away memory", because no pre-allocation
happens.
> If there is no physical swap, then adding zram0 should just shown additional
> swap space, so I don't think it could cause the check to fail.
> But if there is physical swap, the zram device is used with higher preference
> than the physical swap. So I think the explanation could be that the VM has
> a swap partition. Before, some pages would be swapped out to zram, and some
would
> be swapped out to the "real" swap. The fraction of RAM used for compressed
zram
> would be on the order of 25% (zram-fraction=0.5 multiplied by typical
compression 2:1).
>
> But now the kernel sees more zram swap, so it inserts pages there, taking away
> more of RAM, instead of saving pages to disk. So more memory (maybe 50% RAM)
is
> used for the unswappable compressed pages. But this shouldn't break things:
> if there is enough pressure, pages would be swapped out to the physical swap
device
> too.
>
> Assuming that this guess is correct, the check that ipa-server-install is
> doing should be adjusted. It should use the total available memory (ram + all
kinds
> of swap) in the check, and not just available uncompressed pages.
> Or if it wants to ignore disk-based swap for some reason, it should use
> ram + zram + in-memory-zwap in the check.
For bare metal IPA uses the python3-psutil call:
psutil.virtual_memory.available()
I don't know how/if psutil reports zram (or cgroup v1 and v2 for that
matter).
psutil (in general) reports data from /proc/meminfo; available come
from MemAvailable: in that file. This is defined in kernel as:
MemAvailable: An estimate of how much memory is available for starting new
applications, without swapping. Calculated from MemFree,
SReclaimable, the size of the file LRU lists, and the low
watermarks in each zone.
The estimate takes into account that the system needs some
page cache to function well, and that not all reclaimable
slab will be reclaimable, due to items being in use. The
impact of those factors will vary from system to system.
Notice "without swapping" in second line. Next question, how zram impacts
reporting of MemAvailable by kernel?
This is a good note. If zram breaks kernel API promise to user space
(/proc/meminfo is one such API), how can it be enabled by default. I
also would question enabling zram by default if it does not play along
with cgroups. We do depend on cgroups being properly managed by systemd,
including resource allocation.
In my opinion, zram enablement in Fedora is quite premature.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Question on mass rebuild impact
On Thu, Jan 28, 2021 at 08:05:45AM -0700, Orion Poplawski wrote: > Is it possible to still do updates in side-tags for rawhide during the mass > rebuild? What are the ramifications if any for this? Should be fine. If your packages aready were (re)built by mass rebuild, and you build them in a side tag and merge it, the mass rebuild ones just won't be merged in (because there is newer in the main tag). If you packages were not yet (re)built by mass rebuild, then you build them in a side tag and merge it, the mass rebuild ones will be tagged in after the mass rebuild because they are newer/higher. So, yeah, should be ok. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mass rebuild failures on s390
On Thu, Jan 28, 2021 at 10:56:06AM +0100, Miro Hrončok wrote: > On 28. 01. 21 10:49, Vít Ondruch wrote: > > > > Dne 27. 01. 21 v 23:34 Kevin Fenzi napsal(a): > > > On Wed, Jan 27, 2021 at 10:15:20PM +, Richard W.M. Jones wrote: > > > > Here are a couple of my packages which failed mass rebuild > > > > because of apparent problems with the s390 builder: > > > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=60560709 > > > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=60560418 > > > > > > > > Could we automatically look for builds which fail this way > > > > and resubmit them please? > > > The plan is to wait for the entire mass rebuild to finish, then resubmit > > > all the failures. Hopefully that will fix at least most of the above > > > cases. > > > > > > With or without release bump? The latter would be preferable. Without. Just 'koji resubmit N' > Yes, please don't do "mass rebuild second attempt" release bumps this time. We had to do that last time for... some issue with eln? I can't recall, but we do not have to this time as far as I know. 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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, Jan 28, 2021, 6:21 AM Alexander Bokovoy wrote:
>
> With today's OpenQA tests I can point out that using zram on 2048MB RAM
> VMs actually breaks FreeIPA deployment:
>
> https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
>
> OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
> FreeIPA deployment with integrated CA and DNS server. Not anymore with
> zram activated:
>
> Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
> dev-zram0.swap (/dev/zram0 with 1384MB)
>
Swap on zram isn't recently enabled in Fedora, so why are the tests
recently failing?
Also, the default fraction is 0.5 so the zram device size should be 1024MB.
Why is it 1384MB?
> which ends up eating 2/3rds of the whole memory budget and FreeIPA
> installer fails:
>
That's not possible with default settings. The device size is not the
amount of memory used. The device size is virtual. The real amount used
depends on what's paged out to swap divided by the commission ratio.
If swap is being used at all it means the workload already used ~95% of
memory.
> 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments
> [] and options: {'unattended': True, 'ip_addresses': None, 'domain_name': '
> test.openqa.fedoraproject.org', 'realm_name': '
> TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
> 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
> 2021-01-28T02:18:31Z DEBUG IPA platform fedora
> 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
> Prerelease)
> 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
> ...
> 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed,
> exception: ScriptError: Less than the minimum 1.2GB of RAM is available,
> 0.77GB available.
We need more info. Something is consuming more memory than the provisioning
expects. If there was no swap, the problem would be worse.
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Question on mass rebuild impact
On Thu, Jan 28, 2021 at 5:48 PM Miro Hrončok wrote: > > On 28. 01. 21 16:05, Orion Poplawski wrote: > > Is it possible to still do updates in side-tags for rawhide during the mass > > rebuild? What are the ramifications if any for this? > > I've just did so let's see. > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-675d1948a8 > > Note that the packages already finished their mass rebuilds prior to this. You like poking the sleeping bear, don't you? :D I try to take the time between start of mass rebuild and finished mass tagging off from doing my very important packaging work. It's nice, you should try it. 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
Test failures
Hi, I just did a build (new upstream release of iotop-c) and saw a couple of test errors; they look like segfaults or post errors, so I suppose that I didn't do some stupid mistake. Posting the result here, to keep the relevant team informed; in case these are known, sorry for the noise :) https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/8520/testReport/(root)/tests/ With best regards, 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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-01-29 from 17:00:00 to 18:00:00 US/Eastern At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9854/ ___ 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
[ELN] Is it really necessary to build a package 100+ times when there is a bootstrap issue?
This topic was brought up several times already, but I don't think there has been a satisfactory answer to it yet. So let's try again. We have recently updated python-elementpath-2.1.1-2.fc34 and python-xmlschema-1.4.1-1.fc34 -- it requires a very simple bootstrapping that can be seen in the git history. https://bodhi.fedoraproject.org/updates/FEDORA-2021-eb7554bd39 I know that the ELN rebuild tooling cannot handle bootstrapping and I know it has been told this will eventually be solved. I appreciate that it is planned. But in the meantime, is it really necessary to build the packages 100/111 times? https://src.fedoraproject.org/rpms/python-elementpath/c/5de3aa397bda5550047dff85905448c22f844a72?branch=master https://src.fedoraproject.org/rpms/python-xmlschema/c/0c1384c7aaed1d6404bdf96e31044d7ef7671b2b?branch=master Could you please not do that? I realize that sometimes dependency issues are transient. I sometimes beat packages with a stick until they build as well, but more than 100 builds in less than two weeks feels a little far fetched. Please, make the automation stop and inspect the problem by a human after a reasonable amount of trials (I'd say 3, possibly 12, but not 100+). Alternatively at least slow down the firing rate with time. After two weeks of failures it might make sense to give it a try every other day, but not every other hour. 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
Re: Question on mass rebuild impact
On 28. 01. 21 16:05, Orion Poplawski wrote: Is it possible to still do updates in side-tags for rawhide during the mass rebuild? What are the ramifications if any for this? I've just did so let's see. https://bodhi.fedoraproject.org/updates/FEDORA-2021-675d1948a8 Note that the packages already finished their mass rebuilds prior to this. -- 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
Fedora-Rawhide-20210128.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 7 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 34/181 (x86_64), 35/123 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210127.n.1): ID: 763643 Test: x86_64 Server-dvd-iso mediakit_fileconflicts URL: https://openqa.fedoraproject.org/tests/763643 ID: 763690 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/763690 ID: 763692 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/763692 ID: 763704 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/763704 ID: 763735 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/763735 ID: 763749 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/763749 ID: 763754 Test: aarch64 Server-dvd-iso mediakit_fileconflicts@uefi URL: https://openqa.fedoraproject.org/tests/763754 ID: 763771 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/763771 ID: 763778 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/763778 ID: 763786 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/763786 ID: 763788 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/763788 ID: 763789 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/763789 ID: 763790 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/763790 ID: 763819 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/763819 Old failures (same test failed in Fedora-Rawhide-20210127.n.1): ID: 763652 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/763652 ID: 763657 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/763657 ID: 763669 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/763669 ID: 763670 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/763670 ID: 763673 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/763673 ID: 763679 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/763679 ID: 763680 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/763680 ID: 763681 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/763681 ID: 763683 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/763683 ID: 763695 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/763695 ID: 763703 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/763703 ID: 763706 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/763706 ID: 763756 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/763756 ID: 763758 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/763758 ID: 763759 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/763759 ID: 763763 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/763763 ID: 763782 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/763782 ID: 763785 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/763785 ID: 763824 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/763824 ID: 763826 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/763826 ID: 763827 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/763827 ID: 763829 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/763829 ID: 763830 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/763830 ID:
Re: Should opencv require scala on runtime?
On Thu, Jan 28, 2021 at 5:08 AM Miro Hrončok wrote: > I've realized I have scala installed on my F33 developer machine and wanted to > remove it. But apparently, opencv-core pulls it in: > > [~]$ repoquery --installed --whatrequires scala > jacop-0:4.8-2.fc33.noarch > [~]$ repoquery --installed --whatrequires jacop > mp-0:3.1.0-31.20200303git7fd4828.fc33.x86_64 > [~]$ repoquery --installed --whatrequires mp > coin-or-Cbc-0:2.10.5-4.fc33.x86_64 > [~]$ repoquery --installed --whatrequires coin-or-Cbc > coin-or-Clp-0:1.17.6-2.fc33.x86_64 > [~]$ repoquery --installed --whatrequires coin-or-Clp > coin-or-Cbc-0:2.10.5-4.fc33.x86_64 > coin-or-Cgl-0:0.60.3-2.fc33.x86_64 > opencv-core-0:4.3.0-10.fc33.x86_64 > > Is this chain expected? I recently rescued scala when it was orphaned, specifically to save jacop so that the chain to it from the coin-or-* packages would not be broken. But I'm not sure jacop really needs scala. I think jacop may just be providing an interface that scala programs can use to access it, but mp doesn't use that interface. I made a note to myself to look into this, but it hasn't floated to the top of my TODO list yet. If anybody wants to investigate before I get to it, please go ahead. -- 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
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, Jan 28, 2021 at 11:04:34AM -0500, Rob Crittenden wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
> >> With today's OpenQA tests I can point out that using zram on 2048MB RAM
> >> VMs actually breaks FreeIPA deployment:
> >> https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
> >>
> >> OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
> >> FreeIPA deployment with integrated CA and DNS server. Not anymore with
> >> zram activated:
> >>
> >> Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
> >> dev-zram0.swap (/dev/zram0 with 1384MB)
> >>
> >> which ends up eating 2/3rds of the whole memory budget and FreeIPA
> >> installer fails:
> >>
> >> 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments
> >> [] and options: {'unattended': True, 'ip_addresses': None, 'domain_name':
> >> 'test.openqa.fedoraproject.org', 'realm_name':
> >> 'TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
> >> 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
> >> 2021-01-28T02:18:31Z DEBUG IPA platform fedora
> >> 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
> >> Prerelease)
> >> 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
> >> ...
> >> 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed,
> >> exception: ScriptError: Less than the minimum 1.2GB of RAM is available,
> >> 0.77GB available
> >> 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is
> >> available, 0.77GB available
> >> 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
> >> /var/log/ipaserver-install.log for more information
> >
> > Enabling zram doesn't really "take away memory", because no pre-allocation
> > happens.
> > If there is no physical swap, then adding zram0 should just shown additional
> > swap space, so I don't think it could cause the check to fail.
> > But if there is physical swap, the zram device is used with higher
> > preference
> > than the physical swap. So I think the explanation could be that the VM has
> > a swap partition. Before, some pages would be swapped out to zram, and some
> > would
> > be swapped out to the "real" swap. The fraction of RAM used for compressed
> > zram
> > would be on the order of 25% (zram-fraction=0.5 multiplied by typical
> > compression 2:1).
> >
> > But now the kernel sees more zram swap, so it inserts pages there, taking
> > away
> > more of RAM, instead of saving pages to disk. So more memory (maybe 50%
> > RAM) is
> > used for the unswappable compressed pages. But this shouldn't break things:
> > if there is enough pressure, pages would be swapped out to the physical
> > swap device
> > too.
> >
> > Assuming that this guess is correct, the check that ipa-server-install is
> > doing should be adjusted. It should use the total available memory (ram +
> > all kinds
> > of swap) in the check, and not just available uncompressed pages.
> > Or if it wants to ignore disk-based swap for some reason, it should use
> > ram + zram + in-memory-zwap in the check.
>
> For bare metal IPA uses the python3-psutil call:
> psutil.virtual_memory.available()
>
> I don't know how/if psutil reports zram (or cgroup v1 and v2 for that
> matter).
psutil (in general) reports data from /proc/meminfo; available come
from MemAvailable: in that file. This is defined in kernel as:
MemAvailable: An estimate of how much memory is available for starting new
applications, without swapping. Calculated from MemFree,
SReclaimable, the size of the file LRU lists, and the low
watermarks in each zone.
The estimate takes into account that the system needs some
page cache to function well, and that not all reclaimable
slab will be reclaimable, due to items being in use. The
impact of those factors will vary from system to system.
Notice "without swapping" in second line. Next question, how zram impacts
reporting of MemAvailable by kernel?
--
Tomasz Torcz “God, root, what's the difference?”
to...@pipebreaker.pl “God is more forgiving.”
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
>> With today's OpenQA tests I can point out that using zram on 2048MB RAM
>> VMs actually breaks FreeIPA deployment:
>> https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
>>
>> OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
>> FreeIPA deployment with integrated CA and DNS server. Not anymore with
>> zram activated:
>>
>> Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
>> dev-zram0.swap (/dev/zram0 with 1384MB)
>>
>> which ends up eating 2/3rds of the whole memory budget and FreeIPA
>> installer fails:
>>
>> 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments []
>> and options: {'unattended': True, 'ip_addresses': None, 'domain_name':
>> 'test.openqa.fedoraproject.org', 'realm_name':
>> 'TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
>> 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
>> 2021-01-28T02:18:31Z DEBUG IPA platform fedora
>> 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
>> Prerelease)
>> 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
>> ...
>> 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed, exception:
>> ScriptError: Less than the minimum 1.2GB of RAM is available, 0.77GB
>> available
>> 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is available,
>> 0.77GB available
>> 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
>> /var/log/ipaserver-install.log for more information
>
> Enabling zram doesn't really "take away memory", because no pre-allocation
> happens.
> If there is no physical swap, then adding zram0 should just shown additional
> swap space, so I don't think it could cause the check to fail.
> But if there is physical swap, the zram device is used with higher preference
> than the physical swap. So I think the explanation could be that the VM has
> a swap partition. Before, some pages would be swapped out to zram, and some
> would
> be swapped out to the "real" swap. The fraction of RAM used for compressed
> zram
> would be on the order of 25% (zram-fraction=0.5 multiplied by typical
> compression 2:1).
>
> But now the kernel sees more zram swap, so it inserts pages there, taking away
> more of RAM, instead of saving pages to disk. So more memory (maybe 50% RAM)
> is
> used for the unswappable compressed pages. But this shouldn't break things:
> if there is enough pressure, pages would be swapped out to the physical swap
> device
> too.
>
> Assuming that this guess is correct, the check that ipa-server-install is
> doing should be adjusted. It should use the total available memory (ram + all
> kinds
> of swap) in the check, and not just available uncompressed pages.
> Or if it wants to ignore disk-based swap for some reason, it should use
> ram + zram + in-memory-zwap in the check.
For bare metal IPA uses the python3-psutil call:
psutil.virtual_memory.available()
I don't know how/if psutil reports zram (or cgroup v1 and v2 for that
matter).
I considered including swap into the calculation but if you need the
swap just to install the thing then your experience is by definition
going to be poor (for the definition of swap being disk-based). In fact
if the system relies too much on disk-based swap then the installation
process can time out altogether.
>
> It would be nice to see the output of 'swapon -s' and 'zramctl' and 'free'
> on that machine.
>
>> While we can ask Adam to increase memory in those VMs, 2GB RAM was our
>> (FreeIPA) recommended lower level target for home deployments with
>> Celeron or RPI4 systems. Now zram use will force those systems to be
>> unusable out of the box.
>
> That's certainly not the goal. The main goal of the Change is to support
> machines with less RAM, not require more RAM.
>
> 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
>
___
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
[Bug 1921789] New: perl-XML-Feed-0.61 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1921789 Bug ID: 1921789 Summary: perl-XML-Feed-0.61 is available Product: Fedora Version: rawhide Status: NEW Component: perl-XML-Feed Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.61 Current version/release in rawhide: 0.60-1.fc34 URL: http://search.cpan.org/dist/XML-Feed Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/8396/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1921785] New: perl-PPIx-Regexp-0.078 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1921785 Bug ID: 1921785 Summary: perl-PPIx-Regexp-0.078 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PPIx-Regexp Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.078 Current version/release in rawhide: 0.077-1.fc34 URL: http://search.cpan.org/dist/PPIx-Regexp/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3288/ -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: /usr/include/c++/11/string_view:98:21: error: static assertion failed
issue was fixed now, with this patch:
--- include/cxxtools/char.h.orig2021-01-28 08:34:49.182956317 +0100
+++ include/cxxtools/char.h 2021-01-28 08:35:41.524954646 +0100
@@ -68,9 +68,7 @@
typedef int32_t value_type;
//! Constructs a character with a value of 0.
-Char()
-: _value(0)
-{}
+ Char() = default;
//! Constructs a character using the given value as base for the
character value.
Char(value_type ch)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: sourabhdeshmukh
hello Matthew On Thu, 28 Jan 2021 at 20:09, Matthew Miller wrote: > Welcome! Anything in particular you're interested in improving? I am exploring the projects and I am looking for contributing into Packaging. Thank you sourabhdeshmukh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On 28/01/2021 10:39, Vít Ondruch wrote: 2) I would really love you to stop using VMs for your build/testing. With exception of Kernel and Kernel related issues, the argument of "mock being slow" can't stand. Every VM will be more resources hungry then mock, slowing every your task. I'd love to. But then we need to ensure that it is possible to mock build future Fedora 45+ packages from a RHEL-8 installation without issues; due to yum/dnf/rpm being too old, not able to parse the .rpm or .spec files due to new features in use, etc, etc. And add some simple approaches so you can easily access the source code failing to build, so you can add some tweaks and test out manually before diffing and patching up the .spec file for another run. With "simple approaches", I mean to not needing to add additional arguments to mock build so the buildroot doesn't get wiped on errors and that you don't have to dig deep into the /var/lib/mock directories to find the source location For me, this is where fedpkg local excels over mock build -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Question on mass rebuild impact
Is it possible to still do updates in side-tags for rawhide during the mass rebuild? What are the ramifications if any for this? Thanks. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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
Re: Proposal to deprecated `fedpkg local`
Vít Ondruch writes: > Thx everybody for their responses and sorry for such controversial > topic. I am not going to propose this upstream after all. However I have > few takeaways: > > 1) I see responses of Fedora long timers and I understand that you > have polished workflows. But I really think that for newcomers, mock > should be the preferred way. I'd love to see documentation adjusted to > prefer mock everywhere. > > 2) I would really love you to stop using VMs for your build/testing. > With exception of Kernel and Kernel related issues, the argument of > "mock being slow" can't stand. Every VM will be more resources hungry > then mock, slowing every your task. > > 3) The argument of mock being slow can't stand, because in one of my > examples I posted elsewhere in this thread, I picked up the simplest > package I could and the build took 7 seconds. This is certainly not > slow, in this time you can't even switch to your email client to check > your emails. So far on this thread, you've asked feedback on a proposal, and then when provided with feedback you didn't like, repeatedly argued with our comments and told us we're wrong. This is not a good way to engage with feedback. In particular, *numerous* people have told you that mock builds are slow for us. Instead of telling us that we're wrong about our own experience because it doesn't match yours, make an effort to understand what the difference is between them. Or accept it for what it is: feedback that *you asked for*. Thanks, --Robbie 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
Re: Proposal to deprecated `fedpkg local`
Vít Ondruch writes: > Dne 27. 01. 21 v 23:21 Gwyn Ciesla via devel napsal(a): >>> On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote: >>> Hi, I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? >>> >>> Why? I use it all the time. While I understand that it's not as >>> complete a local test as mock, it a lot quicker and less disruptive. >>> And if I want a real test I'll use a scratch build (because that's >>> the only way to test a build across architectures). >>> >> Agreed. Santa didn't bring me the s390x I asked for this year. :( > > Just FTR, mock supports `--arch=ARCH` which will use emulation to > allow you build whatever architecture localy. I have never used it > myself, but I wanted to mention this. I recommend you try. Prepare to be underwhelmed by speed :) Thanks, --Robbie 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
Re: Self Introduction: sourabhdeshmukh
On Thu, Jan 28, 2021 at 07:17:06PM +0530, Sourabh Deshmukh wrote: > I am Sourabh Deshmukh working as DevOps Engineer with work experience > of 2 years. During this phase I worked on Monitoring tools, automation > tools, CICD pipelines etc . I have been a Fedora user since the > release of Fedora26, as I have been using this OS since a long time > and looking forward to contributing to the Fedora Community. Welcome! Anything in particular you're interested in improving? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On 27/01/2021 21:47, Zbigniew Jędrzejewski-Szmek wrote: +1 to everything that Gwyn said. 'fedpkg local' is just so immensely useful for initial package developement. I also use it a lot for systemd & friends: I *want* to build packages against the local environment and install them locally without pulling in any other package updates, and I want to be able to debug build or test failures in the host environment. (I also use mock in various configurations, and copr, and scratch builds, etc. I find mock immensely useful too, but in a later phase of package development. Different tools have different tradeoffs.) All of this +1. I don't do this for systemd, but for OpenVPN related packaging. Also, mock against newer Fedora distros gets more and more complicated as time flies, as I usually do all of this on RHEL [*]. I've recently upgraded to RHEL-8 (from RHEL-7), so I'm not sure how that changes in this aspect, but looking forward to test it out properly. But doing OpenVPN related packaging for quite some years has taught me to not fully trust mock to be capable to builds on more recent Fedora releases (from a RHEL host). The rescue has always been to use fedpkg local (on RHEL) to iron out the build issues before spinning of a VM and run a fedpkg mockbuild in the VM (with a recent Fedora), and then koji build in the end for the broader platform builds. [*] I always try to do main development on an older distribution, as forward porting fixes for issues are always more convenient than backwards porting them. Especially when writing new code and features for a project. -- kind regards, David Sommerseth ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, Jan 28, 2021 at 03:20:38PM +0200, Alexander Bokovoy wrote:
> With today's OpenQA tests I can point out that using zram on 2048MB RAM
> VMs actually breaks FreeIPA deployment:
> https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
>
> OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
> FreeIPA deployment with integrated CA and DNS server. Not anymore with
> zram activated:
>
> Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
> dev-zram0.swap (/dev/zram0 with 1384MB)
>
> which ends up eating 2/3rds of the whole memory budget and FreeIPA
> installer fails:
>
> 2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments []
> and options: {'unattended': True, 'ip_addresses': None, 'domain_name':
> 'test.openqa.fedoraproject.org', 'realm_name':
> 'TEST.OPENQA.FEDORAPROJECT.ORG', 'host_name': None, 'ca_cert
> 2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
> 2021-01-28T02:18:31Z DEBUG IPA platform fedora
> 2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition
> Prerelease)
> 2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
> ...
> 2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed, exception:
> ScriptError: Less than the minimum 1.2GB of RAM is available, 0.77GB available
> 2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is available,
> 0.77GB available
> 2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
> /var/log/ipaserver-install.log for more information
Enabling zram doesn't really "take away memory", because no pre-allocation
happens.
If there is no physical swap, then adding zram0 should just shown additional
swap space, so I don't think it could cause the check to fail.
But if there is physical swap, the zram device is used with higher preference
than the physical swap. So I think the explanation could be that the VM has
a swap partition. Before, some pages would be swapped out to zram, and some
would
be swapped out to the "real" swap. The fraction of RAM used for compressed zram
would be on the order of 25% (zram-fraction=0.5 multiplied by typical
compression 2:1).
But now the kernel sees more zram swap, so it inserts pages there, taking away
more of RAM, instead of saving pages to disk. So more memory (maybe 50% RAM) is
used for the unswappable compressed pages. But this shouldn't break things:
if there is enough pressure, pages would be swapped out to the physical swap
device
too.
Assuming that this guess is correct, the check that ipa-server-install is
doing should be adjusted. It should use the total available memory (ram + all
kinds
of swap) in the check, and not just available uncompressed pages.
Or if it wants to ignore disk-based swap for some reason, it should use
ram + zram + in-memory-zwap in the check.
It would be nice to see the output of 'swapon -s' and 'zramctl' and 'free'
on that machine.
> While we can ask Adam to increase memory in those VMs, 2GB RAM was our
> (FreeIPA) recommended lower level target for home deployments with
> Celeron or RPI4 systems. Now zram use will force those systems to be
> unusable out of the box.
That's certainly not the goal. The main goal of the Change is to support
machines with less RAM, not require more RAM.
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
Re: Orphaning my ocaml packages
On Wed, Jan 27, 2021 at 04:03:51PM -0800, Michel Alexandre Salim wrote: > rpms/ocaml-biniou > rpms/ocaml-cppo > rpms/ocaml-easy-format > rpms/ocaml-xmlm > rpms/ocaml-yojson You can make me maintainer or co-maintainer of all of these. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On Thu, Jan 28, 2021 at 01:40:08PM +0100, Miroslav Suchý wrote: > Dne 28. 01. 21 v 11:54 Daniel P. Berrangé napsal(a): > >Thus mock ends up using the slower storage since it isn't using /home. > > A performance tips: > http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html For the RISC-V builders I wrote an nbdkit plugin to be mounted on /var/lib/mock which should achieve similar performance while having the benefit of using filesystem space instead of RAM+swap. https://libguestfs.org/nbdkit-tmpdisk-plugin.1.html Note the performance advantage is not immediately obvious - it's because the plugin intentionally discards flush and FUA requests, thus maximizing the amount that can be cached in RAM, but not requiring RAM+swap as a tmpfs does. (It would be nice for someone to integrate this more closely with mock so that the individual /var/lib/mock/ directories would be loop mounted as tmpdisk on demand and discarded when mock does a clean operation.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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
Self Introduction: sourabhdeshmukh
hello everyone I am Sourabh Deshmukh working as DevOps Engineer with work experience of 2 years. During this phase I worked on Monitoring tools, automation tools, CICD pipelines etc . I have been a Fedora user since the release of Fedora26, as I have been using this OS since a long time and looking forward to contributing to the Fedora Community. With Regards Thank You saurabhdeshmukh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
Gwyn Ciesla via devel kirjoitti 28.1.2021 klo 0.09: If the user doesn't 'git add .', or has a correct .gitignore, this should be a non issue. Me being the quoted person with a workflow issue, I still think there is a workflow issue. Setting .gitignore is possible of course, but rather annoying and repetitive. Each package has its own repository, so there are a lot of .gitignore files to configure. Also, the names that need to be ignored depend on package version, so it is either messy globbing (or perhaps regexing, if that is supported?) or updating every time version increases. And 'fedpkg local' generates multiple files and directories at repository root, yet another multiplier. Doing it manually every time means spending time with ignore rules instead of packaging software. The other option of not using 'git add .' can also be described as mentally filtering out all the irrelevant unstaged changes to find the ones that should actually be added. That adds cognitive burden, slows things down and leads to mistakes every now and then. It does not help to say "do not make mistakes" if the task is inherently error-prone. Such filtering is something a computer should do, which leads us back to .gitignore. Perhaps a script could create the correct ignore globs for all repositories in one go and that would be it, and have it in the template for new repositories, too? Just an idea, perhaps not worth the effort and complexity. It would help much if 'fedpkg local' would only generate anything in a single directory with constant name - 'build' or whatever. (Oh, and for the original question about deprecating 'fedpkg local' - I don't know. Before this discussion started, I was happily using 'fedpkg local' and did not even know what mock was. I have to get in terms with mock to form an opinion.) The only times I use the git command in fedpkg is to merge between branches, or add/remove packages. If you're just doing changes to things already tracked, such as the spec, sources, patches, scripts, etc, fedpkg commit will add them for you. It also spits out a warning if you commit a spec with a Patch not tracked in git, which is nice. Thank you for this advice Gwyn, and the same goes for Josh for useful git option in another response. I will certainly try these suggestions and see if they can make things easier for me. Otto ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On la, 23 tammi 2021, Chris Murphy wrote:
On Sat, Jan 23, 2021 at 4:29 AM Zbigniew Jędrzejewski-Szmek
wrote:
Hi,
the proposal for Fedora 34 is to use zram-size == 1.0 * ram.
(Which I think is OK for the reasons listed in the Change page [0].)
But the original motivation for this change was boosting the size on
machines with little ram [1]. I wrote an exploratory patch [2] to specify
the size as a formula. From the docs:
> An alternative way to set the zram device size as a mathematical expressoin
> that can be used instead of 'zram-fraction' and 'max-zram-size'. Basic
arithmetic
> operators like '*', '+', '-', '/', are supported, as well as 'min()' and
'max()'
> and the variable 'ram' which specifies size of RAM in megabytes.
>
> Examples:
>
> # this is the same as the default config
> zram-size = min(0.5 * ram, 4096)
>
> # fraction 1.0 for first 4GB, and then fraction 0.5 above that
> zram-size = 1.0 * min(ram, 4096) + 0.5 * max(ram - 4096, 0)
Now I'm a bit torn: the code is nice enough, but it seems to be a solution
in search of a problem. So I thought I'd try a little crowd-sourcing:
Would we have a real use for something like this?
(One possible direction: one thing I want to explore next is using zram
or zwap based on whether the machine has a physical swap device. Maybe
such a language would be useful then — with additional variables
specifying e.g. the physical swap size…)
I think everything discussed so far is neutral to good for all use
cases (all editions and spins) being discussed.
But I also think it's a good idea for zram-generator to be a bit more
biased toward setups with one or more of:
- low memory (4G or less, somewhat subjective)
- limited life storage (eMMC, SD Card, USB stick)
- slow drive (primarily rotational, but also all of the above)
- no swap (zram-based swap is better than no swap)
The above categories pretty much mean that the improvements for
disk-based swap that are in-progress upstream, aren't likely to be
used. That means zram-based swap usage will continue to provide
significant benefit.
With today's OpenQA tests I can point out that using zram on 2048MB RAM
VMs actually breaks FreeIPA deployment:
https://openqa.fedoraproject.org/tests/763006#step/role_deploy_domain_controller/35
OpenQA uses 2048MB RAM for QEMU VMs and this was typically OK for
FreeIPA deployment with integrated CA and DNS server. Not anymore with
zram activated:
Jan 27 21:17:47 fedora zram_generator::generator[25243]: Creating unit
dev-zram0.swap (/dev/zram0 with 1384MB)
which ends up eating 2/3rds of the whole memory budget and FreeIPA
installer fails:
2021-01-28T02:18:31Z DEBUG ipa-server-install was invoked with arguments [] and
options: {'unattended': True, 'ip_addresses': None, 'domain_name':
'test.openqa.fedoraproject.org', 'realm_name': 'TEST.OPENQA.FEDORAPROJECT.ORG',
'host_name': None, 'ca_cert
2021-01-28T02:18:31Z DEBUG IPA version 4.9.1-1.fc34
2021-01-28T02:18:31Z DEBUG IPA platform fedora
2021-01-28T02:18:31Z DEBUG IPA os-release Fedora 34 (Server Edition Prerelease)
2021-01-28T02:18:31Z DEBUG Available memory is 823529472B
...
2021-01-28T02:18:31Z DEBUG The ipa-server-install command failed, exception:
ScriptError: Less than the minimum 1.2GB of RAM is available, 0.77GB available
2021-01-28T02:18:31Z ERROR Less than the minimum 1.2GB of RAM is available,
0.77GB available
2021-01-28T02:18:31Z ERROR The ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
While we can ask Adam to increase memory in those VMs, 2GB RAM was our
(FreeIPA) recommended lower level target for home deployments with
Celeron or RPI4 systems. Now zram use will force those systems to be
unusable out of the box.
That's the tl;dr and now it's giant text wall time...
The remaining category is "everyone else", i.e. >= 8G RAM, and a
reasonably performant SATA SSD or NVMe. This category benefits overall
with the swap on zram approach, mainly because swap thrashing is just
so terrible. However, I expect the future is a return to disk based
swap for two reasons: (1) given highly variable workloads, having 100%
eviction efficacy decomplicates memory management and resource control
(2) there are upstream improvements happening incrementally that are
improving swap performance. e.g. the anonymous memory balancing logic
has been totally reworked.
Neither zram nor zswap support cgroupvs2. There's work happening on
getting zswap cgroups compatible as well as integrating it into memory
management rather than having all these different buffet-style add-ons
that distros and users have to evaluate and integrate. The swap
improvements started happening in kernel 5.8, and I'd say they're
opt-in testable [1] for folks using kernel 5.10+ - whereby they can
switch back and forth between exclusively zram-based and disk-based
swap, to help evaluate what's working better and what isn't.
This is not a case of us moving back to disk-based swap soon. There
Re: Proposal to deprecated `fedpkg local`
Dne 28. 01. 21 v 11:35 Thomas Moschny napsal(a): 3) The argument of mock being slow can't stand, because in one of my examples I posted elsewhere in this thread, I picked up the simplest package I could and the build took 7 seconds. This is certainly not slow, in this time you can't even switch to your email client to check your emails. To add some data points: I roughly see a factor of 2 (with already populated caches). For one of the smaller packages (xml2) it's ~6 seconds for `fedpkg local` vs ~15-20 seconds for `fedpkg mockbuild`. Are you using --no-clean option? I guess this would give you back ~10s, because the would skip the build root initialization. Vít For one of the larger packages (shotwell) it's ~1 minute vs. ~2 minutes. So, from my POV, the argument of mock being slow still stands. - Thomas ___ 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 OpenPGP_signature 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
Fedora rawhide compose report: 20210128.n.0 changes
OLD: Fedora-Rawhide-20210127.n.1 NEW: Fedora-Rawhide-20210128.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 0 Dropped packages:1 Upgraded packages: 156 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:53.45 KiB Size of upgraded packages: 4.52 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -130.86 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE_Appliance raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20210128.n.0-sda.raw.xz Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20210128.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: golang-gopkg-ldap-3-3.2.4-1.fc34 Summary: Basic LDAP v3 functionality for the GO programming language RPMs:golang-gopkg-ldap-3-devel Size:53.45 KiB = UPGRADED PACKAGES = Package: dl-fedora-0.7.6-1.fc34 Old package: dl-fedora-0.7.5-1.fc34 Summary: Fedora image download tool RPMs: dl-fedora Size: 28.28 MiB Size change: 3.80 KiB Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 0.7.5-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Jan 27 2021 Jens Petersen - 0.7.6-1 - improve help text for releases related for Beta and RCs (#1) - if ~/Downloads/iso/ exists then download to it otherwise ~/Downloads/ - support ELN boot.iso Package: dummy-test-package-gloster-0-2529.fc34 Old package: dummy-test-package-gloster-0-2527.fc34 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 159.56 KiB Size change: 112 B Changelog: * Wed Jan 27 2021 packagerbot - 0-2528 - rebuilt * Wed Jan 27 2021 packagerbot - 0-2529 - rebuilt Package: fennel-0.8.0-1.fc34 Old package: fennel-0.7.0-2.fc34 Summary: A Lisp that compiles to Lua RPMs: fennel Size: 83.54 KiB Size change: 4.35 KiB Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 0.7.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Jan 27 2021 Michel Alexandre Salim - 0.8.0-1 - Update to 0.8.0 - Add Requires on lua(abi) for older releases Package: golang-github-ldap-3.2.4-4.fc34 Old package: golang-github-ldap-3.2.4-2.fc34 Summary: Basic LDAP v3 functionality for the GO programming language RPMs: compat-golang-gopkg-ldap-3-devel golang-github-ldap-3-devel Added RPMs: golang-github-ldap-3-devel Dropped RPMs: golang-github-ldap-devel Size: 56.98 KiB Size change: -14.46 KiB Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 3.2.4-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Jan 27 2021 Robert-Andr?? Mauchin - 3.2.4-4 - Add proper import path Package: golang-github-moby-sys-0.2.0-3.git5a29239.20210127git5a29239.fc34 Old package: golang-github-moby-sys-0.2.0-1.fc34 Summary: Moby sys package for Go RPMs: golang-github-moby-sys-devel Size: 54.06 KiB Size change: 6.81 KiB Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 0.2.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Jan 27 2021 Olivier Lemasle - 0.3.0-2.git5a29239 - Update to latest upstream commit Package: golang-github-nxadm-tail-1.4.6-2.fc34 Old package: golang-github-nxadm-tail-1.4.6-1.fc34 Summary: Read from continously updated files (tail -f) RPMs: golang-github-nxadm-tail golang-github-nxadm-tail-devel Size: 3.27 MiB Size change: 6.91 KiB Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 1.4.6-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild Package: golang-github-siddontang-0-0.2.20210111gitbdc7756.fc34 Old package: golang-github-siddontang-0-0.1.20210111gitbdc7756.fc34 Summary: Golang lib for ledisdb RPMs: golang-github-siddontang-devel Size: 74.77 KiB Size change: 151 B Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 0-0.2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild Package: golang-google-grpc-1.35.0-2.fc34 Old package: golang-google-grpc-1.35.0-1.fc34 Summary: Go language implementation of GRPC RPMs: golang-google-grpc-devel golang-google-grpc-status-devel Size: 887.94 KiB Size change: 356 B Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 1.35.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild Package: golang-gopkg-playground-validator-8-8.18.2-5.fc34 Old package: golang-gopkg-playground-validator-8-8.18.2-4.fc33 Summary: Go struct and field validation RPMs: golang-gopkg-playground-validator-8-devel Size: 48.26 KiB Size change: 170 B Changelog: * Tue Jan 26 2021 Fedora Release Engineering
Another delay in the master->main src.fedoraproject.org changes
Greetings everyone. As you know from our last announcement, we had pushed our changes for src.fedoraproject.org out another week. That was going to be today. https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main Unfortunately, the mass rebuild is still submitting changes and we aren't fully ready yet anyhow, so we are going to move the change out another week, to 2021-02-02. We will send an announcement when we start the changes. Thanks for everyone's continued patience. kevin signature.asc Description: PGP signature ___ devel-announce mailing list -- devel-annou...@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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Another delay in the master->main src.fedoraproject.org changes
Greetings everyone. As you know from our last announcement, we had pushed our changes for src.fedoraproject.org out another week. That was going to be today. https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main Unfortunately, the mass rebuild is still submitting changes and we aren't fully ready yet anyhow, so we are going to move the change out another week, to 2021-02-02. We will send an announcement when we start the changes. Thanks for everyone's continued patience. kevin signature.asc Description: PGP signature ___ 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
Fedora-IoT-34-20210128.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 3/16 (x86_64), 7/15 (aarch64) New failures (same test not failed in Fedora-IoT-34-20210124.0): ID: 763622 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/763622 ID: 763627 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/763627 ID: 763630 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/763630 ID: 763633 Test: aarch64 IoT-dvd_ostree-iso base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/763633 ID: 763636 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/763636 Old failures (same test failed in Fedora-IoT-34-20210124.0): ID: 763616 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/763616 ID: 763620 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay URL: https://openqa.fedoraproject.org/tests/763620 ID: 763624 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/763624 ID: 763631 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/763631 ID: 763635 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/763635 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210124.0): ID: 763608 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/763608 Passed openQA tests: 8/15 (aarch64), 12/16 (x86_64) New passes (same test not passed in Fedora-IoT-34-20210124.0): ID: 763638 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/763638 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: System load changed from 0.20 to 0.37 Previous test data: https://openqa.fedoraproject.org/tests/761403#downloads Current test data: https://openqa.fedoraproject.org/tests/763609#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: Mount /run contents changed to 85.01342446% of previous size Mount /boot contents changed to 136.8907862% of previous size Used mem changed from 168 MiB to 312 MiB System load changed from 0.15 to 0.62 Previous test data: https://openqa.fedoraproject.org/tests/761419#downloads Current test data: https://openqa.fedoraproject.org/tests/763625#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
Dne 28. 01. 21 v 11:54 Daniel P. Berrangé napsal(a): Thus mock ends up using the slower storage since it isn't using /home. A performance tips: http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #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
Re: Should opencv require scala on runtime?
On Thu, 2021-01-28 at 13:08 +0100, Miro Hrončok wrote:
> I've realized I have scala installed on my F33 developer machine and
> wanted to
> remove it. But apparently, opencv-core pulls it in:
>
> [~]$ repoquery --installed --whatrequires scala
> jacop-0:4.8-2.fc33.noarch
> [~]$ repoquery --installed --whatrequires jacop
> mp-0:3.1.0-31.20200303git7fd4828.fc33.x86_64
> [~]$ repoquery --installed --whatrequires mp
> coin-or-Cbc-0:2.10.5-4.fc33.x86_64
> [~]$ repoquery --installed --whatrequires coin-or-Cbc
> coin-or-Clp-0:1.17.6-2.fc33.x86_64
> [~]$ repoquery --installed --whatrequires coin-or-Clp
> coin-or-Cbc-0:2.10.5-4.fc33.x86_64
> coin-or-Cgl-0:0.60.3-2.fc33.x86_64
> opencv-core-0:4.3.0-10.fc33.x86_64
>
> Is this chain expected?
>
Yes , OpenCV is built with coin-or-Clp [1] is build with -DWITH_CLP=ON,
and module 'clp' is found clp, version 1.17.6
Extra dependencies: /lib64/libClpSolver.so /lib64/libClp.so
/lib64/libCoinUtils.so
[1]
%{?with_clp:BuildRequires: coin-or-Clp-devel}
--
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
[Test-Announce] Fedora 34 Rawhide 20210128.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 34 Rawhide 20210128.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: parted - 20210124.n.0: parted-3.3.52-1.fc34.src, 20210128.n.0: parted-3.4-1.fc34.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/34 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_34_Rawhide_20210128.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.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 ___ 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
Should opencv require scala on runtime?
I've realized I have scala installed on my F33 developer machine and wanted to remove it. But apparently, opencv-core pulls it in: [~]$ repoquery --installed --whatrequires scala jacop-0:4.8-2.fc33.noarch [~]$ repoquery --installed --whatrequires jacop mp-0:3.1.0-31.20200303git7fd4828.fc33.x86_64 [~]$ repoquery --installed --whatrequires mp coin-or-Cbc-0:2.10.5-4.fc33.x86_64 [~]$ repoquery --installed --whatrequires coin-or-Cbc coin-or-Clp-0:1.17.6-2.fc33.x86_64 [~]$ repoquery --installed --whatrequires coin-or-Clp coin-or-Cbc-0:2.10.5-4.fc33.x86_64 coin-or-Cgl-0:0.60.3-2.fc33.x86_64 opencv-core-0:4.3.0-10.fc33.x86_64 Is this chain expected? -- 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
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On 1/28/21 12:05 PM, Panu Matilainen wrote: On 1/28/21 12:21 PM, Roberto Ragusa wrote: On 1/28/21 9:34 AM, Panu Matilainen wrote: On 1/27/21 8:30 PM, Kevin Fenzi wrote: SO, I don't really understand... Patrick says in the Change: "The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase. This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system." Is that just because he used the server install with fewer files? As directories are not signed, in a smaller installation the directory vs file ratio could be different, making the overhead smaller than in a larger install. Looking at the F33 server edition install, there are 59246 files total, 22837 of which are directories. That's a very different ratio to my laptop install where there are 402158 files total of which 70874 are directories. So it's a case of "it depends" and it depends quite a lot. By no means the overhead is always 45% but neither is it always 20% - depending on the exact package set it can be even be quite a bit more or less than either figure. My data point: I have 1864399 files in rpm DB (rpm -qla|wc -l). That'd be the total number of file entries, including directories. To exclude directories, try rpm -qalv|grep -v ^d|wc -l The rpm database is 770MB (du /var/lib/rpm). For statistics, you might want to compact the db first: rpmdb --rebuilddb Although that clearly is one *big* installation so dunno how much air there might be (or not) in that number. Maybe a big installation, but just a laptop. rpm -qalv|grep -v ^d|wc -l is giving 1652583 files (excluding dirs) and rpmdb --rebuilddb && du /var/lib/rpm is giving 442MB. The extra size would be 162*1652583 = 267MB, which amounts to +60%. 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
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On 1/28/21 12:21 PM, Roberto Ragusa wrote: On 1/28/21 9:34 AM, Panu Matilainen wrote: On 1/27/21 8:30 PM, Kevin Fenzi wrote: SO, I don't really understand... Patrick says in the Change: "The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase. This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system." Is that just because he used the server install with fewer files? As directories are not signed, in a smaller installation the directory vs file ratio could be different, making the overhead smaller than in a larger install. Looking at the F33 server edition install, there are 59246 files total, 22837 of which are directories. That's a very different ratio to my laptop install where there are 402158 files total of which 70874 are directories. So it's a case of "it depends" and it depends quite a lot. By no means the overhead is always 45% but neither is it always 20% - depending on the exact package set it can be even be quite a bit more or less than either figure. My data point: I have 1864399 files in rpm DB (rpm -qla|wc -l). That'd be the total number of file entries, including directories. To exclude directories, try rpm -qalv|grep -v ^d|wc -l The rpm database is 770MB (du /var/lib/rpm). For statistics, you might want to compact the db first: rpmdb --rebuilddb Although that clearly is one *big* installation so dunno how much air there might be (or not) in that number. - 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
Re: Proposal to deprecated `fedpkg local`
On Thu, Jan 28, 2021 at 10:39:16AM +0100, Vít Ondruch wrote: > 2) I would really love you to stop using VMs for your build/testing. With > exception of Kernel and Kernel related issues, the argument of "mock being > slow" can't stand. Every VM will be more resources hungry then mock, slowing > every your task. The point of having a VM is to have a live installed OS so you can install and test runtime functionality the builds after they have completed. Mock is not generally a substitute for this because mock environment is not a running OS, it is just a chroot, so only a subset of packages can be viably tested inside mock. > 3) The argument of mock being slow can't stand, because in one of my > examples I posted elsewhere in this thread, I picked up the simplest package > I could and the build took 7 seconds. This is certainly not slow, in this > time you can't even switch to your email client to check your emails. I don't see numbers anything like that good with 'fedpkg mockbuild', Taking my "libvirt-glib" package as a test 'fedpkg local' - 30 seconds 'fedpkg mockbuild' - 60 seconds (warm cache) 'fedpkg mockbuild' - 5 minutes (no cache) and that's on my fast laptop with fast SSD. On my machine development server which is a few years older 'fedpkg local' - 48 seconds 'fedpkg mockbuild' - 2 minutes 30 seconds (warm cache) 'fedpkg mockbuild' - 6 minutes 50 seconds (no cache) In this case /home is on SSD, and / is HDD. Thus mock ends up using the slower storage since it isn't using /home. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python Classroom Lab help needed: proj-data is suddenly 569M
On 28. 01. 21 11:10, Lumír Balhar wrote: Hello. From my point of view and from the networkx perespective, we can brake this chain and don't install python3-gdal. python3-gdal brings support for special GIS Shapefile which I think we don't need by default in the classroom. I agree: https://pagure.io/fedora-kickstarts/pull-request/752 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Re: Python Classroom Lab help needed: proj-data is suddenly 569M
On 28. 01. 21 11:10, Lumír Balhar wrote: Hello. From my point of view and from the networkx perespective, we can brake this chain and don't install python3-gdal. python3-gdal brings support for special GIS Shapefile which I think we don't need by default in the classroom. I agree: https://pagure.io/fedora-kickstarts/pull-request/752 -- 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
Re: Proposal to deprecated `fedpkg local`
> 3) The argument of mock being slow can't stand, because in one of my examples > I posted elsewhere in this thread, I picked up the simplest package I could > and the build took 7 seconds. This is certainly not slow, in this time you > can't even switch to your email client to check your emails. To add some data points: I roughly see a factor of 2 (with already populated caches). For one of the smaller packages (xml2) it's ~6 seconds for `fedpkg local` vs ~15-20 seconds for `fedpkg mockbuild`. For one of the larger packages (shotwell) it's ~1 minute vs. ~2 minutes. So, from my POV, the argument of mock being slow still stands. - Thomas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On 1/28/21 9:34 AM, Panu Matilainen wrote: On 1/27/21 8:30 PM, Kevin Fenzi wrote: SO, I don't really understand... Patrick says in the Change: "The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase. This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system." Is that just because he used the server install with fewer files? As directories are not signed, in a smaller installation the directory vs file ratio could be different, making the overhead smaller than in a larger install. Looking at the F33 server edition install, there are 59246 files total, 22837 of which are directories. That's a very different ratio to my laptop install where there are 402158 files total of which 70874 are directories. So it's a case of "it depends" and it depends quite a lot. By no means the overhead is always 45% but neither is it always 20% - depending on the exact package set it can be even be quite a bit more or less than either figure. My data point: I have 1864399 files in rpm DB (rpm -qla|wc -l). The rpm database is 770MB (du /var/lib/rpm). An additional 162 bytes per file would raise it by 302MB (+39%). Looks expensive to me, especially when considering that I get no feature for this overhead. 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
Re: Python Classroom Lab help needed: proj-data is suddenly 569M
Hello. From my point of view and from the networkx perespective, we can brake this chain and don't install python3-gdal. python3-gdal brings support for special GIS Shapefile which I think we don't need by default in the classroom. Have a nice day. Lumír On 1/27/21 3:17 PM, Miro Hrončok wrote: Hello, when debugging an unexpected significant file size grow of the Python Classroom Lab [1], I've realized the following package changes since Fedora 33: proj -proj-datumgrid +proj-data-at +proj-data-au +proj-data-be +proj-data-br +proj-data-ca +proj-data-ch +proj-data-de +proj-data-dk +proj-data-es +proj-data-eur +proj-data-fi +proj-data-fo +proj-data-fr +proj-data-is +proj-data-jp +proj-data-nc +proj-data-nl +proj-data-nz +proj-data-pt +proj-data-se +proj-data-sk +proj-data-uk +proj-data-us And /usr/share/proj is huge: [fedora-34]$ du -h /usr/share/proj 569M /usr/share/proj [fedora-33]$ du -h /usr/share/proj 14M /usr/share/proj When I attempt to remove proj, I get: === Package Arch Version Repository Size === Removing: proj x86_64 7.2.1-1.fc34 @anaconda 13 M Removing dependent packages: python3-gdal x86_64 3.2.1-3.fc34 @anaconda 4.1 M Removing unused dependencies: SuperLU x86_64 5.2.1-14.fc33 @anaconda 467 k armadillo x86_64 10.1.2-1.fc34 @anaconda 99 k arpack x86_64 3.7.0-8.fc33 @anaconda 625 k cfitsio x86_64 3.470-3.fc33 @anaconda 1.7 M freexl x86_64 1.0.6-1.fc33 @anaconda 70 k gdal-libs x86_64 3.2.1-3.fc34 @anaconda 26 M geos x86_64 3.9.0-1.fc34 @anaconda 2.2 M hdf-libs x86_64 4.2.15-3.fc33 @anaconda 682 k libdap x86_64 3.20.6-2.fc33 @anaconda 2.1 M libgeotiff x86_64 1.6.0-3.fc34 @anaconda 344 k libgta x86_64 1.0.9-5.fc33 @anaconda 75 k libkml x86_64 1.3.0-29.fc33 @anaconda 1.2 M libpq x86_64 13.1-1.fc34 @anaconda 715 k librttopo x86_64 1.1.0-1.fc34 @anaconda 518 k libspatialite x86_64 5.0.0-3.fc34 @anaconda 16 M mariadb-connector-c x86_64 3.1.11-1.fc34 @anaconda 539 k mariadb-connector-c-config noarch 3.1.11-1.fc34 @anaconda 497 minizip x86_64 2.10.2-1.fc34 @anaconda 354 k netcdf x86_64 4.7.3-5.fc34 @anaconda 1.9 M ogdi x86_64 4.1.0-4.fc33 @anaconda 871 k proj-data-at noarch 7.2.1-1.fc34 @anaconda 2.1 M proj-data-au noarch 7.2.1-1.fc34 @anaconda 118 M proj-data-be noarch 7.2.1-1.fc34 @anaconda 749 k proj-data-br noarch 7.2.1-1.fc34 @anaconda 1.0 M proj-data-ca noarch 7.2.1-1.fc34 @anaconda 94 M proj-data-ch noarch 7.2.1-1.fc34 @anaconda 1.6 M proj-data-de noarch 7.2.1-1.fc34 @anaconda 74 M proj-data-dk noarch 7.2.1-1.fc34 @anaconda 9.9 M proj-data-es noarch 7.2.1-1.fc34 @anaconda 1.0 M proj-data-eur noarch 7.2.1-1.fc34 @anaconda 1.0 M proj-data-fi noarch 7.2.1-1.fc34 @anaconda 288 k proj-data-fo noarch 7.2.1-1.fc34 @anaconda 1.5 k proj-data-fr noarch 7.2.1-1.fc34 @anaconda 1.2 M proj-data-is noarch 7.2.1-1.fc34 @anaconda 5.5 M proj-data-jp noarch 7.2.1-1.fc34 @anaconda 420 k proj-data-nc noarch 7.2.1-1.fc34 @anaconda 1.1 M proj-data-nl noarch 7.2.1-1.fc34 @anaconda 1.1 M proj-data-nz noarch 7.2.1-1.fc34 @anaconda 14 M proj-data-pt noarch 7.2.1-1.fc34 @anaconda 431 k proj-data-se noarch 7.2.1-1.fc34 @anaconda 2.2 M proj-data-sk noarch 7.2.1-1.fc34 @anaconda 1.2 M proj-data-uk noarch 7.2.1-1.fc34 @anaconda 4.8 M proj-data-us noarch 7.2.1-1.fc34 @anaconda 224 M unixODBC x86_64 2.3.9-1.fc34 @anaconda 1.4 M uriparser x86_64 0.9.4-2.fc33 @anaconda 160 k xerces-c x86_64 3.2.3-2.fc33 @anaconda 3.5 M Transaction Summary === Remove 48 Packages Freed space: 637 M When I only remove the data, I get:
Re: Python Classroom Lab help needed: proj-data is suddenly 569M
Hello. From my point of view and from the networkx perespective, we can brake this chain and don't install python3-gdal. python3-gdal brings support for special GIS Shapefile which I think we don't need by default in the classroom. Have a nice day. Lumír On 1/27/21 3:17 PM, Miro Hrončok wrote: Hello, when debugging an unexpected significant file size grow of the Python Classroom Lab [1], I've realized the following package changes since Fedora 33: proj -proj-datumgrid +proj-data-at +proj-data-au +proj-data-be +proj-data-br +proj-data-ca +proj-data-ch +proj-data-de +proj-data-dk +proj-data-es +proj-data-eur +proj-data-fi +proj-data-fo +proj-data-fr +proj-data-is +proj-data-jp +proj-data-nc +proj-data-nl +proj-data-nz +proj-data-pt +proj-data-se +proj-data-sk +proj-data-uk +proj-data-us And /usr/share/proj is huge: [fedora-34]$ du -h /usr/share/proj 569M /usr/share/proj [fedora-33]$ du -h /usr/share/proj 14M /usr/share/proj When I attempt to remove proj, I get: === Package Arch Version Repository Size === Removing: proj x86_64 7.2.1-1.fc34 @anaconda 13 M Removing dependent packages: python3-gdal x86_64 3.2.1-3.fc34 @anaconda 4.1 M Removing unused dependencies: SuperLU x86_64 5.2.1-14.fc33 @anaconda 467 k armadillo x86_64 10.1.2-1.fc34 @anaconda 99 k arpack x86_64 3.7.0-8.fc33 @anaconda 625 k cfitsio x86_64 3.470-3.fc33 @anaconda 1.7 M freexl x86_64 1.0.6-1.fc33 @anaconda 70 k gdal-libs x86_64 3.2.1-3.fc34 @anaconda 26 M geos x86_64 3.9.0-1.fc34 @anaconda 2.2 M hdf-libs x86_64 4.2.15-3.fc33 @anaconda 682 k libdap x86_64 3.20.6-2.fc33 @anaconda 2.1 M libgeotiff x86_64 1.6.0-3.fc34 @anaconda 344 k libgta x86_64 1.0.9-5.fc33 @anaconda 75 k libkml x86_64 1.3.0-29.fc33 @anaconda 1.2 M libpq x86_64 13.1-1.fc34 @anaconda 715 k librttopo x86_64 1.1.0-1.fc34 @anaconda 518 k libspatialite x86_64 5.0.0-3.fc34 @anaconda 16 M mariadb-connector-c x86_64 3.1.11-1.fc34 @anaconda 539 k mariadb-connector-c-config noarch 3.1.11-1.fc34 @anaconda 497 minizip x86_64 2.10.2-1.fc34 @anaconda 354 k netcdf x86_64 4.7.3-5.fc34 @anaconda 1.9 M ogdi x86_64 4.1.0-4.fc33 @anaconda 871 k proj-data-at noarch 7.2.1-1.fc34 @anaconda 2.1 M proj-data-au noarch 7.2.1-1.fc34 @anaconda 118 M proj-data-be noarch 7.2.1-1.fc34 @anaconda 749 k proj-data-br noarch 7.2.1-1.fc34 @anaconda 1.0 M proj-data-ca noarch 7.2.1-1.fc34 @anaconda 94 M proj-data-ch noarch 7.2.1-1.fc34 @anaconda 1.6 M proj-data-de noarch 7.2.1-1.fc34 @anaconda 74 M proj-data-dk noarch 7.2.1-1.fc34 @anaconda 9.9 M proj-data-es noarch 7.2.1-1.fc34 @anaconda 1.0 M proj-data-eur noarch 7.2.1-1.fc34 @anaconda 1.0 M proj-data-fi noarch 7.2.1-1.fc34 @anaconda 288 k proj-data-fo noarch 7.2.1-1.fc34 @anaconda 1.5 k proj-data-fr noarch 7.2.1-1.fc34 @anaconda 1.2 M proj-data-is noarch 7.2.1-1.fc34 @anaconda 5.5 M proj-data-jp noarch 7.2.1-1.fc34 @anaconda 420 k proj-data-nc noarch 7.2.1-1.fc34 @anaconda 1.1 M proj-data-nl noarch 7.2.1-1.fc34 @anaconda 1.1 M proj-data-nz noarch 7.2.1-1.fc34 @anaconda 14 M proj-data-pt noarch 7.2.1-1.fc34 @anaconda 431 k proj-data-se noarch 7.2.1-1.fc34 @anaconda 2.2 M proj-data-sk noarch 7.2.1-1.fc34 @anaconda 1.2 M proj-data-uk noarch 7.2.1-1.fc34 @anaconda 4.8 M proj-data-us noarch 7.2.1-1.fc34 @anaconda 224 M unixODBC x86_64 2.3.9-1.fc34 @anaconda 1.4 M uriparser x86_64 0.9.4-2.fc33 @anaconda 160 k xerces-c x86_64 3.2.3-2.fc33 @anaconda 3.5 M Transaction Summary === Remove 48 Packages Freed space: 637 M When I only remove the data, I get:
Re: Mass rebuild failures on s390
On 28. 01. 21 10:49, Vít Ondruch wrote: Dne 27. 01. 21 v 23:34 Kevin Fenzi napsal(a): On Wed, Jan 27, 2021 at 10:15:20PM +, Richard W.M. Jones wrote: Here are a couple of my packages which failed mass rebuild because of apparent problems with the s390 builder: https://koji.fedoraproject.org/koji/taskinfo?taskID=60560709 https://koji.fedoraproject.org/koji/taskinfo?taskID=60560418 Could we automatically look for builds which fail this way and resubmit them please? The plan is to wait for the entire mass rebuild to finish, then resubmit all the failures. Hopefully that will fix at least most of the above cases. With or without release bump? The latter would be preferable. Yes, please don't do "mass rebuild second attempt" release bumps this time. -- 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
Re: Mass rebuild failures on s390
Dne 27. 01. 21 v 23:34 Kevin Fenzi napsal(a): On Wed, Jan 27, 2021 at 10:15:20PM +, Richard W.M. Jones wrote: Here are a couple of my packages which failed mass rebuild because of apparent problems with the s390 builder: https://koji.fedoraproject.org/koji/taskinfo?taskID=60560709 https://koji.fedoraproject.org/koji/taskinfo?taskID=60560418 Could we automatically look for builds which fail this way and resubmit them please? The plan is to wait for the entire mass rebuild to finish, then resubmit all the failures. Hopefully that will fix at least most of the above cases. With or without release bump? The latter would be preferable. Vít kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org OpenPGP_signature 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
Re: Proposal to deprecated `fedpkg local`
Thx everybody for their responses and sorry for such controversial topic. I am not going to propose this upstream after all. However I have few takeaways: 1) I see responses of Fedora long timers and I understand that you have polished workflows. But I really think that for newcomers, mock should be the preferred way. I'd love to see documentation adjusted to prefer mock everywhere. 2) I would really love you to stop using VMs for your build/testing. With exception of Kernel and Kernel related issues, the argument of "mock being slow" can't stand. Every VM will be more resources hungry then mock, slowing every your task. 3) The argument of mock being slow can't stand, because in one of my examples I posted elsewhere in this thread, I picked up the simplest package I could and the build took 7 seconds. This is certainly not slow, in this time you can't even switch to your email client to check your emails. Vít Dne 27. 01. 21 v 17:17 Vít Ondruch napsal(a): Hi, I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? Vít ___ 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 OpenPGP_signature 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
Re: Proposal to deprecated `fedpkg local`
Dne 27. 01. 21 v 23:21 Gwyn Ciesla via devel napsal(a): -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 4:17 PM, Richard W.M. Jones wrote: On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote: Hi, I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? Why? I use it all the time. While I understand that it's not as complete a local test as mock, it a lot quicker and less disruptive. And if I want a real test I'll use a scratch build (because that's the only way to test a build across architectures). Agreed. Santa didn't bring me the s390x I asked for this year. :( Just FTR, mock supports `--arch=ARCH` which will use emulation to allow you build whatever architecture localy. I have never used it myself, but I wanted to mention this. Vít TL;DR don't drop it. Rich. --- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org OpenPGP_signature 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
Re: Proposal to deprecated `fedpkg local`
On Wed, Jan 27, 2021 at 06:58:05PM +0100, Vít Ondruch wrote: > Dne 27. 01. 21 v 18:53 Petr Menšík napsal(a): > > This would describe my usual workflow as well. fedpkg local is great for > > checking soname did not change, patches apply, to debugging why my test > > suites fail and how they behave. mock usual does not have even vim > > You have vim on your host with your configuration, why would you need it in > mock? > $ fedpkg local failed. $ cd foo-1.2.3/ $ make test t/foo failed. $ vim t/foo make some changes $ make test here is you debugging output I find $ vim /var/lib/mock/SOME_GIBBERISH_I_NEVER_REMEMBER_AND_I_DONT_KNOW_WHICH_IS_THE_RIGHT_ONE/root/builddir/build/BUILD/foo-1.2.3/t/foo less useable. -- Petr 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
Re: dropping selinux-policy strict version requirement
Hi,
the exact version requirement is in place to avoid incompatibility
between the policy on the target system (system you want to install the
module on) and the custom policy module.
Lets call the policy used to compile your module "A", policy on the
target system "B" and your custom module "C".
C can be incompatible with B if A contains a new definition (object
class, permission, type or boolean) that is not present in B and the
newly defined name is used in your module (e.g. because of an interface
used in your module). The incompatibility will prevent installation of
your module ("semodule -i" will fail).
Please see [1] to get an idea of when you can expect new definitions to
appear in RHEL policy.
Depending on an unversioned selinux-policy-base can therefore cause
problems not only when installing policy compiled on RHEL to a CentOS
system, but also when installing it on the same version of RHEL, with
outdated system policy.
I would at least suggest using dependency on some reasonably recent
fixed version of selinux-policy-base, and testing each new build of your
module on a system with that fixed version of selinux-policy-base.
However, it would be best to avoid cross-sytem installations.
Hope this helps.
Vit
[1] - https://access.redhat.com/articles/4854201
On 1/27/21 6:30 PM, Ken Dreyer wrote:
Hi folks,
Many applications ship their own "-selinux" sub-package. These
subpackages usually set a minimal dependency on the exact
selinux-policy version in the buildroot.
In Ceph's case, we have:
Requires(post): selinux-policy-base >= %{_selinux_policy_version}
This version requirement causes problems in two scenarios:
1. If we build Ceph on CentOS Stream, the ceph-selinux package will be
uninstallable on RHEL.
2. If we build Ceph on the latest RHEL 8, the ceph-selinux package
package will be uninstallable on RHEL 8 EUS.
Is it safe to drop the exact version requirement here and just depend
on an unversioned "selinux-policy-base"?
I can't find any official Fedora Packaging Guideline on this. I opened
https://tracker.ceph.com/issues/49034 to track this in Ceph upstream.
- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
On 1/27/21 8:30 PM, Kevin Fenzi wrote: On Wed, Jan 27, 2021 at 10:48:46AM +0200, Panu Matilainen wrote: On 1/26/21 8:44 PM, Kevin Fenzi wrote: So, the thread here kind of fell quiet with everything else going on. It seems clear there's issues to address here before this change might get approved. Here's my list: * Try and change the storage format of the signatures to not take up tons of room. I guess this would be in ima tools and sigul? That'd be rpm upstream work. On my F33 laptop, there are 331284 rpm-installed files. The IMA signature as proposed is apparently 162 bytes per file in the hex-encoded format, this makes for approximately 51 megabytes of data. My rpmdb is about 115 megabytes. That'd be almost 45% increase in size! SO, I don't really understand... Patrick says in the Change: "The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase. This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system." Is that just because he used the server install with fewer files? As directories are not signed, in a smaller installation the directory vs file ratio could be different, making the overhead smaller than in a larger install. Looking at the F33 server edition install, there are 59246 files total, 22837 of which are directories. That's a very different ratio to my laptop install where there are 402158 files total of which 70874 are directories. So it's a case of "it depends" and it depends quite a lot. By no means the overhead is always 45% but neither is it always 20% - depending on the exact package set it can be even be quite a bit more or less than either figure. Or is your or his math wrong here? You're free to check the math [1]. As said above, the size of an IMA signature is 162 bytes per file, which you can also see for yourself by looking at a signed package. Multiply that by the number of files installed. The real overhead from the string array structure is more than that, but just the signature data is 162 bytes per non-directory file entry. Whether the database file size increases by that exact amount depends as a database can preallocate space etc, but there literally is that much more data to store, and otherwise haul around even on unrelated queries. [1] I'm known to get it wrong on occasion, https://github.com/rpm-software-management/rpm/pull/1252 - 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
