Requesting for contact info for Nethack maintainer
Hi all- I've been trying to follow the guidelines for assuming responsibility for a package per https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers and am on step 4, asking if anyone knows how to contact the current maintainer for Nethack 3.6. The issue in question is: https://bugzilla.redhat.com/show_bug.cgi?id=1289974. As I stated in the bug report, I'd be happy to take over responsibility for this package and keep it going forward. Thanks, Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Requesting for contact info for Nethack maintainer
Right, it's nice that my changes would be pushed, but I'm hoping to take the reigns and keep the Nethack package moving forward, and thought pushing the changes were just that, and nothing more. I did request access but the page gave me a catch-22 of needing to be in a particular group to continue; it was awhile ago at the end of last year and I kind of dropped it, but since I've been playing more Nethack on my Fedora 25 laptop, it rekindled my interest in being the maintainer. Sorry if I'm doing this wrong; the maintainer packages are pretty involved and I'm trying to navigate through this; there's no 'dnf -y install maintainer' as far as I can tell. :) Ron On 9 May 2017, at 14:12, Jason L Tibbitts III wrote: "RO" == Ron Olson writes: RO> Hi all- I've been trying to follow the guidelines for assuming RO> responsibility for a package per RO> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers RO> and am on step 4, asking if anyone knows how to contact the current RO> maintainer for Nethack 3.6. Well, I've seen fale around IRC as reently as a month ago, but not more recently. Maybe he's on vacation. I haven't seen lmacken on IRC in a while. RO> As I stated in the bug report, I'd be happy to take over RO> responsibility for this package and keep it going forward. I don't see that you have requested access to the package in the package database. So even if one of the existing, almost certainly super busy maintainers had a couple of minutes to approve your access, they couldn't. And one of the maintainers even offered to approve your access if you would only request it (back in November). Heck, we even had someone willing to push your changes for you. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Requesting for contact info for Nethack maintainer
Sorry, right, I'm trying to become a packager. Funny enough, I use IRC every day; what room should I join (I'm assuming Freenode). On 9 May 2017, at 14:45, Jason L Tibbitts III wrote: "RO" == Ron Olson writes: RO> I did request access but the page gave me a catch-22 of needing to RO> be in a particular group to continue; it was awhile ago at the end RO> of last year and I kind of dropped it, but since I've been playing RO> more Nethack on my Fedora 25 laptop, it rekindled my interest in RO> being the maintainer. I guess what you're trying to say is that you're not a packager. That wasn't mentioned anywhere as far as I can see. The maintainer of any package can request that you be made a packager so that you can assist them with the package, and I'm sure that fale would have done that if you had mentioned that you needed such. I can also sponsor you into the packager group as can several other folks. That's basically just a promise to mentor you and help with questions you may have. For me it would be vastly preferable if you were on IRC because that's a low effort way to communicate, versus email which for me often piles up and gets missed. RO> Sorry if I'm doing this wrong; the maintainer packages are pretty RO> involved and I'm trying to navigate through this; there's no 'dnf -y RO> install maintainer' as far as I can tell. :) Well, there's fedora-packager, but of course it only gets you the tools, not the knowledge. We have a bunch of documentation about becoming a packager; I'm not sure what you've read at this point. I looked at the nethack package and while it's a bit archaic it's not particularly complicated. I personally would do some cleanup simplifications which might make it a bit easier to read and maintain but it's not a difficult package by any means. (The use of X11 core fonts does scare me, though; that's something most of us would try to forget.) Of course I'm assuming that 3.6 hasn't become drastically more complicated. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Self Introduction: Ron Olson
Aloha all- I’m Ron Olson, with the nickname tachoknight. I have been using Unix since 1989 and Linux since about 1992, when we somehow got an early version to run on a Gateway2000 machine. I have submitted for review an update to the Nethack RPM to update it from 3.4.3 (where it had been for many years), to 3.6.0: https://bugzilla.redhat.com/show_bug.cgi?id=1394598 One of the first games I played besides Colossal Cave and Zork was Nethack. I have played thousands of games on a variety of platforms and I credit it for getting me interested in the art of building software; my university got one of the first batches of NeXT cubes and I made it my mission to get Nethack working on it. I want to make sure that the latest version of Nethack is available to as wide an audience as possible so that the game in its current form can continue to be enjoyed by all. It’s great that the Dev Team is still working on it, and it would be remiss of us if we did not keep the repositories updated with the latest released version. My GitHub repo is https://github.com/tachoknight; I am interested in a variety of things and whenever possible want to share whatever knowledge gained with others. Thanks for reading, Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
RE: will disappear from rawhide glibc soon
Already fixed it and sending it to Rawhide now. -Original Message- From: Miro Hrončok Sent: Saturday, April 18, 2020 4:34 AM To: devel@lists.fedoraproject.org; swift-lang-maintain...@fedoraproject.org Subject: Re: will disappear from rawhide glibc soon On 15. 04. 20 17:49, Florian Weimer wrote: > This follows the removal of the system call from Linux 5.5. Having > the header and function just confuses configure checks that assume > that if the function is present, it will do something useful (it never > did on aarch64, and it's been many years since it worked on Fedora > kernels on other architectures). > > Replacements are uname, getentropy, and reading from /proc, but I > really do not expect much fallout from this (famous last words). > > The kernel headers still provide , but that will > eventually disappear as well. swift-lang fails to build: /builddir/build/BUILD/swift-source/swift-corelibs-foundation/CoreFoundation/PlugIn.subproj/CFBundle_InfoPlist.c:21:10: fatal error: 'sys/sysctl.h' file not found #include ^~ -- 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: will disappear from rawhide glibc soon
Yes: https://github.com/apple/swift-corelibs-foundation/pull/2771 -Original Message- From: Florian Weimer Sent: Saturday, April 18, 2020 8:27 AM To: Ron Olson Cc: 'Miro Hrončok' ; devel@lists.fedoraproject.org; swift-lang-maintain...@fedoraproject.org Subject: Re: will disappear from rawhide glibc soon * Ron Olson: > Already fixed it and sending it to Rawhide now. Have you submitted the fix upstream? 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
RE: Many packages unnecessarily link to libpython
swift-lang includes its own private copy of LLDB for its REPL, which uses Python as its scripting language so it too is linking correctly. ___ 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 32 System-Wide Change proposal: x86-64 micro-architecture update
My entire involvement around Fedora is based on the fact that I was able to use machines that had been thrown away because they were deemed ‘too old’. I have several servers and multiple laptops that run Fedora perfectly and none of them would meet this requirement, effectively ending any chance of using Fedora going forward. Perhaps as a compromise there could be a ‘regular’ 64-bit and a 64-bit-optimized-for-machines-made-after-2013 version? Ron On 22 Jul 2019, at 14:23, Jason L Tibbitts III wrote: "BC" == Ben Cotton writes: BC> * Other developers: Other developers may have to adjust test suites BC> which expect exact floating point results, and correct linking with BC> libatomic. They will also have to upgrade their x86-64 BC> machines to something that can execute AVX2 instructions. [...] BC> == Upgrade/compatibility impact == BC> Fedora installations on systems with CPUs which are not able to BC> execute AVX2 instructions will not be able to upgrade. Wow. I understand progress, but I have to say that it's not really cool to toss this bomb out there without some more detailed breakdown of the impact. For my part, I try to keep my equipment relatively up to date but I don't want to throw something away if it's still perfectly useful. And, let's see, I'd have to toss out five desktops (which isn't too bad, I guess) and probably forty perfectly functional servers, some of which aren't really even all that old. Heck, a dozen computational servers would be on the block. Even requiring avx would force me to toss a pretty big pile of stuff. Basically, this would force me to use something other than Fedora. I'd have no choice, since it wouldn't work. I don't want to be that guy with the 20mhz 386 that still wants others to make sure his stuff works, but still, this seems like it's going more than just a bit too far. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ 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 32 System-Wide Change proposal: x86-64 micro-architecture update
Right, I was making a ha-ha-only-serious thought that perhaps there could be a spin that is specifically highly optimized for latest-n-greatest architectures, and if packagers want to maintain two different versions of x64, that’d be their choice, otherwise fallback to the ‘regular’ one. It certainly wouldn’t be the most popular, but for the folks who could stand to benefit from it, they’d know where to find this particular spin. On 22 Jul 2019, at 15:19, Solomon Peachy wrote: On Mon, Jul 22, 2019 at 03:05:15PM -0500, Ron Olson wrote: Perhaps as a compromise there could be a ‘regular’ 64-bit and a 64-bit-optimized-for-machines-made-after-2013 version? It's not as simple as a "CPU newer than date X" cutoff -- Intel limits AVX support to their Xeon and Core brands only. Their current-gen lower-end stuff (sold as Pentium, Celeron and Atom) doesn't support AVX of any flavor. And they sell a _lot_ of those. I think AMD's situation is a bit better, with all of their current processors supporting AVX, and only one (Family 16h) lacking AVX2. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. ___ 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
Trying to reach FAS user brouhaha (Eric Smith)
Hey all, subject line says it all. I’m trying to get in contact with Eric Smith (https://fedoraproject.org/wiki/User:Brouhaha) regarding the libbsd package. I’ve emailed him directly but haven’t heard back; does anyone know if he’s still active in the Fedora community? Thanks, Ron ___ 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: Trying to reach FAS user brouhaha (Eric Smith)
I opened a ticket here: https://pagure.io/fesco/issue/2213 for my specific package. On 22 Aug 2019, at 8:29, Gabriel L. Somlo wrote: On Thu, Aug 22, 2019 at 07:44:29 -0500, tachokni...@gmail.com wrote: Hey all, subject line says it all. I’m trying to get in contact with Eric Smith (https://fedoraproject.org/wiki/User:Brouhaha) regarding the libbsd package. I’ve emailed him directly but haven’t heard back; does anyone know if he’s still active in the Fedora community? Same here, for icestorm: https://bugzilla.redhat.com/show_bug.cgi?id=1740871 and yosys: https://bugzilla.redhat.com/show_bug.cgi?id=1740872 Although, per the official unresponsive maintainer policy at https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I'm still half a week too early to post to the fedora devel list... :) However, since it has come up, I figured I should join the thread. If anyone knows how I could get in touch with Eric regarding yosys and icestorm RPMs, I'd appreciate the pointer. Thanks much, --Gabriel ___ 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: Packages with broken dependencies on Python 3.7
swift-lang has been fixed with a patch and scratch builds on F32 build properly: https://koji.fedoraproject.org/koji/taskinfo?taskID=37348234 On 4 Sep 2019, at 17:39, Miro Hrončok wrote: Hello packagers! The following packages failed to build on Fedora 32 with Python 3.8 and they still require Python 3.7 on runtime. If the packages won't build with Python 3.8, they won't be installable, along with all their dependent packages, in Fedora 32. If there is an "actual" build failure, you should have already received a bug report blocking the tracking bug: https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON38&hide_resolved=1 If it is a dependency failure caused by an external factor (retired package, etc.) there should be a bugreport as well. However, if the package fails to resolve build dependencies only because some other package hasn't been rebuilt with Python 3.8, we have not opened a bug report (yet) to avoid duplication. If you see your package here and are blocked by another package, I recommend to see if the dependency isn't waiting for your help (e.g. the package maintainers haven't yet got time to look into this). Chances are, there is some undiscovered dependency loop as well. The Red Hat Python Maintenance team will gladly help with specific problems, but we will not fix all the packages ourselves. See also https://fedoraproject.org/wiki/Changes/Python3.8 Affected maintainers are bcced (except orphan, groups and maintainers usually disturbed by my spam). Maintainers by package: blender design-sw hobbes1069 ignatenkobrain kwizart luya roma s4504kr slaanesh certbot jhogarth nb clingo thofmann coccinelle rjones condor bbockelm bcotton eerlands matt matyas stevetraylen tstclair ttheisen valtri coreboot-utils lkundrak peter datagrepper ianweller ralph dee jspaleta spot dionaea rebus freecad hobbes1069 jkastner zultron gcc-python-plugindmalcolm jakub gdl orion gnucash notting gplugin ignatenkobrain graphite-api piotrp graphite-web jamielinux jsteffan piotrp kdevelop-python dvratil jgrulich minh libcec pbrobinson libpst carllibpst libunity rdieter mailman3 abompard matrix-synapse dcallagh jcline mraa pbrobinson ocrmypdf qulogic paraview deji orion sagitter player kwizart rmattes timn ttorling pocketsphinx mikep pybind11 jussilehtola python-APScheduler orphan python-OBD rathann python-Pympler rathann python-agate jujens python-agate-dbf jujens python-agate-excel jujens python-agate-sql jujens python-aioresponses gsauthof python-aiosmtpd abompard python-alchimia vpopovic python-anymarkup jchaloup orphan python-anymarkup-core jchaloup orphan python-astroML lupinix python-astroML-addons lupinix python-astropy-healpix lupinix python-astroscrappy lupinix python-asttokens zbyszek python-asynctest rathann python-behavechurchyard orphan python-beniget churchyard python-bz2file besser82 python-cartopy qulogic python-cattrsbrouhaha python-ccdproc lupinix python-certbot-apache jhogarth nb python-certbot-dns-cloudflare nb python-certbot-dns-cloudxns nb python-certbot-dns-digitalocean elyscape nb python-certbot-dns-dnsimple nb python-certbot-dns-dnsmadeeasy nb python-certbot-dns-gehirn elyscape python-certbot-dns-google elyscape nb python-certbot-dns-linode elyscape python-certbot-dns-luadns nb python-certbot-dns-nsone nb python-certbot-dns-ovh elyscape python-certbot-dns-rfc2136 logic nb python-certbot-dns-route53 elyscape nb python-certbot-dns-sakuracloud elyscape python-certbot-nginx jhogarth nb python-chaospy lbazan python-cheetah mikeb mskalick panovotn python-cliappsalimma python-crochet jcline python-csvkitjujens python-dask qulogic python-dbus-python-client-gen grover ignatenkobrain mulhern python-django-appconf mrunge python-django-pyscss mrunge python-elephant lbazan python-envisage orion python-epub athoscr python-flake8-import-order zbyszek python-gast churchyard python-gatspylupinix python-geoplot qulogic python-gfm thm python-gnocchiclient mrunge pkilambi python-grafyaml orphan python-imagehash fab python-inema gsauthof python-into-dbus-python grover ignatenkobrain ilgrad python-jenkins-job-builder ignatenkobrain ktdreyer pabelanger python-jira ishcherb ralph stevetraylen python-joblibbesser82 ignatenkobrain sergiopr python-junit_xml jhogarth python-leveldb carlwgeorge python-libpysal qulogic python-logging-tree orphan ralph python-marshmallow-enum orphan python-mdp zbyszek python-missin
Re: Donate 1 minute of your time to test upgrades from F30 to F31
This is what I got: Error: Problem 1: package gegl03-0.3.30-5.fc30.x86_64 requires libIlmImf-2_2.so.22()(64bit), but none of the providers can be installed - OpenEXR-libs-2.2.0-16.fc30.x86_64 does not belong to a distupgrade repository - problem with installed package gegl03-0.3.30-5.fc30.x86_64 Problem 2: problem with installed package exa-0.8.0-13.module_f30+4041+ebfd9240.x86_64 - package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed - exa-0.8.0-13.module_f30+4041+ebfd9240.x86_64 does not belong to a distupgrade repository - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded - package libgit2-0.28.2-3.fc31.x86_64 is excluded (try to add '--skip-broken' to skip uninstallable packages) I was going to open tickets, per the request, but I guess I don’t know what “excluded” means, and whether “not being to a distupgrade repository” is a temporary thing, or something that really should have a ticket created. Ron On 11 Sep 2019, at 7:54, Miroslav Suchý wrote: Do you want to make Fedora 31 better? Please spend 1 minute of your time and try to run [*]: sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31 --enablerepo=updates-testing distro-sync If you get this prompt: ... Total download size: XXX M Is this ok [y/N]: you can answer N and nothing happens, no need to test the actual upgrade. But very likely you get some dependency problem now. In that case, please report it against the appropriate package. Or against fedora-obsolete-packages if that package should be removed in Fedora 31. Please check existing reports first: https://red.ht/2kuBDPu Thank you [*] this command does not replace `dnf system-upgrade`, but it will reveal potential problems. You may also run `dnf upgrade` before running this command. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #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 ___ 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
submitting bodhi.template.last to fedpkg update?
Hey all- Okay, my curiosity has finally gotten the better of me; is there a way to pass the body.template.last file to ‘fedpkg update’ so I don’t have to fill it out for every single release, or fill it out again when I get a timeout and have to rerun fedpkg update? I’ve been searching for how to do it and have come up empty. Thanks for any info! Ron ___ 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: Automating package maintainers responsivity check
What about packages that see infrequent updates; I maintain Nethack and the Dev Team can and does take years between releases. If it's just a blanket email to ask the packagers if they're still interested that's one thing, but going off package updates may be problematic for some folks. > On Nov 17, 2018, at 6:36 AM, Manas Mangaonkar > wrote: > > Yes, this could be a good idea. Might be too small as a gsoc project though. > > I'd happily take this as i am anyways going to try for gsoc 19 with > fedora,this could be a good starting point. > > A simple dockerized/contenerized python based app could be done as a very > simple implementation. > > > > On Nov 17, 2018 4:35 PM, "Mattia Verga" wrote: > Too often there are "non responsive maintainer" messages here. > > Sometimes this is because a maintainer has lost their interest in Fedora > and left their responsibilities without communication, which means their > packages can be left unmaintained for long time in repositories before > someone notice that. > > At other times the maintainer is still active, but for some reason they > are unreachable to users (email change, etc.). > > I would propose some sort of automatic check of maintainer responsivity. > Maybe a tool that checks a packager activity in the last 6 months and if > there is no activity then sends an email asking the maintainer to > confirm they're still involved in Fedora. In case there's no reply, > either automatically orphan their packages or notify someone > (devel-list) to try to reach them. > > What do you think? > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Strange problem: Builds in container, not on machine
Hey all- I got this issue in my GH account I use for building Swift for Fedora: https://github.com/tachoknight/swift-lang-packaging-fedora/issues/2. The TL;DR is that the person was trying to build Swift on Rawhide which he moved to from an older version of Fedora. This tracks with something I discovered as well: I have a current Fedora VM (not Rawhide) that I’ve been upgrading from version to version for several years now, and suddenly it cannot build Swift due to a series of bizarre error messages like: … /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/set:60:10: note: in file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/set:60: #include ^ /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_tree.h:2008:5: error: missing '#include "gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h"'; 'pair' must be declared before it is used pair/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:185:12: note: declaration here is not visible struct pair … However, using mock or a container, it builds fine, Rawhide, F37, whatever. I’m guessing there’s a setting or environment variable or … ? that is present on my and his systems that doesn’t exist in a new container and thus I nor he can build it, while a container and mock can (and I’ve confirmed with scratch koji builds multiple times). Might anyone have an idea where to check to see what might be causing this? I can’t pin down exactly when this started to happen except that it has been _relatively_ recently, perhaps just in the past few months. Thanks for any suggestions! Ron___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Strange problem: Builds in container, not on machine
Oh sorry, this was copied from my Fedora 37 machine, with GCC 12. Same error in the same place though. :\ On 20 Mar 2023, at 15:58, Florian Weimer wrote: * Ron Olson: Hey all- I got this issue in my GH account I use for building Swift for Fedora: https://github.com/tachoknight/swift-lang-packaging-fedora/issues/2. The TL;DR is that the person was trying to build Swift on Rawhide which he moved to from an older version of Fedora. This tracks with something I discovered as well: I have a current Fedora VM (not Rawhide) that I’ve been upgrading from version to version for several years now, and suddenly it cannot build Swift due to a series of bizarre error messages like: … /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/set:60:10: note: in file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/set:60: #include ^ /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_tree.h:2008:5: error: missing '#include "gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h"'; 'pair' must be declared before it is used pair/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:185:12: note: declaration here is not visible struct pair … Rawhide has GCC 13, so the paths look wrong. Try checking package versions, and run “rpm -Va” to check for corruption. For the error with the /13/ in the path, is it possible that the Clang bundled with Swift cannot handle current libstdc++ headers yet? 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Strange problem: Builds in container, not on machine
The irony is that I figured I had just screwed something up on my system and was going to reinstall when this GH report came in. I’m going to try to reproduce with installing F36, building Swift, then upgrading to F37 and see if that has any effect. On 21 Mar 2023, at 5:17, Jonathan Wakely wrote: On Mon, 20 Mar 2023 at 14:10, Ron Olson wrote: Hey all- I got this issue in my GH account I use for building Swift for Fedora: https://github.com/tachoknight/swift-lang-packaging-fedora/issues/2. The TL;DR is that the person was trying to build Swift on Rawhide which he moved to from an older version of Fedora. This tracks with something I discovered as well: I have a current Fedora VM (not Rawhide) that I’ve been upgrading from version to version for several years now, and suddenly it cannot build Swift due to a series of bizarre error messages like: … /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/set:60:10: note: in file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/set:60: #include ^ /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_tree.h:2008:5: error: missing '#include "gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h"'; 'pair' must be declared before it is used pairHowever, using mock or a container, it builds fine, Rawhide, F37, whatever. I’m guessing there’s a setting or environment variable or … ? No, I don't think so. There's no environment variable that is needed to stop the C++ standard library headers being completely broken. The errors above and in the GH issue make no sense to me, maybe it's a bug in Clang's modules that allow a header to be reincluded, but I don't know why it only shows up on your VM and the reporter's system. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Strange problem: Builds in container, not on machine
Are you referring to the directories under rpmbuild? If so, I delete and recreate the directory and its structure every single time as part of my build shell script. On 23 Mar 2023, at 10:17, Fabio Valentini wrote: On Wed, Mar 22, 2023 at 4:16 PM Ron Olson wrote: The irony is that I figured I had just screwed something up on my system and was going to reinstall when this GH report came in. I’m going to try to reproduce with installing F36, building Swift, then upgrading to F37 and see if that has any effect. I've seen similar problems in the distant past when I needed to maintain C / C++ code for some of my packages ... They were almost always caused by "dirty" (or not completely cleaned) build directories, or were caused by stale items in ccache. Neither "diry build directory" nor ccache affect mock builds (unless you explicitly enable the ccache plugin, which is turned off by default), they seem like likely culprits :) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %patchN deprecated?
One thing to note is that the new format doesn’t work with EPEL releases; I had to revert to the %patchN style for them. On 29 Mar 2023, at 3:53, Florian Festi wrote: On 3/29/23 10:31, Michael J Gruber wrote: Has `%patchN` been deprecated in favour of `%patch N`? Yes, see %patch section on https://rpm-software-management.github.io/rpm/manual/spec.html I got a push by a proven packager to one of the packages which I maintain, commit subject and changelog entry "Fix deprecated patch rpm macro". It contains no explanation and no reference whatsoever. I didn't find any heads up notice, nor info in the packaging guidelines, but I didn't try too hard - because it's not my job. I mean: One person is doing that push. Is it too much to ask to get at least the slightest bit of reference or communication before or into a push which probably affects hundreds of people? If not out of courtesy then out of mere common sense of efficiency? On the technical side, I'd be interested why this is better (fewer macros?) and which releases can take it, and what are the recommendations for `PatchN:`-lines (with or without N), and why (or whether) the recommendation isn't to go for `%autosetup` or `%autopatch` - maybe all answered in the missing reference. Those macros are an ugly hack and RPM upstream rather had them go away. The deprecation suggests a one to one replacement. Ofc using the use of %autosetup or %autopatch is encouraged but that kinda out of scope of the deprecation. 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, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Issue with Rawhide docker image?
Hey all, I am using docker and pulled the latest version of rawhide to use interactively. Sitting in the container I ran `dnf -y update` and got: Config error: Parsing file "/etc/dnf/dnf.conf" failed: Parsing file '/etc/dnf/dnf.conf' failed: IniParser: Missing section header at line 1 I stopped the container, deleted it, deleted the image, tried to pull a fresh instance and got exactly the same issue. Suffice to say this makes the container unusable. What's the protocol for informing the powers-that-be about this issue? Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Issue with Rawhide docker image?
Seems a bit disappointing. I’ve been searching but cannot find any info on configuring docker to use Fedora’s repo so I could just ignore the issue altogether. :) On 5 Jun 2023, at 16:41, Mattia Verga via devel wrote: Il 05/06/23 22:12, Ron Olson ha scritto: Hey all, I am using docker and pulled the latest version of rawhide to use interactively. Sitting in the container I ran `dnf -y update` and got: Config error: Parsing file "/etc/dnf/dnf.conf" failed: Parsing file '/etc/dnf/dnf.conf' failed: IniParser: Missing section header at line 1 I stopped the container, deleted it, deleted the image, tried to pull a fresh instance and got exactly the same issue. Suffice to say this makes the container unusable. What's the protocol for informing the powers-that-be about this issue? Ron See: https://pagure.io/fedora-infrastructure/issue/11358 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Issue with Rawhide docker image?
Yep, that worked, thanks! For folks searching similar info later, I ran: docker pull registry.fedoraproject.org/fedora:rawhide On 6 Jun 2023, at 8:34, David Schwörer wrote: Seems a bit disappointing. I’ve been searching but cannot find any info on configuring docker to use Fedora’s repo so I could just ignore the issue altogether. :) You should be able to use a full url: podman pull registry.fedoraproject.org/fedora:rawhide podman pull quay.io/fedora/fedora:rawhide Same should be true for docker, but I haven't tested. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
I’d be willing to take Toilet, as I love that utility. On 5 Dec 2022, at 5:36, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will fail to install and/or build when the affected package gets > retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2022-12-05.txt > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > see https://packager-dashboard.fedoraproject.org/ > For all orphaned packages, > see https://packager-dashboard.fedoraproject.org/orphan > > Package (co)maintainers Status > Change > > 5minute orphan 0 weeks ago > CFR jvanek, orphan 0 weeks ago > CheMPS2 orphan 0 weeks ago > PolicyKit-olpcorphan 1 weeks ago > abiword chimosky, herrold, huzaifas, 0 weeks ago > orphan > aboot orphan 0 weeks ago > albatross orphan 1 weeks ago > alleyoop orphan 1 weeks ago > alure orphan 0 weeks ago > amor jgrulich, kde-sig, orphan, 1 weeks ago > rdieter, than > anki chkr, orphan 0 weeks ago > asn1c orphan 0 weeks ago > backup-managerorphan 1 weeks ago > bbkeysorphan 0 weeks ago > bharati-m17n orphan 0 weeks ago > bibtex2html orphan, thofmann 0 weeks ago > biosdevname lnykryn, msekleta, orphan, 0 weeks ago > vpavlin > blackbox cicku, orphan0 weeks ago > bluecurve-classic-metacity- gnome-sig, orphan, rstrode 0 weeks ago > theme > bluecurve-gnome-theme gnome-sig, orphan, rstrode 0 weeks ago > bluecurve-gtk-themes gnome-sig, orphan, rstrode 0 weeks ago > bluecurve-icon-theme gnome-sig, orphan, rstrode 0 weeks ago > bluecurve-kde-theme gnome-sig, kkofler, orphan, 0 weeks ago > rdieter, rstrode, than > bluecurve-metacity-theme gnome-sig, orphan, rstrode 0 weeks ago > bluecurve-xmms-skin gnome-sig, orphan, rstrode 0 weeks ago > brainfuck orphan 0 weeks ago > buildbot besser82, ignatenkobrain,1 weeks ago > limb, ngompa, orphan, radez, > smilner > cairo-clock orphan 0 weeks ago > code-editor orphan 1 weeks ago > compton orphan 1 weeks ago > converseenorphan 1 weeks ago > cups-bjnp orphan 1 weeks ago > curlpporphan 0 weeks ago > dmz-cursor-themes company, orphan 1 weeks ago > docker-composelsm5, orphan, ttomecek 1 weeks ago > ejabberd bowlofeggs, jcline, orphan, 0 weeks ago > xavierb > enchant orphan 0 weeks ago > erlang-epgsql lkundrak, orphan 1 weeks ago > eurekaorphan 0 weeks ago > fcitx cheeselee, cicku, orphan, pwu, 1 weeks ago > yanqiyu > fcitx-che
Curious how Upstream Release Monitoring works
Hey all- I’m curious how Upstream Monitoring works; I got a BZ filed that Swift 5.7.2 is available, which I’m building now, but what surprised me was how fast the new version was detected and brought to my attention. Does it use The New Hotness? I set that up awhile ago but I don’t think it files BZ tickets (and I must not have it set up correctly as it hasn’t notified me about any releases for the past year). To be clear this isn’t a complaint, if anything it’s an awesome feature and I’m just curious what the mechanism is that makes it work. Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Linking problem with ncurses on rawhide, not f37
Hey all- I got linking errors on rawhide that I did not get on F37 when building Swift related to curses support (https://kojipkgs.fedoraproject.org//work/tasks/7462/95367462/build.log), like: /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `tparm@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_safe_strcpy@NCURSES6_TINFO_5.2.20001021' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_name_match@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `wtimeout@NCURSES6_TINFO_5.0.19991023' /usr/bin/ld: /usr/lib64/libncurses.so.6: undefined reference to `_nc_doalloc@NCURSES6_TINFO_5.0.19991023' In Rawhide the ncurses libs are at 6.3-4.20221126, while f37 is 6.3-3.20220501. I recall seeing some messages go by related to ncurses on the list here regarding the -compat library, but I’m not sure if that’s related to my issue. It seems weird that some of the functions it’s unable to find are part of the library (e.g. wtimeout is a valid function, according to the man pages). Could there be something weird with rawhide’s copy of ncurses or was there some big update that removed all these functions? Thanks! Ron___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
If you’re interested in testing any changes/fixes with Swift, you can use my Swift-for-Fedora repo (https://github.com/tachoknight/swift-lang-packaging-fedora). `setup-container.sh` does what you think it does in case you’re using podman or docker, and `justbuild.sh` actually does all the work to actually create the artifacts. Hope that helps! Ron On 16 Dec 2022, at 5:24, Miroslav Lichvar wrote: On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: Miroslav, we may have to revert the versioning change if the AS_NEEDED approach does not work. Ok, I reverted that change, at least until I have more time for testing the possible fixes. Linking versioned libncurses against unversioned libtinfo etc. would solve this, but I don't know how it would to get to this point. I don't know much about ELF. Is it possible to remove versions from specific symbols in the symbol table after the libraries are built, maybe with some tool like chrpath? -- Miroslav Lichvar___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Linking problem with ncurses on rawhide, not f37
Thanks for doing that, Swift builds correctly on Rawhide now: https://koji.fedoraproject.org/koji/taskinfo?taskID=95546843 On 16 Dec 2022, at 5:24, Miroslav Lichvar wrote: > On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: >> Miroslav, we may have to revert the versioning change if the AS_NEEDED >> approach does not work. > > Ok, I reverted that change, at least until I have more time for > testing the possible fixes. > >> Linking versioned libncurses against >> unversioned libtinfo etc. would solve this, but I don't know how it >> would to get to this point. > > I don't know much about ELF. Is it possible to remove versions from > specific symbols in the symbol table after the libraries are built, > maybe with some tool like chrpath? > > -- > Miroslav Lichvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Macro expanded on comment?
Hey all- I commented out a SOURCES line in a spec file to test something and got an interesting warning: “Macro expanded in comment on line …”. I assume it’s just that, a warning, but was kinda surprised to see a commented-out line being evaluated at all. I did some searching and came across this BZ from 2015: https://bugzilla.redhat.com/show_bug.cgi?id=1224660 that seems to suggest there’s a better way (%dnl), so if I want to comment something out instead of putting a # in front of the line, I should use %dnl? Thanks for any info! Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Pavel edition
Sorry if I missed it, but what is your script running against; are you checking the spec files in src.fedoraproject.org? I ask because I updated swift-lang to Apache-2.0[1] on Jan 23, but I see it’s still on the list of packages to be converted. [1] https://src.fedoraproject.org/rpms/swift-lang/blob/rawhide/f/swift-lang.spec On 29 Jan 2023, at 10:41, Miroslav Suchý wrote: Two weeks ago we had: * 23030 spec files in Fedora * 29390 license tags in all spec files * 22766 tags have not been converted to SPDX yet * 8986 tags can be trivially converted using `license-fedora2spdx` Today we have: * 23036 spec files in Fedora * 29407 license tags in all spec files * 22611 tags have not been converted to SPDX yet * 8885 tags can be trivially converted using `license-fedora2spdx` The list of packages needed to be converted is again here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt New version of fedora-license-data has been released. Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ has been updated too. I updated the progress in this spreadsheet: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing You converted 155 license tags in 16 days. New projection when we will be finished is 2024-08-14. Pure linear approximation. Tip: do you want to audit licenses in your tarball? Unpack the tarball and try: dnf install askalono-cli askalono crawl /path/to/directory Why Pavel edition? Because yesterday we had and presidential election in Czechia and Petr Pavel is our new president https://en.wikipedia.org/wiki/Petr_Pavel Do you hesitate how to proceed with the migration? Please follow https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
%dnl macro not available for epel-8 builds?
Hi all, I submitted a scratch build of Swift to Koji for EPEL 8 and it pretty much immediately failed, and looking at root.log I found: DEBUG util.py:443: error: line 71: Unknown tag: %dnl Source31: https://github.com/apple/swift-format/archive/swift-5.8-DEVELOPMENT-SNAPSHOT-2023-02-20-a.tar.gz#/swift-format.tar.gz Fedora and EPEL 9 builds all work, so I guess %dnl isn’t available on EPEL 8? Thanks for any info! Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
aarch64 builds failing due to use of undeclared identifier '__NR_newfstatat'
Hey all- All my swift-lang builds are failing on aarch64 due to the error above. I noticed this was referenced on the kernel mailing list: https://lore.kernel.org/all/838053e0-b186-4e9f-9668-9a3384a71...@app.fastmail.com/. It’s noted that Arnd Bergmann will be fixing it; I’m curious how long that would take to percolate down to Fedora, and would this eventually be available on all current supported versions (i.e. 39 and later). Thanks! Ron -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No matching package to install: 'pkgconfig(xorg-macros) >= 1.8
Hey all, I’m trying to get bdftopcf built for EPEL 10 but it’s failing with the aforementioned error (No matching package to install: 'pkgconfig(xorg-macros) >= 1.8). I guess I don’t understand what kind of package this is, and who to contact to see what can be done; I’ve dealt with regular packages but this seems to be a special package type. Thanks for any info, Ron -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: No matching package to install: 'pkgconfig(xorg-macros) >= 1.8
Thanks Petr!
On 11 Sep 2024, at 10:33, Petr Pisar wrote:
V Wed, Sep 11, 2024 at 08:24:41AM -0700, Ron Olson napsal(a):
Hey all, I’m trying to get bdftopcf built for EPEL 10 but it’s
failing with
the aforementioned error (No matching package to install:
'pkgconfig(xorg-macros) >= 1.8). I guess I don’t understand what
kind of
package this is, and who to contact to see what can be done; I’ve
dealt
with regular packages but this seems to be a special package type.
It's not special:
# dnf repoquery --qf '%{sourcerpm}\n' --whatprovides
'pkgconfig(xorg-macros)'
Updating and loading repositories:
Repositories loaded.
xorg-x11-util-macros-1.20.1-2.fc41.src.rpm
You want to contact xorg-x11-util-macros component owner.
-- Petr
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Email when build completes
Hey all, I _think_ I remember that I’d get an email when a build submitted to koji completed, regardless of whether it was scratch or not. Am I remembering that correctly and if so, is it still possible to get them? Thanks for any info! Ron-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Email when build completes
Thanks Gary, is there any documentation on how the rules work? I _think_ I created the appropriate rule but I haven’t received any notification and it’s likely I just did it wrong. On 13 Sep 2024, at 11:00, Gary Buhrmaster wrote: On Fri, Sep 13, 2024 at 3:40 PM Ron Olson wrote: Hey all, I think I remember that I’d get an email when a build submitted to koji completed, regardless of whether it was scratch or not. Am I remembering that correctly and if so, is it still possible to get them? Thanks for any info! Yes, you can get them. You have to set up the appropriate notifications at: https://notifications.fedoraproject.org/ The old notification system was retired about a year ago (I think?), and one needed to create new rules to continue to get notifications. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Email when build completes
The reason why I was wondering about documentation is because I feel like I didn’t set it up right insofar as I haven’t gotten any emails yet from my koji builds. :\ On 14 Sep 2024, at 2:19, Sandro wrote: On 13-09-2024 18:26, Ron Olson wrote: Thanks Gary, is there any documentation on how the rules work? I _think_ I created the appropriate rule but I haven’t received any notification and it’s likely I just did it wrong. I have set "Tracking Rule" to "My Events" with "Applications" set to "Koji". There are probably other options like "Artifacts by user". But that rule definition works for me. However, yesterday afternoon (UTC+2), I noticed quite some delay in the messages being delivered. Some arrived only an hour after the build job was actually finished. So, there's that as well. -- Sandro -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Rawhide Docker image not working
Hey all- I was trying to do a build with the Rawhide Docker image and any attempt to use dnf results in: `Downloading successful, but checksum doesn't match. Calculated: 730609d….` This prevents anything being installed via `dnf`. Just letting you know, Ron-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Flock CFP: Language SIGs discussion
There isn’t a SIG, and I don’t know if there’s any interest really, but I’d be happy to tell my tales of packaging Swift for Fedora. :\ Ron On 5 Jul 2023, at 1:22, Jens-Ulrik Petersen wrote: I have submitted a Flock proposal to have a common discussion session for (modern) Language SIGs. I think for this to be successful we need representatives from various Language SIGs to be there (Rust, Haskell, OCaml, Golang and of course Python and older ecosystems like Perl, R, TeX come to mind immediately - surely there are more). Language packaging experts are also welcome of course independently or affiliated to one or more language SIGs. Of course I also hope there will be broad attendance by interested contributors. The idea is to talk about common and distinct problems faced, both to learn from each other and to come up with practical ideas and plans for generally easing Fedora's mass packaging efforts. If you plan to be at Flock and are willing and able to represent your Language SIG at this Flock session do please reply or reach out to me. I think each SIG could do a brief presentation there to kick off the dialogue. Thanks, Jens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Package fails to build for aarch64, works for x86_64
Hey all- I was trying to submit the released version of Swift 5.9 to Fedora but I get a build failure only for the aarch64 platform for Rawhide and F39: https://koji.fedoraproject.org/koji/buildinfo?buildID=2291751 (F39) https://koji.fedoraproject.org/koji/buildinfo?buildID=2291750 (Rawhide/F40) While it compiled for both fine on F38: https://koji.fedoraproject.org/koji/buildinfo?buildID=2291752 What is the rule/advice around a situation like this insofar as should I release it for the current platforms (F38,F37,EPEL9) and try to figure out what’s going on with the aarch64 build, or should it be an all-or-nothing, release to every platform or none at all? I’d personally lean towards trying to provide the new shiny where possible, but I can see making a case for holding off due to F39 coming down the road. Complicating all this is trying to gauge interest in there being an aarch64 version of Swift for Fedora. Could I, possibly, temporarily drop support for aarch64 in the spec file for 5.9 so all versions of x86_64 can get it, and then re-enable it for if/when I figure out what’s going on with the aarch64 version? The funny thing is that Apple has already started providing development versions of Swift 5.10 and it does, in fact, build on both x86_64 and aarch64. Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Package fails to build for aarch64, works for x86_64
> Are upstream responsive to issues in general, and in particular this > case which is not the current version? I mean to say, do you think > they'd provide a fix very quickly if you asked them to look at it? > Sorry for the confusion, 5.9 is the current version, it was released on Monday; I wanted to get it built and Fedora as soon as possible as part of Fedora’s “First” principle. :) My guess is the response will be “Pull requests welcome!”; I don’t know if they try to support Linux outside of the x86_64 architecture. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Package fails to build for aarch64, works for x86_64
Right, I was leaning in that direction regardless, if only because it means keeping track of what-has-what easier. :) On 21 Sep 2023, at 9:56, Adam Williamson wrote: On Thu, 2023-09-21 at 09:24 -0500, Ron Olson wrote: Could I, possibly, temporarily drop support for aarch64 in the spec file for 5.9 so all versions of x86_64 can get it, and then re-enable it for if/when I figure out what’s going on with the aarch64 version? Please don't do this. It's very unfriendly to the other arch. In case you're not aware, if you do this, the arch does not keep the previous version of the package in its repo - the package disappears from the repo entirely. For stable releases this isn't *so* bad because it's at least still present in the frozen release repo, but for development releases, that means the package is completely gone from that release for new installs. aarch64 is one of our primary arches. If a package is in Fedora and not clearly entirely useless on that arch, it should build for that arch, and if it doesn't, that needs to be fixed. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Package fails to build for aarch64, works for x86_64
I’m trying to correlate the two; the first was a warning when using Swift, and it was on both intel and aarch64, while in this new situation it can’t even build Swift properly without the crash. :\ On 22 Sep 2023, at 7:02, Richard W.M. Jones wrote: On Thu, Sep 21, 2023 at 03:39:21PM +0100, Richard W.M. Jones wrote: I am doing a build locally myself to see if it is reproducible. It is indeed reproducible (albeit the build took ~ 24 hours). I have a coredump and stack trace if that's helpful? Peter mentioned this bug which does seem to be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=2203541 I'll add the details there in a moment. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide
This is the first time I’ve heard of buildflags.md; where might I find this file? On 26 Sep 2023, at 12:21, Florian Weimer wrote: redhat-rpm-config-267-1.fc40 activates the first phase of compiler flags to avoid regressions in the Fedora C99 port. Implicit ints and implicit function declarations will be rejected by default. The recommended way to opt out is to set %build_type_safety_c to 0. See the buildflags.md documentation. I tried very hard to bring the number of build failures to 0, but in the end, every time I got close, some other package popped up that failed to build. So I have now made the switch in the knowledge that some packages will still fail to build. The discussion regarding this topic at the GNU Tools Cauldron last weekend was quite positive, and it is likely that GCC 14 will make a similar change by default. 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, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide
I mean this sincerely: Where is the excellent documentation? I admit that I’ve been frustrated that web searches leads me all over the place, sometimes the documentation is obsolete, or it’s someone’s blog post, etc. I’ve been surprised again and again there’s a macro for this or that which could have made the job much easier, but I had no idea until I asked here or in IRC. On 27 Sep 2023, at 11:52, Carlos O'Donell wrote: On 9/27/23 12:47, Richard W.M. Jones wrote: On Wed, Sep 27, 2023 at 11:22:04AM -0500, Ron Olson wrote: This is the first time I’ve heard of buildflags.md; where might I find this file? $ ls -l -h /usr/share/doc/redhat-rpm-config/buildflags.md -rw-r--r--. 1 root root 28K Feb 28 2023 /usr/share/doc/redhat-rpm-config/buildflags.md (part of the redhat-rpm-config package) I didn't know it existed either :-) You have 5 years of excellent documentation by Florian and others to catch up on! :-) -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Swift on aarch64 and 39 and Rawhide...suggestions?
Hey all- I’m still having a difficult time trying to figure out what to do about this issue I’m having. Swift 5.9 was released awhile ago and I’ve been able to build it for x864_64 on all versions of Fedora (Rawhide, 39, 38, 37) just fine. On aarch64 (the only other architecture supported), it fails to build for 39 and Rawhide, where the Swift compiler crashes with an LLVM stacktrace while in the process of building the rest of the toolchain (in other words, it’s not that Swift builds and packages correctly and then doesn’t work when installed, it crashes during one of the compilation phases it uses to build the entire toolchain). I’ve been trying to troubleshoot this problem and have it seems that the issue may lay with ld-linux-aarch.so.1: [root@6ba0f8c47e54 swift-source]# lldb ./build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend (lldb) target create "./build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend" Current executable set to '/root/rpmbuild/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend' (aarch64). (lldb) ru Process 142 launched: '/root/rpmbuild/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend' (aarch64) Process 142 stopped * thread #1, name = 'swift-frontend', stop reason = exec frame #0: 0xf7fd84c0 ld-linux-aarch64.so.1`_start at dl-start.S:22 That’s as far as I’ve gotten. I not sure what the next move should be; troubleshooting core libraries is not something I’ve done before and have no idea where to start. Any help or suggestions would be greatly appreciated. I’ve been extremely busy on non-packaging things and honestly don’t really have the time to dig into this. Thanks! Ron___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
temp symlink while building spec file?
Hi all- Since Apple released Swift 5.9 it requires a previous version of Swift to build; it seems it can’t be built from scratch anymore just using the source. To make it more complicated, during compiling it’s expected that certain libraries are available specifically at /usr/lib/swift. In a container, I can symlink the necessary directory with “ln -s /usr/libexec/swift/5.8.1/lib/swift /usr/lib/swift” and Swift builds fine. This doesn’t work with Mock and I’m trying to think of a way to build Swift without introducing more patches; I’ve been able to create a patch that changes the directory it’s looking for, but at the cost of compile errors later on. Might anyone have a suggestion about what can be done within mock to minimize the changes needed to the source? I’m really hoping to avoid adding any more patches as I feel there’s already too many (8!) just to make it build successfully. I was wondering if I could submit a newer version of 5.8.1 with the symlink as part of the rpm so that it would be available going forward. This seems like the “safest” option, but before doing that I was wondering if there was a specific thing that allows this in Mock that I’m just not aware of. Thanks for any info! Ron -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Confused about what to do about a ticket
Hey all, https://bugzilla.redhat.com/show_bug.cgi?id=2114563 was reported against Swift on Rawhide. I fixed the issue and responded on 8/4 that the Koji build was successful, but I got two additional, presumably automated, notes from Ben Cotton and Miro that suggest something else needs to be done. Since this is/was a rawhide build there’s nothing to “fedpkg update” as I recall, so I guess what I’m asking is what should I do to make it clear that Swift is working for Rawhide/F37? I admit I’ve always been kind-of unsure how Rawhide works insofar as I’ve never submitted a “formal update” to it (i.e. the aforementioned “fedpkg update” command). Thanks, Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Confused about what to do about a ticket
Thanks for the info, I did just that. Do you or anyone knows if there is a webpage that describes how to handle Rawhide updates specifically? I haven’t found anything useful about what to do in this particular situation. Ron On 26 Aug 2022, at 9:04, Tom Hughes wrote: > On 26/08/2022 14:48, Ron Olson wrote: > >> https://bugzilla.redhat.com/show_bug.cgi?id=2114563 was reported against >> Swift on Rawhide. I fixed the issue and responded on 8/4 that the Koji build >> was successful, but I got two additional, presumably automated, notes from >> Ben Cotton and Miro that suggest something else needs to be done. Since this >> is/was a rawhide build there’s nothing to “fedpkg update” as I recall, so I >> guess what I’m asking is what should I do to make it clear that Swift is >> working for Rawhide/F37? I admit I’ve always been kind-of unsure how Rawhide >> works insofar as I’ve never submitted a “formal update” to it (i.e. the >> aforementioned “fedpkg update” command). > > Well it was reported before branching and you fixed it but > didn't actually close it so it looks like it is still an active > bug and hence got automatically moved to F37 and added as a > blocker to the FTBFS bug. > > If it was fixed before branching, as appears to be the case then > the fix is in F37 now so you can just close it NEXTRELEASE. > > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Confused about what to do about a ticket
Thanks for that info, I actually did not know about that particular feature of the changelog. I’ll try to use that from now on. On 26 Aug 2022, at 9:02, Vít Ondruch wrote: > If you included `Resolves: rhbz#2114563` in the changelog, the automatically > created bodhi update would resolve the ticket. Since you have not done this, > then you have to close the ticket yourself and possibly include the NVR in > 'Fixed In Versoin' field. > > > Vít > > > > Dne 26. 08. 22 v 15:48 Ron Olson napsal(a): >> Hey all, >> >> https://bugzilla.redhat.com/show_bug.cgi?id=2114563 was reported against >> Swift on Rawhide. I fixed the issue and responded on 8/4 that the Koji build >> was successful, but I got two additional, presumably automated, notes from >> Ben Cotton and Miro that suggest something else needs to be done. Since this >> is/was a rawhide build there’s nothing to “fedpkg update” as I recall, so I >> guess what I’m asking is what should I do to make it clear that Swift is >> working for Rawhide/F37? I admit I’ve always been kind-of unsure how Rawhide >> works insofar as I’ve never submitted a “formal update” to it (i.e. the >> aforementioned “fedpkg update” command). >> >> Thanks, >> >> Ron >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Troubleshooting EPEL 8 build
Hey all- I’m having an issue trying to get Swift 5.6.3 built on EPEL-8, even though it builds fine for everything else (Rawhide, F36, F35, EPEL-9): “undefined reference to 'std::__throw_bad_array_new_length()’”. https://koji.fedoraproject.org/koji/taskinfo?taskID=91757790 Never saw this issue before with previous Swift builds on EPEL-8, so I tried troubleshooting it by building it with mock, but what’s weird is that when I try building it with the various EPEL-8 flavors I have in /etc/mock, they all build fine. I noticed there’s a “epel-7-x86_64.cfg”, but no epel-8-x86_64.cfg; what is Koji using to build EPEL-8 projects? Also, on a related note, what is the protocol for having one platform fail to build, while the others do? Is it okay to submit the Fedora/EPEL-9 builds to production, or is it more of a all-or-nothing kind of thing? I’ve been taking the latter approach, but I’ve been wondering if it’s not okay to let everyone else have the latest-n-greatest, as I’ve been having a lot of trouble finding the time to troubleshoot this EPEL-8 issue. Thanks! Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
SSL CERTIFICATE_VERIFY_FAILED?
Hey all-
When trying to do a `fedpkg update`, I got this response:
```
Could not execute update: Could not generate update request: {"status":
"error", "errors": [{"location": "body", "name": "builds",
"description": "Unable to create update. [SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has
expired (_ssl.c:997)"}]}
A copy of the filled in template is saved as bodhi.template.last
```
But the update shows up on bodhi as an active update.
Is there something I can do to fix this; never seen this error before.
Thanks,
Ron___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: SSL CERTIFICATE_VERIFY_FAILED?
Thanks Kevin, much appreciated!
On 11 Sep 2022, at 14:45, Kevin Fenzi wrote:
> On Sun, Sep 11, 2022 at 12:31:34PM -0500, Ron Olson wrote:
>> Hey all-
>>
>> When trying to do a `fedpkg update`, I got this response:
>>
>> ```
>> Could not execute update: Could not generate update request: {"status":
>> "error", "errors": [{"location": "body", "name": "builds", "description":
>> "Unable to create update. [SSL: CERTIFICATE_VERIFY_FAILED] certificate
>> verify failed: certificate has expired (_ssl.c:997)"}]}
>> A copy of the filled in template is saved as bodhi.template.last
>> ```
>> But the update shows up on bodhi as an active update.
>>
>> Is there something I can do to fix this; never seen this error before.
>
> It's nothing on your end. It's server node certs on the rabbitmq cluster
> that runs fedora-messaging. ;(
>
> I've renewd those certs now and I think I fixed your updates, so it should be
> fixed.
>
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Troubleshooting EPEL 8 build
Unfortunately I can’t get that rhel+epel8 to work, as it complains
“ERROR: /etc/pki/entitlement is not a directory is
subscription-manager installed?”. I went through all the other epel-8
flavors and they _all_ work. I added this to the spec file as a test:
%if 0%{?rhel} && 0%{?rhel} == 8
BuildRequires: gcc-toolset-11
%endif
So I could try a scratch build on koji but it failed too
(https://koji.fedoraproject.org/koji/taskinfo?taskID=91951147).
Not sure how to fix this; I can’t get it to fail on any local
instance, and apparently Koji uses its own special flavor of EPEL-8 so
it’s pretty frustrating. The weird thing is that it _was_ working
before with earlier builds of Swift.
Sigh.
Ron
On 9 Sep 2022, at 8:12, Stephen Smoogen wrote:
On Fri, 9 Sept 2022 at 08:59, Ron Olson wrote:
Hey all-
I’m having an issue trying to get Swift 5.6.3 built on EPEL-8, even
though
it builds fine for everything else (Rawhide, F36, F35, EPEL-9):
“undefined
reference to 'std::__throw_bad_array_new_length()’”.
https://koji.fedoraproject.org/koji/taskinfo?taskID=91757790
Never saw this issue before with previous Swift builds on EPEL-8, so
I
tried troubleshooting it by building it with mock, but what’s weird
is that
when I try building it with the various EPEL-8 flavors I have in
/etc/mock,
they all build fine. I noticed there’s a “epel-7-x86_64.cfg”,
but no
epel-8-x86_64.cfg; what is Koji using to build EPEL-8 projects?
In order to do local mock builds of epel-8 you need to either make
some
symbolic links in /etc/mock or choose a distribution to build against:
[root@alma8-wsl2 ~]# ls -l /etc/mock/*epel-8*
-rw-r--r--. 1 root mock 251 Aug 10 08:06
/etc/mock/alma+epel-8-aarch64.cfg
-rw-r--r--. 1 root mock 251 Aug 10 08:06
/etc/mock/alma+epel-8-ppc64le.cfg
-rw-r--r--. 1 root mock 248 Aug 10 08:06
/etc/mock/alma+epel-8-x86_64.cfg
-rw-r--r--. 1 root mock 310 Aug 10 08:06
/etc/mock/centos-stream+epel-8-aarch64.cfg
-rw-r--r--. 1 root mock 310 Aug 10 08:06
/etc/mock/centos-stream+epel-8-ppc64le.cfg
-rw-r--r--. 1 root mock 307 Aug 10 08:06
/etc/mock/centos-stream+epel-8-x86_64.cfg
-rw-r--r--. 1 root mock 262 Aug 10 08:06
/etc/mock/circlelinux+epel-8-aarch64.cfg
-rw-r--r--. 1 root mock 262 Aug 10 08:06
/etc/mock/circlelinux+epel-8-ppc64le.cfg
-rw-r--r--. 1 root mock 259 Aug 10 08:06
/etc/mock/circlelinux+epel-8-x86_64.cfg
lrwxrwxrwx. 1 root root 23 Feb 25 2022 /etc/mock/epel-8-aarch64.cfg
->
alma+epel-8-aarch64.cfg
lrwxrwxrwx. 1 root root 22 Feb 25 2022 /etc/mock/epel-8-x86_64.cfg
->
alma+epel-8-x86_64.cfg
-rw-r--r--. 1 root mock 263 Aug 10 08:06
/etc/mock/oraclelinux+epel-8-aarch64.cfg
-rw-r--r--. 1 root mock 260 Aug 10 08:06
/etc/mock/oraclelinux+epel-8-x86_64.cfg
-rw-r--r--. 1 root mock 162 Aug 10 08:06
/etc/mock/rhel+epel-8-aarch64.cfg
-rw-r--r--. 1 root mock 162 Aug 10 08:06
/etc/mock/rhel+epel-8-ppc64le.cfg
-rw-r--r--. 1 root mock 160 Aug 10 08:06
/etc/mock/rhel+epel-8-s390x.cfg
-rw-r--r--. 1 root mock 161 Aug 10 08:06
/etc/mock/rhel+epel-8-x86_64.cfg
-rw-r--r--. 1 root mock 250 Aug 10 08:06
/etc/mock/rocky+epel-8-aarch64.cfg
-rw-r--r--. 1 root mock 247 Aug 10 08:06
/etc/mock/rocky+epel-8-x86_64.cfg
In my case, I chose alma+epel-8 to make the builds. Koji does not use
any
of these configs but for every build creates its own 'buildroot' and
aims
the mocks spawned against that. This makes it hard to make a 1:1 link
but
the closest would be /etc/mock/rhel+epel-8-${basearch}.cfg
My guess is that the default epel-8 libstdc is too old and you will
need to
set up the spec to use the gcc-toolset-10 or gcc-toolset-11 to get a
new
enough compiler and library to work with.
Also, on a related note, what is the protocol for having one platform
fail
to build, while the others do? Is it okay to submit the Fedora/EPEL-9
builds to production, or is it more of a all-or-nothing kind of
thing? I’ve
been taking the latter approach, but I’ve been wondering if it’s
not okay
to let everyone else have the latest-n-greatest, as I’ve been
having a lot
of trouble finding the time to troubleshoot this EPEL-8 issue.
Thanks!
Ron
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard
battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https:/
Re: Troubleshooting EPEL 8 build
Thanks for the info and yeah, that seemed to do the trick in enabling
it, but unfortunately it still works, in that I am able to build the
package successfully without errors. :\
On 13 Sep 2022, at 14:55, Neal Gompa wrote:
On Tue, Sep 13, 2022 at 3:36 PM Ron Olson
wrote:
Unfortunately I can’t get that rhel+epel8 to work, as it complains
“ERROR: /etc/pki/entitlement is not a directory is
subscription-manager installed?”. I went through all the other
epel-8 flavors and they all work. I added this to the spec file as a
test:
%if 0%{?rhel} && 0%{?rhel} == 8
BuildRequires: gcc-toolset-11
%endif
So I could try a scratch build on koji but it failed too
(https://koji.fedoraproject.org/koji/taskinfo?taskID=91951147).
Not sure how to fix this; I can’t get it to fail on any local
instance, and apparently Koji uses its own special flavor of EPEL-8
so it’s pretty frustrating. The weird thing is that it was working
before with earlier builds of Swift.
You need to enable it at the beginning of %build
%If 0%{?el8}
# Enable GCC Toolset 11
. /opt/rh/gcc-toolset-11/enable
%endif
Then it'll work.
--
真実はいつも一つ！/ 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, report it:
https://pagure.io/fedora-infrastructure/new_issue___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Koji builds by date?
Hey all- I’m trying to monitor some builds and once they’re done they disappear from “Active”, but when I switch to “All” I see, well, everything, including for previous dates. Is it possible to specify a specific date to Koji a la “Show me all builds for the specified date”? I looked at the API tab but didn’t find anything useful, though maybe I missed it. Thanks! Ron -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Koji builds by date?
Oh, awesome, thanks Dan! On 20 Jun 2024, at 11:24, Dan Horák wrote: On Thu, 20 Jun 2024 11:21:30 -0400 Ron Olson wrote: Hey all- I’m trying to monitor some builds and once they’re done they disappear from “Active”, but when I switch to “All” I see, well, everything, including for previous dates. Is it possible to specify a specific date to Koji a la “Show me all builds for the specified date”? I looked at the API tab but didn’t find anything useful, though maybe I missed it. see koji list-history --help Dan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Strange error building on Rawhide
Hey all- I’m trying to build Swift 6 on Rawhide and it looks like it gets to the very end, to the %install section, then errors out with: ``` + /usr/bin/add-determinism --brp -j4 /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is outside of $RPM_BUILD_ROOT error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) ``` Never, ever seen that particular message. I’m assuming the RPM build tools on Rawhide are newer and perhaps there’s something I should be adding to my spec file that I’m not aware of, as often is the case. :\ Thanks for any help, Ron-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Strange error building on Rawhide
Dunno if it should matter, but this is: Fedora Linux 41 (Toolbx Container Image Prerelease), running on a Sway Atomic machine (Fedora Linux 40.20240613.0 (Sway Atomic)). On 26 Jun 2024, at 10:31, Ron Olson wrote: Hey all- I’m trying to build Swift 6 on Rawhide and it looks like it gets to the very end, to the %install section, then errors out with: ``` + /usr/bin/add-determinism --brp -j4 /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is outside of $RPM_BUILD_ROOT error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) ``` Never, ever seen that particular message. I’m assuming the RPM build tools on Rawhide are newer and perhaps there’s something I should be adding to my spec file that I’m not aware of, as often is the case. :\ Thanks for any help, Ron-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Strange error building on Rawhide
Yep, same error: + /usr/bin/add-determinism --brp -j4 /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is outside of $RPM_BUILD_ROOT error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) On 26 Jun 2024, at 12:50, Michael J Gruber wrote: So you're runnning rpmbuild in a toolbox, right? Can you reproduce this with mock? [ I think we bottom post here in general, but I kept with your choice. Feel free to reorder ... ] Ron Olson venit, vidit, dixit 2024-06-26 17:35:11: Dunno if it should matter, but this is: Fedora Linux 41 (Toolbx Container Image Prerelease), running on a Sway Atomic machine (Fedora Linux 40.20240613.0 (Sway Atomic)). On 26 Jun 2024, at 10:31, Ron Olson wrote: Hey all- I’m trying to build Swift 6 on Rawhide and it looks like it gets to the very end, to the %install section, then errors out with: ``` + /usr/bin/add-determinism --brp -j4 /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is outside of $RPM_BUILD_ROOT error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) ``` Never, ever seen that particular message. I’m assuming the RPM build tools on Rawhide are newer and perhaps there’s something I should be adding to my spec file that I’m not aware of, as often is the case. :\ Thanks for any help, Ron-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Strange error building on Rawhide
Whoops, sorry, pasted the wrong thing; I’ll send an update with the mock-based error as soon as I can get access to my machine again (network problems :\ ). On 27 Jun 2024, at 9:27, Ron Olson wrote: Yep, same error: + /usr/bin/add-determinism --brp -j4 /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is outside of $RPM_BUILD_ROOT error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) On 26 Jun 2024, at 12:50, Michael J Gruber wrote: So you're runnning rpmbuild in a toolbox, right? Can you reproduce this with mock? [ I think we bottom post here in general, but I kept with your choice. Feel free to reorder ... ] Ron Olson venit, vidit, dixit 2024-06-26 17:35:11: Dunno if it should matter, but this is: Fedora Linux 41 (Toolbx Container Image Prerelease), running on a Sway Atomic machine (Fedora Linux 40.20240613.0 (Sway Atomic)). On 26 Jun 2024, at 10:31, Ron Olson wrote: Hey all- I’m trying to build Swift 6 on Rawhide and it looks like it gets to the very end, to the %install section, then errors out with: ``` + /usr/bin/add-determinism --brp -j4 /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is outside of $RPM_BUILD_ROOT error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) ``` Never, ever seen that particular message. I’m assuming the RPM build tools on Rawhide are newer and perhaps there’s something I should be adding to my spec file that I’m not aware of, as often is the case. :\ Thanks for any help, Ron-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
RPM for libblocksruntime?
Hi all- I know this has come up before, though I apologize that I couldn't find the info, but what is preventing Fedora from including "libblocksruntime" as an available RPM? Debian provides it: https://packages.debian.org/source/jessie/libblocksruntime and it's a requirement for compiling Apple's Swift programming language on Fedora. If it's just a question of somebody doing it, I'm happy to volunteer assuming there isn't some hard-block that would prevent it from being accepted. Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review Request: swift-lang (Apple's Swift programming language)
Hi all- I'm looking for a package review of Apple's Swift programming language: https://bugzilla.redhat.com/show_bug.cgi?id=1536780 I greatly appreciate any and all assistance in getting Swift available on Fedora. Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Review Request: swift-lang (Apple's Swift programming language)
I forgot to mention that I'd be willing to do a review-swap for this as well. Ron On 27 Feb 2018, at 14:08, Ron Olson wrote: Hi all- I'm looking for a package review of Apple's Swift programming language: https://bugzilla.redhat.com/show_bug.cgi?id=1536780 I greatly appreciate any and all assistance in getting Swift available on Fedora. Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: New Fedora Developer Portal release
Hi, how would I go about adding a page for Swift under Languages and Databases? I looked at "Create a new Project" but I couldn't how to create a page that would fall under that section. Ron On Fri, Jun 17, 2022 at 12:04 PM Jarek Prokop wrote: > Hi all, > > I have pushed new update for Fedora Developer Portal. > New content should be available in the coming hour or 2 with the > following changes and updates. > > New: Julia installation page: >* > > https://developer.fedoraproject.org/tech/languages/julia/julia-installation.html > > Update go package installation instructions as they were outdated: >* > https://developer.fedoraproject.org/tech/languages/go/go-packages.html >* > https://developer.fedoraproject.org/tech/languages/go/go-programs.html > > Update Java sections: >* > > https://developer.fedoraproject.org/tech/languages/java/java-build-tools-installation.html >* > > https://developer.fedoraproject.org/tech/languages/java/java-installation.html > > Update list of available Pythons in Fedora: >* > > https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html > > Regards, > Jarek > ___ > 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
Renaming a spec file
Hey all, is it possible to rename a spec file? I tried to submit a build using “swiftlang.spec” where previously it had been “swift-lang.spec”, and Koji complained that it couldn’t find swift-lang.spec when trying to build the SRPM: https://koji.fedoraproject.org/koji/taskinfo?taskID=88496417 Is there a specific procedure that needs to be done, or is this a “you-can-never-change-it” situation. Ron ___ 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: Renaming a spec file
Ah, I was afraid of that, seems like a lot of trouble to remove the “-“, but I understand why the process is necessary. On 21 Jun 2022, at 10:26, Neal Gompa wrote: > On Tue, Jun 21, 2022 at 11:25 AM Ron Olson wrote: >> >> Hey all, is it possible to rename a spec file? I tried to submit a build >> using “swiftlang.spec” where previously it had been “swift-lang.spec”, and >> Koji complained that it couldn’t find swift-lang.spec when trying to build >> the SRPM: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=88496417 >> >> Is there a specific procedure that needs to be done, or is this a >> “you-can-never-change-it” situation. >> > > IIRC, you need to do a package rename, since the tooling matches the > git repo name to the spec file name. > > > > -- > 真実はいつも一つ！/ 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 ___ 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
What to do about this Koschei email?
Hey all- Koschei is sending me an email warning me that Nethack builds started to fail in Rawhide[1], but it seems that it successfully built after that, so why is it still sending the emails? Is there something I have to acknowledge or clear to make the emails stop? Thanks, Ron [1] [https://apps.fedoraproject.org/koschei/package/nethack?collection=f37](https://apps.fedoraproject.org/koschei/package/nethack?collection=f37) ___ 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: F37 proposal: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)
I have a Pi 4 that runs Fedora just fine; I use it to build Swift (takes almost 24 hours, but ¯\_(ツ)_/¯) so what doesn’t work? What podcast was this mentioned on? On 6 Jul 2022, at 4:55, Neal Gompa wrote: > On Wed, Jul 6, 2022 at 2:49 AM Peter Boy wrote: >> >> I very much appreciate the work to support the various SBC devices like >> Raspberry Pi and workalikes. But I'm a little lost with this proposal. >> >>> Am 05.07.2022 um 23:16 schrieb Ben Cotton : >>> The work around Raspberry Pi 4 has been on going for a number of >>> years, but we've never officially supported it due to lack of >>> accelerated graphics and other key features. A few of us have led the >>> push to get the accelerated graphics work over the line upstream so it >>> now makes sense to enable this in Fedora and make support for the >>> Raspberry Pi 4 more official. >> >> Why Raspberry Pi, and that as the only model from the large number of >> comparable devices? >> >> Why not other devices, whose makers - as far as I understood the discussion >> - are far more OSS friendly or e.g. explicitly name Fedora as a recommended >> operating system? >> >> I know, Raspberry Pi is very popular. But this looks to me a bit like >> Fedora, the proverbial uninvited guest shouting "me too" from his corner. >> > > Because one of the biggest complaints we get about Fedora ARM is that > it *doesn't* work. It was even featured in a recent podcast as a > severe problem with Fedora. The Raspberry Pi is the only mass produced > ARM device everyone can get their hands on *everywhere* (when in > stock). The device has penetrated the public consciousness in a way > nothing else has. > > And make no mistake, *all* SBCs are not very good at being OSS > friendly, even *if* they mention Fedora by name. Vendors generally do > not care about mainline support, and it's usually up to *someone else* > to get it done. The Raspberry Pi has the benefit of visibility, so > people try very hard to get it done. > > > > -- > 真実はいつも一つ！/ 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 ___ 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
sys/timeb.h removed in Rawhide?
Hey all- Pretty much as the subject says, I have a compile failure on Rawhide where a cpp file references . I checked and the file is not present in Rawhide, it *is* present in Fedora 32 and Fedora 33. I haven't found any references to it being deprecated so I'm wondering why it's missing. Thanks, Ron ___ 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
Popularity contest for Fedora
Hey all, While installing Debian for setting up an appliance, I discovered they have something called a “popularity contest” that, according to my understanding, allows for package statistics to be gathered and used by the developers/packagers. Has anything like this been considered for Fedora? It would actually be kind of nice to see installation statistics of my packages, if only to determine if I’m the only one using them. :) Ron ___ 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
git clone under mock/koji builders
Hey all- I have a package that gets an artifact from a repo *and* expects to have code from a different branch in the same repo. In my spec file, I can easily get the artifact via Sources, but getting the code from the separate branch required me to execute a “git clone” then checkout the branch. This works fine until I tried doing a mock build where I ran into the issue that networking like this is apparently unavailable. I saw that I can enabled it with a command line switch, but I presume that’s not possible with koji. Is there any proper way to checkout code with git from within koji? Thanks for any info! Ron___ 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: git clone under mock/koji builders
Is it possible to clone a repo as part of a Source line? I’ve been looking and can’t find any examples. On 21 Jan 2022, at 10:34, Miro Hrončok wrote: > On 21. 01. 22 17:21, Ron Olson wrote: >> Hey all- >> >> I have a package that gets an artifact from a repo /and/ expects to have >> code from a different branch in the same repo. In my spec file, I can easily >> get the artifact via Sources, but getting the code from the separate branch >> required me to execute a “git clone” then checkout the branch. This works >> fine until I tried doing a mock build where I ran into the issue that >> networking like this is apparently unavailable. I saw that I can enabled it >> with a command line switch, but I presume that’s not possible with koji. >> >> Is there any proper way to checkout code with git from within koji? > > No. You need to add it as an extra Source. Koji builds are always offline. > > -- > 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
Incredible lag of koji notifications
Hey all, I _just_ got an email for my failed job from koji (https://koji.fedoraproject.org/koji/taskinfo?taskID=81627145). The job started (and finished) on Friday the 21st and yet I just got the email about five minutes ago. Is something going on, or is this a normal amount of time? Thanks! Ron___ 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
Weirdness with clang and stdatomic.h on Rawhide
Hey all, I’m troubleshooting an issue and came up with this sample program: https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 13, on Rawhide, won’t compile that program, while on Fedora 35 it does. The reason why is that on Rawhide, stdatomic.h exists under /usr/include/c++/12 while it does not exist on 35, so clang uses its built-in stdatomic per https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations. If it uses its internal version, the sample program compiles fine. Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 202002L”, so that means C++2b or later, not C++20. This seems to create a problem for clang which, since the file is present, wants to use it, but since it’s effectively empty due to the #ifdef, compiling of the sample program fails. Is it possible to disable clang’s use of the header file as a flag? I’ve been unable to find anything like that, and obviously renaming the header is out of the question. Also, is it correct to the setting stdatomic.h to only be used by c++2b? Thanks for any info, Ron ___ 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: Weirdness with clang and stdatomic.h on Rawhide
Well, yes and no. The code I linked to in the pastebin is what demonstrates the issue. The code in question is Apple’s libdispatch which I package separately as well as part of Swift. In that situation they’re using a C++ file that uses the underlying primitives in stdatomic in macros for their own higher-level functions, thus why stdatomic is ultimately being invoked. On 1 Feb 2022, at 3:26, Jonathan Wakely wrote: > On Tue, 1 Feb 2022 at 09:15, Jonathan Wakely wrote: >> >> On Mon, 31 Jan 2022 at 22:45, Ron Olson wrote: >>> >>> Hey all, >>> >>> I’m troubleshooting an issue and came up with this sample program: >>> https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang >>> 13, on Rawhide, won’t compile that program, while on Fedora 35 it does. >>> >>> The reason why is that on Rawhide, stdatomic.h exists under >>> /usr/include/c++/12 while it does not exist on 35, so clang uses its >>> built-in stdatomic per >>> https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations. >> >> But that's about C, not C++. >> >>> If it uses its internal version, the sample program compiles fine. >>> >>> Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > >>> 202002L”, so that means C++2b or later, not C++20. This seems to create a >>> problem for clang which, since the file is present, wants to use it, but >>> since it’s effectively empty due to the #ifdef, compiling of the sample >>> program fails. >>> >>> Is it possible to disable clang’s use of the header file as a flag? I’ve >>> been unable to find anything like that, and obviously renaming the header >>> is out of the question. Also, is it correct to the setting stdatomic.h to >>> only be used by c++2b? >> >> Yes, that's 100% correct. >> >> Clang is at fault here. does not exist in C++ up to and >> including the current C++20 standard, so Clang should not assume it's >> present or usable. >> >> In C++23 there is now a header in the C++ library for >> compatibility. That's what I added to GCC, and that's what Clang is >> now picking up. >> >> Why is C++ code in Clang using a C header that isn't part of C++? > > I think I misread, this isn't code in Clang, this is your code and > you're just using Clang, right? > > So then you can fix your code fairly easily. > ___ > 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: Weirdness with clang and stdatomic.h on Rawhide
Hi Jonathan-
The issue isn’t the variable, really, it’s the functions that are
used in the macros. I ran a scratch build on koji so you can see the
errors in question:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82338440
The build log shows the issue when trying to build block.cpp which
ultimately references the macros which reference the functions in
stdatomic:
/builddir/build/BUILD/swift-corelibs-libdispatch-swift-5.5.2-RELEASE/src/shims/lock.h:304:6:
error: use of undeclared identifier 'memory_order_release'
if (os_atomic_inc_orig(&dte->dte_value, release) == 0) {
^
/builddir/build/BUILD/swift-corelibs-libdispatch-swift-5.5.2-RELEASE/src/shims/atomic.h:143:3:
note: expanded from macro 'os_atomic_inc_orig'
os_atomic_add_orig((p), 1, m)
^
/builddir/build/BUILD/swift-corelibs-libdispatch-swift-5.5.2-RELEASE/src/shims/atomic.h:81:3:
note: expanded from macro 'os_atomic_add_orig'
_os_atomic_c11_op_orig((p), (v), m, add, +)
^
/builddir/build/BUILD/swift-corelibs-libdispatch-swift-5.5.2-RELEASE/src/shims/atomic.h:77:3:
note: expanded from macro '_os_atomic_c11_op_orig'
memory_order_##m)
^
On 1 Feb 2022, at 14:40, Jonathan Wakely wrote:
On Tue, 1 Feb 2022 at 15:00, Ron Olson wrote:
Well, yes and no. The code I linked to in the pastebin is what
demonstrates the issue. The code in question is Apple’s libdispatch
which I package separately as well as part of Swift. In that
situation they’re using a C++ file that uses the underlying
primitives in stdatomic in macros for their own higher-level
functions, thus why stdatomic is ultimately being invoked.
Does this help?
https://github.com/apple/swift-corelibs-libdispatch/compare/main...jwakely:patch-1
___
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: Weirdness with clang and stdatomic.h on Rawhide
Here’s a question: what if the following was added to stdatomic.h at the end of the file: #else #include_next #endif // C++23 Since the rest of the file is gated by C++23, this allows C++ programs that reference this header to have a chance to pick up the Clang one, if it exists. If Clang isn’t installed, it doesn’t matter insofar as the C++ program is going to fail anyway because it hasn’t explicitly set -std=c++2b. Just a thought. On 1 Feb 2022, at 14:40, Jonathan Wakely wrote: > On Tue, 1 Feb 2022 at 15:00, Ron Olson wrote: >> >> Well, yes and no. The code I linked to in the pastebin is what demonstrates >> the issue. The code in question is Apple’s libdispatch which I package >> separately as well as part of Swift. In that situation they’re using a C++ >> file that uses the underlying primitives in stdatomic in macros for their >> own higher-level functions, thus why stdatomic is ultimately being invoked. > > Does this help? > > https://github.com/apple/swift-corelibs-libdispatch/compare/main...jwakely:patch-1 > ___ > 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: Weirdness with clang and stdatomic.h on Rawhide
Oh, I forgot I could test for Clang too…I tried that fix and it works for me. :) On 4 Feb 2022, at 13:35, Jonathan Wakely wrote: > On Thu, 3 Feb 2022 at 20:27, Ron Olson wrote: >> >> Here’s a question: what if the following was added to stdatomic.h at the end >> of the file: >> >> #else >> #include_next >> #endif // C++23 >> >> Since the rest of the file is gated by C++23, this allows C++ programs that >> reference this header to have a chance to pick up the Clang one, if it >> exists. If Clang isn’t installed, it doesn’t matter insofar as the C++ >> program is going to fail anyway because it hasn’t explicitly set -std=c++2b. > > That will fail miserably with GCC, because the C library's > cannot be included in C++ (because it uses C features > that are not valid in C++). > > But I'll test: > > #elif defined __clang__ > #include_next > ___ > 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
More is not Less
Hey all- Sorry if I missed something, but under Rawhide I discovered when I tried to “more somefile.txt” I got “less” behavior, while Fedora 35 still runs more like, uh, more. I like less, but sometimes I need to use more, so having more act like less breaks some workflows. Is this the expected behavior? Ron ___ 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: More is not Less
Right, that is the issue; I was surprised to find `more` clearing the screen. I use `less` a lot, but what I like `more` for is that it essentially works like a teletypewriter of yore where I can pipe it to other things. On 18 Feb 2022, at 14:22, przemek klosowski via devel wrote: On 2/13/22 22:08, Todd Zullinger wrote: Ron Olson wrote: Sorry if I missed something, but under Rawhide I discovered when I tried to “more somefile.txt” I got “less” behavior, while Fedora 35 still runs more like, uh, more. I'm not quite sure what "less" behavior you mean, so I'm only guessing. FWIW 'less' clears the screen so I sometimes use 'more' when I want some text (e.g. a tutorial example from a man page) to remain visible on the screen after I quit reading the man page. OTOH, you can get the non-clearing behavior by doing 'less -X', so maybe alias more='less -X' is a workaround. ___ 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
CPU does not support x86-64-v2?
Hey all- I’m trying to build my packages for EPEL-9 on my up-to-date F35 machine using Mock. I checked /etc/mock but can’t find any specific epel-9 config so I went with centos-stream+epel-next-9. Okay, fine, but when I run the job, it fails immediately with the error “Fatal glibc error: CPU does not support x86-64-v2”. The machine is a VM under ESXi with the following cpu info: Architecture:x86_64 CPU op-mode(s):32-bit, 64-bit Address sizes: 42 bits physical, 48 bits virtual Byte Order:Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Vendor ID: GenuineIntel Model name:Intel(R) Xeon(R) CPU X7350 @ 2.93GHz CPU family: 6 Model: 15 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 2 Stepping:11 BogoMIPS:5851.73 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ht syscall nx lm constant_t sc arch_perfmon pebs bts nopl tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni ssse3 cx16 x2apic tsc_deadline_timer h ypervisor lahf_lm pti tsc_adjust dtherm Virtualization features: Hypervisor vendor: VMware Virtualization type: full Caches (sum of all): L1d: 256 KiB (8 instances) L1i: 256 KiB (8 instances) L2:8 MiB (2 instances) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-7 Vulnerabilities: Itlb multihit: KVM: Mitigation: VMX unsupported L1tf: Mitigation; PTE Inversion Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown Meltdown: Mitigation; PTI Spec store bypass: Vulnerable Spectre v1:Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2:Mitigation; Full generic retpoline, STIBP disabled, RSB filling Srbds: Not affected Tsx async abort: Not affected I guess there was some CPU requirement change that I didn’t catch; is this going to make creating Fedora-based VMs difficult going forward? I don’t have the money to upgrade my equipment. :( Ron ___ 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
Issue trying to install RPM packaging tools with F35?
Hey all- I’m trying to install the packaging tools in a container image of Fedora 35 and keep getting this error when it reaches the “RUN dnf install -y fedora-packager fedora-review” command: The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. [91mError: Error downloading packages: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=x86_64 [getaddrinfo() thread failed to start] [0mThe command '/bin/sh -c dnf install -y fedora-packager fedora-review' returned a non-zero code: 1 [Pipeline] } For reference, I’m using “FROM fedora:35”. Anyone seen anything similar? Thanks! Ron ___ 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
Renaming a project/package?
Hey all- To be consistent with other flavors of Linux, I’m thinking of changing the package name from “swift-lang” to “swiftlang”. I haven’t found any info about renaming an existing project/package, and was wondering what the procedures would be. Thanks! Ron ___ 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: Renaming a project/package?
Thank you Alexander, my search-engine prowess failed me here. :) Ron On 30 Sep 2021, at 15:03, Alexander Ploumistos wrote: > Hello Ron, > > On Thu, Sep 30, 2021 at 9:55 PM Ron Olson wrote: >> >> I haven’t found any info about renaming an existing project/package, and was >> wondering what the procedures would be. > > We have this: > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/ > ___ > 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
Strategy for staying on Rawhide
Hey all- I have a VM that I want to always keep on Rawhide. That was F34 until this past week or so and now I want to update it track F35. Can I basically just follow the instructions at https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ and pass it —releasever=rawhide; I did this when I went from F33 to Rawhide, but I wasn’t sure if I could do a “rawhide” to “rawhide” upgrade. Thanks! Ron ___ 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: CompilerPolicy Change (System-Wide Change proposal)
Swift (swift-lang) absolutely, positively requires clang. I tried building Swift with gcc and that is a lost weekend I’d love to get back. Ron On 23 Apr 2021, at 14:46, Florian Weimer wrote: * Gary Buhrmaster: For C/C++ projects: If the upstream has no stated preference for the compiler, the packager SHOULD use the system default compiler (i.e. GCC). If the upstream specifies a preference, in their documentation, build, or support processes, the packager SHOULD follow the direction of the upstream. Are there any upstreams that specify a preference for Clang in general? Usually it's a specific binary build of Clang, or maybe a source build with certain patches applied (and that is downloaded and built the first time the project is built, as some sort of bootstrapping step). So it's not so much “use Clang”, but “use our compiler, not the system compiler”. 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 ___ 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
Status of CMake on EPEL-8?
Hi all- I’m trying to build a package under EPEL-8[1] but it fails due to CMake being too old: CMake 3.15.1 or higher is required. You are running version 3.11.4. Is there any plans on bringing CMake up to the current version of Fedora (3.19.7) or at the very least to something >= 3.15.1? Thanks! Ron [1] https://kojipkgs.fedoraproject.org//work/tasks/3421/66973421/build.log ___ 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: Status of CMake on EPEL-8?
Hm, so does that mean it was packaged specifically for CentOS so it presumably shows up in the CentOS repos? On 30 Apr 2021, at 10:33, Michael Catanzaro wrote: On Fri, Apr 30 2021 at 10:26:49 AM -0500, Ron Olson wrote: Is there any plans on bringing CMake up to the current version of Fedora (3.19.7) or at the very least to something >= 3.15.1? Good news: looks like CentOS Stream 8 currently has CMake 3.18.2: https://git.centos.org/rpms/cmake/commits/c8s I don't know when that will reach the EPEL buildroot though. ___ 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
Building for EPEL-8 and CMake (again)
Hey all- Awhile back I asked about the status of CMake in CentOS so I could build my packages for EPEL-8; they require a version of CMake that is greater than 3.11.4 which is currently available. CentOS Stream has a later version, as does RHEL 8.4. I get that CentOS Stream is the future of CentOS, but when I run a koji build for EPEL 8 it uses CentOS 8, not CentOS Stream and thus all my builds fail. TL;DR: How can I build anything for EPEL 8 with CMake if the package is too old? Thanks! Ron ___ 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 CoreOS stable stream now rebased to Fedora 34
If I may, I think the issue is right there in the name: Fedora CoreOS. The Fedora name brings some expectations and it seems CoreOS, by its nature, can’t be at parity with the other Fedora flavors and that leads to confusion. I can attest that I was surprised when I learned Fedora CoreOS didn’t support cgroups v2 and that confused me; it’s Fedora, of course it would have the latest-n-greatest. I used CoreOS before it bought by RH, and I could accept whatever limitations it had because there were no expectations. Here’s a specialized distro that does things in its own way. I’m guessing this is laughably not possible, but I’m going to suggest anyway that maybe it be renamed either back to simply “CoreOS” or something new like “Bowler” or whatever that indicates that it is its own special thing and expectations can be set accordingly. On 20 May 2021, at 2:24, Clement Verna wrote: > On Wed, 19 May 2021 at 22:48, Joe Doss wrote: > >> On Wed, May 19, 2021 at 2:45 AM Clement Verna >>> wrote: I think this is the fundamental difference here, Fedora CoreOS does not have a version number. It has 3 streams, stable, testing and next, these streams are based on a version of Fedora Linux but that should just be a detail that most end users should not have to care about. >> >> I disagree here. Fedora CoreOS has the Fedora name in it and it should >> have the same fundamental features and changes that ship with each >> Fedora release. To say it doesn't have a base version and that users >> shouldn't care about it is pretty dismissive. >> > > Sorry if that sounded dismissive, but that's really how I feel. I recognize > that I have a bias towards thinking that most FCOS users are similar to my > profile. > I am a developer and I don't have a strong interest in the OS, I just > expect it to work and provide me the tools needed to do my job. To me > that's the beauty of FCOS, I get a solid, tested OS that get automated > updates and just works, I honestly don't care to know which version of > Fedora Linux it is based on or which features it has. I want to spin-up an > instance make sure that my application works and forget about it. > I also understand that there are other type of users that will care much > more about the base OS than me:-). > > >> Another difference is that Fedora CoreOS has automatic updates and if we want our users to trust these automatic updates we need them to be rock solid. This leads to Fedora CoreOS being more conservative on how changes are rolled out to users, taking the example rolling out cgroups v2 in the Fedora 31 time frame would have broken all users that are using Docker to run their containers and this was not acceptable :-). If some users are getting confused and get curious about why there are these differences and learn more about how Fedora CoreOS works, that's a good thing IMO :-) >> >> Confusing and frustrating your users is a bad thing. >> > >> On 5/19/21 6:54 AM, Neal Gompa wrote: >>> No. This is a cop-out and a bad answer. The reason this happened is >>> because Fedora CoreOS historically has not participated in the >>> development of Fedora Linux, including the Changes process, and >>> generally rolled back features instead of adapting with them during >>> the development cycle. >>> >>> It's not like making changes and breaking upgrades is acceptable in >>> Fedora Linux either. It's just that the Fedora CoreOS WG has not >>> participated in the main development process and rolled back changes >>> instead of adapting to them, which has frustrated pretty much >>> everyone. The containers team in particular was extremely unhappy to >>> find out cgroup v1 was still used in FCOS. I was pretty cheesed off >>> when I discovered the sqlite rpmdb feature was rolled back in FCOS. >>> >>> In general, I'm not pleased with how Fedora CoreOS does this. >>> Hopefully they will do better in the future. >> >> I'll echo Neal's sentiment here. This is a cop-out and bad answer. >> > >> It is frustrating to consume FCOS only to see features that are in the >> current release of Fedora are rolled back. Even in today's FCOS WG >> meeting I brought up adding in zswap to FCOS and it is shelved until >> Kubernetes adds for support swap enabled systems. >> >> The RHCOS and Openshift teams should be back porting these breaking >> changes, so FCOS can look to the future with Fedora. FCOS should not be >> shackled by limits imposed by RHCOS/Openshift/Kubernetes. >> >> Joe >> >> >> >> -- >> Joe Doss >> j...@solidadmin.com >> ___ >> 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/archi
Re: Building for EPEL-8 and CMake (again)
Hm, maybe it’s still rolling out? I fired up a new centos container and got: [root@4c38ec50ea30 /]# more /etc/os-release NAME="CentOS Linux" VERSION="8" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="8" PLATFORM_ID="platform:el8" PRETTY_NAME="CentOS Linux 8" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:8" HOME_URL="https://centos.org/"; BUG_REPORT_URL="https://bugs.centos.org/"; CENTOS_MANTISBT_PROJECT="CentOS-8" CENTOS_MANTISBT_PROJECT_VERSION="8" [root@4c38ec50ea30 /]# dnf install cmake Failed to set locale, defaulting to C.UTF-8 CentOS Linux 8 - AppStream 825 kB/s | 6.3 MB 00:07 CentOS Linux 8 - BaseOS 262 kB/s | 2.3 MB 00:08 CentOS Linux 8 - Extras 41 kB/s | 9.6 kB 00:00 Dependencies resolved. === PackageArchitecture Version Repository Size === Installing: cmake x86_64 3.11.4-7.el8appstream 8.1 M Installing dependencies: cmake-data noarch 3.11.4-7.el8appstream 1.3 M cmake-filesystem x86_64 3.11.4-7.el8appstream40 k cmake-rpm-macros noarch 3.11.4-7.el8appstream39 k emacs-filesystem noarch 1:26.1-5.el8baseos 69 k libuv x86_64 1:1.38.0-2.el8 appstream 151 k Transaction Summary === Install 6 Packages Total download size: 9.7 M Installed size: 29 M On 30 May 2021, at 14:13, Orion Poplawski wrote: > On 5/18/21 2:24 PM, Ron Olson wrote: >> Hey all- >> >> Awhile back I asked about the status of CMake in CentOS so I could build my >> packages for EPEL-8; they require a version of CMake that is greater > than 3.11.4 which is currently available. CentOS Stream has a later version, > as does RHEL 8.4. I get that CentOS Stream is the future of CentOS, but when > I run a koji build for EPEL 8 it uses CentOS 8, not CentOS Stream and thus > all my builds fail. > > EPEL builds against RHEL, not CentOS. Now that RHEL8.4 has been released, > cmake 3.18.2 is available in the EPEL8 buildroot. > >> TL;DR: How can I build anything for EPEL 8 with CMake if the package is > too old? > > Otherwise, someone would need to package a separate cmake3 package for EPEL > to provide a newer cmake. > > -- > 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/ ___ 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: Building for EPEL-8 and CMake (again)
Out of curiosity, what will EPEL be built on going forward, if CentOS fades away and CentOS Stream takes its place? On 1 Jun 2021, at 17:21, Neal Gompa wrote: > On Tue, Jun 1, 2021 at 6:06 PM Nico Kadel-Garcia wrote: >> >> On Tue, Jun 1, 2021 at 4:49 PM Orion Poplawski wrote: >>> >>> CentOS has not yet released 8.4. >> >> Is there any reason to think there will ever be one? I'm staring at >> the announcement of CentOS 8 Stream at >> https://blog.centos.org/2020/12/future-is-centos-stream/ , and I don't >> see any hint that 8.4 will be published as anything but a set of >> updates on top of 8.3. > > CentOS Linux 8.4 has already been confirmed to be coming. It just > takes a bit of time for them to get it ready. > > > > -- > 真実はいつも一つ！/ 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: Building for EPEL-8 and CMake (again)
Oh, so, wait, when doing an EPEL build, is it against CentOS or RHEL? Honestly I always thought CentOS was the image being using by Koji for rpm builds. On 1 Jun 2021, at 15:49, Orion Poplawski wrote: > CentOS has not yet released 8.4. > > On 6/1/21 2:45 PM, Ron Olson wrote: >> Hm, maybe it’s still rolling out? I fired up a new centos container and got: >> >> >> [root@4c38ec50ea30 /]# more /etc/os-release >> NAME="CentOS Linux" >> VERSION="8" >> ID="centos" >> ID_LIKE="rhel fedora" >> VERSION_ID="8" >> PLATFORM_ID="platform:el8" >> PRETTY_NAME="CentOS Linux 8" >> ANSI_COLOR="0;31" >> CPE_NAME="cpe:/o:centos:centos:8" >> HOME_URL="https://centos.org/ <https://centos.org/> " >> BUG_REPORT_URL="https://bugs.centos.org/ <https://bugs.centos.org/> " >> CENTOS_MANTISBT_PROJECT="CentOS-8" >> CENTOS_MANTISBT_PROJECT_VERSION="8" >> [root@4c38ec50ea30 /]# dnf install cmake >> Failed to set locale, defaulting to C.UTF-8 >> CentOS Linux 8 - AppStream 825 kB/s | 6.3 MB 00:07 >> CentOS Linux 8 - BaseOS 262 kB/s | 2.3 MB 00:08 >> CentOS Linux 8 - Extras 41 kB/s | 9.6 kB 00:00 >> Dependencies resolved. >> >> >> Package Architecture Version Repository Size >> >> Installing: >> cmake x86_64 3.11.4-7.el8 appstream 8.1 M >> Installing dependencies: >> cmake-data noarch 3.11.4-7.el8 appstream 1.3 M >> cmake-filesystem x86_64 3.11.4-7.el8 appstream 40 k >> cmake-rpm-macros noarch 3.11.4-7.el8 appstream 39 k >> emacs-filesystem noarch 1:26.1-5.el8 baseos 69 k >> libuv x86_64 1:1.38.0-2.el8 appstream 151 k >> >> >> Transaction Summary >> >> Install 6 Packages >> >> Total download size: 9.7 M >> Installed size: 29 M >> >> On 30 May 2021, at 14:13, Orion Poplawski wrote: >> >> On 5/18/21 2:24 PM, Ron Olson wrote: >> >> Hey all- >> >> Awhile back I asked about the status of CMake in CentOS so I could >> build my packages for EPEL-8; they require a version of CMake that is >> greater >> >> than 3.11.4 which is currently available. CentOS Stream has a later >> version, as does RHEL 8.4. I get that CentOS Stream is the future of >> CentOS, but when I run a koji build for EPEL 8 it uses CentOS 8, not >> CentOS Stream and thus all my builds fail. >> >> EPEL builds against RHEL, not CentOS. Now that RHEL8.4 has been released, >> cmake 3.18.2 is available in the EPEL8 buildroot. >> >> TL;DR: How can I build anything for EPEL 8 with CMake if the package >> is >> >> too old? >> >> Otherwise, someone would need to package a separate cmake3 package for >> EPEL to provide a newer cmake. >> >> -- >> 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/ <https://www.nwra.com/> >> > > > -- > 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/ ___ 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
Strange error from koji
Hey all, I’m trying to build my package for EPEL and got a strange error clang-11: error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Werror,-Wunused-command-line-argument] clang-11: error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' [-Werror,-Wunused-command-line-argument] https://kojipkgs.fedoraproject.org//work/tasks/653/69120653/build.log The relevant section of the spec file is: %build export CXX=clang++ export CC=clang %cmake -G Ninja . %cmake_build Is this a bug, or something I’m doing wrong? If it is a bug I’d be happy to file a ticket in Bugzilla, but I’m not sure which project to file it under. Ron ___ 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: Strange error from koji
Hm, I do have %global toolchain clang set, which interestingly enough was not picked up by the %cmake macro (thus my explicit setting of CXX and CC) so I guess for the time being I’ll revert to manually building without the macros. :\ On 2 Jun 2021, at 10:51, Tom Stellard wrote: > On 6/1/21 5:51 PM, Ron Olson wrote: >> Hey all, I’m trying to build my package for EPEL and got a strange error >> >> clang-11: error: argument unused during compilation: >> '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' >> [-Werror,-Wunused-command-line-argument] >> clang-11: error: argument unused during compilation: >> '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' >> [-Werror,-Wunused-command-line-argument] >> >> https://kojipkgs.fedoraproject.org//work/tasks/653/69120653/build.log >> >> The relevant section of the spec file is: >> >> %build >> export CXX=clang++ >> export CC=clang >> %cmake -G Ninja . >> %cmake_build >> >> Is this a bug, or something I’m doing wrong? If it is a bug I’d be happy to >> file a ticket in Bugzilla, but I’m not sure which project to file it under. >> > > Some of the default Fedora flags aren't supported by clang, so if you build in > clang you need to use the clang equivalents of those flags. In rawhide, > you can enable the correct flags by setting the macro: > > %global toolchain clang > > I'm not sure if this macro is supported in EPEL, though, so you may need > to manually update the flags yourself. > > -Tom > >> Ron >> ___ >> 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: Strange error from koji
https://github.com/tachoknight/libdispatch-packaging-fedora/blob/main/libdispatch.spec On 2 Jun 2021, at 12:59, Tom Stellard wrote: > On 6/2/21 10:57 AM, Ron Olson wrote: >> Hm, I do have %global toolchain clang set, which interestingly enough was >> not picked up by the %cmake macro (thus my explicit setting of CXX and CC) >> so I guess for the time being I’ll revert to manually building without the >> macros. :\ >> > > Can you show me your full spec file? > > -Tom > >> On 2 Jun 2021, at 10:51, Tom Stellard wrote: >> >> On 6/1/21 5:51 PM, Ron Olson wrote: >> >> Hey all, I’m trying to build my package for EPEL and got a strange >> error >> >> clang-11: error: argument unused during compilation: >> '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' >> [-Werror,-Wunused-command-line-argument] >> clang-11: error: argument unused during compilation: >> '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' >> [-Werror,-Wunused-command-line-argument] >> >> https://kojipkgs.fedoraproject.org//work/tasks/653/69120653/build.log >> <https://kojipkgs.fedoraproject.org//work/tasks/653/69120653/build.log> >> >> The relevant section of the spec file is: >> >> %build >> export CXX=clang++ >> export CC=clang >> %cmake -G Ninja . >> %cmake_build >> >> Is this a bug, or something I’m doing wrong? If it is a bug I’d be >> happy to file a ticket in Bugzilla, but I’m not sure which project to file >> it under. >> >> Some of the default Fedora flags aren't supported by clang, so if you >> build in >> clang you need to use the clang equivalents of those flags. In rawhide, >> you can enable the correct flags by setting the macro: >> >> %global toolchain clang >> >> I'm not sure if this macro is supported in EPEL, though, so you may need >> to manually update the flags yourself. >> >> -Tom >> >> Ron >> ___ >> 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/ >> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> <https://fedoraproject.org/wiki/Mailing_list_guidelines> >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> <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 >> <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
undefined symbol `__libc_stack_end' in F36/Rawhide
Hey all- Building swiftlang on F36/Rawhide results in a a failure that, boiled down to its essence, appears to be: /usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32 against undefined symbol `__libc_stack_end' can not be used when making a shared object; recompile with -fPIC It compiles fine on 35 so I’m guessing glibc has been updated; a bunch of web searching hasn’t come up with any useful suggestions, the one ancient Bugzilla ticket I found was not resolved. Any suggestions on what to do about this? Thanks! Ron ___ 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: undefined symbol `__libc_stack_end' in F36/Rawhide
/asan_premap_shadow.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_report.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_rtl.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_shadow_setup.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_stack.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_stats.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_suppressions.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_thread.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_win.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_interceptors_vfork.S.o lib/asan/CMakeFiles/RTAsan_dynamic.x86_64.dir/asan_new_delete.cpp.o lib/asan/CMakeFiles/RTAsan_dynamic_version_script_dummy.x86_64.dir/dummy.cpp.o lib/ubsan/CMakeFiles/RTUbsan_cxx.x86_64.dir/ubsan_handlers_cxx.cpp.o lib/ubsan/CMakeFiles/RTUbsan_cxx.x86_64.dir/ubsan_type_hash.cpp.o lib/ubsan/CMakeFiles/RTUbsan_cxx.x86_64.dir/ubsan_type_hash_itanium.cpp.o lib/ubsan/CMakeFiles/RTUbsan_cxx.x86_64.dir/ubsan_type_hash_win.cpp.o -lstdc++ -lgcc_s -lc -ldl -lrt -lm -lpthread -Wl,--allow-shlib-undefined On 9 Mar 2022, at 15:07, Ron Olson wrote: > Hey all- > > Building swiftlang on F36/Rawhide results in a a failure that, boiled down to > its essence, appears to be: > > /usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32 against > undefined symbol `__libc_stack_end' can not be used when making a shared > object; recompile with -fPIC > > It compiles fine on 35 so I’m guessing glibc has been updated; a bunch of web > searching hasn’t come up with any useful suggestions, the one ancient > Bugzilla ticket I found was not resolved. > > Any suggestions on what to do about this? > > Thanks! > > Ron ___ 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: undefined symbol `__libc_stack_end' in F36/Rawhide
I tried building on Rawhide for aarch64 and had a similar, but different error: /usr/bin/ld: /tmp/lto-llvm-759ff6.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `signgam@@GLIBC_2.17' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/lto-llvm-759ff6.o(.text.__interceptor_lgamma+0x9c): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `signgam@@GLIBC_2.17' /usr/bin/ld: final link failed: bad value On 11 Mar 2022, at 5:21, Sérgio Basto wrote: Hello, On Thu, 2022-03-10 at 09:36 +0100, Florian Weimer wrote: * Ron Olson: Building swiftlang on F36/Rawhide results in a a failure that, boiled down to its essence, appears to be: /usr/bin/ld: /tmp/lto-llvm-4fd0b1.o: relocation R_X86_64_PC32 against undefined symbol `__libc_stack_end' can not be used when making a shared object; recompile with -fPIC It compiles fine on 35 so I’m guessing glibc has been updated; a bunch of web searching hasn’t come up with any useful suggestions, the one ancient Bugzilla ticket I found was not resolved. Any suggestions on what to do about this? How is __libc_stack_end declared in the sources? This could be a Clang bug or a bug in the source package. by coincidence rawhide compose doomed since 20220309 (...) , i.e. maybe this is a serious thing and someone need to look what is happening to rawhide composes -- Sérgio M. B.___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
