Fedora-Cloud-30-20200422.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: Python packages up for adoption
On 22. 04. 20 0:39, Adam Williamson wrote: Can someone run the handy script (wherever it is) that provides the list of things that depend on this and who maintains them? I feel like maybe some of my stuff might need some of these but I'm not sure... Since claiming the orphaned packages is one click action, I strongly suggest to actually orphan the packages. That will include them in https://churchyard.fedorapeople.org/orphans.txt -- 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
dropping NSS DBM format support in F33+
Hello, I am not sure if this deserves a Fedora Change proposal, so I'd like to hear any opinions first before proceeding with the process. NSS (the crypto library used by Firefox) historically supports 2 database formats: SQLite and DBM. The latter is considered legacy and we switched the default database format to SQLite in F28[1]. Since then I presume most of the applications have switched to the new format. Therefore we are planning to phase out the support of DBM, targetting F33+. Please let me know if there is any concern. Footnotes: [1] https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Non-responsive maintainer: mruprich (Michal Ruprich)
Hi Robbie, I'm pretty sure Michal would respond if you contacted him via email. Also Michal is far from being inactive on bugzilla and the fact that he has few open bugs does not prove otherwise. Regarding the abrt reports: I can see a lot of them are for Wireshark, but given the size of Wireshark codebase and speed of its development it would require a huge effort to fix all of them. So please contact him via email, I'm pretty sure you will find solutions for your bugs. Regards, Martin On 21/04/2020 23:32, Robbie Harwood wrote: Hi, in accordance with non-responsive maintainer policy [1], does anyone know how to contact Michal Ruprich (mruprich)? Michal, if you're still interested in maintaining your packages, please respond here and also in: https://bugzilla.redhat.com/show_bug.cgi?id=1815163 https://bugzilla.redhat.com/show_bug.cgi?id=1822646 https://bugzilla.redhat.com/show_bug.cgi?id=1822671 Required non-responsive maintainer bug: https://bugzilla.redhat.com/show_bug.cgi?id=1826528 Complete list of open bugs (32, including unaddressed abrt reports from early 2019): https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&classification=Fedora&email1=mruprich&emailassigned_to1=1&emailtype1=substring&list_id=11007173&query_format=advanced Thanks, --Robbie 1: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Automatic tools for soname bumps
Hello, first, I'm sorry for a partial screw-up of the libxc soname bump announcement. It appears I am not alone: there are a few soname bumps each month, many of them still unannounced. This raises the question: shouldn't there be some sort of automatic tool for making soname bump announcements? It seems to me that this is a thing where computers easily beat humans: query for dependent packages, and shoot their maintainers an email. Maybe something that could go in fedpkg? Whenever changed sonames are detected, hold the update aside and start ringing the alarm bells? -- Susi Lehtola Fedora Project Contributor jussileht...@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: Non-responsive maintainer: mruprich (Michal Ruprich)
On 22. 04. 20 10:21, Martin Sehnoutka wrote: Regarding the abrt reports: I can see a lot of them are for Wireshark, but given the size of Wireshark codebase and speed of its development it would require a huge effort to fix all of them. Not related to Michal at all, more general thought: If the maintain is unable (for any reason including "no time") to solve the ABRT bugzillas, they should clearly state that and close them as CANTFIX, or at least unassigned themselves. Ignoring the report for a year is not good practice. -- 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: Automatic tools for soname bumps
On 22. 04. 20 10:25, Susi Lehtola wrote: Hello, first, I'm sorry for a partial screw-up of the libxc soname bump announcement. It appears I am not alone: there are a few soname bumps each month, many of them still unannounced. I'd guess the biggest problem is that a lot of packages have soname bumps hidden by * globs. I.e. the maintainers update thei package without even realizing they've bumped. This is getting better and better now, as more packages follow the rule not to do this and use a more strict glob. This raises the question: shouldn't there be some sort of automatic tool for making soname bump announcements? It seems to me that this is a thing where computers easily beat humans: query for dependent packages, and shoot their maintainers an email. Maybe something that could go in fedpkg? Whenever changed sonames are detected, hold the update aside and start ringing the alarm bells? If somebody does this, note that there are basically 3 steps here: 1. $ repoquery --repo=rawhide --source --whatrequires 'libfoo.so.1.0()(64bit)' 2. https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-maintainers 3. Write and send e-mail. However, do you propose that this would happen automagically when the soname is bumped? What if I am already in touch with the dependent package owners? IMHO better automation would be to gate stuff at reverse rpmdeplint: https://pagure.io/fedora-ci/general/issue/46 There are 2 problems with that: - such check in the CI does not exist yet - gating is still opt-in See also: https://pagure.io/fesco/issue/2343 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-32-20200421.0 compose check report
No missing expected images. Failed openQA tests: 7/173 (x86_64) ID: 583590 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/583590 ID: 583609 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/583609 ID: 583612 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/583612 ID: 583627 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/583627 ID: 583687 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/583687 ID: 583691 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/583691 ID: 583712 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/583712 Soft failed openQA tests: 18/173 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 583572 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/583572 ID: 583573 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/583573 ID: 583581 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/583581 ID: 583584 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/583584 ID: 583608 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/583608 ID: 583629 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/583629 ID: 583633 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/583633 ID: 583636 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/583636 ID: 583637 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/583637 ID: 583664 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/583664 ID: 583667 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/583667 ID: 583675 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/583675 ID: 583678 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/583678 ID: 583684 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/583684 ID: 583703 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/583703 ID: 583720 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/583720 ID: 583739 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/583739 ID: 583741 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/583741 Passed openQA tests: 148/173 (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: Automatic tools for soname bumps
On Wed, Apr 22, 2020 at 10:55 AM Miro Hrončok wrote: > > On 22. 04. 20 10:25, Susi Lehtola wrote: > > Hello, > > > > > > first, I'm sorry for a partial screw-up of the libxc soname bump > > announcement. > > It appears I am not alone: there are a few soname bumps each month, many of > > them > > still unannounced. Hi! I'm sorry about first claiming the libxc soname bump was unannounced, I corrected that in a follow-up email. I had seen lots of broken dependencies on the old library version in fedora-health-check, and when I looked none of the dependent packages had been rebuilt - which is why I assumed the bump was unannounced. > I'd guess the biggest problem is that a lot of packages have soname bumps > hidden > by * globs. I.e. the maintainers update thei package without even realizing > they've bumped. > > This is getting better and better now, as more packages follow the rule not to > do this and use a more strict glob. I agree, this at least helps to make it not happen accidentally. For most new packages, this rule is now enforced by reviewers, so things are starting to get better :) > > This raises the question: shouldn't there be some sort of automatic tool for > > making soname bump announcements? It seems to me that this is a thing where > > computers easily beat humans: query for dependent packages, and shoot their > > maintainers an email. Maybe something that could go in fedpkg? Whenever > > changed > > sonames are detected, hold the update aside and start ringing the alarm > > bells? > > If somebody does this, note that there are basically 3 steps here: > > 1. > > $ repoquery --repo=rawhide --source --whatrequires 'libfoo.so.1.0()(64bit)' > > 2. > > https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-maintainers > > 3. > > Write and send e-mail. > > > However, do you propose that this would happen automagically when the soname > is > bumped? What if I am already in touch with the dependent package owners? I'm not sure how that could be automated, in particular the "one week in advance" aspect of the current Update Policy for soname bumps in rawhide. Some rebuilds for soname bumps might be "just fine", while others will require coordination with the owners of dependent packages (possibly due to API changes). It's impossible for any automation to figure out if an soname bump falls into the first or into the second category, so some amount of human intervention will probably always be necessary. However: I still think we could do better, and at least provide some scripts to automate the things that are possible to be automated, for example: - querying repositories for: "which packages depend on this version of the shared libraries in this package" - filling out an email template for: "hello, soname bump in libbar incoming in a week", with fooz-maintain...@fp.org of dependent foo packages in CC > IMHO better automation would be to gate stuff at reverse rpmdeplint: > >https://pagure.io/fedora-ci/general/issue/46 > > There are 2 problems with that: > > - such check in the CI does not exist yet > - gating is still opt-in > > See also: > >https://pagure.io/fesco/issue/2343 Yup, that's what I originally proposed to do ... but with taskotron being decomissioned (the machine it runs on won't be moved to the new datacenter, IIRC), that won't work. Gating updates for soname bumps should not be too hard to a thing to do (you only need to query RPM Provides before and after, and compare provides for shared libraries), and it would at least make sure nothing gets pushed without human interaction. Maybe that check could be integrated into rpminspect? Even writing a standalone check should not be that difficult (querying RPM provides and comparing strings). Fabio > -- > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Non-responsive maintainer: mruprich (Michal Ruprich)
Good point, thanks! On 22/04/2020 10:42, Miro Hrončok wrote: On 22. 04. 20 10:21, Martin Sehnoutka wrote: Regarding the abrt reports: I can see a lot of them are for Wireshark, but given the size of Wireshark codebase and speed of its development it would require a huge effort to fix all of them. Not related to Michal at all, more general thought: If the maintain is unable (for any reason including "no time") to solve the ABRT bugzillas, they should clearly state that and close them as CANTFIX, or at least unassigned themselves. Ignoring the report for a year is not good practice. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Test-Announce] Fedora 32 Candidate RC-1.5 Available Now!
But from *where* do I download the ISO ? On Wed, 22 Apr 2020 at 08:46, wrote: > According to the schedule [1], Fedora 32 Candidate RC-1.5 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Test coverage information for the current release can be seen at: > https://www.happyassassin.net/testcase_stats/32 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Summary > > The individual test result pages are: > > https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Installation > https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Base > https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Server > https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Cloud > https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Desktop > https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Security_Lab > > All RC priority test cases for each of these test pages [2] must > pass in order to meet the RC Release Criteria [3]. > > Help is available on #fedora-qa on irc.freenode.net [4], or on the > test list [5]. > > Current Blocker and Freeze Exception bugs: > http://qa.fedoraproject.org/blockerbugs/current > > [1] http://fedorapeople.org/groups/schedule/f-32/f-32-quality-tasks.html > [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan > [3] https://fedoraproject.org/wiki/Fedora_32_RC_Release_Criteria > [4] irc://irc.freenode.net/fedora-qa > [5] > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ > ___ > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Test-Announce] Fedora 32 Candidate RC-1.5 Available Now!
On Wed, Apr 22, 2020 at 11:55 AM Silvia Sánchez wrote: > > But from *where* do I download the ISO ? > > On Wed, 22 Apr 2020 at 08:46, wrote: >> […] >> You can see all results, find testing instructions and image download >> locations, and enter results on the Summary page: >> >> https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Summary >> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Test-Announce] Fedora 32 Candidate RC-1.5 Available Now!
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Summary#Downloads ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Test-Announce] Fedora 32 Candidate RC-1.5 Available Now!
Oh, great, thank you! On Wed, 22 Apr 2020 at 12:02, Artem Tim wrote: > > https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.5_Summary#Downloads > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Replace buildroot overrides with user side tags?
Yesterday I had to use that functionality for the very first time and with Mohan's comment in mind about the resource cost, I was leaning towards using buildroot overrides. I ended up creating side tags, for the simple reason that the available documentation was much more clearer. Are we supposed to clean up after ourselves, i.e. delete the side tags after submitting the updates to bodhi, or are the tags deleted automatically? If we are to delete them, at which point in the updates' life cycle is it safe to do so? After submission? When they hit stable? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Replace buildroot overrides with user side tags?
On 22. 04. 20 12:18, Alexander Ploumistos wrote: Are we supposed to clean up after ourselves, i.e. delete the side tags after submitting the updates to bodhi, or are the tags deleted automatically? If we are to delete them, at which point in the updates' life cycle is it safe to do so? After submission? When they hit stable? AFAIK You don't need to clean anything. If you had to, I'd suggest doing it after the update hits stable, co you don't delete it before that happens, only to realize you need to change something based on the update feedback. -- 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: Automatic tools for soname bumps
On 4/22/20 11:54 AM, Miro Hrončok wrote: > On 22. 04. 20 10:25, Susi Lehtola wrote: >> first, I'm sorry for a partial screw-up of the libxc soname bump >> announcement. >> It appears I am not alone: there are a few soname bumps each month, many of >> them >> still unannounced. > > I'd guess the biggest problem is that a lot of packages have soname bumps > hidden > by * globs. I.e. the maintainers update thei package without even realizing > they've bumped. > > This is getting better and better now, as more packages follow the rule not to > do this and use a more strict glob. If the updates system caught changed sonames and triggered a warning / mails to affected package maintainers, this would not be a problem. >> This raises the question: shouldn't there be some sort of automatic tool for >> making soname bump announcements? It seems to me that this is a thing where >> computers easily beat humans: query for dependent packages, and shoot their >> maintainers an email. Maybe something that could go in fedpkg? Whenever >> changed >> sonames are detected, hold the update aside and start ringing the alarm >> bells? > > If somebody does this, note that there are basically 3 steps here: > > 1. > $ repoquery --repo=rawhide --source --whatrequires 'libfoo.so.1.0()(64bit)' > > 2. > https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-maintainers > > 3. > Write and send e-mail. Three steps with manual labor instead one. A simple script could do this. > However, do you propose that this would happen automagically when the soname > is > bumped? What if I am already in touch with the dependent package owners? Then they get two emails notifying them about an upcoming soname bump. -- Susi Lehtola Fedora Project Contributor jussileht...@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: Automatic tools for soname bumps
On Wed, Apr 22, 2020 at 6:45 AM Susi Lehtola wrote: > > On 4/22/20 11:54 AM, Miro Hrončok wrote: > > On 22. 04. 20 10:25, Susi Lehtola wrote: > >> first, I'm sorry for a partial screw-up of the libxc soname bump > >> announcement. > >> It appears I am not alone: there are a few soname bumps each month, many > >> of them > >> still unannounced. > > > > I'd guess the biggest problem is that a lot of packages have soname bumps > > hidden > > by * globs. I.e. the maintainers update thei package without even realizing > > they've bumped. > > > > This is getting better and better now, as more packages follow the rule not > > to > > do this and use a more strict glob. > > If the updates system caught changed sonames and triggered a warning / mails > to > affected package maintainers, this would not be a problem. > > >> This raises the question: shouldn't there be some sort of automatic tool > >> for > >> making soname bump announcements? It seems to me that this is a thing where > >> computers easily beat humans: query for dependent packages, and shoot their > >> maintainers an email. Maybe something that could go in fedpkg? Whenever > >> changed > >> sonames are detected, hold the update aside and start ringing the alarm > >> bells? > > > > If somebody does this, note that there are basically 3 steps here: > > > > 1. > > $ repoquery --repo=rawhide --source --whatrequires 'libfoo.so.1.0()(64bit)' > > > > 2. > > https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-maintainers > > > > 3. > > Write and send e-mail. > > Three steps with manual labor instead one. A simple script could do this. > > > However, do you propose that this would happen automagically when the > > soname is > > bumped? What if I am already in touch with the dependent package owners? > > Then they get two emails notifying them about an upcoming soname bump. We used to get them with spam-o-matic[1], but that's been disabled for a few years... [1]: https://pagure.io/releng/blob/master/f/scripts/spam-o-matic -- 真実はいつも一つ！/ 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: Replace buildroot overrides with user side tags?
On Wed, Apr 22, 2020 at 12:29:23PM +0200, Miro Hrončok wrote: > On 22. 04. 20 12:18, Alexander Ploumistos wrote: > > Are we supposed to clean up after ourselves, i.e. delete the side tags > > after submitting the updates to bodhi, or are the tags deleted > > automatically? If we are to delete them, at which point in the > > updates' life cycle is it safe to do so? After submission? When they > > hit stable? > > AFAIK You don't need to clean anything. Indeed. On stable releases the side tag is removed when the update is created while on rawhide the side-tag is only removed when the update lands in the rawhide buildroot (ie: the update is pushed to stable). Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Build failure of Crawl on F32+
Hi all. Any idea about why this error comes out on F32+ and not on F31? ``` ui.cc:2086:12: error: 'iswalnum' was not declared in this scope; did you mean 'isaalnum'? 2086 | return iswalnum(c) || c == '_' || c == '-'; |^~~~ |isaalnum make: *** [Makefile:1601: ui.o] Error 1 ``` GitHub ticket: https://github.com/crawl/crawl/issues/1372 Build on F31: https://koji.fedoraproject.org/koji/taskinfo?taskID=43635124 Build on F33: https://koji.fedoraproject.org/koji/taskinfo?taskID=43636815 -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Build failure of Crawl on F32+
On Wed, 22 Apr 2020 13:00:26 +0200 Antonio Trande wrote: > Hi all. > > Any idea about why this error comes out on F32+ and not on F31? new GCC 10 and a header not included? https://en.cppreference.com/w/cpp/string/wide/iswalnum Dan > ``` > ui.cc:2086:12: error: 'iswalnum' was not declared in this scope; did > you mean 'isaalnum'? > 2086 | return iswalnum(c) || c == '_' || c == '-'; > |^~~~ > |isaalnum > make: *** [Makefile:1601: ui.o] Error 1 > ``` > > GitHub ticket: https://github.com/crawl/crawl/issues/1372 > > Build on F31: > https://koji.fedoraproject.org/koji/taskinfo?taskID=43635124 > > Build on F33: > https://koji.fedoraproject.org/koji/taskinfo?taskID=43636815 > > -- > --- > Antonio Trande > Fedora Project > mailto 'sagitter at fedoraproject dot org' > GPG key: 0x7B30EE04E576AA84 > GPG key server: https://keys.openpgp.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: Build failure of Crawl on F32+
At 12:00 on 22 Apr 2020, Antonio Trande wrote: > Hi all. > > Any idea about why this error comes out on F32+ and not on F31? > > ``` > ui.cc:2086:12: error: 'iswalnum' was not declared in this scope; did you > mean 'isaalnum'? > 2086 | return iswalnum(c) || c == '_' || c == '-'; > |^~~~ > |isaalnum > make: *** [Makefile:1601: ui.o] Error 1 > ``` Perhaps: #include ? > GitHub ticket: https://github.com/crawl/crawl/issues/1372 > > Build on F31: https://koji.fedoraproject.org/koji/taskinfo?taskID=43635124 > > Build on F33: https://koji.fedoraproject.org/koji/taskinfo?taskID=43636815 -- Mark Knoop ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++
This is a strange one: https://koji.fedoraproject.org/koji/buildinfo?buildID=1496787 (cd _build/default/src && /usr/bin/gcc -I /usr/lib64/ocaml -I /usr/lib64/ocaml/bytes -I /usr/lib64/ocaml/cudf -I /usr/lib64/ocaml/extlib -I glpk -O2 -fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -I . -DUSEGLPK -g -o removed_criteria.o -c removed_criteria.cpp) cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++ gcc src/notuptodate_criteria.o (exit 1) What I don't understand is where/what adds this flag. It doesn't appear in the upstream project, it's not anywhere in rpm --showrc, and it's not in the dist-git repo. It's not in the build tool this project uses (dune). It's like it's appearing from out of nowhere :-( Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++
On Wed, Apr 22, 2020 at 12:47:11PM +0100, Richard W.M. Jones wrote: > This is a strange one: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1496787 > > (cd _build/default/src && /usr/bin/gcc -I /usr/lib64/ocaml -I > /usr/lib64/ocaml/bytes -I /usr/lib64/ocaml/cudf -I /usr/lib64/ocaml/extlib -I > glpk -O2 -fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -g > -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC > -I . -DUSEGLPK -g -o removed_criteria.o -c removed_criteria.cpp) > cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++ > gcc src/notuptodate_criteria.o (exit 1) > > What I don't understand is where/what adds this flag. It doesn't > appear in the upstream project, it's not anywhere in rpm --showrc, and > it's not in the dist-git repo. It's not in the build tool this > project uses (dune). > > It's like it's appearing from out of nowhere :-( It turns out it comes from dune (the build tool), although I'm still unclear how and why. In any case I added a rather hacky workaround so I can get the build going again: https://src.fedoraproject.org/rpms/ocaml-mccs/c/c3dd0983c7fbecda3fb82a2bb41941308a81b714?branch=master Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-20200422.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: annobin says a lot "ICE: attempting to access a gcc command line option that is not stored in global_options"
*sigh* Sorry guys. Please try using annobin-9.21.1-fc33. This should fix the 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
Re: Automatic tools for soname bumps
On Wed, Apr 22, 2020 at 3:26 AM Susi Lehtola wrote: > > This raises the question: shouldn't there be some sort of automatic tool > for > making soname bump announcements? It seems to me that this is a thing where > computers easily beat humans: query for dependent packages, and shoot their > maintainers an email. Maybe something that could go in fedpkg? Whenever > changed > sonames are detected, hold the update aside and start ringing the alarm > bells? > This is far from automatic but this is my workflow (now with the availability of side tags): 1. Update the spec file 2. Perform a local mock build for rawhide (fedpkg mockbuild) 3. rm -f the debugsource packages because abppkgdiff has not been updated to deal with the fact we have both debuginfo and debugsource packages generated now. 4. Run fedabipkgdiff --dso-only --from fc33 /path/to/results/build 5. Nothing scary in the output (or zero diff)? fedpkg build (and sleep easy) -> DONE ELSE: 6. "$ dnf repoquery --repo=rawhide --provides " skim through the results for the important bits and then: $ dnf repoquery --repo=rawhide --source --whatrequires "" 7. Create a side-tag 8. Make sure all dependencies rebuild 9. Submit side-tag update in Bodhi. Automating 6 & 7 would be very helpful. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
What CPU extensions can we assume are available by arch?
I'm working on packaging a project that makes use of AVX/AVX2/NEON to process and improve the quality of low bitrate human speech: https://github.com/mozilla/LPCNet I'm having trouble determining what the base CPU targets for Fedora can accommodate. For example, ss it safe to assume AVX2 on x86_64? At this time upstream only supports AVX/AVX2/NEON, but if they did add support for SVE on aarch64, can I use it? What about VSX on ppc64le? It doesn't look like I have any options on s390x since the base is "-march=zEC12+" which from what I can tell doesn't support the extended intrinsics required. I found this but all the information seems to be wildly out of date and even if it wasn't it doesn't tell me what I need to know: https://fedoraproject.org/wiki/Architectures This is very much an area I'm not familiar with. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What CPU extensions can we assume are available by arch?
* Richard Shaw: > I'm working on packaging a project that makes use of AVX/AVX2/NEON to process > and > improve the quality of low bitrate human speech: > > https://github.com/mozilla/LPCNet > > I'm having trouble determining what the base CPU targets for Fedora can > accommodate. > > For example, ss it safe to assume AVX2 on x86_64? No (although the builders support it). You can assume SSE2, but nothing more recent. The glibc dynamic loader can select different library versions based on the ISA support level, but that this is more of a theory at this point because there are no useful, well-documented selection criteria. > At this time upstream only supports AVX/AVX2/NEON, but if they did add > support for SVE on aarch64, can I use it? No. I don't think the builders support it yet. > What about VSX on ppc64le? Yes, but only the parts that are in POWER8. > It doesn't look like I have any options on s390x since the base is > "-march=zEC12+" which from what I can tell doesn't support the > extended intrinsics required. Yes, vectorization is added in z13 (with more extensions in later ISAs). Red Hat Enterprise Linux 8 is built for z13, so it may make sense to have conditionals that automatically detect this. 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: What CPU extensions can we assume are available by arch?
On Wed, Apr 22, 2020 at 1:54 PM Florian Weimer wrote: > > * Richard Shaw: > > > I'm working on packaging a project that makes use of AVX/AVX2/NEON to > > process and > > improve the quality of low bitrate human speech: > > > > https://github.com/mozilla/LPCNet > > > > I'm having trouble determining what the base CPU targets for Fedora can > > accommodate. > > > > For example, ss it safe to assume AVX2 on x86_64? > > No (although the builders support it). > > You can assume SSE2, but nothing more recent. > > The glibc dynamic loader can select different library versions based on > the ISA support level, but that this is more of a theory at this point > because there are no useful, well-documented selection criteria. > > > At this time upstream only supports AVX/AVX2/NEON, but if they did add > > support for SVE on aarch64, can I use it? > > No. I don't think the builders support it yet. > > > What about VSX on ppc64le? > > Yes, but only the parts that are in POWER8. We on;y support POWER8 and later in Fedora for ppc64le. > > It doesn't look like I have any options on s390x since the base is > > "-march=zEC12+" which from what I can tell doesn't support the > > extended intrinsics required. > > Yes, vectorization is added in z13 (with more extensions in later ISAs). > Red Hat Enterprise Linux 8 is built for z13, so it may make sense to > have conditionals that automatically detect this. > > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: ProtonMail Bridge rpm build request
I'll have a look. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, April 21, 2020 5:22 PM, Maximiliano Sandoval via devel wrote: > Hi everyone, I would like to request a rpm build for protonmail-bridge, which > recently released its source at github. I have been unable to produce a build > locally for reasons I don't quite understand. There is already a build in the > aur (see PKGBUILD). > > I have only managed to determine that the build requires > > gcc, gcc-c++, gcc-go, gnome-keyring-devel, qt5-qtmultimedia-devel, > dejavu-fonts-all, libglvnd-devel, libsecret-devel, golang, make, go-rpm-macros > > > I would happily help to maintain such package, but currently I am not able to > build it. > > Best regards, > M. > > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What CPU extensions can we assume are available by arch?
W dniu 22.04.2020 o 14:52, Florian Weimer pisze: >> At this time upstream only supports AVX/AVX2/NEON, but if they did >> add support for SVE on aarch64, can I use it? > No. I don't think the builders support it yet. You can assume NEON on aarch64 as it is mandatory part. SVE is in one or two cpus so far so you can not assume it. On armhfp you have nothing. Builders have NEON but there were some armv7 cpus without NEON... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: What CPU extensions can we assume are available by arch?
* Peter Robinson: >> > What about VSX on ppc64le? >> >> Yes, but only the parts that are in POWER8. > > We on;y support POWER8 and later in Fedora for ppc64le. Yes, that's what I meant: you cannot assume POWER9 or -mfuture. (There is nothing earlier than POWER8 for ppc64le anyway, some earlier machine types were only used for the architecture bringup and do not implement the ppc64le ISA.) 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: ProtonMail Bridge rpm build request
My apologies, this is written in Go with submodules, and packaging will require more Go expertise than I possess. I imaging the release tarball, once there is one, will be simpler. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, April 22, 2020 8:02 AM, Gwyn Ciesla via devel wrote: > I'll have a look. > > -- > Gwyn Ciesla > she/her/hers > > in your fear, seek only peace > in your fear, seek only love > -d. bowie > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, April 21, 2020 5:22 PM, Maximiliano Sandoval via devel > devel@lists.fedoraproject.org wrote: > > > Hi everyone, I would like to request a rpm build for protonmail-bridge, > > which recently released its source at github. I have been unable to produce > > a build locally for reasons I don't quite understand. There is already a > > build in the aur (see PKGBUILD). > > > I have only managed to determine that the build requires > > > gcc, gcc-c++, gcc-go, gnome-keyring-devel, qt5-qtmultimedia-devel, > > dejavu-fonts-all, libglvnd-devel, libsecret-devel, golang, make, > > go-rpm-macros > > > > > > > > I would happily help to maintain such package, but currently I am not able > > to build it. > > > Best regards, > > M. > > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/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 signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Build failure of Crawl on F32+
On 22/04/20 13:34, Mark Knoop wrote: > At 12:00 on 22 Apr 2020, Antonio Trande wrote: >> Hi all. >> >> Any idea about why this error comes out on F32+ and not on F31? >> >> ``` >> ui.cc:2086:12: error: 'iswalnum' was not declared in this scope; did you >> mean 'isaalnum'? >> 2086 | return iswalnum(c) || c == '_' || c == '-'; >> |^~~~ >> |isaalnum >> make: *** [Makefile:1601: ui.o] Error 1 >> ``` > > Perhaps: > > #include > So easy... Thank you. -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB
On Thu, Mar 26, 2020, at 8:35 AM, Zbigniew Jędrzejewski-Szmek wrote: > > Relying on the target distro management stack sound nice, but is > actually problematic: how do you run the next version before you > install the next version? Sure, you can install stuff to some temporary > location and run the tools from there, but then you are running in > a very custom franken-environment. This is exactly what rpm-ostree does - it always makes a new rootfs (hardlinked) and runs scripts in there (using bubblewrap). > Such a mode of running would face > the same issue as anaconda installer: it would only get tested during > the upgrade season, languishing otherwise. You have correctly identified the rationale behind why rpm-ostree works the way it does. Every single upstream commit and every Fedora CoreOS release is gated on this working. However, we have the opposite problem in that extending this model to supporting live updates *and* this is hard: https://github.com/coreos/rpm-ostree/issues/639 As far as the database transition...today rpm-ostree generates the rpmdb server side by default, and updating it is a transactional operation (along with the rest of the transaction) so dunno, I guess at some point we'll just flip the default build-side. We may need to make it a build-time option. It would be most ideal if Fedora N-1 at least supported reading from the new format, because if e.g. one does an upgrade, then e.g. the desktop a11y stack happens to be broken and you roll back, the old rpm-ostree may fail to parse the RPM database in the new deployment root. Although, if the new rpmdb is in a different place, then maybe it will just appear to be nonexistent and I *think* that would work. This is probably best tracked in https://github.com/coreos/rpm-ostree/issues/1964 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-IoT-33-20200422.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Passed openQA tests: 8/8 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 131 MiB to 147 MiB 1 services(s) added since previous compose: zezere_ignition.service Previous test data: https://openqa.fedoraproject.org/tests/582631#downloads Current test data: https://openqa.fedoraproject.org/tests/584194#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 133 MiB to 148 MiB 1 services(s) added since previous compose: zezere_ignition.service Previous test data: https://openqa.fedoraproject.org/tests/582633#downloads Current test data: https://openqa.fedoraproject.org/tests/584196#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What CPU extensions can we assume are available by arch?
Ok, so to sum up... I can assume NEON on aarch64 and that's about it. So how do I handle this from a packaging perspective? Do I build multiple times and create optimized and non-optimized packages? and -AVX/AVX2/NEON? I don't want to ExcludeArch as long as it "builds" but without the extensions i'm not sure real time processing can happen. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python packages up for adoption
On Wed, 2020-04-22 at 09:54 +0200, Miro Hrončok wrote: > On 22. 04. 20 0:39, Adam Williamson wrote: > > Can someone run the handy script (wherever it is) that provides the > > list of things that depend on this and who maintains them? I feel > > like > > maybe some of my stuff might need some of these but I'm not sure... > > Since claiming the orphaned packages is one click action, I strongly > suggest to > actually orphan the packages. > > That will include them in > https://churchyard.fedorapeople.org/orphans.txt > Ah okay, I have orphaned all the packages that had not been picked up already. Thanks! - Jeremy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: What CPU extensions can we assume are available by arch?
Regarding x86_64 and AVX2, last year we had a very heated discussion about this on the mailing list. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U/#MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U tl;dr: there was a proposal to make "x86_64" in Fedora mean "must support at least AVX2" and it met with a lot of backlash. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++
On Wed, Apr 22, 2020 at 6:01 AM Richard W.M. Jones wrote: > It turns out it comes from dune (the build tool), although I'm still > unclear how and why. In any case I added a rather hacky workaround so > I can get the build going again: No, it isn't dune; it's ocaml itself. From "Changes" under "Bug fixes": - #7917, #9426: Use GCC option -fexcess-precision=standard when available, avoiding a problem with x87 excess precision in Float.round. (Xavier Leroy, review by Sébastien Hinderer) -- 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: Previous awesome background images
My personal favorite is Fedora 26 https://fedoraproject.org/wiki/Wallpapers#Fedora_26 I am not an artist, but the silhouette of the calming woods with the reflection it on the lake is just *serene*. On Fri, Apr 17, 2020 at 5:44 PM Miro Hrončok wrote: > > On 17. 04. 20 16:07, Kamil Paral wrote: > > I'm disappointed with default wallpapers in the latest releases. I wonder > > if we > > could go back to more artistic images from previous releases? Here are some > > of > > my favorite ones: > > https://fedoraproject.org/wiki/Wallpapers#Fedora_29 > > https://fedoraproject.org/wiki/Wallpapers#Fedora_27 > > https://fedoraproject.org/wiki/Wallpapers#Fedora_21 > > https://fedoraproject.org/wiki/Wallpapers#Fedora_16 > > https://fedoraproject.org/wiki/Wallpapers#Fedora_15 > > https://fedoraproject.org/wiki/Wallpapers#Fedora_11 > > https://fedoraproject.org/wiki/Wallpapers#Fedora_7 > > > > Especially the one in Fedora 15 (GNOME edition) and 16 was outstanding. Can > > we > > do more of those, please? > > I love both the design and concept of the F25-F28 wallpapers. > > "As of the past 3 releases, we choose a sequential letter of the alphabet and > come up with a list of scientists / mathematicians / technologists to serve as > an inspiration for the desktop background’s visual concept" > > https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/ > > I am sad we haven't followed the pattern. (However I don't know the reasoning > for stopping that.) > > (I've changed the subject line, because I don't want to participate in what > was > in there.) > > -- > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: What CPU extensions can we assume are available by arch?
On Wed, Apr 22, 2020 at 9:28 AM Artur Iwicki wrote: > Regarding x86_64 and AVX2, last year we had a very heated discussion about > this on the mailing list. > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U/#MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U > > tl;dr: there was a proposal to make "x86_64" in Fedora mean "must support > at least AVX2" and it met with a lot of backlash. > Now that you mention it that does tickle some brain cells... So it seems what's really needed is a method to support software with optimizations above the baseline without leaving other people behind. The only way I can think of to do that that would be to have optional "enhanced" repos available that people can enable if their system supports it. The hard part would be keeping it in sync with the main repo. It would have to be a parallel build process and similar to the current process if one fails the build is a NOGO across the board. Could we treat them like arches? Something like: X86_64 & X86_64-AVX2 armv7hf & armv7fh-NEON etc... It would absolutely have to be OPT IN because once you enable it your system is no longer necessarily portable to other hardware. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What CPU extensions can we assume are available by arch?
On 4/22/20 9:51 AM, Richard Shaw wrote: So it seems what's really needed is a method to support software with optimizations above the baseline without leaving other people behind. There are varying software that do this. Glibc is one. FFmpeg is another. There's also a library that could return supported features, but I'm not sure if this will work for your use-case. https://github.com/google/cpu_features ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: What CPU extensions can we assume are available by arch?
On Wed, Apr 22, 2020 at 10:13 AM Michael Cronenworth wrote: > On 4/22/20 9:51 AM, Richard Shaw wrote: > > So it seems what's really needed is a method to support software with > > optimizations above the baseline without leaving other people behind. > > There are varying software that do this. Glibc is one. FFmpeg is another. > There's > also a library that could return supported features, but I'm not sure if > this will > work for your use-case. > I'm not sure all upstream have the manpower or knowledge to do it dynamically, plus in the case of LPCNet, it's required as it's the whole point of the project. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What CPU extensions can we assume are available by arch?
On Wednesday, 22 April 2020 at 16:51, Richard Shaw wrote: > On Wed, Apr 22, 2020 at 9:28 AM Artur Iwicki wrote: > > > Regarding x86_64 and AVX2, last year we had a very heated discussion about > > this on the mailing list. > > > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U/#MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U > > > > tl;dr: there was a proposal to make "x86_64" in Fedora mean "must support > > at least AVX2" and it met with a lot of backlash. > > > > Now that you mention it that does tickle some brain cells... > > So it seems what's really needed is a method to support software with > optimizations above the baseline without leaving other people behind. > > The only way I can think of to do that that would be to have optional > "enhanced" repos available that people can enable if their system supports > it. The hard part would be keeping it in sync with the main repo. It would > have to be a parallel build process and similar to the current process if > one fails the build is a NOGO across the board. > > Could we treat them like arches? > Something like: > X86_64 & X86_64-AVX2 If upstream doesn't support runtime selection of SIMD-optimized code paths based on CPU capabilities, you can build several versions and have glibc handle that by putting each version in a special subdirectory of /usr/lib64, e.g.: /usr/lib64/haswell /usr/lib64/haswell/avx512_1/ See https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture for some details. > armv7hf & armv7fh-NEON There already is armv7hnl (=ARMv7 with NEON) and RPM Fusion makes use of it, for example. Fedora builders don't support this as far as I know. Hope that helps. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-IoT-31-20200422.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Passed openQA tests: 8/8 (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: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
The SONAME bump has been done, and the re-builds of all packages have finished successfully. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: What CPU extensions can we assume are available by arch?
On Wed, Apr 22, 2020 at 9:25 AM Dominik 'Rathann' Mierzejewski wrote: > If upstream doesn't support runtime selection of SIMD-optimized code > paths based on CPU capabilities, you can build several versions and > have glibc handle that by putting each version in a special subdirectory > of /usr/lib64, e.g.: > /usr/lib64/haswell > /usr/lib64/haswell/avx512_1/ See https://pagure.io/packaging-committee/issue/926. -- 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: What CPU extensions can we assume are available by arch?
* Dominik Mierzejewski: > If upstream doesn't support runtime selection of SIMD-optimized code > paths based on CPU capabilities, you can build several versions and > have glibc handle that by putting each version in a special subdirectory > of /usr/lib64, e.g.: > /usr/lib64/haswell > /usr/lib64/haswell/avx512_1/ > > See > https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture > for some details. These are ill-defined unfortuantely and as such not very useful. For example, -march=haswell does not result in code that can be placed in a haswell subdirectory. I'm working with AMD and Intel to come up with a better subdirectory definition that also matches between GCC and glibc. 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: What CPU extensions can we assume are available by arch?
On Wed, Apr 22, 2020 at 10:19:47AM -0500, Richard Shaw wrote: > On Wed, Apr 22, 2020 at 10:13 AM Michael Cronenworth > wrote: > > > On 4/22/20 9:51 AM, Richard Shaw wrote: > > > So it seems what's really needed is a method to support software with > > > optimizations above the baseline without leaving other people behind. > > > > There are varying software that do this. Glibc is one. FFmpeg is another. > > There's > > also a library that could return supported features, but I'm not sure if > > this will > > work for your use-case. > > > > I'm not sure all upstream have the manpower or knowledge to do it > dynamically, plus in the case of LPCNet, it's required as it's the whole > point of the project. Surely there must be something which decides whether or not to use LPCNet? It sounds like this pushes the decision / fallback path to some other component. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++
* Jerry James: > On Wed, Apr 22, 2020 at 6:01 AM Richard W.M. Jones wrote: >> It turns out it comes from dune (the build tool), although I'm still >> unclear how and why. In any case I added a rather hacky workaround so >> I can get the build going again: > > No, it isn't dune; it's ocaml itself. From "Changes" under "Bug fixes": > > - #7917, #9426: Use GCC option -fexcess-precision=standard when available, > avoiding a problem with x87 excess precision in Float.round. > (Xavier Leroy, review by Sébastien Hinderer) This option should not have an effect on Fedora because we use SSE2 math on i686 (and x86-64, of course), which does not suffer from this issue. I think we can remove it. 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: What CPU extensions can we assume are available by arch?
On Wed, Apr 22, 2020 at 10:42 AM Richard W.M. Jones wrote: > On Wed, Apr 22, 2020 at 10:19:47AM -0500, Richard Shaw wrote: > > I'm not sure all upstream have the manpower or knowledge to do it > > dynamically, plus in the case of LPCNet, it's required as it's the whole > > point of the project. > > Surely there must be something which decides whether or not to use > LPCNet? It sounds like this pushes the decision / fallback path to > some other component. > The fork of LPCNet specifical being developed for ham radio digital communications will build without optimizations but warns that the code will be very slow. FreeDV (already in Fedora) is getting a new "mode" which requires LPCNet to work. So without the glibc implementation I'm still "stuck". Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++
On Wed, Apr 22, 2020 at 06:05:57PM +0200, Florian Weimer wrote: > * Jerry James: > > > On Wed, Apr 22, 2020 at 6:01 AM Richard W.M. Jones > > wrote: > >> It turns out it comes from dune (the build tool), although I'm still > >> unclear how and why. In any case I added a rather hacky workaround so > >> I can get the build going again: > > > > No, it isn't dune; it's ocaml itself. From "Changes" under "Bug fixes": > > > > - #7917, #9426: Use GCC option -fexcess-precision=standard when available, > > avoiding a problem with x87 excess precision in Float.round. > > (Xavier Leroy, review by Sébastien Hinderer) > > This option should not have an effect on Fedora because we use SSE2 math > on i686 (and x86-64, of course), which does not suffer from this issue. > I think we can remove it. I commented on the upstream bug report so let's see what they say. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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
Fedora rawhide compose report: 20200422.n.0 changes
OLD: Fedora-Rawhide-20200421.n.0 NEW: Fedora-Rawhide-20200422.n.0 = SUMMARY = Added images:0 Dropped images: 8 Added packages: 3 Dropped packages:4 Upgraded packages: 197 Downgraded packages: 0 Size of added packages: 9.52 MiB Size of dropped packages:542.34 KiB Size of upgraded packages: 7.02 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -20.98 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20200421.n.0.s390x.tar.xz Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20200421.n.0.iso Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20200421.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20200421.n.0.s390x.tar.xz Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200421.n.0.s390x.vmdk Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200421.n.0.s390x.raw.xz Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20200421.n.0.iso Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200421.n.0.s390x.qcow2 = ADDED PACKAGES = Package: freeopcua-0-0.9.20200131.da2b76f.fc33 Summary: Open Source C++ OPC-UA Server and Client Library RPMs:freeopcua freeopcua-devel Size:9.43 MiB Package: gnome-shell-extension-bubblemail-0.71-1.fc33 Summary: GNOME Shell indicator for new and unread mail using Bubblemail RPMs:gnome-shell-extension-bubblemail Size:34.69 KiB Package: golang-github-bettercap-readline-1.4-1.20200421git9cec905.fc33 Summary: Pure go implementation for GNU-Readline kind library RPMs:golang-github-bettercap-readline-devel Size:48.68 KiB = DROPPED PACKAGES = Package: python-nose-cov-1.6-19.fc32 Summary: nose plugin for coverage reporting, including subprocesses and multiprocessing RPMs:python3-nose-cov Size:15.50 KiB Package: python-nose-xcover-1.0.11-7.fc32 Summary: Extends nose.plugins.cover to add Cobertura-style XML reports RPMs:python3-nose-xcover Size:14.75 KiB Package: rubygem-pry-nav-0.3.0-3.fc32 Summary: Simple execution navigation for Pry RPMs:rubygem-pry-nav rubygem-pry-nav-doc Size:225.28 KiB Package: rubygem-spy-1.0.0-4.fc32 Summary: Simple modern mocking library that uses the spy pattern RPMs:rubygem-spy rubygem-spy-doc Size:286.82 KiB = UPGRADED PACKAGES = Package: abrt-2.14.0-3.fc33 Old package: abrt-2.14.0-2.fc32 Summary: Automatic bug detection and reporting tool RPMs: abrt abrt-addon-ccpp abrt-addon-kerneloops abrt-addon-pstoreoops abrt-addon-upload-watch abrt-addon-vmcore abrt-addon-xorg abrt-atomic abrt-cli abrt-console-notification abrt-dbus abrt-desktop abrt-devel abrt-gui abrt-gui-devel abrt-gui-libs abrt-libs abrt-plugin-bodhi abrt-plugin-machine-id abrt-plugin-sosreport abrt-retrace-client abrt-tui python3-abrt python3-abrt-addon python3-abrt-container-addon python3-abrt-doc Size: 6.99 MiB Size change: -107.55 KiB Changelog: * Tue Apr 21 2020 Bj??rn Esser - 2.14.0-3 - Rebuild (json-c) Package: anaconda-33.11-1.fc33 Old package: anaconda-33.10-1.fc33 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 19.70 MiB Size change: -78.77 KiB Changelog: * Tue Apr 21 2020 Martin Kolman - 33.11-1 - Reset the partitioning of Blivet-GUI (#1826286) (vponcova) - Fix the validation of a device label (#1823221) (vponcova) - Use the new base classes in sources (vslavik) - Add base classes for mounting sources (vslavik) - Add test if the spokes ordering is correct (jkonecny) - Fix ordering of spokes with the same priority (jkonecny) - Fix TUI Kernel and Unsupported HW spokes ordering (jkonecny) - Switch collecting & ordering action classes to static (jkonecny) - Add TUI/GUI tests for standalone spokes priority (jkonecny) - Use join_paths instead of os.path.join in sources (vslavik) - Get ui/__init__.py closer to pep8 (jkonecny) - Allow to remove incomplete devices (#1823232) (vponcova) - subscription: RHSMObserver & StartRHSMTask (mkolman) - Make sure that the summary button is really hidden (#1823467) (vponcova) - Use default priority in the GUI spokes (jkonecny) - Fix TUI spokes priorities (jkonecny) - Add back default priority for standalone spokes (jkonecny) - subscription: Add initial RHSM DBus API identifiers (mkolman) - Install scripts at /usr/bin (vponcova) - Remove mock from the test dependencies (vponcova) - Install test dependencies from pip when possible (
Re: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
On Wed, 22 Apr 2020 12:00:37 +0200 Björn 'besser82' Esser wrote: > The SONAME bump has been done, and the re-builds of all packages have > finished successfully. looks you have missed s390utils with the rebuilds and it's also missing in the initial list of packages. How did you created the list - searching for the library soname in binary rpms or for json-c-devel in source rpms? I took care of the rebuild, that's not a problem. 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
Re: Non-responsive maintainer: mruprich (Michal Ruprich)
Martin Sehnoutka writes: > Hi Robbie, > > I'm pretty sure Michal would respond if you contacted him via email. Hi Martin, you've dropped Michal from CC in your reply, but I did include Michal on my original email. In other words: this *is* contacting by email :) > Also Michal is far from being inactive on bugzilla and the fact that > he has few open bugs does not prove otherwise. If you click on the three bugs I highlight, you'll see that it's not about having open bugs: it's about not responding to questions about them. In other words: not being responsive. To make this as clear as I can, let's look at https://bugzilla.redhat.com/show_bug.cgi?id=1815163 Due to handling a CVE with Michal around telnet-server, I became aware that we ship telnet-server at all. On 2020-03-19, I file the bug requesting its removal. Three weeks later, after receiving no response to what should be an easy request, I offer a patch on 2020-04-09 (and NEEDINFO). Twelve days later, *still* receiving no response, I carry out the process for what we do in Fedora when maintainers don't respond. Almost immediately, I have a reply. This is not how we "deal with reported bugs in a timely manner" as our package maintainers are expected to do. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Re: Fedora 32 Final Go/No-Go meeting
This is your reminder that the Go/No-Go meeting for the Fedora 32 Final release will be held tomorrow, Thursday, 2020-04-23 at 17:00 UTC in #fedora-meeting-1. For more information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting View the meeting on Fedocal at: https://apps.fedoraproject.org/calendar/meeting/9738/ -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
Am Mittwoch, den 22.04.2020, 19:02 +0200 schrieb Dan Horák: > On Wed, 22 Apr 2020 12:00:37 +0200 > Björn 'besser82' Esser wrote: > > > The SONAME bump has been done, and the re-builds of all packages > > have > > finished successfully. > > looks you have missed s390utils with the rebuilds and it's also > missing > in the initial list of packages. How did you created the list - > searching for the library soname in binary rpms or for json-c-devel in > source rpms? I took care of the rebuild, that's not a problem. Hi Dan, I created the list of packages with the following chain of commands: dnf --releasever=rawhide repoquery --whatrequires json-c | \ xargs dnf --releasever=rawhide info | \ grep -i 'source' | sed -e 's!^.*: !!g' | sort -u; I ran that on Fedora 32 x86_64, and unfortunately the `s390utils` was not amoung the listed packages for some reason. Björn signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-IoT-32-20200422.0 compose check report
No missing expected images. Passed openQA tests: 8/8 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 145 MiB to 161 MiB 1 services(s) added since previous compose: zezere_ignition.service Previous test data: https://openqa.fedoraproject.org/tests/578973#downloads Current test data: https://openqa.fedoraproject.org/tests/584385#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 146 MiB to 161 MiB 1 services(s) added since previous compose: zezere_ignition.service Previous test data: https://openqa.fedoraproject.org/tests/578972#downloads Current test data: https://openqa.fedoraproject.org/tests/584387#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
On 22. 04. 20 19:47, Björn 'besser82' Esser wrote: Hi Dan, I created the list of packages with the following chain of commands: dnf --releasever=rawhide repoquery --whatrequires json-c | \ xargs dnf --releasever=rawhide info | \ grep -i 'source' | sed -e 's!^.*: !!g' | sort -u; I ran that on Fedora 32 x86_64, and unfortunately the `s390utils` was not amoung the listed packages for some reason. Because it has: ExclusiveArch: s390 s390x -- 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
Non-responsive maintainer: laxathom (Xavier Lamien)
Hi, I've been trying to get in contact with Xavier Lamien since Sep 2019 [1]. The package libgdiplus is particularly important to have mono built in EPEL 8. I am following the policy for non-responsive package maintainers [2]. In 7 days if I don't get any answers I will be filling a ticket to maintain it if none is against it. 1 https://bugzilla.redhat.com/show_bug.cgi?id=1749560 2 https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ Thank you. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
Am Mittwoch, den 22.04.2020, 20:02 +0200 schrieb Miro Hrončok: > On 22. 04. 20 19:47, Björn 'besser82' Esser wrote: > > Hi Dan, > > > > I created the list of packages with the following chain of commands: > > > > dnf --releasever=rawhide repoquery --whatrequires json-c | \ > > xargs dnf --releasever=rawhide info | \ > > grep -i 'source' | sed -e 's!^.*: !!g' | sort -u; > > > > I ran that on Fedora 32 x86_64, and unfortunately the `s390utils` > > was > > not amoung the listed packages for some reason. > > Because it has: > > ExclusiveArch: s390 s390x Is there any better command that will work regardless of the system's arch? signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
On 22. 04. 20 20:16, Björn 'besser82' Esser wrote: Am Mittwoch, den 22.04.2020, 20:02 +0200 schrieb Miro Hrončok: On 22. 04. 20 19:47, Björn 'besser82' Esser wrote: Hi Dan, I created the list of packages with the following chain of commands: dnf --releasever=rawhide repoquery --whatrequires json-c | \ xargs dnf --releasever=rawhide info | \ grep -i 'source' | sed -e 's!^.*: !!g' | sort -u; I ran that on Fedora 32 x86_64, and unfortunately the `s390utils` was not amoung the listed packages for some reason. Because it has: ExclusiveArch: s390 s390x Is there any better command that will work regardless of the system's arch? I ma not aware of such, unfortunately. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 compose report: 20200422.n.0 changes
OLD: Fedora-32-20200421.n.0 NEW: Fedora-32-20200422.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Non-responsive maintainer: laxathom (Xavier Lamien)
Oh hi, Looks like your email get lost in the pile if you tried to reach me personally or my bugzilla's filter is too efficient I'd say. Any way, I'll have a look at your ticket asap. Also, I'm more than welcome to get co-maintainer on this package so feel free to request access since you're looking into it. Cheers, -x On Wed, Apr 22, 2020, 8:10 PM Breno Brand Fernandes wrote: > Hi, > > I've been trying to get in contact with Xavier Lamien since Sep 2019 [1]. > The package libgdiplus is particularly important to have mono built in > EPEL 8. > > I am following the policy for non-responsive package maintainers [2]. > In 7 days if I don't get any answers I will be filling a ticket to > maintain it if none is against it. > > 1 https://bugzilla.redhat.com/show_bug.cgi?id=1749560 > 2 > https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ > > Thank you. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Non-responsive maintainer: laxathom (Xavier Lamien)
I already built it. But you can update to 6.0.5 :) ср, 22 апр. 2020 г. в 22:04, Xavier Lamien : > > Oh hi, > > Looks like your email get lost in the pile if you tried to reach me > personally or my bugzilla's filter is too efficient I'd say. > > Any way, I'll have a look at your ticket asap. > Also, I'm more than welcome to get co-maintainer on this package so feel free > to request access since you're looking into it. > > Cheers, > -x > > > On Wed, Apr 22, 2020, 8:10 PM Breno Brand Fernandes > wrote: >> >> Hi, >> >> I've been trying to get in contact with Xavier Lamien since Sep 2019 [1]. >> The package libgdiplus is particularly important to have mono built in EPEL >> 8. >> >> I am following the policy for non-responsive package maintainers [2]. >> In 7 days if I don't get any answers I will be filling a ticket to maintain >> it if none is against it. >> >> 1 https://bugzilla.redhat.com/show_bug.cgi?id=1749560 >> 2 >> https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ >> >> Thank you. >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
gpgv2: symbol lookup error: /lib64/libgcrypt.so.20: undefined symbol: dlopen
gpgverify commands are failing in Rawhide at the moment: gpgv2: symbol lookup error: /lib64/libgcrypt.so.20: undefined symbol: dlopen I filed a BZ about it: https://bugzilla.redhat.com/show_bug.cgi?id=1826925 (or is this a bug in gnupg2?) I guess this will affect any package that verifies a tarball signature. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: kiss-fft's builds failure on rawhide after upgrading of gcc and glibc
Il giorno mar, 21/04/2020 alle 21.27 +0200, Guido Aulisi ha scritto: > Il giorno mar, 21/04/2020 alle 11.19 -0700, Samuel Sieb ha scritto: > > On 4/21/20 2:30 AM, Guido Aulisi wrote: > > > I'm trying to understand why kiss-fft (an FFT library) is failing > > > in > > > rawhide only on aarch64. > > > The failing test does some fft calculation and compares them with > > > the > > > same done with numpy. > > > For waht I understood the upgrade of gcc and/or glibc makes this > > > test > > > fail only on aarch64, and I cannot undestand why gcc or glibc > > > changed > > > the maths or the precision used on this arch. > > > > Can you get the output to see what's happening in the failing > > test? > > That might help to figure out what's going wrong. > > Yes, of course, sorry I forgot to link the Koschei failed build: > > https://koschei.fedoraproject.org/package/kiss-fft?collection=f33 > > And this is the build.log: > https://kojipkgs.fedoraproject.org/work/tasks/8318/43588318/build.log > With the latest update of gcc and glibc kiss-fft's builds are back to normal now, thanks gcc folks! Ciao Guido ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
On Wed, Apr 22, 2020 at 8:28 PM Miro Hrončok wrote: > > On 22. 04. 20 20:16, Björn 'besser82' Esser wrote: > > Am Mittwoch, den 22.04.2020, 20:02 +0200 schrieb Miro Hrončok: > >> On 22. 04. 20 19:47, Björn 'besser82' Esser wrote: > >>> Hi Dan, > >>> > >>> I created the list of packages with the following chain of commands: > >>> > >>> dnf --releasever=rawhide repoquery --whatrequires json-c | \ > >>> xargs dnf --releasever=rawhide info | \ > >>> grep -i 'source' | sed -e 's!^.*: !!g' | sort -u; > >>> > >>> I ran that on Fedora 32 x86_64, and unfortunately the `s390utils` > >>> was > >>> not amoung the listed packages for some reason. > >> > >> Because it has: > >> > >> ExclusiveArch: s390 s390x > > > > > > Is there any better command that will work regardless of the system's > > arch? > > I ma not aware of such, unfortunately. If you include the -source repo and query for things that require json-c-devel, that will includes s390utils.src: $ dnf --quiet --repo rawhide --repo rawhide-source --releasever rawhide repoquery --whatrequires json-c-devel abrt-0:2.14.0-3.fc33.src bind-32:9.11.18-2.fc33.src bind-lite-devel-32:9.11.18-2.fc33.i686 bind-lite-devel-32:9.11.18-2.fc33.x86_64 bluez-0:5.54-2.fc33.src bti-0:034-18.fc33.src clamav-0:0.102.2-6.fc33.src cpu-x-0:3.2.4-6.20191114gitfa0fe58.fc32.src cryptsetup-0:2.3.1-4.fc33.src device-mapper-multipath-0:0.8.2-6.fc33.src dmlite-0:1.13.99-5.fc33.src fastd-0:18-15.fc33.src fcitx-0:4.2.9.7-3.fc33.src freeradius-0:3.0.21-2.fc33.src frr-0:7.3-4.fc33.src fwts-0:20.02.00-2.fc33.src gdal-0:3.0.4-3.fc33.src gdcm-0:3.0.1-7.fc33.src gfal2-0:2.17.2-2.fc33.src girara-0:0.3.4-2.fc33.src girara-devel-0:0.3.4-2.fc33.i686 girara-devel-0:0.3.4-2.fc33.x86_64 gluster-block-0:0.4-7.fc33.src google-compute-engine-oslogin-0:1.4.3-5.fc33.src igt-gpu-tools-0:1.24-4.20191213git048f585.fc33.src lcgdm-dav-0:0.22.0-5.fc33.src libdnf-0:0.47.0-2.fc33.src libhubbub-0:0.3.6-2.fc32.src liblognorm-devel-0:2.0.3-9.fc32.i686 liblognorm-devel-0:2.0.3-9.fc32.x86_64 libmypaint-0:1.5.0-2.fc33.src libmypaint-devel-0:1.5.0-2.fc33.i686 libmypaint-devel-0:1.5.0-2.fc33.x86_64 libmypaint2-0:2.0.0-0.7.beta.1.fc33.src libmypaint2-devel-0:2.0.0-0.7.beta.1.fc33.i686 libmypaint2-devel-0:2.0.0-0.7.beta.1.fc33.x86_64 libreport-0:2.12.0-4.fc33.src libreport-web-devel-0:2.12.0-4.fc33.i686 libreport-web-devel-0:2.12.0-4.fc33.x86_64 libstorj-0:1.0.3-4.fc33.src libstorj-devel-0:1.0.3-4.fc33.i686 libstorj-devel-0:1.0.3-4.fc33.x86_64 libu2f-host-0:1.1.10-5.fc33.src libu2f-server-0:1.0.1-18.fc33.src libverto-jsonrpc-0:0.1.0-24.fc33.src libverto-jsonrpc-devel-0:0.1.0-24.fc33.i686 libverto-jsonrpc-devel-0:0.1.0-24.fc33.x86_64 libvmi-0:0.11.0-18.20170706gite919365.fc33.src mpris-scrobbler-0:0.3.5-4.fc33.src mraa-0:2.1.0-2.fc33.src mypaint-0:2.0.0-0.6.beta.0.fc32.src nbd-runner-0:0.5.3-3.fc33.src ndctl-0:68-2.fc33.src newsbeuter-0:2.9-15.fc33.src newsboat-0:2.19-3.fc33.src opae-0:1.4.1-5.fc33.src openhpi-0:3.8.0-11.fc33.src opensips-0:3.0.2-6.fc33.src postgis-0:3.0.1-2.fc33.src riemann-c-client-0:1.9.0-15.fc33.src riemann-c-client-devel-0:1.9.0-15.fc33.i686 riemann-c-client-devel-0:1.9.0-15.fc33.x86_64 rpm-ostree-0:2020.1.80.g3ec5e287-2.fc33.src rpminspect-0:0.12-2.fc33.src s390utils-2:2.12.0-3.fc32.src satyr-0:0.30-3.fc33.src satyr-devel-0:0.30-3.fc33.i686 satyr-devel-0:0.30-3.fc33.x86_64 strongswan-0:5.8.4-3.fc33.src subscription-manager-0:1.27.1-2.fc33.src sway-0:1.4-5.fc33.src syslog-ng-0:3.25.1-3.fc33.src systemtap-0:4.3-0.20200212git91ffb97ad335.fc33.src tlog-0:7-3.fc33.src tpm2-tss-0:2.4.0-2.fc33.src tpm2-tss-devel-0:2.4.0-2.fc33.i686 tpm2-tss-devel-0:2.4.0-2.fc33.x86_64 trace-cmd-0:2.8.3-2.fc33.src xrootd-1:4.11.3-2.fc33.src zmap-0:2.1.1-13.fc33.src That's because Exclusive/ExcludeArch isn't evaluated when packages are copied into the source repos. Fabio > -- > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
On Wed, 22 Apr 2020 20:27:29 +0200 Miro Hrončok wrote: > On 22. 04. 20 20:16, Björn 'besser82' Esser wrote: > > Am Mittwoch, den 22.04.2020, 20:02 +0200 schrieb Miro Hrončok: > >> On 22. 04. 20 19:47, Björn 'besser82' Esser wrote: > >>> Hi Dan, > >>> > >>> I created the list of packages with the following chain of > >>> commands: > >>> > >>> dnf --releasever=rawhide repoquery --whatrequires json-c | \ > >>> xargs dnf --releasever=rawhide info | \ > >>> grep -i 'source' | sed -e 's!^.*: !!g' | sort -u; > >>> > >>> I ran that on Fedora 32 x86_64, and unfortunately the `s390utils` > >>> was > >>> not amoung the listed packages for some reason. > >> > >> Because it has: > >> > >> ExclusiveArch: s390 s390x > > > > > > Is there any better command that will work regardless of the > > system's arch? > > I ma not aware of such, unfortunately. dnf repoquery --disablerepo=\* --enablerepo=rawhide-source --arch=src --whatrequires json-c-devel This "source" list should be the same as the "binary" one, except some corner cases. 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
Re: OCaml 4.11 prerelease in Rawhide (was: Re: ocaml-bisect-ppx and related updates)
https://bodhi.fedoraproject.org/updates/FEDORA-2020-150918c861 A summary of what happened: * Coq (and friends) don't build because camlp5 -> lablgtk3 -> coq. camlp5 has not been ported upstream to OCaml 4.11. * Same for haxe and why3. * I wasn't able to "unbootstrap" menhir and dune since they both depend on Coq. * GPG verification is broken in Rawhide so I couldn't complete some of my packages (https://bugzilla.redhat.com/show_bug.cgi?id=1826925) Everything else built, but you may have noticed that I had to push a few rather ugly fixes to get several packages to build. In all cases I have opened bugs upstream so with luck these will get fixed in time for real OCaml 4.11. I scratch-built the OCaml compiler package on RISC-V, which if you can remember a very long time ago was the whole purpose of the exercise. I'll work with David to see if we can build the remaining packages for Fedora/RISC-V. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Non-responsive maintainer: laxathom (Xavier Lamien)
Thanks Vasiliy, much appreciated. On Wed, Apr 22, 2020, 9:07 PM Vascom wrote: > I already built it. > > But you can update to 6.0.5 :) > > ср, 22 апр. 2020 г. в 22:04, Xavier Lamien : > > > > Oh hi, > > > > Looks like your email get lost in the pile if you tried to reach me > personally or my bugzilla's filter is too efficient I'd say. > > > > Any way, I'll have a look at your ticket asap. > > Also, I'm more than welcome to get co-maintainer on this package so feel > free to request access since you're looking into it. > > > > Cheers, > > -x > > > > > > On Wed, Apr 22, 2020, 8:10 PM Breno Brand Fernandes > wrote: > >> > >> Hi, > >> > >> I've been trying to get in contact with Xavier Lamien since Sep 2019 > [1]. > >> The package libgdiplus is particularly important to have mono built in > EPEL 8. > >> > >> I am following the policy for non-responsive package maintainers [2]. > >> In 7 days if I don't get any answers I will be filling a ticket to > maintain it if none is against it. > >> > >> 1 https://bugzilla.redhat.com/show_bug.cgi?id=1749560 > >> 2 > https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ > >> > >> Thank you. > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: ProtonMail Bridge rpm build request
In any case I have made a repo with the spec in the meanwhile https://github.com/A6GibKm/protonmail-bridge.spec, and it builds fine. But I am not sure how to handle go modules for a possible koji release. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Review Swap: bowtie2 - A read aligner for genome sequencing
Hi, Could anyone swap the review? Review Request: bowtie2 - A read aligner for genome sequencing https://bugzilla.redhat.com/show_bug.cgi?id=1824348 bowtie2 [1] is C++ software for genome analysis.It can be also used for COVID-19 analysis [2]. Thanks. Jun [1] https://github.com/BenLangmead/bowtie2 [2] https://nf-co.re/viralrecon -- 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: Previous awesome background images
On 22. 04. 20 16:40, Mohan Boddu wrote: My personal favorite is Fedora 26 https://fedoraproject.org/wiki/Wallpapers#Fedora_26 I am not an artist, but the silhouette of the calming woods with the reflection it on the lake is just*serene*. I love that one, especially the "hidden gem": it is a visual representation of the sound of saying "Fedora". -- 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: Non-responsive maintainer: laxathom (Xavier Lamien)
Hi Vascom, I don't see the -devel package available. Why is that? On Wed, 22 Apr 2020 at 15:07, Vascom wrote: > I already built it. > > But you can update to 6.0.5 :) > > ср, 22 апр. 2020 г. в 22:04, Xavier Lamien : > > > > Oh hi, > > > > Looks like your email get lost in the pile if you tried to reach me > personally or my bugzilla's filter is too efficient I'd say. > > > > Any way, I'll have a look at your ticket asap. > > Also, I'm more than welcome to get co-maintainer on this package so feel > free to request access since you're looking into it. > > > > Cheers, > > -x > > > > > > On Wed, Apr 22, 2020, 8:10 PM Breno Brand Fernandes > wrote: > >> > >> Hi, > >> > >> I've been trying to get in contact with Xavier Lamien since Sep 2019 > [1]. > >> The package libgdiplus is particularly important to have mono built in > EPEL 8. > >> > >> I am following the policy for non-responsive package maintainers [2]. > >> In 7 days if I don't get any answers I will be filling a ticket to > maintain it if none is against it. > >> > >> 1 https://bugzilla.redhat.com/show_bug.cgi?id=1749560 > >> 2 > https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ > >> > >> Thank you. > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Non-responsive maintainer: laxathom (Xavier Lamien)
Thanks for answering Xavier. I am checking with Vascom why I can't see the libgdiplus-devel in EPEL 8. - Breno On Wed, 22 Apr 2020 at 15:04, Xavier Lamien wrote: > Oh hi, > > Looks like your email get lost in the pile if you tried to reach me > personally or my bugzilla's filter is too efficient I'd say. > > Any way, I'll have a look at your ticket asap. > Also, I'm more than welcome to get co-maintainer on this package so feel > free to request access since you're looking into it. > > Cheers, > -x > > > On Wed, Apr 22, 2020, 8:10 PM Breno Brand Fernandes > wrote: > >> Hi, >> >> I've been trying to get in contact with Xavier Lamien since Sep 2019 [1]. >> The package libgdiplus is particularly important to have mono built in >> EPEL 8. >> >> I am following the policy for non-responsive package maintainers [2]. >> In 7 days if I don't get any answers I will be filling a ticket to >> maintain it if none is against it. >> >> 1 https://bugzilla.redhat.com/show_bug.cgi?id=1749560 >> 2 >> https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ >> >> Thank you. >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Review Swap: bowtie2 - A read aligner for genome sequencing
On 4/22/20 9:55 PM, Jun Aruga wrote: Hi, Could anyone swap the review? Review Request: bowtie2 - A read aligner for genome sequencing https://bugzilla.redhat.com/show_bug.cgi?id=1824348 I can take it. bowtie2 [1] is C++ software for genome analysis.It can be also used for COVID-19 analysis [2]. Thanks. Jun [1] https://github.com/BenLangmead/bowtie2 [2] https://nf-co.re/viralrecon ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: What CPU extensions can we assume are available by arch?
Richard Shaw writes: I'm having trouble determining what the base CPU targets for Fedora can accommodate. For example, ss it safe to assume AVX2 on x86_64? Nope. Linux thinkpad 5.5.16-200.fc31.x86_64 #1 SMP Wed Apr 8 16:43:33 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux [ /proc/cpuinfo: flags : ... avx ... Last year a proposal was floated to require avx2 for Fedora 3-something. It didn't go well. pgptHZAbRBITt.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
[Test-Announce] Fedora 32 Candidate RC-1.6 Available Now!
According to the schedule [1], Fedora 32 Candidate RC-1.6 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/32 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.6_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.6_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.6_Base https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.6_Server https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.6_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.6_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.6_Security_Lab All RC priority test cases for each of these test pages [2] must pass in order to meet the RC Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-32/f-32-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_32_RC_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ ___ 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
Fedora-32-20200422.0 compose check report
No missing expected images. Soft failed openQA tests: 21/173 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 584428 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/584428 ID: 584429 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/584429 ID: 584430 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/584430 ID: 584433 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/584433 ID: 584435 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/584435 ID: 584452 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/584452 ID: 584465 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/584465 ID: 584486 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/584486 ID: 584489 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/584489 ID: 584507 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/584507 ID: 584508 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/584508 ID: 584520 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/584520 ID: 584530 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/584530 ID: 584534 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/584534 ID: 584545 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/584545 ID: 584569 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/584569 ID: 584571 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/584571 ID: 584581 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/584581 ID: 584594 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/584594 ID: 584597 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/584597 ID: 584600 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/584600 Passed openQA tests: 152/173 (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
Schedule for Thursday's FPC Meeting (2020-04-23 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2020-04-23 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2020-04-23 09:00 PDT US/Pacific 2020-04-23 12:00 EDT --> US/Eastern <-- 2020-04-23 16:00 UTC UTC 2020-04-23 17:00 BST Europe/London 2020-04-23 18:00 CEST Europe/Berlin 2020-04-23 18:00 CEST Europe/Paris 2020-04-23 21:30 IST Asia/Calcutta New Day: Friday - 2020-04-24 00:00 HKT Asia/Hong_Kong 2020-04-24 00:00 +08 Asia/Singapore 2020-04-24 01:00 JST Asia/Tokyo 2020-04-24 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Issues = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 = New Issues = #topic #963 Blanket Bootstrap Exception for building Mono .fpc 963 https://pagure.io/packaging-committee/issue/963 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines https://pagure.io/packaging-committee/pull-request/814 #topic #pr-938 Add Package Review Process page https://pagure.io/packaging-committee/pull-request/938 = New Pull Requests = #topic #pr-#942 Recommend storing changelog entries in separate file. https://pagure.io/packaging-committee/pull-request/942 #topic #pr-#947 Deprecate Old Style Dependency Generators https://pagure.io/packaging-committee/pull-request/947 #topic #pr-#954 Prohibit use of `rpm` command from specfile. https://pagure.io/packaging-committee/pull-request/954 #topic #pr-#962 Docuemnt how to pass arguments to %py3_build/install https://pagure.io/packaging-committee/pull-request/962 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: ProtonMail Bridge rpm build request
Il 22/04/20 00:22, Maximiliano Sandoval via devel ha scritto: > Hi everyone, I would like to request a rpm build for > [protonmail-bridge](https://protonmail.com/bridge/), which recently released > its source at [github](https://github.com/ProtonMail/proton-bridge). I have > been unable to produce a build locally for reasons I don't quite understand. > There is already a build in the aur (see > [PKGBUILD](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=protonmail-bridge)). > > I have only managed to determine that the build requires > ``` > gcc, gcc-c++, gcc-go, gnome-keyring-devel, qt5-qtmultimedia-devel, > dejavu-fonts-all, libglvnd-devel, libsecret-devel, golang, make, go-rpm-macros > ``` > I would happily help to maintain such package, but currently I am not able to > build it. > This is something I would really like to have in Fedora repos, but it requires some Golang packaging skills which I miss. Golang packaging guidelines follows specific rules, the specfile you provide is not valid, I think. For whoever wants to try packaging protonmail-bridge, note that there are several issues opened upstream by users asking a cleaner code for having it built into distro repositories: https://github.com/ProtonMail/proton-bridge/issues/9 https://github.com/ProtonMail/proton-bridge/issues/16 https://github.com/ProtonMail/proton-bridge/issues/20 Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
