Re: x86_64-v2 in Fedora
On Wed, Jun 16, 2021 at 12:37:57PM +0200, Eugene Syromiatnikov wrote: > On Wed, Jun 16, 2021 at 09:28:47AM +0100, Daniel P. Berrangé wrote: > > On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote: > > > Hey all, > > > > > > Earlier this week, I was helping with processing features for openSUSE > > > Leap 15.4[1] and I discovered that they're planning on introducing > > > x86_64-v2 to openSUSE soon. The reference for this change was that > > > RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions > > > have been considering bumping up to v2 or v3[3][4]. > > > > > > Some cursory examination of the new x86_64 sublevels seem to indicate > > > that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the > > > first couple of generations of x86_64 CPUs from Intel and AMD. I > > > personally don't have any computers that don't have support for > > > x86_64-v2 anymore. > > > > Yes, you loose primarily Intel Conroe and Penryn generations and > > AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion > > of Fedora installs. > > What many seem to confuse here is when there were the first CPUs > that support a particular set of instruction versus the last one that > does not. Intel almost prides itself on its product segmentation, > and there is a ton of recently (in 2020!) released Pentium/Celeron/Atom > CPUs that still do not support even AVX[1][2]. > > [1] > https://ark.intel.com/content/www/us/en/ark/products/203896/intel-pentium-gold-g6400e-processor-4m-cache-3-80-ghz.html > released in Q2 2020, only SSE4.1/4.2 is listed, cf. > > https://ark.intel.com/content/www/us/en/ark/products/199283/intel-core-i3-10100-processor-6m-cache-up-to-4-30-ghz.html > [2] > https://www.tomshardware.com/news/intels-latest-celeron-and-pentium-cpus-finally-get-avx2-avx-512-support Oops, I confused "Gen 3" above with x86_64-v3; however, with regards to v2 support, Westmere-based Pentiums/Celerons were released in 2011 and do not support SSE4.1/4.2. [1] https://www.cpu-world.com/sspec/SL/SLBT6.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: x86_64-v2 in Fedora
On Wed, Jun 16, 2021 at 09:28:47AM +0100, Daniel P. Berrangé wrote: > On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote: > > Hey all, > > > > Earlier this week, I was helping with processing features for openSUSE > > Leap 15.4[1] and I discovered that they're planning on introducing > > x86_64-v2 to openSUSE soon. The reference for this change was that > > RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions > > have been considering bumping up to v2 or v3[3][4]. > > > > Some cursory examination of the new x86_64 sublevels seem to indicate > > that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the > > first couple of generations of x86_64 CPUs from Intel and AMD. I > > personally don't have any computers that don't have support for > > x86_64-v2 anymore. > > Yes, you loose primarily Intel Conroe and Penryn generations and > AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion > of Fedora installs. What many seem to confuse here is when there were the first CPUs that support a particular set of instruction versus the last one that does not. Intel almost prides itself on its product segmentation, and there is a ton of recently (in 2020!) released Pentium/Celeron/Atom CPUs that still do not support even AVX[1][2]. [1] https://ark.intel.com/content/www/us/en/ark/products/203896/intel-pentium-gold-g6400e-processor-4m-cache-3-80-ghz.html released in Q2 2020, only SSE4.1/4.2 is listed, cf. https://ark.intel.com/content/www/us/en/ark/products/199283/intel-core-i3-10100-processor-6m-cache-up-to-4-30-ghz.html [2] https://www.tomshardware.com/news/intels-latest-celeron-and-pentium-cpus-finally-get-avx2-avx-512-support ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Wed, Feb 17, 2021 at 08:14:47PM +0100, Pierre - Yves Chibon wrote: > On Wed, Feb 17, 2021 at 08:00:49PM +0100, Miro Hrončok wrote: > > On 17. 02. 21 19:46, Eugene Syromiatnikov wrote: > > > On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main > > > > > > > > == Summary == > > > > > > > > This Change will move Fedora git repositories to use "main" as the > > > > default git branch instead of "master". Specific repositories will be > > > > manually moved and default git branch for new projects will be set to > > > > use "main". > > > > > > The way this change has been performad made at least rpms/microcode_ctl > > > repository unusable[1][2] by koji. > > > > > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174686 > > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174675 > > > > The same happens locally: > > > > $ fedpkg clone microcode_ctl > > Cloning into 'microcode_ctl'... > > remote: Enumerating objects: 994, done. > > remote: Counting objects: 100% (994/994), done. > > remote: Compressing objects: 100% (773/773), done. > > remote: Total 994 (delta 477), reused 411 (delta 208), pack-reused 0 > > Receiving objects: 100% (994/994), 3.30 MiB | 3.01 MiB/s, done. > > Resolving deltas: 100% (477/477), done. > > fatal: cannot process 'refs/remotes/origin/rawhide' and > > 'refs/remotes/origin/rawhide/user/kyle/amd-ucode-2011-01-11' at the same > > time > > Could not execute clone: Failed to execute command. > > Could you try again? > > refs/heads/rawhide/user/kyle/amd-ucode-2011-01-11 has been renamed to > refs/heads/rawhide_old/user/kyle/amd-ucode-2011-01-11 > that should remove the conflict. It is working now, thank you! > > 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main > > == Summary == > > This Change will move Fedora git repositories to use "main" as the > default git branch instead of "master". Specific repositories will be > manually moved and default git branch for new projects will be set to > use "main". The way this change has been performad made at least rpms/microcode_ctl repository unusable[1][2] by koji. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174686 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=62174675 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: youtube-dl Copyright Violations
On Mon, Oct 26, 2020 at 12:13:07PM +0100, Vitaly Zaitsev via devel wrote: > On 26.10.2020 11:28, Damian Ivanov wrote: > >Well if some tests do download copyrighted material, > >I wonder how this has become blocked in the first place... > > I think upstream can easily move the tests to a separate repository and > remove the copyrighted URLs from the documentation. IANAL, but I think that the crux of the RIAA's request is that the offending code used as an evidence of copyright-circumventing nature of the source code as a whole, so it's not that simple for having-h264-codec-in-a-separate-repository-for-legal-reasons Fedora. And this is indeed up to legal, may be youtube-dl RPM have to be a downloader for the actual source code now to be legally clean, or something. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package downgrades from fedora 32 -> fedora 33 (updated + annotated list inside)
On Sat, Oct 03, 2020 at 12:53:28AM +0200, Fabio Valentini wrote: > - strace is newer in 32 than in 33: > 0:5.8-1.fc32 > 0:5.7.0.6.7ab6-1.fc33 FWIW, the 5.9-1 version is available (but not in 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: This is bad, was Re: Fedora 33 System-Wide Change proposal:???? systemd-resolved
On Fri, Oct 02, 2020 at 09:23:12AM -0400, Solomon Peachy wrote: > On Fri, Oct 02, 2020 at 02:34:15PM +0200, Eugene Syromiatnikov wrote: > > Only those that think that they are smarter that a user and ignore her/his > > privacy. > > In other words, all of them? > > FFS, if Fedora is "bad" for doing these things, how is MacOS, iOS, > Android, or even Windows acceptible? > > (out-of-the-box, that is. because that's what we're talking about here) They are not, and that is why people use Linux. > > The things in the list above definitely either shouldn't be > > done at all (like captive portla checks and checks for updates), or ask > > for explicit user consent (everything else). > > Great, more things for the user to click through *every single time*. The great UX invention of "do not ask this question again" saves the day again. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: This is bad, was Re: Fedora 33 System-Wide Change proposal:???? systemd-resolved
On Fri, Oct 02, 2020 at 07:16:38AM -0500, Michael Catanzaro wrote: > On Fri, Oct 2, 2020 at 12:34 am, Marius Schwarz > wrote: > >If you send a DNS REQUEST to a US DNS server from within a company > >network, and with ipv6 the internal ip is sent out i learned lately, you > >have sent personal data which is protected under the GDRP. It's not > >unlikely to use company pcs for private webvisits while having a meal > >break. > > Hm, thanks for the explanation. I guess the DNS request would indeed be the > *first* way you lose, because you have to do DNS before you do anything > else. But you are going to lose immediately after anyway: > > * Immediately after you connect to the network, Fedora connects to > http://fedoraproject.org/static/hotspot.txt to see if you're behind a > captive portal > * Next, GNOME Software starts checking for updates in the background. You've > leaked "personal data" to fedoraproject.org again, and also fwupd. > * You open Firefox, it downloads Safe Browsing data from Google. (Admittedly > this one is probably only behind a European CDN, but maybe Google is having > a bad day, or maybe IP address logs are sent to the US.) Oh yeah, it also > displays news from Pocket. Probably it does more connections to the US that > I don't know about. > * You switch to Financial Mode in Calculator, it downloads exchange rate > data. > * Anything crashes. A truncated stack trace gets sent to Fedora. > > I'm sure my list is missing quite a lot. > If your interpretation is correct, > then I suppose German companies should immediately discontinue use of > Fedora, and also most other computer operating systems Only those that think that they are smarter that a user and ignore her/his privacy. The things in the list above definitely either shouldn't be done at all (like captive portla checks and checks for updates), or ask for explicit user consent (everything else). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: systemd-resolved
On Tue, Sep 01, 2020 at 02:28:57PM +0200, Florian Weimer wrote: > There are also concerns that the DNS infrastructure cannot > handle the load unless there is one level of shared caching betweeen the > endpoints and the authoritative servers. Those DNS caches certainly > suppress some of the problematic client behavior (but they also add > their own share of broken queries, of course). Well, all that distributed caching hierarchy is undermined by some auxiliary non-DNS Google project anyway: https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormous-load-on-global-root-dns-servers/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: btrfs and default page sizes (4k vs 64k)
On Wed, Sep 16, 2020 at 03:04:45PM -0400, Josef Bacik wrote: > At the time we tied the fs blocksize to the > page size, because it was unlikely that a user would mkfs a fs on one arch > and move it over to another arch. But one doesn't need "another arch" for page size to change; many architectures (arm, mips, powerpc, sparc, to name a few) support multiple page sizes. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings
On Thu, Sep 10, 2020 at 10:36:18AM +0200, alcir...@posteo.net wrote: > On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote: > > > > > > A quick reminder that we're about to release with the system > > configured to use > > Google DNS when no DNS servers are configured. If privacy is valued > > at all, > > this needs to be addressed before release. > > > These DNS addresses are bundled upstream in systemd. And they are used > in the event of a misconfiguration of your network settings, isn't it? > However they are easily customizable in /etc/systemd/resolved.conf > (FallbackDNS option) It's about the distribution's default setting, not a configuration possibility. > And for the records: https://github.com/systemd/systemd/issues/8782 > > The same thing is true for system time and date (systemd default to > Google NTP servers). But as far as I can see it is already addressed > here > https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329 I believe that it is the point of the John's e-mail: this issue is still *not* addressed in Fedora. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction: Eugene Syromiatnikov
Hello. My name is Eugene Syromiatnikov, I am a Software Engineer at Red Hat, an IBM company. I maintain strace and microcode_ctl packages in RHEL, among other things. Also, I am a strace developer and used to contribute to the MoinMoin wiki project. My main areas of interests are computer architecture, low-level programming, and high-performance computing. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Download all build artifacts from a scratch build?
On Wed, Jul 29, 2020 at 07:37:31AM -0500, Richard Shaw wrote: > I'm working on fixing a package but I have to use scratch builds because > the tests only pass when running on koji, not a local mock build. It > produces several rpms which I'd like to download for testing purposes. > > Currently I have to go to the url of the scratch build and download them > individually. Is there an easier way? koji download-task ? > https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds > > didn't provide any help. > > 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
