Fedora-Cloud-30-20200209.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-31-20200209.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package uses Gradle (retired) to build: what to do?
Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit : > > What does it tell? To me, it says that FOSS platforms don't care > about > Java as much as they used to. We're clearly able to do stuff with Go > and Rust, which are just as "anti-distribution" as Java is (based on > what other people say). While the Go core team definitely cares little about distributions, the Go module system is enforcing similar sanity rules than us (no locked versions, semver, etc) which makes it quite a lot friendlier than Java. Any language that passed the stone age of 'it builds locally with a stash of fixed third party code of dubious origin and freshness' will be easier to distribute than Java. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Packaging of Ansible collections
Hello, Did anybody had an experience of packaging Ansible collections into an RPM? I guess if would be enough to put the files somewhere under /usr/share/ansible, but not sure. Also I'm not sure what download URL could be used. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Packaging of Ansible collections
On Sun, Feb 9, 2020 at 4:59 AM Igor Gnatenko wrote: > > Hello, > > Did anybody had an experience of packaging Ansible collections into an RPM? > > I guess if would be enough to put the files somewhere under > /usr/share/ansible, but not sure. Also I'm not sure what download URL could > be used. The most recent example of this I know of is the openshift-ansible playbook package: https://github.com/openshift/openshift-ansible/blob/release-3.11/openshift-ansible.spec But we don't have any specific guidelines for packaging playbooks and roles... -- 真実はいつも一つ!/ 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
Policy for non-responsive reviewers
Hello, I've been waiting almost 2 months for my reviewer to respond on my package request. I pinged and set needinfo some time ago, but still nothing. My package is FTBFS and FTI in F31, and I've been stuck because of this. Looking at policies, I see one for non-responsive maintainerw [1], but I don't think this really applies. There's a page about the package review process [2] which mentions several items about non-responsive *submitters*, but nothing about reviewers. There's also some mention of legal blockers, but not how to ping for clarification there. Neither the Join page [3] nor the review guidelines [4] mention anything about timelines. Now I know there's no _technical_ reason why I can't un-assign a bug, but I'd rather discuss policy here. * Who should be pinged, needinfo'd, or otherwise contacted, and after how long? * If there's a legal question, who should be pinged and when? * At what point does a packager give up and ask for another reviewer (by setting back to NEW)? [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [2] https://fedoraproject.org/wiki/Package_Review_Process [3] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers [4] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
g++ 10: static declared in extern "C" inline function
Hi, I've stumbled upon a regression, and I'm not sure this is a gcc 10 bug or not. Consider the sample program in [1], a simplification of a real case out there [2]. It fails to compile in Fedora Rawhide with the following message: /tmp/cccbVeNV.s: Assembler messages: /tmp/cccbVeNV.s:59: Error: symbol `f' is already defined The example defines two static local pointers to a callback under the same name in two different inline functions that are not static. I'm not sure whether this is entirely correct, given that the C version (removing the extern "C" declaration) throws a warning, but still, previous versions of g++ produce prefixed static symbols that don't collide, and the compilation succeeds. Thoughts? [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c [2] https://github.com/RcppCore/RcppEigen/blob/master/inst/include/RcppEigenStubs.h -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Policy for non-responsive reviewers
On Sun, Feb 9, 2020 at 6:21 AM Elliott Sales de Andrade wrote: > > Hello, > > I've been waiting almost 2 months for my reviewer to respond on my > package request. I pinged and set needinfo some time ago, but still > nothing. My package is FTBFS and FTI in F31, and I've been stuck > because of this. > > Looking at policies, I see one for non-responsive maintainerw [1], but > I don't think this really applies. There's a page about the package > review process [2] which mentions several items about non-responsive > *submitters*, but nothing about reviewers. There's also some mention > of legal blockers, but not how to ping for clarification there. > Neither the Join page [3] nor the review guidelines [4] mention > anything about timelines. > > Now I know there's no _technical_ reason why I can't un-assign a bug, > but I'd rather discuss policy here. > * Who should be pinged, needinfo'd, or otherwise contacted, and after how > long? > * If there's a legal question, who should be pinged and when? > * At what point does a packager give up and ask for another reviewer > (by setting back to NEW)? > > [1] > https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ > [2] https://fedoraproject.org/wiki/Package_Review_Process > [3] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > [4] > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ > What is the review you're waiting on? -- 真実はいつも一つ!/ 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
Re: g++ 10: static declared in extern "C" inline function
Iñaki Ucar writes: Thoughts? [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c I managed to find the part of the C++ standard that specified the semantics of extern "C" linkage, it is [dcl.link]. The term used is "language linkage". There is no such thing as an inline function in C. That code compiles C++ code with C language linkage. Reading the C++ standard,, all that the standard seems to specify is language linkage of declarations. Quoting: # Every implementation shall provide for linkage to functions written in the C # programming language, "C", and linkage to C ++ functions, "C++". # # [ Example: # complex sqrt(complex); # // C++ linkage by default # extern "C" { # double sqrt(double); # // C linkage # } # — end example ] The standard does not seem to specify the definitions of functions inside a language linkage specification. Either that is unspecified and therefore is a compiler extension; or it is clear that the only thing that belongs inside extern "C" is C code, and there's no such thing as inline functions in C, so declaring C++ code with C linkage would also be considered a compiler extension. This code compiles in gcc 9, but not in gcc 10. That's life, for compiler extensions. pgpzys8IBYkpI.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 09, 2020 10:30:41 +0100, Nicolas Mailhot via devel wrote: > Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit : > > > > What does it tell? To me, it says that FOSS platforms don't care > > about > > Java as much as they used to. We're clearly able to do stuff with Go > > and Rust, which are just as "anti-distribution" as Java is (based on > > what other people say). > > While the Go core team definitely cares little about distributions, the > Go module system is enforcing similar sanity rules than us (no locked > versions, semver, etc) which makes it quite a lot friendlier than Java. > > Any language that passed the stone age of 'it builds locally with a > stash of fixed third party code of dubious origin and freshness' will > be easier to distribute than Java. Thanks for all your comments everyone. What I deduce from here is that packaging and maintaining Gradle is quite a task, and it may not be doable (or worth doing) with our limited resources. So, to bring the thread back to the original question: what do we do? - Does anyone have experience with converting Gradle based projects to Maven? Can we use something like this in %prep, for example, or locally generate the pom files and ship them in src.rpm? https://stackoverflow.com/questions/12888490/gradle-build-gradle-to-maven-pom-xml https://docs.gradle.org/current/userguide/maven_plugin.html - If it is possible to convert from Maven poms to Gradle build files, can we do the opposite perhaps? What are our other options? (Of course, I assume bundling the Gradle binary for Fedora is out.) -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20200209.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 25 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 99/169 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200207.n.2): ID: 518918 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/518918 ID: 518955 Test: x86_64 universal install_pxeboot URL: https://openqa.fedoraproject.org/tests/518955 Old failures (same test failed in Fedora-Rawhide-20200207.n.2): ID: 518797 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/518797 ID: 518798 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518798 ID: 518800 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/518800 ID: 518805 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518805 ID: 518810 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/518810 ID: 518811 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/518811 ID: 518812 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/518812 ID: 518813 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/518813 ID: 518814 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/518814 ID: 518822 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/518822 ID: 518827 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/518827 ID: 518830 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/518830 ID: 518837 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518837 ID: 518838 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/518838 ID: 518839 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518839 ID: 518840 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/518840 ID: 518841 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/518841 ID: 518856 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/518856 ID: 518861 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518861 ID: 518865 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/518865 ID: 518867 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/518867 ID: 518874 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/518874 ID: 518876 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/518876 ID: 518877 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/518877 ID: 51 Test: x86_64 universal install_multi **GATING** URL: https://openqa.fedoraproject.org/tests/51 ID: 518889 Test: x86_64 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/518889 ID: 518890 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/518890 ID: 518891 Test: x86_64 universal install_kickstart_firewall_configured **GATING** URL: https://openqa.fedoraproject.org/tests/518891 ID: 518892 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/518892 ID: 518893 Test: x86_64 universal install_repository_http_variation **GATING** URL: https://openqa.fedoraproject.org/tests/518893 ID: 518894 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/518894 ID: 518895 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/518895 ID: 518896 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/518896 ID: 518898 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/518898 ID: 518899 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/518899 ID: 518900 Test: x86_64 uni
Fedora rawhide compose report: 20200209.n.0 changes
OLD: Fedora-Rawhide-20200207.n.2 NEW: Fedora-Rawhide-20200209.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 8 Dropped packages:7 Upgraded packages: 62 Downgraded packages: 0 Size of added packages: 9.91 MiB Size of dropped packages:5.15 MiB Size of upgraded packages: 2.90 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 122.02 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: antlr4-project-4.8-1.fc32 Summary: Parser generator (ANother Tool for Language Recognition) RPMs:antlr4 antlr4-cpp-runtime antlr4-cpp-runtime-devel antlr4-doc antlr4-javadoc antlr4-maven-plugin antlr4-runtime antlr4-runtime-test-annotation-processors antlr4-runtime-test-annotations golang-antlr4-runtime-devel mono-antlr4-runtime python3-antlr4-runtime swift-antlr4-runtime Size:9.74 MiB Package: python-textparser-0.23.0-2.fc32 Summary: Python text parser RPMs:python3-textparser Size:22.29 KiB Package: rust-dissimilar-1.0.1-1.fc32 Summary: Diff library with semantic cleanup, based on Google's diff-match-patch RPMs:rust-dissimilar+default-devel rust-dissimilar-devel Size:40.02 KiB Package: rust-retry-1.0.0-1.fc32 Summary: Utilities for retrying operations that can fail RPMs:rust-retry+default-devel rust-retry-devel Size:22.47 KiB Package: rust-rustyline-derive-0.3.0-1.fc32 Summary: Rustyline derive macros (Completer, Helper, Hinter, Highlighter) RPMs:rust-rustyline-derive+default-devel rust-rustyline-derive-devel Size:15.94 KiB Package: rust-serde_repr-0.1.5-1.fc32 Summary: Derive Serialize and Deserialize for C-like enums RPMs:rust-serde_repr+default-devel rust-serde_repr-devel Size:25.95 KiB Package: rust-serde_url_params-0.2.0-1.fc32 Summary: URL parameters serialization RPMs:rust-serde_url_params+default-devel rust-serde_url_params-devel Size:25.75 KiB Package: rust-tower-service-0.3.0-1.fc32 Summary: Asynchronous, request / response based, client or server trait RPMs:rust-tower-service+default-devel rust-tower-service-devel Size:20.34 KiB = DROPPED PACKAGES = Package: antlr4-4.5.2-8.fc31 Summary: Java parser generator RPMs:antlr4 antlr4-javadoc antlr4-maven-plugin antlr4-runtime Size:1.78 MiB Package: ndoutils-2.1.2-10.fc32 Summary: Stores all configuration and event data from Nagios in a database RPMs:ndoutils Size:1.97 MiB Package: planner2html-1.0.1-17.fc31 Summary: Convert planner files to html RPMs:planner2html Size:97.58 KiB Package: quassel-irssi-0-11.20171203git079be66.fc31 Summary: An irssi plugin to connect to quassel core RPMs:quassel-irssi Size:206.82 KiB Package: quasselc-0-10.20170111gita0a1e6b.fc32 Summary: API to access a Quassel Core in pure C RPMs:quasselc quasselc-devel Size:217.37 KiB Package: sound-theme-acoustic-1.0-15.fc32 Summary: Sound theme made on an acoustic guitar RPMs:sound-theme-acoustic Size:202.00 KiB Package: tudu-0.9.1-15.fc32 Summary: A simple, command line interface to do list application RPMs:tudu Size:709.32 KiB = UPGRADED PACKAGES = Package: asdcplib-2.10.34-1.fc32 Old package: asdcplib-2.10.32-6.fc32 Summary: AS-DCP file access libraries RPMs: asdcplib asdcplib-devel asdcplib-tools Size: 3.09 MiB Size change: 1.13 KiB Changelog: * Sat Feb 08 2020 Simone Caronni - 2.10.34-1 - Update to 2.10.34. Package: bes-3.20.6-1.fc32 Old package: bes-3.20.5-3.fc32 Summary: Back-end server software framework for OPeNDAP RPMs: bes bes-devel bes-doc Size: 316.70 MiB Size change: 5.53 MiB Changelog: * Sat Feb 08 2020 Orion Poplawski - 3.20.6-1 - Update to 3.20.6 Package: buildah-1.14.0-0.31.dev.git82ff48a.fc32 Old package: buildah-1.14.0-0.30.dev.git0a063c4.fc32 Summary: A command line tool used for creating OCI Images RPMs: buildah buildah-tests Size: 86.70 MiB Size change: 47.84 KiB Changelog: * Wed Jan 29 2020 RH Container Bot - 1.14.0-0.31.dev.git82ff48a - autobuilt 82ff48a Package: cataclysm-dda-0.D.10304-1.20200207gite7271b0.fc32 Old package: cataclysm-dda-0.D.10280-1.20200131gitbab7781.fc32 Summary: Turn-based survival game set in a post-apocalyptic world RPMs: cataclysm-dda cataclysm-dda-data cataclysm-dda-tiles cataclysm-dda-tiles-data Size: 66.70 MiB Size change: 1.69 MiB Changelog: * Fri Feb 07 2020 Artem Polishchuk - 0.D.10304-1.20200207gite7271b0 - Update to 10304 Package: ccdciel-0.9.68-2.fc32 Old package: ccdciel-0.9.65-1.fc32 Summary: CCD capture software RPMs: ccdciel Size: 25.69 MiB Size change: 8.94 MiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 0.9.65-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sat Feb 01 2020 Mattia Verga - 0.9.68-1 - U
Re: Policy for non-responsive reviewers
On Sun, Feb 9, 2020 at 4:21 AM Elliott Sales de Andrade wrote: > Looking at policies, I see one for non-responsive maintainerw [1], but > I don't think this really applies. There's a page about the package > review process [2] which mentions several items about non-responsive > *submitters*, but nothing about reviewers. There's also some mention > of legal blockers, but not how to ping for clarification there. > Neither the Join page [3] nor the review guidelines [4] mention > anything about timelines. https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews I don't know why that page is so hard to find. I have to hunt around for awhile every time I want it. Perhaps there should be a link to it from https://fedoraproject.org/wiki/Package_Review_Process ? -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for non-responsive reviewers
On Sun, Feb 9, 2020 at 5:15 PM Jerry James wrote: > > On Sun, Feb 9, 2020 at 4:21 AM Elliott Sales de Andrade > wrote: > > Looking at policies, I see one for non-responsive maintainerw [1], but > > I don't think this really applies. There's a page about the package > > review process [2] which mentions several items about non-responsive > > *submitters*, but nothing about reviewers. There's also some mention > > of legal blockers, but not how to ping for clarification there. > > Neither the Join page [3] nor the review guidelines [4] mention > > anything about timelines. > > https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews > > I don't know why that page is so hard to find. I have to hunt around > for awhile every time I want it. Perhaps there should be a link to it > from https://fedoraproject.org/wiki/Package_Review_Process ? Yes please, around "You should fix any blockers that the reviewer identifies.". Can you add the link? François > -- > Jerry James > http://www.jamezone.org/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 9, 2020 at 8:49 AM Ankur Sinha wrote: > > On Sun, Feb 09, 2020 10:30:41 +0100, Nicolas Mailhot via devel wrote: > > Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit : > > > > > > What does it tell? To me, it says that FOSS platforms don't care > > > about > > > Java as much as they used to. We're clearly able to do stuff with Go > > > and Rust, which are just as "anti-distribution" as Java is (based on > > > what other people say). > > > > While the Go core team definitely cares little about distributions, the > > Go module system is enforcing similar sanity rules than us (no locked > > versions, semver, etc) which makes it quite a lot friendlier than Java. > > > > Any language that passed the stone age of 'it builds locally with a > > stash of fixed third party code of dubious origin and freshness' will > > be easier to distribute than Java. > > Thanks for all your comments everyone. What I deduce from here is that > packaging and maintaining Gradle is quite a task, and it may not be > doable (or worth doing) with our limited resources. > > So, to bring the thread back to the original question: what do we do? > > - Does anyone have experience with converting Gradle based projects to > Maven? Can we use something like this in %prep, for example, or > locally generate the pom files and ship them in src.rpm? > > https://stackoverflow.com/questions/12888490/gradle-build-gradle-to-maven-pom-xml > https://docs.gradle.org/current/userguide/maven_plugin.html > > - If it is possible to convert from Maven poms to Gradle build files, > can we do the opposite perhaps? > > What are our other options? (Of course, I assume bundling the Gradle > binary for Fedora is out.) > One way to bootstrap getting Gradle back in Fedora is to have it packaged with a vendored set of source dependencies, and build everything from source that way. That'll make each gradle package build quite slow, but at least packaging the dependencies can be done iteratively rather than all at once. This is essentially the approach that was done for Go and some "special" Python applications. As the Fedora guidelines allow bundling provided the spec has versioned bundled() Provides, this is the fastest, most-compliant approach. -- 真実はいつも一つ!/ 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
Re: g++ 10: static declared in extern "C" inline function
On Sun, 9 Feb 2020 at 14:20, Sam Varshavchik wrote: > > Iñaki Ucar writes: > > > Thoughts? > > > > [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c > > I managed to find the part of the C++ standard that specified the semantics > of extern "C" linkage, it is [dcl.link]. The term used is "language linkage". > > There is no such thing as an inline function in C. That code compiles C++ > code with C language linkage. > > Reading the C++ standard,, all that the standard seems to specify is > language linkage of declarations. Quoting: > > # Every implementation shall provide for linkage to functions written in the C > # programming language, "C", and linkage to C ++ functions, "C++". > # > # [ Example: > # complex sqrt(complex); > # // C++ linkage by default > # extern "C" { > # double sqrt(double); > # // C linkage > # } > # — end example ] > > The standard does not seem to specify the definitions of functions inside > a language linkage specification. Either that is unspecified and therefore > is a compiler extension; or it is clear that the only thing that belongs > inside extern "C" is C code, and there's no such thing as inline functions > in C, so declaring C++ code with C linkage would also be considered a > compiler extension. > > This code compiles in gcc 9, but not in gcc 10. That's life, for compiler > extensions. So, summing up, nothing wrong with that code according to the standard. Therefore, since this is a regression that breaks previous behaviour, I'd say this is a bug in gcc, right? Iñaki ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 9, 2020 at 2:49 PM Ankur Sinha wrote: > > On Sun, Feb 09, 2020 10:30:41 +0100, Nicolas Mailhot via devel wrote: > > Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit : > > > > > > What does it tell? To me, it says that FOSS platforms don't care > > > about > > > Java as much as they used to. We're clearly able to do stuff with Go > > > and Rust, which are just as "anti-distribution" as Java is (based on > > > what other people say). > > > > While the Go core team definitely cares little about distributions, the > > Go module system is enforcing similar sanity rules than us (no locked > > versions, semver, etc) which makes it quite a lot friendlier than Java. > > > > Any language that passed the stone age of 'it builds locally with a > > stash of fixed third party code of dubious origin and freshness' will > > be easier to distribute than Java. (snip) > Thanks for all your comments everyone. What I deduce from here is that > packaging and maintaining Gradle is quite a task, and it may not be > doable (or worth doing) with our limited resources. Yeah, I don't think gradle can be maintained as a limited-resource community effort ... Mikolaj is the original maintainer, and he wrote some documentation for how to bootstrap gradle. However, he since dropped all but one of his fedora packages, and the bootstrapping process is now outdated and does not work anymore (we tried). See: https://src.fedoraproject.org/rpms/gradle/tree/f30 Additionally, gradle requires groovy to build, and groovy requires gradle to build, and gradle requires gradle to build. And both gradle and groovy are retired on f31+. So it's going to require some multi-step bootstrap to get anything off the ground again :( To make things even more interesting, new versions of gradle now also include scala and kotlin code :D > So, to bring the thread back to the original question: what do we do? > > - Does anyone have experience with converting Gradle based projects to > Maven? Can we use something like this in %prep, for example, or > locally generate the pom files and ship them in src.rpm? > > https://stackoverflow.com/questions/12888490/gradle-build-gradle-to-maven-pom-xml > https://docs.gradle.org/current/userguide/maven_plugin.html > > - If it is possible to convert from Maven poms to Gradle build files, > can we do the opposite perhaps? Yes, that's possible, and in fact, that's what a few packages already do. For example, aqute-bnd and testng are built this way (with generated or hand-ported pom.xml files included as %{SOURCEX} files, and then used as maven input). However, this is also more or less preventing us from updating these packages since we didn't do this port and have no idea how to adapt these files for new versions. > What are our other options? (Of course, I assume bundling the Gradle > binary for Fedora is out.) - Option 1: Convert package build systems from gradle to maven. Pro: Works with current packaging tools. Con: might make package updates harder. - Option 2: Bring back gradle, possibly in a multi-step bootstrapping process (like Neal outlined), with a "full-bundled" build is done first to get things off the ground, and after that, components can be de-bundled one after another. Pro: no changes necessary for packages built with gradle. Con: Lots of work packaging gradle and its ecosystem. - Option 3: Retire packages requiring gradle, and ship them as flatpaks >:-D Fabio > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Policy for non-responsive reviewers
On Sun., Feb. 9, 2020, 11:15 a.m. Jerry James, wrote: > On Sun, Feb 9, 2020 at 4:21 AM Elliott Sales de Andrade > wrote: > > Looking at policies, I see one for non-responsive maintainerw [1], but > > I don't think this really applies. There's a page about the package > > review process [2] which mentions several items about non-responsive > > *submitters*, but nothing about reviewers. There's also some mention > > of legal blockers, but not how to ping for clarification there. > > Neither the Join page [3] nor the review guidelines [4] mention > > anything about timelines. > > https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews > > I don't know why that page is so hard to find. I have to hunt around > for awhile every time I want it. Perhaps there should be a link to it > from https://fedoraproject.org/wiki/Package_Review_Process ? > Ah, thank you. Yes it would definitely be best to link it from somewhere else. Should it also be moved to policy documents at https://docs.fedoraproject.org/en-US/fesco/ (Is it a FESCo policy?) -- > Jerry James > http://www.jamezone.org/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini wrote: > > On Sun, Feb 9, 2020 at 2:49 PM Ankur Sinha wrote: > > > > On Sun, Feb 09, 2020 10:30:41 +0100, Nicolas Mailhot via devel wrote: > > > Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit : > > > > > > > > What does it tell? To me, it says that FOSS platforms don't care > > > > about > > > > Java as much as they used to. We're clearly able to do stuff with Go > > > > and Rust, which are just as "anti-distribution" as Java is (based on > > > > what other people say). > > > > > > While the Go core team definitely cares little about distributions, the > > > Go module system is enforcing similar sanity rules than us (no locked > > > versions, semver, etc) which makes it quite a lot friendlier than Java. > > > > > > Any language that passed the stone age of 'it builds locally with a > > > stash of fixed third party code of dubious origin and freshness' will > > > be easier to distribute than Java. > > (snip) > > > Thanks for all your comments everyone. What I deduce from here is that > > packaging and maintaining Gradle is quite a task, and it may not be > > doable (or worth doing) with our limited resources. > > Yeah, I don't think gradle can be maintained as a limited-resource > community effort ... Mikolaj is the original maintainer, and he wrote > some documentation for how to bootstrap gradle. However, he since > dropped all but one of his fedora packages, and the bootstrapping > process is now outdated and does not work anymore (we tried). > > See: https://src.fedoraproject.org/rpms/gradle/tree/f30 > > Additionally, gradle requires groovy to build, and groovy requires > gradle to build, and gradle requires gradle to build. And both gradle > and groovy are retired on f31+. So it's going to require some > multi-step bootstrap to get anything off the ground again :( > > To make things even more interesting, new versions of gradle now also > include scala and kotlin code :D > Do we even have recent versions of scala in Fedora? And as far as I know, Kotlin is still not in Fedora either... > > So, to bring the thread back to the original question: what do we do? > > > > - Does anyone have experience with converting Gradle based projects to > > Maven? Can we use something like this in %prep, for example, or > > locally generate the pom files and ship them in src.rpm? > > > > https://stackoverflow.com/questions/12888490/gradle-build-gradle-to-maven-pom-xml > > https://docs.gradle.org/current/userguide/maven_plugin.html > > > > - If it is possible to convert from Maven poms to Gradle build files, > > can we do the opposite perhaps? > > Yes, that's possible, and in fact, that's what a few packages already > do. For example, aqute-bnd and testng are built this way (with > generated or hand-ported pom.xml files included as %{SOURCEX} files, > and then used as maven input). However, this is also more or less > preventing us from updating these packages since we didn't do this > port and have no idea how to adapt these files for new versions. > > > What are our other options? (Of course, I assume bundling the Gradle > > binary for Fedora is out.) > > - Option 1: Convert package build systems from gradle to maven. > Pro: Works with current packaging tools. > Con: might make package updates harder. > As I think we can see here, this option doesn't really scale well and causes more problems than it solves. > - Option 2: Bring back gradle, possibly in a multi-step bootstrapping > process (like Neal outlined), with a "full-bundled" build is done > first to get things off the ground, and after that, components can be > de-bundled one after another. > Pro: no changes necessary for packages built with gradle. > Con: Lots of work packaging gradle and its ecosystem. > At least initially, it shouldn't be bad, and unbundling can be done iteratively with relatively little pain. This has the benefit of unlocking most of the JVM ecosystem for Fedora again, as Gradle has become the most popular option for building stuff on the JVM. > - Option 3: Retire packages requiring gradle, and ship them as flatpaks >:-D > I hope you're not being serious. The Java ecosystem is a lot more than just the Eclipse IDE. There's a lot of server side software, developer tools, web code, and desktop apps that use Java ecosystem software in some way. The problem is that we need to start getting people who are interested in the JVM/Java ecosystem to come together and help reboot the Java SIG, ideally as a cross-distro SIG like the Rust SIG is. How we get there? I don't know. -- 真実はいつも一つ!/ 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
Re: Package uses Gradle (retired) to build: what to do?
> netcdf-java[1] uses the Gradle build system, and is required to update hdfview[2] to the latest version. Gradle, however, was retired[3] as "out of date, broken, fails to build, basically unmaintainable". Checking the build.grade file (gradle recipe filei) of netcdf-java, is it possible to build and run it with "javac" and "java" command without "gradle"? https://github.com/Unidata/netcdf-java/blob/master/build.gradle -- Jun | He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Packaging of Ansible collections
On Sun, Feb 9, 2020 at 4:59 AM Igor Gnatenko wrote: > > Hello, > > Did anybody had an experience of packaging Ansible collections into an RPM? > > I guess if would be enough to put the files somewhere under > /usr/share/ansible, but not sure. Also I'm not sure what download URL could > be used. It's a problem. Most published ansible layouts rely on local tuning of the upstream, "reference" cookbook. Even the awx build tools rely on an internal, local playbook to set up an ansible server in a docker container for the "docker compose" based setups. It's not really *friendly* to modular, static playbook setups like RPM deployments on the ansible server. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [Retired] gstreamer & gstreamer-plugins-base
On Friday, January 31, 2020 7:58:55 AM MST Peter Robinson wrote: > Feankly if a proprietary piece of software hasn't migrated in 8+ years I > would be looking for a replacement. Proprietary software works at the speed of eventually. This is why RHEL maintains compat libraries going back a ridiculous amount of time, and why RHEL 5, for example, is still used today. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [Retired] gstreamer & gstreamer-plugins-base
On Sun, Feb 9, 2020 at 5:36 PM John M. Harris Jr wrote: > > On Friday, January 31, 2020 7:58:55 AM MST Peter Robinson wrote: > > Feankly if a proprietary piece of software hasn't migrated in 8+ years I > > would be looking for a replacement. > > Proprietary software works at the speed of eventually. This is why RHEL > maintains compat libraries going back a ridiculous amount of time, and why > RHEL 5, for example, is still used today. > At some point, someone has to push to eject button. Speaking from experience, it's rare that ISVs are willing to be proactive and move forward as the community does. The difference between FOSS ISVs and proprietary software ISVs is that the community cannot do anything to help fix software for the latter. They only move forward when forced to. I'm sorry, but it simply does not make sense to keep gstreamer0.10 in Fedora anymore. I don't say that lightly: the first package I ever contributed to Fedora was a pygtk2 application using gstreamer0.10 called oggconvert. But it is dead this days, and I retired it for Fedora 31. Nobody is caring for these things, and stuff like this is usually a source of major security issues. Even today, those people using RHEL 5 are only *now* moving to RHEL 7 because it was EOLed three years ago. Folks depending on RHEL 6 who are slow to move are starting their plans to move to RHEL 8. It is what it is. But Fedora is not RHEL. Fedora is supposed to be the place where everything happens first. And if we want RHEL releases without old, unmaintained stuff, we have to chuck it in Fedora first. -- 真実はいつも一つ!/ 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
Re: Packaging of Ansible collections
On 2/9/20 2:58 AM, Igor Gnatenko wrote: Hello, Did anybody had an experience of packaging Ansible collections into an RPM? I guess if would be enough to put the files somewhere under /usr/share/ansible, but not sure. Also I'm not sure what download URL could be used. It seems to me that "ansible-galaxy collection install" simply unpacks the tarball. So, this seems reasonable to me: Name: ansible-collection-%{namespace}-%{pkgname} Source0: https://galaxy.ansible.com/download/%{namespace}-%{pkgname}-%{version}.tar.gz %install mkdir -p %{buildroot}%{_datadir}/ansible/collections/ansible_collections/%{namespace}/%{name} tar xf %SOURCE0 -C %{buildroot}%{_datadir}/ansible/collections/ansible_collections/%{namespace}/%{pkgname} -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] 2020-02-10 @ 17:00 UTC - Fedora 32 Blocker Review Meeting
# F32 Blocker Review meeting # Date: 2020-02-10 # Time: 17:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 1 proposed Beta blocker and 2 proposed Final blockers to review, so let's have a Fedora 32 blocker review meeting tomorrow! If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F32 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good evening and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Proposal to CANCEL: 2020-02-10 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting for tomorrow. We met the last few weeks and I don't think we have any urgent business this week. There will be a blocker review meeting. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: g++ 10: static declared in extern "C" inline function
Iñaki Ucar writes: On Sun, 9 Feb 2020 at 14:20, Sam Varshavchik wrote: > > Iñaki Ucar writes: > > > Thoughts? > > > > [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c > > I managed to find the part of the C++ standard that specified the semantics > of extern "C" linkage, it is [dcl.link]. The term used is "language linkage". > > There is no such thing as an inline function in C. That code compiles C++ > code with C language linkage. > > Reading the C++ standard,, all that the standard seems to specify is > language linkage of declarations. Quoting: > > # Every implementation shall provide for linkage to functions written in the C > # programming language, "C", and linkage to C ++ functions, "C++". > # > # [ Example: > # complex sqrt(complex); > # // C++ linkage by default > # extern "C" { > # double sqrt(double); > # // C linkage > # } > # — end example ] > > The standard does not seem to specify the definitions of functions inside > a language linkage specification. Either that is unspecified and therefore > is a compiler extension; or it is clear that the only thing that belongs > inside extern "C" is C code, and there's no such thing as inline functions > in C, so declaring C++ code with C linkage would also be considered a > compiler extension. > > This code compiles in gcc 9, but not in gcc 10. That's life, for compiler > extensions. So, summing up, nothing wrong with that code according to the standard. Therefore, since this is a regression that breaks previous behaviour, I'd say this is a bug in gcc, right? No, exactly the opposite. As I wrote: > Reading the C++ standard,, all that the standard seems to specify is > language linkage of declarations. The code that fails to compile is not a declaration. It defines an inline C++ function. I find nothing in C++ standard that specifies function definitions inside linkage specifications. This is a declaration: void foo(); This is a definition: void bar() { } pgpmQbf8EyTMR.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-30-20200210.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org