Re: Any recent changes to the arm builders?
* Kevin Fenzi: > On Sun, Aug 15, 2021 at 01:51:16PM +0200, Florian Weimer wrote: >> * Kevin Fenzi: >> >> > Yes. They were mistakenly running the normal kernel (so they had ~3GB >> > memory available). I moved them back to the lpae kernel (so they see >> > 40GB memory), but this causes >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1920183 >> > >> > basically OOM kills kojid, which restarts kojid, which restarts the >> > build, which kills kojid, etc... >> >> Why aren't the builders running 64-bit kernels, like we do for x86-64? > > This is not a configuration that I think we support in any way. Who is “we”? I expect that 64-bit kernel bugs will get more attention upstream. > At least rpm rejects trying to install a aarch64 kernel on a 32bit > userspace. The host (including kojid) should probably be 64-bit, and only the chroot 32-bit. If that doesn't work, it's an RPM bug/missing feature. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Hello, according to the size of this change and the possible breakage of multiple packages before f35 mass rebuild, we decided (team working on this change) to postpone this change to early lifecycle of f36, where we will have enough time to resolve any problems until f36 mass rebuild. On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi wrote: > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote: > > Currently, we are trying to stay away from the compat package and with > the > > help of other package maintainers trying to fix the failures. We will > give > > time to react accordingly and see other possible steps in a few weeks > time. > > > > Currently multiple FTBFS bugs in bugzilla were created according to > > autoconf-2.71. More information available here: > > > > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > Whats the current status of this Change? > > It didn't land before mass rebuild. Is it still planned for f35? > > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Running rawhide mockbuild on Fedora 33 fails with GPG check
One problem is mock doesn't have the right GPG key for rawhide at this point. It's easy to fix. # ls -al /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-* ... -rw-r--r--. 1 root root 1668 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary -rw-r--r--. 1 root root 1668 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-35-primary -rw-r--r--. 1 root root 1668 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary lrwxrwxrwx. 1 root root 29 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary -> RPM-GPG-KEY-fedora-35-primary # cd /usr/share/distribution-gpg-keys/fedora/ # rm RPM-GPG-KEY-fedora-rawhide-primary rm: remove symbolic link 'RPM-GPG-KEY-fedora-rawhide-primary'? y # ln -s RPM-GPG-KEY-fedora-36-primary RPM-GPG-KEY-fedora-rawhide-primary Furthermore, /etc/mock/templates/fedora-rawhide.tpl has hard-coded version 35 which needs to bump to 36. There's a second problem, that fedora-review claims to take a --mock-config= option, but it seems not to work. It always wants to build for rawhide. Thanks, Matt On Sun, Aug 15, 2021 at 7:06 AM Otto Urpelainen wrote: > Sérgio Basto kirjoitti 15.8.2021 klo 3.12: > > Hi, > > > > I'm seeing the same problem, for a quick fix, we need update > > /etc/mock/templates/fedora-rawhide.tpl line 12 with > > config_opts['releasever'] = '36', as reference [1] ... > > > > We need a new mock-core-configs package with configurations for "Fedora > > 35 branched" some work in progress here [2] > > Having followed the Fedora process for some time now, I have noticed > that issues of this kind happen at every branching. > > I wonder if more things could work like dist-git branches already do, > where rawhide is always rawhide, branching does not affect it, and > branched releases receive a new configuration at the moment of > branching? Opposed to that, Mock and other places follow a model where > rawhide is Fedora N+1 and branching means a) reconfiguring rawhide as > Fedora N+2 and b) creating a new configuration for the actual Fedora > N+1. The need to do a) means that rawhide easily breaks when branching > occurs. > > When you branch B off from A, it is understandable that B won't be > completely functional until the branching is completed. But there should > be no reason for A to stop working, simply because there should not be > any reason to modify A at all. > > I am not very familiar with Mock internals, but I suppose that Mock is > *not* one of the places where such change of approach would be easy. I > suppose it has a relation with dist tags, and if you changed rawhide's > dist tag from 'fc(n+1)' to 'rawhide', you should probably do mass > rebuild only after branching to get dist tag right in the branched > release. And you would probably have to consider a lot of other things, > too. > > But there are also places where it would be easy to avoid breakage > simply calling rawhide, 'rawhide': At least the thing where a Toolbox > container build from f34 image can be either actually Fedora 34 or > Fedora Rawhide, depending on things [1]. > > [1]: https://github.com/containers/toolbox/issues/722 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: apitrace: undefined reference to `__libc_dlopen_mode', `__libc_dlsym'
I'd need help with the following issue with apitrace, which failed the mass rebuild with: apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:70: undefined reference to `__libc_dlopen_mode' apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:72: undefined reference to `__libc_dlsym' The code triggering this is below. Have these symbols disappeared from libc resp is there any alternative? I've raised this upstream but so far no activity [1]. I'm not really knowledgeable enough in this area to judge the best way to fix this. Is anyone able to help with this? Otherwise I'll have to orphain/retire apitrace for F35+. According to the comments in https://github.com/apitrace/apitrace.git file wrappers/dlsym.cpp , the purpose is "to obtain the true dlsym" by explicit lookup in libdl.so.2, which is a library that no longer exists in glibc-2.34, having been combined into libc.so itself. The only legitimate way to find "the true dlsym" is to trust dl_iterate_phdr (/usr/include/link.h) and call it, dig through all the Dynamic sections to find all the symbols named 'dlsym', then choose the one you want: perhaps by being defined in a file whose DT_SONAME is "libc.so" and having symbol version GLIBC_2.2.5 . Because such code has not been contributed, then apitrace should be orphaned/retired in F35+. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Updated hdf5/netcdf/octave coming to rawhide/f35
On 8/9/21 7:35 PM, devel@lists.fedoraproject.org wrote: I'm starting to build packages and all dependencies for an updated hdf5/netcdf/octave stack in a side tag. I've just submitted the updates for F35 and F36. There are a few packages have failed to build (mainly due to arm or other package issues - not many due to these updates it seems) and I'll be working on them and/or filing bugs for them shortly. -- Orion Poplawski he/him/his - surely the least important thing about me 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Proposal to CANCEL: 2021-08-16 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting tomorrow. Again I don't have anything in particular for the agenda. If you're aware of anything it would be useful to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: requesting help to update spyder
On Sun, 15 Aug 2021, Elliott Sales de Andrade wrote: I am trying to update spyder on rawhide and F35. The main issue I have is that pyqt requirements are strict. From the setup file, 'pyqt5<5.13', 'pyqtwebengine<5.13', Fedora has 5.15.x. If I relax QT versions, built and launch spyder, I get this error and spyder fails to launch. scaled(self, int, int, aspectRatioMode: Qt.AspectRatioMode = Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = Qt.FastTransformation): argument 1 has unexpected type 'float' scaled(self, QSize, aspectRatioMode: Qt.AspectRatioMode = Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = Qt.FastTransformation): argument 1 has unexpected type 'float' Do you know where is this error triggered? Try explicitly converting the floats to integers. Yeah, that sounds more like a common Python 3.10 issue than an issue with newer PyQt. No, this is definitely a change in PyQt, or at least sip, cf. https://github.com/matplotlib/matplotlib/pull/17565 https://github.com/matplotlib/matplotlib/pull/17600 The fix is 'easy', but you need to find everywhere that might trigger it. QSize takes an int now, as it does in Qt (from C++), instead of coercing a float. Python 3.10 also contains a change where you can no longer pass floats to extension modules in cases where there would a loss of precision (e.g., as an int). Scott ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: requesting help to update spyder
On Sun, 15 Aug 2021 at 19:40, Scott Talbert wrote: > > On Sun, 15 Aug 2021, Miro Hrončok wrote: > > >> Hi, > >> > >> I am trying to update spyder on rawhide and F35. The main issue I have is > >> that pyqt requirements are strict. From the setup file, > >> > >> 'pyqt5<5.13', > >> 'pyqtwebengine<5.13', > >> > >> Fedora has 5.15.x. If I relax QT versions, built and launch spyder, I get > >> this error and spyder fails to launch. > >> > >> scaled(self, int, int, aspectRatioMode: Qt.AspectRatioMode = > >> Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = > >> Qt.FastTransformation): argument 1 has unexpected type 'float' > >> > >> scaled(self, QSize, aspectRatioMode: Qt.AspectRatioMode = > >> Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = > >> Qt.FastTransformation): argument 1 has unexpected type 'float' > > > > Do you know where is this error triggered? Try explicitly converting the > > floats to integers. > > Yeah, that sounds more like a common Python 3.10 issue than an issue with > newer PyQt. > No, this is definitely a change in PyQt, or at least sip, cf. https://github.com/matplotlib/matplotlib/pull/17565 https://github.com/matplotlib/matplotlib/pull/17600 The fix is 'easy', but you need to find everywhere that might trigger it. QSize takes an int now, as it does in Qt (from C++), instead of coercing a float. > Scott -- Elliott ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: requesting help to update spyder
On Sun, 15 Aug 2021, Miro Hrončok wrote: Hi, I am trying to update spyder on rawhide and F35. The main issue I have is that pyqt requirements are strict. From the setup file, 'pyqt5<5.13', 'pyqtwebengine<5.13', Fedora has 5.15.x. If I relax QT versions, built and launch spyder, I get this error and spyder fails to launch. scaled(self, int, int, aspectRatioMode: Qt.AspectRatioMode = Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = Qt.FastTransformation): argument 1 has unexpected type 'float' scaled(self, QSize, aspectRatioMode: Qt.AspectRatioMode = Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = Qt.FastTransformation): argument 1 has unexpected type 'float' Do you know where is this error triggered? Try explicitly converting the floats to integers. Yeah, that sounds more like a common Python 3.10 issue than an issue with newer PyQt. Scott___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On Sun, Aug 15, 2021 at 6:44 PM Demi Marie Obenour wrote: > > On 8/14/21 12:19 PM, Kevin Fenzi wrote: > > On Fri, Aug 13, 2021 at 09:34:11PM -0600, Orion Poplawski wrote: > >> Have there been any recent changes to the arm (32bit) builders? It seems > >> like I'm having much more issues there with builds likely running out of > >> memory or similar. > > > > Yes. They were mistakenly running the normal kernel (so they had ~3GB > > memory available). I moved them back to the lpae kernel (so they see > > 40GB memory), but this causes > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1920183 > > > > basically OOM kills kojid, which restarts kojid, which restarts the > > build, which kills kojid, etc... > > Mark kojid as non-killable by setting its OOM score to -1000? Adding > swap might also help, but then the build is by no means guaranteed to > finish in a reasonable amount of time. > > > I've tried all kinds of things here, but haven't been able to find any > > way to make it work. Arm folks can't duplicate it on non koji builders. > > I suspect the number of people using lpae on 32bit arm is... low. > > We could just go back to non lpae, but that breaks building some other > > packages (llvm fails to build for example). > > > > It makes me wonder if we should consider letting 32bit arm go... > > (insert pitchforks and torches). > > > > Anyhow, if anyone has any ideas, let me know. > > > > kevin > > If Fedora wants to keep supporting 32-bit platforms, I believe the only > reasonable solution is cross-compilation. 32-bit systems are nowadays > almost always embedded, and everyone cross-compiles in the embedded > world. > ARM is the only remaining non-embedded 32-bit architecture in common use. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On 8/14/21 12:19 PM, Kevin Fenzi wrote: > On Fri, Aug 13, 2021 at 09:34:11PM -0600, Orion Poplawski wrote: >> Have there been any recent changes to the arm (32bit) builders? It seems >> like I'm having much more issues there with builds likely running out of >> memory or similar. > > Yes. They were mistakenly running the normal kernel (so they had ~3GB > memory available). I moved them back to the lpae kernel (so they see > 40GB memory), but this causes > > https://bugzilla.redhat.com/show_bug.cgi?id=1920183 > > basically OOM kills kojid, which restarts kojid, which restarts the > build, which kills kojid, etc... Mark kojid as non-killable by setting its OOM score to -1000? Adding swap might also help, but then the build is by no means guaranteed to finish in a reasonable amount of time. > I've tried all kinds of things here, but haven't been able to find any > way to make it work. Arm folks can't duplicate it on non koji builders. > I suspect the number of people using lpae on 32bit arm is... low. > We could just go back to non lpae, but that breaks building some other > packages (llvm fails to build for example). > > It makes me wonder if we should consider letting 32bit arm go... > (insert pitchforks and torches). > > Anyhow, if anyone has any ideas, let me know. > > kevin If Fedora wants to keep supporting 32-bit platforms, I believe the only reasonable solution is cross-compilation. 32-bit systems are nowadays almost always embedded, and everyone cross-compiles in the embedded world. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: apitrace: undefined reference to `__libc_dlopen_mode', `__libc_dlsym'
On 25.07.21 12:51, Sandro Mani wrote: Hi I'd need help with the following issue with apitrace, which failed the mass rebuild with: apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:70: undefined reference to `__libc_dlopen_mode' apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:72: undefined reference to `__libc_dlsym' The code triggering this is below. Have these symbols disappeared from libc resp is there any alternative? I've raised this upstream but so far no activity [1]. I'm not really knowledgeable enough in this area to judge the best way to fix this. Is anyone able to help with this? Otherwise I'll have to orphain/retire apitrace for F35+. Thanks Sandro [1] https://github.com/apitrace/apitrace/issues/756 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On Sun, Aug 15, 2021 at 11:43:48AM +0200, Miro Hrončok wrote: > On 14. 08. 21 18:19, Kevin Fenzi wrote: > > It makes me wonder if we should consider letting 32bit arm go... > > (insert pitchforks and torches). > > Let's propose it and see what people say? As a package maintainer, I would > certainly appreciate this. > > I can draft a change proposal next week. How about we give time for the iot and arm folks who likely have not seen this yet to chime in. :) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On Sun, Aug 15, 2021 at 01:51:16PM +0200, Florian Weimer wrote: > * Kevin Fenzi: > > > Yes. They were mistakenly running the normal kernel (so they had ~3GB > > memory available). I moved them back to the lpae kernel (so they see > > 40GB memory), but this causes > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1920183 > > > > basically OOM kills kojid, which restarts kojid, which restarts the > > build, which kills kojid, etc... > > Why aren't the builders running 64-bit kernels, like we do for x86-64? This is not a configuration that I think we support in any way. At least rpm rejects trying to install a aarch64 kernel on a 32bit userspace. > As far as I understand it, there is both kernel and CPU support for that > (on CPUs that support 32-bit at all). If it can be made to work that would be great, but my understanding is that it does not. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On Sat, Aug 14, 2021 at 12:57:40PM -0400, Frank Ch. Eigler wrote: > Kevin Fenzi writes: > > > It makes me wonder if we should consider letting 32bit arm go... > > (insert pitchforks and torches). > > ... or go back to an F32 kernel? At this point it would have a gillion CVE's... but also I am not sure it would work due to the change from direct boot to uefi booting. Might be worth trying tho... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On Thu, Aug 12, 2021 at 06:14:57PM -0700, Michel Alexandre Salim via devel
wrote:
> On Thu, Aug 12, 2021 at 05:23:18PM -0700, Michel Alexandre Salim via devel
> wrote:
> > On Wed, Aug 11, 2021 at 10:56:39AM +0300, Panu Matilainen wrote:
> > > On 8/10/21 8:53 PM, Ankur Sinha wrote:
> > > > On Thu, Aug 05, 2021 09:01:14 +0200, Miroslav Suchý wrote:
> > > > > Dne 05. 08. 21 v 2:42 Michel Alexandre Salim via devel napsal(a):
> > > > > > This is now implemented on Rawhide; Fedora updates are in testing:
> > > > >
> > > > > Where is it documented?
> > > > >
> > > > > I suggest one of these
> > > > >
> > > > > https://rpm-packaging-guide.github.io/
> > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/
> > > >
> > > > That would be great. I was trying to put %limit_build at the top of my
> > > > spec and kept getting errors. Then I looked at the mcrouter spec and
> > > > realised this needs to go into the %build section XD
> > >
> > > Yes, the macro is a strange as it mixes rpm macro language and shell
> > > language, relying on some rather subtle aspects of how spec parsing and
> > > macros work and has to be placed in a shell section. If you ask me, it's
> > > asking for trouble.
> > >
> > > Setting RPM_BUILD_NCPUS environment should achieve the same without
> > > requiring the twisty %global override which looks like it may break
> > > _smp_build_ncpus use in later sections (but I may be missing something
> > > there)
> > >
> > So - I did try exporting RPM_BUILD_NCPUS earlier, and having tried it
> > again, could not figure out how to set that definition from within a
> > macro. Any idea?
> >
> > openSUSE's macro overrides %_smp_mflags instead, which ... seems to work
> > for them, but I agree that we should rather use an environment variable
> > instead.
> >
> Some findings:
> - overriding %_smp_mflags works. But I have to use %global - %define
> does not work - and that triggers some ugly warnings at every build
> - setting RPM_BUILD_NCPUS (or, similarly, %_smp_ncpus_max) does not work
> since %_smp_build_ncpus is already defined by then
>
> Seems like the proper fix here is to either:
> - try and get this macro into RPM proper, so we can have %limit_build
> declared at the top of the spec. This will likely push the change back
> to F36 at the earliest, and would make it hard to retrofit on existing
> releases, unless we want to carry out-of-tree patches.
> - _smp_build_ncpus also seems to be defined per platform, even though
> the definition is mostly identical, so this will be a bit messy
> - change the usage, and require users who want to limit the build to do
> something like this:
>
> %make_build %{limit_build -m 4096} -- with %limit_build used as a
> %function that spits out the relevant -j override
>
Updated pull request, using the latter option:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/141
The macro is now rewritten in Lua, since I can't coerce the shell
definition to just output a value. Tested locally with mock (I had to
copy fedora-34-x86_64 to fedora-35-x86_64 as the Rawhide target is
currently failing on GPG verification).
- if limit_build computes a number that is higher than %_smp_build_ncpus
it outputs nothing
- if it computes a value that is smaller, it outputs '-j'
- if it computes a value less than 1 it outputs '-j1'
Tested with mcrouter locally and setting the memory requirement to some
ridiculous value (-m 409600) I do end up with a single-core build.
Inline documentation is provided, once the PR is reviewed and this is
built for Rawhide I'll update the packaging guideline.
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora-IoT-34-20210815.0 compose check report
No missing expected images. Failed openQA tests: 1/16 (x86_64), 3/15 (aarch64) New failures (same test not failed in Fedora-IoT-34-20210809.0): ID: 948737 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/948737 ID: 948764 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/948764 ID: 948766 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/948766 Old failures (same test failed in Fedora-IoT-34-20210809.0): ID: 948753 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/948753 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-20210809.0): ID: 948738 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/948738 Passed openQA tests: 1/16 (x86_64), 12/15 (aarch64) New passes (same test not passed in Fedora-IoT-34-20210809.0): ID: 948736 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/948736 ID: 948752 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/948752 Skipped non-gating openQA tests: 13 of 31 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Running rawhide mockbuild on Fedora 33 fails with GPG check
Sérgio Basto kirjoitti 15.8.2021 klo 3.12: Hi, I'm seeing the same problem, for a quick fix, we need update /etc/mock/templates/fedora-rawhide.tpl line 12 with config_opts['releasever'] = '36', as reference [1] ... We need a new mock-core-configs package with configurations for "Fedora 35 branched" some work in progress here [2] Having followed the Fedora process for some time now, I have noticed that issues of this kind happen at every branching. I wonder if more things could work like dist-git branches already do, where rawhide is always rawhide, branching does not affect it, and branched releases receive a new configuration at the moment of branching? Opposed to that, Mock and other places follow a model where rawhide is Fedora N+1 and branching means a) reconfiguring rawhide as Fedora N+2 and b) creating a new configuration for the actual Fedora N+1. The need to do a) means that rawhide easily breaks when branching occurs. When you branch B off from A, it is understandable that B won't be completely functional until the branching is completed. But there should be no reason for A to stop working, simply because there should not be any reason to modify A at all. I am not very familiar with Mock internals, but I suppose that Mock is *not* one of the places where such change of approach would be easy. I suppose it has a relation with dist tags, and if you changed rawhide's dist tag from 'fc(n+1)' to 'rawhide', you should probably do mass rebuild only after branching to get dist tag right in the branched release. And you would probably have to consider a lot of other things, too. But there are also places where it would be easy to avoid breakage simply calling rawhide, 'rawhide': At least the thing where a Toolbox container build from f34 image can be either actually Fedora 34 or Fedora Rawhide, depending on things [1]. [1]: https://github.com/containers/toolbox/issues/722 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
* Kevin Fenzi: > Yes. They were mistakenly running the normal kernel (so they had ~3GB > memory available). I moved them back to the lpae kernel (so they see > 40GB memory), but this causes > > https://bugzilla.redhat.com/show_bug.cgi?id=1920183 > > basically OOM kills kojid, which restarts kojid, which restarts the > build, which kills kojid, etc... Why aren't the builders running 64-bit kernels, like we do for x86-64? As far as I understand it, there is both kernel and CPU support for that (on CPUs that support 32-bit at all). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
argyllcms package license change
Hello. License changed from "GPLv3+ and AGPLv3+ and MIT" to "AGPLv3+ and GPLv2+ and GPLv3+ and MIT and GFDL". -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On Sun, Aug 15, 2021 at 11:44 AM Miro Hrončok wrote: > > On 14. 08. 21 18:19, Kevin Fenzi wrote: > > It makes me wonder if we should consider letting 32bit arm go... > > (insert pitchforks and torches). > > Let's propose it and see what people say? As a package maintainer, I would > certainly appreciate this. > > I can draft a change proposal next week. I think there's some variables we need to consider here, for example: - Which 32-bit ARM hardware does Fedora currently support, and how old are those boards? Can we drop support for those with, let's say, Fedora 36? - What's the impact on different editions, like on the IoT Edition? My guess is that it's the one that's most impacted by dropping 32-bit ARM support (though I may be wrong here). If those two are no problem, then I'd probably support dropping armv7hl from Fedora as well. It's probably easier to do than dropping 32-bit x86, because there's no multilib support on aarch64 in Fedora. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On 14. 08. 21 18:19, Kevin Fenzi wrote: It makes me wonder if we should consider letting 32bit arm go... (insert pitchforks and torches). Let's propose it and see what people say? As a package maintainer, I would certainly appreciate this. I can draft a change proposal next week. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On 15. 08. 21 4:13, Orion Poplawski wrote: Or perhaps at least a statement that support for it is "best effort" only to make it more acceptable to ExcludeArch it on some packages. Due to the nature of our dependency chain, this would be just slower version of not including it. E.g. we have trouble building Python and if we ExcludeArch it, the distro is not working any more. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20210815.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210814.0): ID: 948720 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/948720 ID: 948731 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/948731 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On 14/08/2021 20:29, Jeff Law wrote: Letting 32bit arm go would have my support. I suspect it's less and less interesting as a platform every day and it causes nothing but headaches. +1 for dropping armv7. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210815.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210814.0): ID: 948704 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/948704 ID: 948715 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/948715 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
