Re: blocked for tag f39-updates-candidate
Ah thanks so much! This is my first time unretiring something :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
blocked for tag f39-updates-candidate
I recently requested to unretire rocm-smi, but after it was completed I tried to rebuild and I get this: BuildError: package rocm-smi is blocked for tag f39-updates-candidate See: https://koji.fedoraproject.org/koji/taskinfo?taskID=103328747 So I'm not sure if a) it was not unretired correctly, or b) I forgot to do something. Any suggestions? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
+1 Yes this has been mentioned many times on the thread. You can't say the user has consented but also have it opt-out. Saying that opt-in data isn't useful because most users won't opt-in is implying the desire of a dark pattern to encourage more data collection. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
Agreed 100%. Dark patterning or similar isn't the way to go. If telemetry is included, it should be opt-in with very clear explanation of why opt-ing in is important and beneficial. Opt-out and "by consent" are mutually exclusive in most circumstances. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
Unfortunately this might just be what happens. I know that I would personally always opt out on principle, and would vote for opt-in or dropping the proposal. I am under the impression that most Fedora users are in the same boat as me. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Anyone want to review swap? (rocm-opencl)
Thanks Luya! I've landed rocm-opencl in rawhide, with epel8/9 and Fedora 36 pending :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Anyone want to review swap? (rocm-opencl)
I'm looking to see if anyone wants to review swap with me: https://bugzilla.redhat.com/show_bug.cgi?id=2090823 Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[EPEL-devel] Thirdparty EL repo conflicting with EPEL
I made a ticket for request for advise: https://pagure.io/epel/issue/185 But I wanted to post here to give more visibility. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Interest in a ROCm SIG?
Fantastic idea, I've just created a new page. I'll update it as I have time: https://fedoraproject.org/wiki/SIGs/HC ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Interest in a ROCm SIG?
A few people contact me directly trying to run things like PyTorch, which requires large amounts of ROCm to get working (most of which Fedora does not have yet). I feel like a SIG, or at least some wiki page would help organize things a bit for those who want to tackle it but are unaware of the resources available. Also is there a better mailing list for this? I'd hate to keep spamming devel with my ROCm related interest :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: ROCm-OpenCL package
Thanks Felix, An open concern that I have been discussing with the ROCm guys is that HIP (used for things like pytorch) requires rocm-opencl source code to compile. It seems they want to go with the llvm-project approach in the longterm, having opencl, hip, and the common static lib "ROCclr" as one source tree. I was going to just package rocm-opencl as-is for now and add hip as a subpackage later. Let me know if anyone has any concerns with this idea, or if there's a better way to handle it. Thanks ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: ROCm-OpenCL package
I'm up for a review swap if there's no takers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
ROCm-OpenCL package
For anyone interested I made a review request: https://bugzilla.redhat.com/show_bug.cgi?id=2090823 I'm not 100% sure what to do with some of the debug related rpmlint errors. Any help would be much appreciated. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: NVIDIA Open-Source GPU Kernel Modules: How does that affect Fedora Linux?
As far as I know, RedHat is working with Nvidia to get this upstream and working with nouveau. I'm sure there's a bunch of challenges around that though, so I don't expect much over the next few quarters.___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: A way to prepare custom source tarballs from .spec file to improve CI experience
+1 to using an rpm macro to avoid adding an external script, if spectool can work with it. Something like: %global source0_generate_script ( \ curl ... \ rm -rf ... \ tar ... ) I'm not sure if that syntax is correct.___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Revisiting ROCm packaging
> Nice work! Thanks :) > The only x86 32-bit use I can think of would be wine if it supports ROCm. Yeah I looked into it, and it looks like rocm-runtime fails on 32bit due to some assumptions for 64bit in the code. I don't think there's too much value to 32bit, so it's not really worth trying to rework the code. > The answer in Fedora is usually: work with upstream to unbundle. If > ROCclr is used by more than one package then there's value in unbundling > it and making it a shared library. Same for the others. Yeah, upstream seems a bit uninterested. Last time I checked, you could build ROCclr independently as a static lib, but it's deprecated. I might try that when I have time, and then see how easy it is to convert to a shared lib. Thanks for the feedback ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Revisiting ROCm packaging
I made a thread late last year inquirying about interest in ROCm packaging; in that time I've introduced a few packages amd updated a few existing packages to the latest version. Right now, Fedora is just short of making good use of ROCm, as it needs a frontend like OpenCL or HIP. I have a COPR where I've been experimenting on x86_64, aarch64, and ppc64le: https://copr.fedorainfracloud.org/coprs/mystro256/rocm-opencl/ I would like to know if anyone is interested in maintaining, testing, or providing feedback on these packages. They're a bit rough around the edges, but ultimately I don't have the ability to be a primary maintainer for these. With that said, I encourage anyone to freely take my work as a starting point. I would also be intested in non-commitally helping keep packages up to date if they land in Fedora. If you missed the original thread, I am an AMD employee, but my involvement in Fedora and packaging ROCm in Fedora is completely unrelated to my employment. I've been tinkering with rocm-opencl to make it better to package and I have a few patches in my COPR that I've been informally sharing with the developers. I didn't try to enable 32bit OpenCL given that 32bit has been falling out of favour, but I don't mind attempting to build it if there's a use for it. HIP has a few more complicate issues to deal with, such as this: https://src.fedoraproject.org/rpms/clang/pull-request/156 I think the one thing that bugs me the most is the bundling. Both of them bundle a static library called "ROCclr" and some older OpenCL headers. HIP also bundles some of rocm-opencl, along with a khronos header. If anyone is interested, I would like some feedback on how to tackle this. Anyway thanks for reading :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: FESCo wants to know what you use i686 packages for
It seems like my needs are pretty common: Steam, Wine, misc games (OpenGL, SDL, maybe vulkan, XWayland). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
Quick update, I've made some new package reviews: ROCm-Device-Libs: https://bugzilla.redhat.com/show_bug.cgi?id=2044664 ROCm-CompilerSupport: https://bugzilla.redhat.com/show_bug.cgi?id=2045955 ROCm-Device-Libs is needed to update "rocm-runtime" and for ROCm-CompilerSupport. ROCm-CompilerSupport is needed to allow packaging "ROCclr" which is a common layer used for HIP and OpenCL. Hopefully, that can get the ball rolling a bit. I also have made pull requests to update hsakmt and rocm-runtime (blocked by missing ROCm-Device-Libs package): https://src.fedoraproject.org/rpms/hsakmt/pull-request/6 https://src.fedoraproject.org/rpms/rocm-runtime/pull-request/7 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: ROCm-Device-Libs packaging question
I created a new review request, hopefully that encourages some conversation on the topic :) https://bugzilla.redhat.com/show_bug.cgi?id=2044664 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
ROCm-Device-Libs packaging question
In order to update "rocm-runtime" to the latest, it requires a new package "ROCm-Device-Libs" as a build requirement. The issue is that the project installs files into /usr/amdgcn, which seems incorrect to me based on the FHS and Fedora guidelines. Here's the upstream for reference: https://github.com/RadeonOpenCompute/ROCm-Device-Libs I made a test package but to get it to pass rpmlint, I patched it to put amdgcn in "share/amdgcn" and made it a noarch package because it doesn't compile any cpu specific code. I proposed to upstream to make this change and it seems they don't agree and strongly prefer putting the files in "lib/amdgcn". It seems the files are bitcode to be used with clang, so the binaries are not traditional libraries. At the moment these files are CPU arch independent, but they said they might want to add some x86 bit code later. I guess I have a few questions: - does bitcode belong in lib? share? Does it matter if these libraries are bitcode or not? - if they were to add x86_64 bitcode, would it then belong in lib64? What about GPU related bitcode? - If no debug info is generated, does this automatically make it a noarch package? I don't think bitcode would generate debug information regardless of arch - Would lib/amdgcn would be ok if it's noarch? - is this a fesco worthy question? Thanks!___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
Yes, this can't be updated until someone packages ROCM-Device-Libs unfortunately. If anyone volunteers, I'm happy to help review. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
> On Thu, Dec 16, 2021 at 05:07:10PM -0000, Jeremy Newton wrote: > > I think that'd be awesome -- and those internal clean-ups are really > appreciated. Having the infrastructure there is nice, but I'm also curious: > are there any application-level tools that are in Fedora Linux already or > which could be packaged, to serve as a showcase for the technology? Well I think OpenCL would be a good starting point since it's been around for a while and lots of applications use it. Fedora already has some of the base components already (hsakmt, rocm-runtime, llvm). For OCL, fedora would just need: - ROCm-Device-Libs (bitcode compiled by LLVM, needed to upgrade rocm-runtime to the latest version) - ROCm-CompilerSupport (LLVM plugin, used for runtime compilation) - ROCclr (a middle layer that does the generic compute work) - ROCm-OpenCL-Runtime (the opencl frontend for rocclr) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
Yeah I think the technical leads are mostly on board with following FHS as close as possible, which is an obvious plus for Fedora. I think the biggest issue is the scale of the problem, and it almost feel likes they need to work component by component, but [2] will definitely be fixed for all components once they're done assessing everything. I think the thing I've been advocating for is to use GNUInstallDirs [4] as much as possible, which works really well with Fedora's cmake macros and other distro scripts. If you have any other complaints, please let me know, and I can try to advocate for them. Unfortunately I work on the graphics side, so I'm not well versed in the ROCm github and the known issues. [2] https://github.com/RadeonOpenCompute/rocm_smi_lib/issues/84 [4] https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Any interest in ROCm packaging?
Full disclosure, I am both a Fedora packager and an employee at AMD. To be clear, the following is not at all endorsed by my employer; my interest and use of Fedora is purely a personal hobby and I would like to keep it that way. There has been a recent effort to step up Debian packaging of ROCm, and would like to see if anyone has some interest in expanding the Fedora ROCm packages. I see there's a few packages already, and I'm hoping to help with some internal processes to make ROCm more distro friendly, such as better FHS compliance, clearer licensing, etc. Anyone interested? I would be happy to try to help or review package requests :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Firefox related unbundle?
Indeed, but they should add the provides: bundled(cubeb) in the spec Anyway, I made a review request for anyone interested: https://bugzilla.redhat.com/show_bug.cgi?id=1826034 I plan to make a pull request to Firefox later if I can get it to unbundle. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Firefox related unbundle?
Good to know, thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Firefox related unbundle?
I package dolphin-emu, which bundled libcubeb in the latest version. I've built it in rawhide and I'm trying to systematically unbundle things. Looks like cubeb is apart of the Firefox source tree (./meda/libcubeb/). Should I email gecko-bugs-nob...@fedoraproject.org or make a bug report? It looks like it's a library made to be staticly linked. Maybe a new firefox subpackage with static libraries + headers would work? I believe several packages do this already. Just throwing this out there as I'm not sure the best way to move forward. Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Some preliminary Fedora 25 stats — and future release scheduling
I feel like the batched update makes a lot of sense, providing the same amount of QA/testing time is still provided and some rules are set on what can and cannot be pushed in that update. E.g., since GTK now has a LTS model, I would assume major release updates would only ever be pushed to rawhide or pre-release branches? As well, how would this be implemented? A new branch that we push major updates to certain packages? Or will we have some core app/library maintainers (such as for GNOME or KDE) that will push one big update to testing half way through a release's life? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: C++ build errors
Thanks! I'll take a look into the port guide. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
C++ build errors
Anyone have any idea what causes these errors? Trying to update a package and it failed during a local test build in mock (f25): In file included from /usr/include/c++/6.2.1/stdlib.h:36:0, from expr.ypp:5: /usr/include/c++/6.2.1/cstdlib:124:11: error: '::div_t' has not been declared using ::div_t; ^ /usr/include/c++/6.2.1/cstdlib:125:11: error: '::ldiv_t' has not been declared using ::ldiv_t; ^~ /usr/include/c++/6.2.1/cstdlib:127:11: error: '::abort' has not been declared using ::abort; ^ /usr/include/c++/6.2.1/cstdlib:128:11: error: '::abs' has not been declared using ::abs; ^~~ /usr/include/c++/6.2.1/cstdlib:129:11: error: '::atexit' has not been declared using ::atexit; ^~ /usr/include/c++/6.2.1/cstdlib:132:11: error: '::at_quick_exit' has not been declared using ::at_quick_exit; ^ /usr/include/c++/6.2.1/cstdlib:135:11: error: '::atof' has not been declared using ::atof; ^~~~ /usr/include/c++/6.2.1/cstdlib:136:11: error: '::atoi' has not been declared using ::atoi; ^~~~ /usr/include/c++/6.2.1/cstdlib:137:11: error: '::atol' has not been declared using ::atol; ^~~~ /usr/include/c++/6.2.1/cstdlib:138:11: error: '::bsearch' has not been declared using ::bsearch; ^~~ /usr/include/c++/6.2.1/cstdlib:139:11: error: '::calloc' has not been declared using ::calloc; ^~ /usr/include/c++/6.2.1/cstdlib:140:11: error: '::div' has not been declared using ::div; ^~~ /usr/include/c++/6.2.1/cstdlib:141:11: error: '::exit' has not been declared using ::exit; ^~~~ /usr/include/c++/6.2.1/cstdlib:142:11: error: '::free' has not been declared using ::free; ^~~~ /usr/include/c++/6.2.1/cstdlib:143:11: error: '::getenv' has not been declared using ::getenv; ^~ /usr/include/c++/6.2.1/cstdlib:144:11: error: '::labs' has not been declared using ::labs; ^~~~ /usr/include/c++/6.2.1/cstdlib:145:11: error: '::ldiv' has not been declared using ::ldiv; ^~~~ /usr/include/c++/6.2.1/cstdlib:146:11: error: '::malloc' has not been declared using ::malloc; ^~ /usr/include/c++/6.2.1/cstdlib:148:11: error: '::mblen' has not been declared using ::mblen; ^ /usr/include/c++/6.2.1/cstdlib:149:11: error: '::mbstowcs' has not been declared using ::mbstowcs; ^~~~ /usr/include/c++/6.2.1/cstdlib:150:11: error: '::mbtowc' has not been declared using ::mbtowc; ^~ /usr/include/c++/6.2.1/cstdlib:152:11: error: '::qsort' has not been declared using ::qsort; ^ /usr/include/c++/6.2.1/cstdlib:155:11: error: '::quick_exit' has not been declared using ::quick_exit; ^~ /usr/include/c++/6.2.1/cstdlib:158:11: error: '::rand' has not been declared using ::rand; ^~~~ /usr/include/c++/6.2.1/cstdlib:159:11: error: '::realloc' has not been declared using ::realloc; ^~~ /usr/include/c++/6.2.1/cstdlib:160:11: error: '::srand' has not been declared using ::srand; ^ /usr/include/c++/6.2.1/cstdlib:161:11: error: '::strtod' has not been declared using ::strtod; ^~ /usr/include/c++/6.2.1/cstdlib:162:11: error: '::strtol' has not been declared using ::strtol; ^~ /usr/include/c++/6.2.1/cstdlib:163:11: error: '::strtoul' has not been declared using ::strtoul; ^~~ /usr/include/c++/6.2.1/cstdlib:164:11: error: '::system' has not been declared using ::system; ^~ /usr/include/c++/6.2.1/cstdlib:166:11: error: '::wcstombs' has not been declared using ::wcstombs; ^~~~ /usr/include/c++/6.2.1/cstdlib:167:11: error: '::wctomb' has not been declared using ::wctomb; ^~ /usr/include/c++/6.2.1/cstdlib:220:11: error: '::lldiv_t' has not been declared using ::lldiv_t; ^~~ /usr/include/c++/6.2.1/cstdlib:226:11: error: '::_Exit' has not been declared using ::_Exit; ^ /usr/include/c++/6.2.1/cstdlib:230:11: error: '::llabs' has not been declared using ::llabs; ^ /usr/include/c++/6.2.1/cstdlib:236:11: error: '::lldiv' has not been declared using ::lldiv; ^ /usr/include/c++/6.2.1/cstdlib:247:11: error: '::atoll' has not been declared using ::atoll; ^ /usr/include/c++/6.2.1/cstdlib:248:11: error: '::strtoll' has not been declared using ::strtoll; ^~~ /usr/include/c++/6.2.1/cstdlib:249:11: error: '::strtoull' has not been declared using ::strtoull; ^~~~ /usr/include/c++/6.2.1/cstdlib:251:11: error: '::strtof' has not been declared using ::strtof; ^~ /usr/include/c++/6.2.1/cstdlib:252:11: error: '::strtold' has not been declared using ::strtold; ^~~ /usr/include/c++/6.2.1/cstdlib:260:11:
Re: No arch broken dependency issue
So does exclusive arch actually block the unsupported arches come f26? The
emails are annoying but I'm more concerned that things will be broken when
branch from rawhide happens.
On Mon, Nov 14, 2016 at 6:50 AM, Pavel Raiskup <prais...@redhat.com> wrote:
> On Sunday, November 13, 2016 4:28:26 PM CET Jeremy Newton wrote:
> > Hi,
> > I was wondering if any of the RPM guru's know how to fix an issue I'm
> having.
> >
> > I keep getting this email:
> > >orthorobot has broken dependencies in the rawhide tree:
> > >On ppc64le:
> > >orthorobot-1.1-4.fc26.noarch requires love
> > >Please resolve this as soon as possible.
> >
> > This is because it's noarch that depends on "love", which doesn't
> compile on ppc64le.
> >
> > I added an exclusive arch to the spec in hopes to silence this:
> > >ExclusiveArch: %{arm} %{ix86} x86_64 %{mips} aarch64 ppc64 noarch
> >
> > Is this not sufficient anymore for noarch? Or is this a bug in buildsys?
>
> I recently filed similar thing against pungi:
> https://pagure.io/pungi-fedora/issue/87
>
> Pavel
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
No arch broken dependency issue
Hi,
I was wondering if any of the RPM guru's know how to fix an issue I'm having.
I keep getting this email:
>orthorobot has broken dependencies in the rawhide tree:
>On ppc64le:
>orthorobot-1.1-4.fc26.noarch requires love
>Please resolve this as soon as possible.
This is because it's noarch that depends on "love", which doesn't compile on
ppc64le.
I added an exclusive arch to the spec in hopes to silence this:
>ExclusiveArch: %{arm} %{ix86} x86_64 %{mips} aarch64 ppc64 noarch
Is this not sufficient anymore for noarch? Or is this a bug in buildsys?
Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 25 Beta status is GO, release on Oct 11, 2016
At risk of asking a redundant question, I'm assuming Wayland is still a go? IIRC the contingency deadline was the beta. I ask because it does not appear to be a part of the changeset, yet this FEDCo ticket seems to suggest otherwise: https://fedorahosted.org/fesco/ticket/1615 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Including tlp in Fedora Workstation by default
* Do you think that the average user with a clicking sound card or disk ** corruption when suspending would be able to make the link to this new ** package?* Even better ... the integrated mouse pointer on my external ThinkPad USB keyboard stops working if USB suspend is enabled for this device. I get this same issue with my computer, but TLP doesn't suspend input devices... or at least it should. +1 ... If the kernel isn't perfect, lets make the kernel perfect instead. Just my 2 cents. The one thing I like about TLP would be the ability to tune the machine based on power state. If the kernel or gnome or whatever can do this, I applaud it. Something like this should be default and tweak-able. This includes disk spin down time, bus powersave modes and variable writeback rates. It's quite clear that battery life sucks for the stock install... I think some initiative should be taken regardless of the method. I'm sure that laptops are the most effected by this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
