[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7f0ce51dbd python-bleach-3.1.4-2.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-72116e7775 chromium-81.0.4044.122-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b928468862 openvpn-2.4.9-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing guidelines-support-library-3.0.1-1.el8 mono-6.6.0-8.el8 sword-1.8.1-18.el8 Details about builds: guidelines-support-library-3.0.1-1.el8 (FEDORA-EPEL-2020-10035b60d7) Guidelines Support Library Update Information: Updated to version 3.0.1. Changelog: https://github.com/microsoft/GSL/releases/tag/v3.0.1 ChangeLog: * Sat Apr 25 2020 Vitaly Zaitsev - 3.0.1-1 - Updated to version 3.0.1. * Fri Apr 17 2020 Vitaly Zaitsev - 3.0.0-1 - Updated to version 3.0.0. * Mon Feb 3 2020 Vitaly Zaitsev - 2.1.0-1 - Updated to version 2.1.0. * Wed Jan 29 2020 Fedora Release Engineering - 1.0.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild mono-6.6.0-8.el8 (FEDORA-EPEL-2020-21d2ce425f) Cross-platform, Open Source, .NET development framework Update Information: First package of Mono for Epel 8. ChangeLog: References: [ 1 ] Bug #1752940 - build of mono for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1752940 sword-1.8.1-18.el8 (FEDORA-EPEL-2020-1e88cccde9) Free Bible Software Project Update Information: Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild ChangeLog: ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: What CPU extensions can we assume are available by arch?
On 4/25/20 12:24 UTC, Kevin Kofler wrote: Richard Shaw wrote: As far as LCPNet itself I've communicated with the primary developer quite a bit over the last week. LPCNet *will not work* without optimizations (at least not in real time which is the point). Has anyone (upstream or elsewhere) ever looked into doing an SSE2 version of the vector code? Most of LPCNet computation is "embarrassingly parallel"; for each vector operation, then each output element could be computed simultaneously. So an SSE2 version would be competitive with the AVX1 version (use the same instructions, just don't VEX encode them) except for any advantage that AVX gains from using 3-operand instructions instead of just 2-operand. The existing code should be enhanced to align each 'float' array to a cache-line boundary, and to place scalar members of 'struct's into any "holes". Also, the existing code is single-threaded. A two-threaded version with one thread computing vector elements [0, 16*floor(N/32)) and a second thread computing the rest, would be nearly twice as fast as long as synchronization was fast [futex to the rescue.] Two threads might trigger thermal throttling on older CPUs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: cryptominisat soname bump
On Sat, Apr 25, 2020 at 5:39 PM Jerry James wrote: > I'm building cryptominisat 5.7.0 in Rawhide. This involves an soname > bump, so I am also rebuilding its dependencies: cvc4, stp, yices, and > sagemath. Except I can't rebuild sagemath because jmol and jsmol have been retired. It will be necessary to figure out how to build sagemath without them, which may take a little time. The stp and yices builds are done, and I'm working on the cvc4 build. -- 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
cryptominisat soname bump
I'm building cryptominisat 5.7.0 in Rawhide. This involves an soname bump, so I am also rebuilding its dependencies: cvc4, stp, yices, and sagemath. -- 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: coreos-assembler v0.8.0
On 4/25/20 6:50 AM, Micah Abbott wrote: The CoreOS team is pleased to announce the latest release of `coreos-assembler` - our opinionated build tool that we use to build and test Fedora CoreOS and Red Hat CoreOS. https://github.com/coreos/coreos-assembler/releases/tag/v0.8.0 The team created `coreos-assembler` as a way to bind together Ignition, `rpm-ostree`, and many other Fedora RPMs to build, test, and deliver Fedora CoreOS and Red Hat CoreOS artifacts. `coreos-assembler` is delivered as a container image (quay.io/coreos/coreos-assembler), ready to be run via "rootless" `podman`, and provides an easy on-ramp for people and projects that want a "custom" Fedora CoreOS style system. Check out the release notes via the tag above and come talk to us at our usual places: - #fedora-coreos on Freenode - CoreOS category on the forums - https://discussion.fedoraproject.org/c/server/coreos/5 Really nice! Would it make sense to anounce this in the forum too, so questions about this can go on a single thread? Also curious if Silverblue is using this too, or do they have differing needs. Cheers, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
NeuroFedora review swap: python-spyking-circus
Hello, Would anyone like to swap simple reviews please? I'd like to get python-spyking-circus reviewed for NeuroFedora: https://bugzilla.redhat.com/show_bug.cgi?id=1827948 Description: SpyKING CIRCUS is a python code to allow fast spike sorting on multi channel recordings. A publication on the algorithm can be found at https://elifesciences.org/articles/34518. It has been tested on datasets coming from in vitro retina with 252 electrodes MEA, from in vivo hippocampus with tetrodes, in vivo and in vitro cortex data with 30 and up to 4225 channels, with good results. Synthetic tests on these data show that cells firing at more than 0.5Hz can be detected, and their spikes recovered with error rates at around 1%, even resolving overlapping spikes and synchronous firing. It seems to be compatible with optogenetic stimulation, based on experimental data obtained in the retina. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1827947] New: perl-Code-TidyAll-0.78 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1827947 Bug ID: 1827947 Summary: perl-Code-TidyAll-0.78 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Code-TidyAll Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.78 Current version/release in rawhide: 0.75-2.fc32 URL: http://search.cpan.org/dist/Code-TidyAll/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/8650/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: dropping NSS DBM format support in F33+
On Sat, Apr 25, 2020 at 10:21 AM Daiki Ueno wrote: > > Hello Ondrej, > > Ondrej Mosnacek writes: > > > On Fri, Apr 24, 2020 at 11:12 PM Ondrej Mosnacek > > wrote: > >> On Fri, Apr 24, 2020 at 8:50 PM Ondrej Mosnacek > >> wrote: > >> > On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno > >> > wrote: > >> > > 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. > >> > > >> > It seems this broke the kernel build. I did some scratch build today > >> > to test some patches, but it failed with this: > >> > > >> > + /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir > >> > /etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s > >> > pesign: Could not initialize nss. > >> > NSS says "The certificate/key database is in an old, unsupported > >> > format." errno says "No such file or directory" > >> > error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) > >> > RPM build errors: > >> > Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) > >> > Child return code was: 1 > >> > >> Probably related: https://github.com/rhboot/pesign/issues/34 > > > > I filed a bug against pesign here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1827902 > > Good catch, and thank you for filing the bug. For the meantime I > reverted the DBM disablement to unblock the kernel package build: > https://src.fedoraproject.org/rpms/nss/c/fc0174ead16bac476cce55fb2918fbfd9b448023?branch=master > Thanks for that, I know they were working on a fix for pesign on Friday, but I am not sure what their timeframe is. Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: dropping NSS DBM format support in F33+
On Sat, Apr 25, 2020, at 6:21 AM, Ondrej Mosnacek wrote: > On Fri, Apr 24, 2020 at 11:12 PM Ondrej Mosnacek wrote: > > On Fri, Apr 24, 2020 at 8:50 PM Ondrej Mosnacek wrote: > > > On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno > > > wrote: > > > > 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. > > > > > > It seems this broke the kernel build. I did some scratch build today > > > to test some patches, but it failed with this: > > > > > > + /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir > > > /etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s > > > pesign: Could not initialize nss. > > > NSS says "The certificate/key database is in an old, unsupported > > > format." errno says "No such file or directory" > > > error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) > > > RPM build errors: > > > Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) > > > Child return code was: 1 > > > > Probably related: https://github.com/rhboot/pesign/issues/34 > > I filed a bug against pesign here: > https://bugzilla.redhat.com/show_bug.cgi?id=1827902 > Shouldn't https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql have prevented such bugs? I.e., why didn't the default change get picked up automatically here? V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: dropping NSS DBM format support in F33+
Hello Ondrej, Ondrej Mosnacek writes: > On Fri, Apr 24, 2020 at 11:12 PM Ondrej Mosnacek wrote: >> On Fri, Apr 24, 2020 at 8:50 PM Ondrej Mosnacek wrote: >> > On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno wrote: >> > > 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. >> > >> > It seems this broke the kernel build. I did some scratch build today >> > to test some patches, but it failed with this: >> > >> > + /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir >> > /etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s >> > pesign: Could not initialize nss. >> > NSS says "The certificate/key database is in an old, unsupported >> > format." errno says "No such file or directory" >> > error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) >> > RPM build errors: >> > Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) >> > Child return code was: 1 >> >> Probably related: https://github.com/rhboot/pesign/issues/34 > > I filed a bug against pesign here: > https://bugzilla.redhat.com/show_bug.cgi?id=1827902 Good catch, and thank you for filing the bug. For the meantime I reverted the DBM disablement to unblock the kernel package build: https://src.fedoraproject.org/rpms/nss/c/fc0174ead16bac476cce55fb2918fbfd9b448023?branch=master 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
coreos-assembler v0.8.0
The CoreOS team is pleased to announce the latest release of `coreos-assembler` - our opinionated build tool that we use to build and test Fedora CoreOS and Red Hat CoreOS. https://github.com/coreos/coreos-assembler/releases/tag/v0.8.0 The team created `coreos-assembler` as a way to bind together Ignition, `rpm-ostree`, and many other Fedora RPMs to build, test, and deliver Fedora CoreOS and Red Hat CoreOS artifacts. `coreos-assembler` is delivered as a container image (quay.io/coreos/coreos-assembler), ready to be run via "rootless" `podman`, and provides an easy on-ramp for people and projects that want a "custom" Fedora CoreOS style system. Check out the release notes via the tag above and come talk to us at our usual places: - #fedora-coreos on Freenode - CoreOS category on the forums - https://discussion.fedoraproject.org/c/server/coreos/5 Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Fedora 33 Rawhide 20200425.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 33 Rawhide 20200425.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly 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/33 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_33_Rawhide_20200425.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200425.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200425.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200425.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200425.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200425.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200425.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ 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: boost package in fedora
Thank you. пт, 24 апр. 2020 г., 14:40 Jonathan Wakely : > On 20/04/20 15:43 +0300, Vascom wrote: > >Will Boost ever be updated on Fedora again? > > > >https://bugzilla.redhat.com/show_bug.cgi?id=1558278 > > Yes. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 Sat, Apr 25, 2020 at 7:24 AM Kevin Kofler wrote: > Richard Shaw wrote: > > As far as LCPNet itself I've communicated with the primary developer > quite > > a bit over the last week. LPCNet *will not work* without optimizations > (at > > least not in real time which is the point). > > Has anyone (upstream or elsewhere) ever looked into doing an SSE2 version > of > the vector code? It should be faster than scalar (especially considering > that the "scalar" floating-point code (under the default -mfpmath=sse) > actually loads everything into SSE2 registers as well, but does not > actually > make use of the vectorization) and it would match the baseline of many > distributions and upstreams out there. > Well, I think that would be a bit beyond us ham radio guys, the version we're using is a fork of the main project: https://github.com/mozilla/LPCNet Which only provides AVX, AVX2, and NEON options. I don't think the NEON one is even fast enough (due the the hardware that uses it more than the instruction set). > > I think we're going to work towards a static build option, we just have > to > > figure out the mechanics. The main application does check for AVX/AVX2 > and > > disables the 2020 mode if it's not available. > > Well, if the application does the runtime detection, I guess you can get > away with relying on that. The problems will start if some other > application > comes and wants to use the library unconditionally. > I think the direction we're heading is to include it in the package of the main FreeDV program. This fork is tightly connected to FreeDV/codec2. Planning either a static build or private library. 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?
Hi Rechard, I recommend using the simde (SIMD Everywhere) library for the packaging and contribution to the upstream. https://github.com/nemequ/simde You do not need to care about the availability by arch or compiler when using this library. simde-devel is available in Fedora stable versions now. [1] libsimde-dev is available in Debian, hopefully soon available to the stable versions and Ubuntu. [2] Here are the actual examples 1 [3] and 2 [4] implementing it. [1] https://src.fedoraproject.org/rpms/simde/ [2] https://wiki.debian.org/SIMDEverywhere [3] https://github.com/lh3/minimap2/pull/597 [4] https://github.com/BenLangmead/bowtie2/blob/master/sse_wrap.h -- 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: What CPU extensions can we assume are available by arch?
Richard Shaw wrote: > As far as LCPNet itself I've communicated with the primary developer quite > a bit over the last week. LPCNet *will not work* without optimizations (at > least not in real time which is the point). Has anyone (upstream or elsewhere) ever looked into doing an SSE2 version of the vector code? It should be faster than scalar (especially considering that the "scalar" floating-point code (under the default -mfpmath=sse) actually loads everything into SSE2 registers as well, but does not actually make use of the vectorization) and it would match the baseline of many distributions and upstreams out there. That said, of course, it would still be slower than AVX and hence possibly still too slow for real time (also considering that pre-AVX CPUs are typically slower to begin with). I guess it would have to be tried to see whether it can work. > I think we're going to work towards a static build option, we just have to > figure out the mechanics. The main application does check for AVX/AVX2 and > disables the 2020 mode if it's not available. Well, if the application does the runtime detection, I guess you can get away with relying on that. The problems will start if some other application comes and wants to use the library unconditionally. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-20200425.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 2/8 (x86_64) Old failures (same test failed in Fedora-IoT-33-20200423.0): ID: 586597 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/586597 ID: 586598 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/586598 Skipped non-gating openQA tests: 6 of 8 -- 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?
Sam Varshavchik wrote: > 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 ... And even that is not safe to assume. The baseline is SSE2, nothing more. No SSE3, SSSE3, SSE4.1, SSE4.2, AVX(1), AVX2, and most definitely no AVX-512 (none of the defined subsets of it). For any of these, CPU support MUST be detected at runtime before attempting to use them. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Boost 1.73.0 will obsolete boost-nowide in rawhide
Hi, I've just created a change proposal to update Boost in rawhide to the latest upstream package, 1.73.0, due out any day now. This will include Boost.Nowide, so I think the standalone boost-nowide currently in Fedora should be retired for F33. The alternative would be to omit the nowide library from the main boost package, but I don't see any great advantage to doing that. Another significant change is that upstream Boost no longer installs the 'bjam' executable, which we ship in the boost-jam subpackage. That executable was renamed to 'b2' nine years ago[1] but Fedora has only ever shipped it as the old name, bjam. Since upstream no longer installs 'bjam' I'm going to replace the boost-jam package with boost-b2 which provides /usr/bin/b2. It would be possible to install it as both bjam and b2 for one release to give users a chance to transition, although my guess is that while bjam is available nobody will change, and so it just delays the switch for a release. As far as I can tell, no packages in Fedora make use of boost-jam or /usr/bin/bjam so this only affects users' own code (and I don't know how many people use bjam/b2 for their own projects). [1] https://boostorg.github.io/build/manual/master/index.html#bbv2.faq.names ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Fri, Apr 24, 2020 at 6:10 PM Steven Munroe wrote: > > The Linux kernel notified each process of the Platform and Hardware > Capabilities it the AUX Vector (Defined in the Application Binary > Interface Document for each platform). The compilers provide a easy to > use interface to interrogate this: > > https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations.html#Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations > . > Similarly for x86. > > This is the mechanism that the dynamic linker / runtime use to select > the best implementation (of for example memcpy or cosf128) based on > the platform (POWER8 vs POWER9). > > This CAN be used by any project/package. I am working on documenting > this (implementing dynamic IFUNC selection for platform specific > optimizations) as part of the PVECLIB project. If interested send me a > note. > This explanation helps quite a bit. Thanks. However, I'm not really a programmer. My "developer" duties for the varios freetel projects are largely limited to creating/managing the CMake build system. As far as LCPNet itself I've communicated with the primary developer quite a bit over the last week. LPCNet *will not work* without optimizations (at least not in real time which is the point). I think we're going to work towards a static build option, we just have to figure out the mechanics. The main application does check for AVX/AVX2 and disables the 2020 mode if it's not available. 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: Previous awesome background images
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 think that one is artistically beautiful, but the deep winter feeling that it gives is depressing. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Chris Murphy wrote: > I have the benefit of looking at the background on a crap laptop > display as well as a rather nice NEC self-calibrating display suitable > for medical imaging. And this background looks good to me on both > displays. That's non-trivial to achieve, there are always compromises. > It's not really possible to make smooth gradients of short distances > on low end panels, of course some noise is necessary. So in short, you are saying that this artwork is great because it looks good on some 16-color or 256-color display, which it achieves by looking like a 256-color display on ALL displays? Seriously? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: dropping NSS DBM format support in F33+
On Fri, Apr 24, 2020 at 11:12 PM Ondrej Mosnacek wrote: > On Fri, Apr 24, 2020 at 8:50 PM Ondrej Mosnacek wrote: > > On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno wrote: > > > 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. > > > > It seems this broke the kernel build. I did some scratch build today > > to test some patches, but it failed with this: > > > > + /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir > > /etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s > > pesign: Could not initialize nss. > > NSS says "The certificate/key database is in an old, unsupported > > format." errno says "No such file or directory" > > error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) > > RPM build errors: > > Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) > > Child return code was: 1 > > Probably related: https://github.com/rhboot/pesign/issues/34 I filed a bug against pesign here: https://bugzilla.redhat.com/show_bug.cgi?id=1827902 -- Ondrej Mosnacek Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-20200425.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20200425.0 compose check report
No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 586595 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/586595 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-30-20200425.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
Quick review
I have what should be a very simple review here. Just a MinGW build of an existing Fedora package. Anyone looking for something simple, or a quick swap? https://bugzilla.redhat.com/show_bug.cgi?id=1827887 --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
