Fedora-Cloud-33-20211118.0 compose check report
No missing expected images. Failed openQA tests: 1/8 (x86_64) New failures (same test not failed in Fedora-Cloud-33-2024.0): ID: 1065838 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli URL: https://openqa.fedoraproject.org/tests/1065838 Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-2024.0): ID: 1065834 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1065834 ID: 1065843 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1065843 Passed openQA tests: 6/8 (x86_64), 7/8 (aarch64) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: Reduce number of packages that are built for i686
Nov 17, 2021 4:56:36 AM Zbigniew Jędrzejewski-Szmek : > On Wed, Nov 17, 2021 at 10:53:30AM +, Zbigniew Jędrzejewski-Szmek wrote: > [...] >> >> And obviously the advantage is that this can be done now, and doesn't >> require any new infra or maintenance. The only trick would be how to >> figure out the transitive BR tree, but apparently there are some scripts >> that people have. > > s/people/Fabio/ ;) Fabio, Can you please provide a link to your script? Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Add a game grou;p to https://src.fedoraproject.org/groups
https://src.fedoraproject.org/groups Thoughts? ___ 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: Announcing LLVM Snapshot Packages for Fedora Linux
Cool, how about a llvm-git package when it gets more testing? ___ 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: RFC: Reduce number of packages that are built for i686
On Wed, Nov 17, 2021 at 10:07 PM Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 17 November 2021 at 18:58, Peter Robinson wrote: > [...] > > What else is there that people care about in Fedora that's only i686? > > There are some old proprietary games with i686-only binaries. I'll check > which packages are required by the ones I have. I think the easy answer here is, indeed, "games". And for some Fedora users, that might not be an important use case. But given the increased interest in "Gaming on Linux" (even though some tech YouTubers still consider Fedora a hat meme distro), I think this is something Fedora as an increasingly popular "mainstream" linux distribution should definitely continue to support. However, wine, as packaged for Fedora - I assume to support running both 32-bit and 64-bit windows applications - requires both x86_64 and i686 libraries on x86_64: $ sudo dnf repoquery --requires wine --resolve --recursive | grep i686 | wc -l 255 So, wine needs i686 multilib packages on x86_64 even if you don't want to use it to run games, but just for running *any* Windows application. Additionally, the steam RPM (as provided by the opt-in third-party repository that comes installed by default with Fedora Workstation) is a i686-only package (sad face), and hence also pulls in i686 libraries: $ sudo dnf repoquery --requires steam --resolve --recursive | grep i686 | wc -l 221 And any "older" games you want to play from Steam (or GOG, or wherever) will also require i686 libraries, as they're probably 32-bit only applications (if they're even linux native binaries, otherwise they'll require wine, which *also* pulls in i686 libraries). Considering there's a big overlap between those two package sets (steam + wine dependencies) and that some of those i686-arch packages are actually subpackages of the same source package, the number of i686 packages we need to support for the two only important use cases of i686 multilib should be around 200, plus their build-only dependencies. Two Hundred (or even make it 300) packages - that's around 1% of the whole corpus of Fedora packages (with almost 23000 source packages in rawhide). Which I think confirms my suspicion that just building *everything* for i686 is 99% wasteful ... (Yes, yes, I know that some of those 23000 packages are noarch, like python or perl stuff ... don't go fetching your torches and pitchforks just yet.) Fabio ___ 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: F37 Change: RetireARMv7 (System-Wide Change proposal)
On 11/16/21 7:05 PM, Kevin Kofler via devel wrote: > Realistically, they will just stick to Fedora 36 forever and just stop > updating the devices (or try updating them anyway and get no updates from > the server, obviously). > > Sticking an EOL label on a software release is not going to magically make > it go away. Maybe so, but what can we do? We already did this for i686 hosts, and I'll bet there are still folks running F30 for that, or even EOL versions of currently supported arches. They may exist, but they "go away" from the perspective of what we choose to 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: F36 Change: Unit Names in Systemd Messages (Self-Contained Change proposal)
On Wed, Nov 17, 2021 at 01:49:00PM -0500, Matthew Miller wrote: > On Mon, Nov 15, 2021 at 09:06:49AM -0500, Ben Cotton wrote: > > Started Journal Service. > > Finished Load Kernel Modules. > > Starting Apply Kernel Variables... > > Starting Create Volatile Files and Directories... > > Finished Apply Kernel Variables. > [...] > > Started systemd-journald.service - Journal Service. > > Finished systemd-modules-load.service - Load Kernel Modules. > > Finished systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in > > /dev. > > Starting systemd-sysctl.service - Apply Kernel Variables... > [...] > > This is pretty bikesheddy, but... I find the new format hard to follow > because the service names _aren't_ easily readable, and the following > human-readable text has ragged-left-edge alignment. > > Would something like > > Started Journal Service (systemd-journald.service). > Finished Load Kernel Modules (systemd-modules-load.service). > Finished Create Static Device Nodes in /dev > (systemd-tmpfiles-setup-dev.service) > etc. > > be possible? This was one of the versions proposed when we were implementing this upstream. We ultimately chose the one proposed, primarily because it is expected that truncation will occur e.g. on 80 char ttys, and it is better if the description is truncated, rather than the unit name. Also, in the 'name' format, the name is the only thing that is displayed, and I think this is the format is the most useful. It is then nice that the 'combined' format is an extension of 'name', and not something completely different. On the console, the unit name part is highlighted, so it's not so wall-of-texty as in the example I pasted. Zbyszek ___ 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: RFC: Reduce number of packages that are built for i686
On Wed, Nov 17, 2021 at 05:58:43PM +, Peter Robinson wrote: > > What else is there that people care about in Fedora that's only i686? Well, wine? I don't know how much 32bit wine is used these days. And not 'in fedora', but people always bring up steam when these disccussions happen. I wonder why they are sticking with 32bit? kevin 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: Reduce number of packages that are built for i686
On Wednesday, 17 November 2021 at 18:58, Peter Robinson wrote: [...] > What else is there that people care about in Fedora that's only i686? There are some old proprietary games with i686-only binaries. I'll check which packages are required by the ones I have. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Unit Names in Systemd Messages (Self-Contained Change proposal)
On 11/17/21 13:49, Matthew Miller wrote: Finished systemd-modules-load.service - Load Kernel Modules. Finished systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev. Starting systemd-sysctl.service - Apply Kernel Variables... [...] Would something like Started Journal Service (systemd-journald.service). Finished Load Kernel Modules (systemd-modules-load.service). Finished Create Static Device Nodes in /dev (systemd-tmpfiles-setup-dev.service) etc. be possible? I find Matthew's version much easier to read and comprehend, especially when it comes as a wall of startup text. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Firefox Hardware acceleration & VA-API how-to
VDPAU is not VA-API that's correct Setting VDPAU_DRIVER means nothing to Firefox because it is not using VDPAU. https://fedoraproject.org/wiki/Changes/VA-API_1.0.0#Detailed_Description https://ffmpeg.org/doxygen/0.8/group__VDPAU__Decoding.html "libva-vdpau-driver which allows to use the VA-API enabled players with VDPAU backend (such as NVIDIA binary driver)." https://trac.ffmpeg.org/wiki/HWAccelIntro#PlatformAPIAvailability VDPAU / Linux / NVIDIA -> 'Fully usable' ffmpeg -hwaccels ... Hardware acceleration methods: vdpau cuda vaapi qsv drm opencl vulkan find/dl a 'busy' 4K+ h264 vid e.g. @ https://jell.yfish.us/media/jellyfish-250-mbps-4k-uhd-h264.mkv T="jellyfish-250-mbps-4k-uhd-h264.mkv" F="jellyfish-250-mbps-4k-uhd-h264.mp4" ffmpeg -i ${T} -codec copy ${F} ls -al ${F} ${T} -rw-r--r-- 1 test test 896M Dec 21 2016 jellyfish-250-mbps-4k-uhd-h264.mkv -rw-r--r-- 1 test test 896M Nov 17 14:37 jellyfish-250-mbps-4k-uhd-h264.mp4 exec un-accel'd FFmpeg decoder rm -f test.ts && ffmpeg -i ${F} test.ts sar 1 100 Linux 5.14.17-301.fc35.x86_64 (test.loc)11/17/2021 _x86_64_(16 CPU) 02:23:27 PM CPU %user %nice %system %iowait %steal %idle 02:23:28 PM all 0.38 0.00 0.50 1.95 0.00 97.17 02:23:29 PM all 19.29 0.00 1.44 0.00 0.00 79.27 02:23:30 PM all 88.85 0.13 2.01 0.00 0.00 9.02 02:23:31 PM all 88.08 0.00 1.63 0.00 0.00 10.29 02:23:32 PM all 87.38 0.00 1.87 0.00 0.00 10.74 02:23:33 PM all 89.01 0.00 1.76 0.06 0.00 9.17 02:23:34 PM all 87.81 0.06 1.95 0.00 0.00 10.18 02:23:35 PM all 87.95 0.06 1.62 0.00 0.00 10.37 02:23:36 PM all 89.77 0.00 1.95 0.00 0.00 8.29 02:23:37 PM all 89.36 0.00 2.00 0.00 0.00 8.64 02:23:38 PM all 55.63 0.13 1.32 0.19 0.00 42.74 02:23:39 PM all 0.44 0.00 0.56 0.00 0.00 99.00 02:23:40 PM all 0.62 0.00 0.56 0.06 0.00 98.75 ... exec vaapi<-vdpau accel'd VA-API FFmpeg decoder rm -f test.ts && ffmpeg -hwaccel vdpau -i ${F} test.ts sar 1 100 Linux 5.14.17-301.fc35.x86_64 (test.loc)11/17/2021 _x86_64_(16 CPU) 02:29:09 PM CPU %user %nice %system %iowait %steal %idle 02:29:10 PM all 0.63 0.06 0.31 0.00 0.00 99.00 02:29:11 PM all 0.50 0.00 0.69 0.25 0.00 98.56 02:29:12 PM all 8.48 0.13 2.07 0.31 0.00 89.01 02:29:13 PM all 31.32 0.00 2.76 0.00 0.00 65.91 02:29:14 PM all 31.47 0.00 2.01 0.00 0.00 66.52 02:29:15 PM all 33.98 0.00 2.81 0.00 0.00 63.21 02:29:16 PM all 34.43 0.12 2.79 0.12 0.00 62.54 02:29:17 PM all 32.87 0.13 2.38 0.44 0.00 64.18 02:29:18 PM all 30.01 0.00 2.62 0.19 0.00 67.19 02:29:19 PM all 27.51 0.06 2.62 0.00 0.00 69.81 02:29:20 PM all 29.92 0.06 2.61 0.00 0.00 67.41 02:29:21 PM all 28.58 0.00 2.59 0.06 0.00 68.77 02:29:22 PM all 28.25 0.00 2.46 0.13 0.00 69.17 02:29:23 PM all 5.11 0.06 1.62 0.00 0.00 93.20 02:29:24 PM all 0.31 0.00 0.31 0.00 0.00 99.37 02:29:25 PM all 0.87 0.12 0.81 0.06 0.00 98.13 no vaapi without vdpau translation rm -f test.ts && ffmpeg -hwaccel vaapi -i ${F} test.ts [AVHWDeviceContext @ 0x557bc805f840] libva: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null) [AVHWDeviceContext @ 0x557bc805f840] Failed to initialise VAAPI connection: -1 (unknown libva error). Device creation failed: -5.
Fedora CoreOS Meeting Minutes 2021-11-17
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-17/fedora_coreos_meeting.2021-11-17-16.31.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-17/fedora_coreos_meeting.2021-11-17-16.31.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-17/fedora_coreos_meeting.2021-11-17-16.31.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by dustymabe at 16:31:24 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2021-11-17/fedora_coreos_meeting.2021-11-17-16.31.log.html . Meeting summary --- * roll call (dustymabe, 16:31:28) * Action items from last meeting (dustymabe, 16:36:21) * jlebon filed https://github.com/coreos/fedora-coreos-tracker/issues/1024 (jlebon, 16:36:48) * During major version rebases, align FCOS testing with GA (dustymabe, 16:38:23) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1024 (dustymabe, 16:38:32) * we'll discuss this in january 2022 when the F35 rebase has landed in our stable stream and any currently unknown issues have been fleshed out (dustymabe, 16:46:19) * work items awaiting some action (dustymabe, 16:47:22) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues?q=is%3Aissue+is%3Aopen+label%3Astatus%2Fpending-action (dustymabe, 16:47:34) * - call for topics (dustymabe, 16:51:40) * Make publicly accessible coreos-assembler builds for architectures != x86_64 (dustymabe, 16:53:52) * LINK: https://github.com/coreos/coreos-assembler/issues/2470 (dustymabe, 16:53:57) * LINK: https://github.com/coreos/enhancements/pull/7 makes the OSBS alignment much stronger (walters, 16:57:30) * we'll investigate OSBS further to see if that solution can possibly solve our needs here without too many contraints (dustymabe, 17:05:17) * open floor (dustymabe, 17:05:52) Meeting ended at 17:15:27 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (84) * jlebon (25) * zodbot (22) * walters (12) * travier[m] (11) * davdunc (8) * jdoss (6) * lucab (3) * jmarrero (2) * nemric (1) * miabbott (1) * ravanelli (1) * mnguyen_ (1) * bgilbert (1) Generated by `MeetBot`_ 0.3 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ 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: F36 Change: Unit Names in Systemd Messages (Self-Contained Change proposal)
On Mon, Nov 15, 2021 at 09:06:49AM -0500, Ben Cotton wrote: > Started Journal Service. > Finished Load Kernel Modules. > Starting Apply Kernel Variables... > Starting Create Volatile Files and Directories... > Finished Apply Kernel Variables. [...] > Started systemd-journald.service - Journal Service. > Finished systemd-modules-load.service - Load Kernel Modules. > Finished systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in > /dev. > Starting systemd-sysctl.service - Apply Kernel Variables... [...] This is pretty bikesheddy, but... I find the new format hard to follow because the service names _aren't_ easily readable, and the following human-readable text has ragged-left-edge alignment. Would something like Started Journal Service (systemd-journald.service). Finished Load Kernel Modules (systemd-modules-load.service). Finished Create Static Device Nodes in /dev (systemd-tmpfiles-setup-dev.service) etc. be possible? -- Matthew Miller Fedora Project Leader ___ 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: RFC: Reduce number of packages that are built for i686
> > > Since it's not practical to modify almost all Fedora packages to add > > > "ExcludeArch: %{ix86}" to them, we'd probably need a different > > > machanism for this. I have a vague idea: > > > > Is it really not? This seems the easiest way to go about it, honestly - > > just have it be permitted for maintainers to opt their stuff out of > > building on x86 and let the problem take care of itself recursively. > > Yeah, I think I'd go this way too. Instead of trying to maintain this > centrally in koji, do it at package level, using proven-packager privileges > to smooth the initial process. > > I.e. something like: OK, we don't want to build libreoffice for i686. > libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same time* > any packages which (transitively) BR:libreoffice, are also annotated. > (They don't even need to be rebuild.) > And then repeat for another "big" package. > > I think this way to go is OK because we mostly care about some of the > "big" packages that take a long time to build. Most low-level packages > build just fine on i686 so we don't care if they are built unnecessarily. > > And obviously the advantage is that this can be done now, and doesn't > require any new infra or maintenance. The only trick would be how to > figure out the transitive BR tree, but apparently there are some scripts > that people have. I know it's been discussed, and I don't really care enough to read old threads TBH, but I suppose the question is what is mlutilib actually used for. The usual reply is "legacy and proprietary apps". And of course it's fine to continue to support them but how many actually are there? From a RHEL perspective, RHEL-9 has now forked off, and that will be supported for 10+ years for "enterprise" even after RHEL-10 in ~ 3 years so enterprise has means of running them in a supported manner until 2032 if they so wish so does Red Hat still need i686? What else is there that people care about in Fedora that's only i686? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Firefox Hardware acceleration & VA-API how-to
On 11/17/21 8:26 AM, PGNet Dev wrote: On 11/16/21 22:48, Michael Cronenworth wrote: On 11/15/21 12:03 PM, PGNet Dev wrote: launch @ shell VDPAU_DRIVER=nvidia MOZ_LOG="Dmabuf:5, PlatformDecoderModule:5" firefox I think you mean: LIBVA_DRIVER_NAME=nvidia firefox nope. Take a closer look at all of those links you threw at me. :) VDPAU is not VA-API. Setting VDPAU_DRIVER means nothing to Firefox because it is not using VDPAU. ___ 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: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
On Wed, Nov 17, 2021 at 3:58 PM Iñaki Ucar wrote: > > On Wed, 17 Nov 2021 at 16:19, Peter Robinson wrote: > > > > On Wed, Nov 17, 2021 at 11:51 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Nov 17, 2021 at 03:49:55AM +0100, Kevin Kofler via devel wrote: > > > > Users are going to miss the iwconfig tool. Not only is it still being > > > > used > > > > out of habit (just like ifconfig from net-tools), but (also just like > > > > ifconfig) it is also much more user-friendly. E.g., running "iwconfig" > > > > without arguments prints a nice summary of the wireless devices and > > > > their > > > > properties, such as access point ESSID and BSSID, bit rate, signal > > > > level, > > > > etc., whereas running "iw" without arguments prints a 132-line help > > > > output > > > > with around a hundred different commands (with no explanation as to what > > > > they do, as that would require even more than 132 lines: the --help > > > > output > > > > is 445 lines long). "iw" also exposes implementation details in the most > > > > unfriendly way, by requiring the user to use "dev ", "phy > > > > ", "wdev ", or "reg" prefixes depending on the individual > > > > command (and it is entirely unclear to the user why something is a dev > > > > property, a phy property, or both), whereas "iwconfig" takes the same > > > > interface name for all commands. > > > > > > > > The new ip, iw, and route tools have clearly been designed by kernel > > > > developers for kernel developers, not for end users or even system > > > > administrators. The old ifconfig and iwconfig are much easier to use. > > > > > > The same applies for nft and ss ;) Those tools are supposed to be the > > > future, > > > but using them feels as if the people who wrote them never used them. > > > > > > Dunno, maybe we can keep wireless-tools package? Is it a burden to > > > keep in the distro? > > > > The problems is it doesn't provide huge amounts of useful information > > for modern HW like anything after 11a/11g like no support for > > 11n/ac/ax HW and it doesn't report a lot of the newer available > > frequencies like newer added 5Ghz bands so while it does provide some > > slightly useful information if you actually look closely a lot of it > > is actually incorrect. > > > > For example it reports I don't have encryption on my 11ac WiFi which > > is connected to a WPA3 AP likely because it doesn't understand it. Is > > the nicely formatted information useful if it's actively wrong? It > > would probably more useful to alias iwconfig to "iw dev" as that > > information is close to what iwconfig provides but is actually > > accurate on vaguely modern hardware. > > "iw dev" reports SSID, channel number and a lot of other useless > information, such as center and width of the channel (iwconfig reports > current bitrate, link quality and signal level, which are far more > useful), MAC (iwconfig reports the APs MAC instead) or multicast > statistics that are all equal to 0. I don't see what piece of output > from iwconfig is not accurate, at least with my hardware (11ac). It doesn't report encryption, it doesn't report any of the 5ghz channels that weren't in the origianl 11a spec just to name a few. ___ 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
License changes in KiCad
I am building kicad-6.0.0-rc1 for rawhide. As compared to the previous 5.1 series of builds, there are some license changes in the new 6.0 series, as follows: The main package changes from "AGPLv3+" to "GPLv3+" The doc package changes from "CC-BY-SA 4.0 with exception" to "CC-BY-SA" The 3d models package changes from "GPLv3+ or CC-BY-3.0+" to "GPLv3+ or CC-BY" Steve ___ 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: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
On Wed, 17 Nov 2021 at 16:19, Peter Robinson wrote: > > On Wed, Nov 17, 2021 at 11:51 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Nov 17, 2021 at 03:49:55AM +0100, Kevin Kofler via devel wrote: > > > Users are going to miss the iwconfig tool. Not only is it still being used > > > out of habit (just like ifconfig from net-tools), but (also just like > > > ifconfig) it is also much more user-friendly. E.g., running "iwconfig" > > > without arguments prints a nice summary of the wireless devices and their > > > properties, such as access point ESSID and BSSID, bit rate, signal level, > > > etc., whereas running "iw" without arguments prints a 132-line help output > > > with around a hundred different commands (with no explanation as to what > > > they do, as that would require even more than 132 lines: the --help output > > > is 445 lines long). "iw" also exposes implementation details in the most > > > unfriendly way, by requiring the user to use "dev ", "phy > > > ", "wdev ", or "reg" prefixes depending on the individual > > > command (and it is entirely unclear to the user why something is a dev > > > property, a phy property, or both), whereas "iwconfig" takes the same > > > interface name for all commands. > > > > > > The new ip, iw, and route tools have clearly been designed by kernel > > > developers for kernel developers, not for end users or even system > > > administrators. The old ifconfig and iwconfig are much easier to use. > > > > The same applies for nft and ss ;) Those tools are supposed to be the > > future, > > but using them feels as if the people who wrote them never used them. > > > > Dunno, maybe we can keep wireless-tools package? Is it a burden to > > keep in the distro? > > The problems is it doesn't provide huge amounts of useful information > for modern HW like anything after 11a/11g like no support for > 11n/ac/ax HW and it doesn't report a lot of the newer available > frequencies like newer added 5Ghz bands so while it does provide some > slightly useful information if you actually look closely a lot of it > is actually incorrect. > > For example it reports I don't have encryption on my 11ac WiFi which > is connected to a WPA3 AP likely because it doesn't understand it. Is > the nicely formatted information useful if it's actively wrong? It > would probably more useful to alias iwconfig to "iw dev" as that > information is close to what iwconfig provides but is actually > accurate on vaguely modern hardware. "iw dev" reports SSID, channel number and a lot of other useless information, such as center and width of the channel (iwconfig reports current bitrate, link quality and signal level, which are far more useful), MAC (iwconfig reports the APs MAC instead) or multicast statistics that are all equal to 0. I don't see what piece of output from iwconfig is not accurate, at least with my hardware (11ac). -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Firefox Hardware acceleration & VA-API how-to
Am 17.11.21 um 15:26 schrieb PGNet Dev: On 11/16/21 22:48, Michael Cronenworth wrote: On 11/15/21 12:03 PM, PGNet Dev wrote: launch @ shell VDPAU_DRIVER=nvidia MOZ_LOG="Dmabuf:5, PlatformDecoderModule:5" firefox I think you mean: LIBVA_DRIVER_NAME=nvidia firefox nope. https://en.wikipedia.org/wiki/Video_Acceleration_API "As of 2019, VA-API is natively supported by libva-vdpau-driver for cards supported by VDPAU" libva-vdpau-driver is the translation layer that provides a VDPAU-based backend for VA-API. @ https://wiki.archlinux.org/title/Hardware_video_acceleration#Configuring_VDPAU " Configuring VDPAU You can override the driver for VDPAU by using the VDPAU_DRIVER environment variable. The correct driver name depends on your setup: ... For NVIDIA's proprietary version set it to nvidia. Note: You can find the installed drivers in /usr/lib/vdpau/. They are used as /usr/lib/vdpau/libvdpau_${VDPAU_DRIVER}.so " ls -al /usr/lib64/vdpau//libvdpau*nvidia* lrwxrwxrwx 1 root root 25 Nov 15 10:04 /usr/lib64/vdpau//libvdpau_nvidia.so.1 -> libvdpau_nvidia.so.495.44* -rwxr-xr-x 1 root root 620K Nov 15 10:04 /usr/lib64/vdpau//libvdpau_nvidia.so.495.44* cref: https://wiki.archlinux.org/title/Hardware_video_acceleration#VDPAU_drivers https://wiki.archlinux.org/title/Hardware_video_acceleration#NVIDIA_driver_only https://wiki.archlinux.org/title/Hardware_video_acceleration#Application_support Have you actually been able to get this working with Firefox? I tried a while ago and failed. IIRC the predominant opinion online was that libva-vdpau-driver, which was not updated in almost a decade, was good for passing vainfo but not for much else. Best regards. Julian ___ 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: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
On Wed, Nov 17, 2021 at 11:51 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Nov 17, 2021 at 03:49:55AM +0100, Kevin Kofler via devel wrote: > > Users are going to miss the iwconfig tool. Not only is it still being used > > out of habit (just like ifconfig from net-tools), but (also just like > > ifconfig) it is also much more user-friendly. E.g., running "iwconfig" > > without arguments prints a nice summary of the wireless devices and their > > properties, such as access point ESSID and BSSID, bit rate, signal level, > > etc., whereas running "iw" without arguments prints a 132-line help output > > with around a hundred different commands (with no explanation as to what > > they do, as that would require even more than 132 lines: the --help output > > is 445 lines long). "iw" also exposes implementation details in the most > > unfriendly way, by requiring the user to use "dev ", "phy > > ", "wdev ", or "reg" prefixes depending on the individual > > command (and it is entirely unclear to the user why something is a dev > > property, a phy property, or both), whereas "iwconfig" takes the same > > interface name for all commands. > > > > The new ip, iw, and route tools have clearly been designed by kernel > > developers for kernel developers, not for end users or even system > > administrators. The old ifconfig and iwconfig are much easier to use. > > The same applies for nft and ss ;) Those tools are supposed to be the future, > but using them feels as if the people who wrote them never used them. > > Dunno, maybe we can keep wireless-tools package? Is it a burden to > keep in the distro? The problems is it doesn't provide huge amounts of useful information for modern HW like anything after 11a/11g like no support for 11n/ac/ax HW and it doesn't report a lot of the newer available frequencies like newer added 5Ghz bands so while it does provide some slightly useful information if you actually look closely a lot of it is actually incorrect. For example it reports I don't have encryption on my 11ac WiFi which is connected to a WPA3 AP likely because it doesn't understand it. Is the nicely formatted information useful if it's actively wrong? It would probably more useful to alias iwconfig to "iw dev" as that information is close to what iwconfig provides but is actually accurate on vaguely modern hardware. ___ 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: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
On Wed, Nov 17, 2021 at 12:06 PM Solomon Peachy wrote: > > On Wed, Nov 17, 2021 at 11:30:40AM +0100, Iñaki Ucar wrote: > > I didn't complain. I'm not opposing, yet I'm acknowledging that it is > > not true that iwconfig is unused. It is very much used, if not just > > for printing the nice summary that the tool provides when called > > without arguments. > > IIRC there are still a few WEXT-only drivers for obsolete wifi hardware > in the Linux kernel. I don't know if Fedora builds them or not, but drop > iwconfig and that hardware becomes unusable under Fedora. (prism2_usb > comes to mind) There's one driver that depends on it and that was only ever shipped on i686 hardware which we obviously don't support any longer. The prism2_usb is in staging on it's way out of the kernel and hasn't been built in Fedora for years. > Meanwhile, the default summary output of 'iwconfig' is all I have used > it for in many, many years. It is _very_ useful in a way that no other > tool has been. (not unlike the default output of ifconfig _still_ being > more generally useful than 'ip') > > I'm sure all of the info that iwconfig provides can be extracted from > iw, but it's a lot less convenient. (Plus some of us have muscle memory > going back to when iwconfig was the new hotness...) It also doesn't provide huge amounts of useful information for modern HW like anything after 11a/11g like no support for 11n/ac/ax HW and it doesn't report a lot of the newer available frequencies like newer added 5Ghz bands so while it does provide some slightly useful information if you actually look closely a lot of it is actually incorrect. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FESCo election nominations are now open
Today is the last day to nominate candidates for the open seats on the Fedora Engineering Steering Committee. To nominate yourself (or others, if you check with them first), visit: https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations For more information, see the Community Blog post: https://communityblog.fedoraproject.org/f35-elections-nominations-now-open/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Firefox Hardware acceleration & VA-API how-to
On 11/16/21 22:48, Michael Cronenworth wrote: On 11/15/21 12:03 PM, PGNet Dev wrote: launch @ shell VDPAU_DRIVER=nvidia MOZ_LOG="Dmabuf:5, PlatformDecoderModule:5" firefox I think you mean: LIBVA_DRIVER_NAME=nvidia firefox nope. https://en.wikipedia.org/wiki/Video_Acceleration_API "As of 2019, VA-API is natively supported by libva-vdpau-driver for cards supported by VDPAU" libva-vdpau-driver is the translation layer that provides a VDPAU-based backend for VA-API. @ https://wiki.archlinux.org/title/Hardware_video_acceleration#Configuring_VDPAU " Configuring VDPAU You can override the driver for VDPAU by using the VDPAU_DRIVER environment variable. The correct driver name depends on your setup: ... For NVIDIA's proprietary version set it to nvidia. Note: You can find the installed drivers in /usr/lib/vdpau/. They are used as /usr/lib/vdpau/libvdpau_${VDPAU_DRIVER}.so " ls -al /usr/lib64/vdpau//libvdpau*nvidia* lrwxrwxrwx 1 root root 25 Nov 15 10:04 /usr/lib64/vdpau//libvdpau_nvidia.so.1 -> libvdpau_nvidia.so.495.44* -rwxr-xr-x 1 root root 620K Nov 15 10:04 /usr/lib64/vdpau//libvdpau_nvidia.so.495.44* cref: https://wiki.archlinux.org/title/Hardware_video_acceleration#VDPAU_drivers https://wiki.archlinux.org/title/Hardware_video_acceleration#NVIDIA_driver_only https://wiki.archlinux.org/title/Hardware_video_acceleration#Application_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: LTO objects after build: Rebuilding vs erroring out
* Jakub Jelinek: > Or if we recorded all command line options we care about into LTO bytecode > (Optimization/Target options are recorded already on a per-function basis > but I'm worried about others), just have a gcc driver mode that turns > a non-fat LTO object into normal non-LTO object. I think that would be useful, it would match the LLVM LTO approach. It's not going to be a perfect replay, but it's at least as good as other uses of that LTO data, so I think it will be fine. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Announcing LLVM Snapshot Packages for Fedora Linux
On Wed, 3 Nov 2021 at 14:50, Neal Gompa wrote: > On Wed, Nov 3, 2021 at 9:47 AM Jonathan Wakely wrote: > > > > > > > > On Fri, 8 Oct 2021 at 11:15, Konrad Kleine wrote: > >> > >> Dear Fedora packagers, developers and users, > >> > >> we have some good news for you: > >> > >> We are beginning to build nightly snapshot packages of LLVM for the > latest > >> versions of Fedora Linux (currently 34, 35 and rawhide) for a growing > list of > >> architectures. > >> > >> You can grab them here: > >> > >> > https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/ > >> > > > > Nice to see this going public, I will definitely be using it, thanks! > > > > And I'll shamelessly plug my copr with weekly GCC snapshots ;-) > > https://copr.fedorainfracloud.org/coprs/jwakely/gcc-latest/ > > > > Maybe this is worth a commblog or magazine post? > There's going to be a blog entry about this. I cannot tell when it will be public though. I've submitted a lightning talk for this year's LLVM virtual event and it will be aired tomorrow: https://llvm.swoogo.com/2021devmtg/agenda. I hope that adding the link to the copr page on the llvm front-page will also increase the visibility: https://github.com/llvm/llvm-www/pull/9. > > > > -- > 真実はいつも一つ!/ 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
Zbigniew Jędrzejewski-Szmek wrote: > Dunno, maybe we can keep wireless-tools package? Is it a burden to > keep in the distro? I guess the issue is that the tool(s) will no longer work if the subsystem is completely removed from the kernel. Would it be possible to ship the kernel with only wext interface compatibility (for wireless-tools) in mac80211 enabled and with wext itself disabled? Or does the interface compatibility in this case require shipping the entire wext subsystem? 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
On Wed, Nov 17, 2021 at 11:30:40AM +0100, Iñaki Ucar wrote: > I didn't complain. I'm not opposing, yet I'm acknowledging that it is > not true that iwconfig is unused. It is very much used, if not just > for printing the nice summary that the tool provides when called > without arguments. IIRC there are still a few WEXT-only drivers for obsolete wifi hardware in the Linux kernel. I don't know if Fedora builds them or not, but drop iwconfig and that hardware becomes unusable under Fedora. (prism2_usb comes to mind) Meanwhile, the default summary output of 'iwconfig' is all I have used it for in many, many years. It is _very_ useful in a way that no other tool has been. (not unlike the default output of ifconfig _still_ being more generally useful than 'ip') I'm sure all of the info that iwconfig provides can be extracted from iw, but it's a lot less convenient. (Plus some of us have muscle memory going back to when iwconfig was the new hotness...) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (libra.chat) 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
On Wed, Nov 17, 2021 at 03:49:55AM +0100, Kevin Kofler via devel wrote: > Users are going to miss the iwconfig tool. Not only is it still being used > out of habit (just like ifconfig from net-tools), but (also just like > ifconfig) it is also much more user-friendly. E.g., running "iwconfig" > without arguments prints a nice summary of the wireless devices and their > properties, such as access point ESSID and BSSID, bit rate, signal level, > etc., whereas running "iw" without arguments prints a 132-line help output > with around a hundred different commands (with no explanation as to what > they do, as that would require even more than 132 lines: the --help output > is 445 lines long). "iw" also exposes implementation details in the most > unfriendly way, by requiring the user to use "dev ", "phy > ", "wdev ", or "reg" prefixes depending on the individual > command (and it is entirely unclear to the user why something is a dev > property, a phy property, or both), whereas "iwconfig" takes the same > interface name for all commands. > > The new ip, iw, and route tools have clearly been designed by kernel > developers for kernel developers, not for end users or even system > administrators. The old ifconfig and iwconfig are much easier to use. The same applies for nft and ss ;) Those tools are supposed to be the future, but using them feels as if the people who wrote them never used them. Dunno, maybe we can keep wireless-tools package? Is it a burden to keep in the distro? Zbyszek ___ 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: RFC: Reduce number of packages that are built for i686
On Wed, Nov 17, 2021 at 12:17:30PM +0100, Fabio Valentini wrote: > I really *don't* think a manual, individual opt-out like this is a good idea. > > Imagine the scenario where a package maintaner unilaterally adds > "ExcludeArch: %{ix68}" to one of their packages. This might be an > honest mistake, for example, because the repoquery was not done > correctly, or because they thought that nothing depends on that > package. Then, this results in cascading build failures of all > dependent packages, because a broken build on any arch fails the whole > build, requiring cascading changes to all packages in the dependency > tree, more work for all manitainers that are involved. > > Because I think we should respect package maintainers' time, I don't > think I should put the burden of figuring this out and fixing > breakages on them, which is why I suggested a centralized approach > that will not put more work on *every single package maintainer*. I agree that a centralized approach would be nice. The question is whether we can make it happen within a reasonable time frame and without too much work. I don't really grok koji internals, so I don't know how hard it would be to feed it an updateable list of packages to skip. Zbyszek ___ 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: RFC: Reduce number of packages that are built for i686
On Wed, Nov 17, 2021 at 11:27:13AM +, Ahmed Almeleh wrote: > I see your point, I am a part of the Quality Assurance team here. > > +1 On retiring all i686 (32 Bit Systems) Did you see the part where we are using those packages for multilib? This would immediately kill Wine, Steam, and 32-bit development on Fedora. The fact that we're discussing a complicated way is because the complicated way is needed to avoid breaking use cases that we care about, not because we like complexity for complexity's sake. Zbyszek ___ 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: RFC: Reduce number of packages that are built for i686
I see your point, I am a part of the Quality Assurance team here. +1 Making it easier on package maintainers +1 On retiring all i686 (32 Bit Systems) On Wed, 17 Nov 2021, 11:18 Fabio Valentini, wrote: > On Wed, Nov 17, 2021 at 11:53 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote: > > (small snip) > > > > Is it really not? This seems the easiest way to go about it, honestly > - > > > just have it be permitted for maintainers to opt their stuff out of > > > building on x86 and let the problem take care of itself recursively. > > > > Yeah, I think I'd go this way too. Instead of trying to maintain this > > centrally in koji, do it at package level, using proven-packager > privileges > > to smooth the initial process. > > > > I.e. something like: OK, we don't want to build libreoffice for i686. > > libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same > time* > > any packages which (transitively) BR:libreoffice, are also annotated. > > (They don't even need to be rebuild.) > > And then repeat for another "big" package. > > > > I think this way to go is OK because we mostly care about some of the > > "big" packages that take a long time to build. Most low-level packages > > build just fine on i686 so we don't care if they are built unnecessarily. > > > > And obviously the advantage is that this can be done now, and doesn't > > require any new infra or maintenance. The only trick would be how to > > figure out the transitive BR tree, but apparently there are some scripts > > that people have. > > I really *don't* think a manual, individual opt-out like this is a good > idea. > > Imagine the scenario where a package maintaner unilaterally adds > "ExcludeArch: %{ix68}" to one of their packages. This might be an > honest mistake, for example, because the repoquery was not done > correctly, or because they thought that nothing depends on that > package. Then, this results in cascading build failures of all > dependent packages, because a broken build on any arch fails the whole > build, requiring cascading changes to all packages in the dependency > tree, more work for all manitainers that are involved. > > Because I think we should respect package maintainers' time, I don't > think I should put the burden of figuring this out and fixing > breakages on them, which is why I suggested a centralized approach > that will not put more work on *every single package maintainer*. > > Fabio > ___ > 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 > ___ 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: RFC: Reduce number of packages that are built for i686
On Wed, Nov 17, 2021 at 11:53 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote: (small snip) > > Is it really not? This seems the easiest way to go about it, honestly - > > just have it be permitted for maintainers to opt their stuff out of > > building on x86 and let the problem take care of itself recursively. > > Yeah, I think I'd go this way too. Instead of trying to maintain this > centrally in koji, do it at package level, using proven-packager privileges > to smooth the initial process. > > I.e. something like: OK, we don't want to build libreoffice for i686. > libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same time* > any packages which (transitively) BR:libreoffice, are also annotated. > (They don't even need to be rebuild.) > And then repeat for another "big" package. > > I think this way to go is OK because we mostly care about some of the > "big" packages that take a long time to build. Most low-level packages > build just fine on i686 so we don't care if they are built unnecessarily. > > And obviously the advantage is that this can be done now, and doesn't > require any new infra or maintenance. The only trick would be how to > figure out the transitive BR tree, but apparently there are some scripts > that people have. I really *don't* think a manual, individual opt-out like this is a good idea. Imagine the scenario where a package maintaner unilaterally adds "ExcludeArch: %{ix68}" to one of their packages. This might be an honest mistake, for example, because the repoquery was not done correctly, or because they thought that nothing depends on that package. Then, this results in cascading build failures of all dependent packages, because a broken build on any arch fails the whole build, requiring cascading changes to all packages in the dependency tree, more work for all manitainers that are involved. Because I think we should respect package maintainers' time, I don't think I should put the burden of figuring this out and fixing breakages on them, which is why I suggested a centralized approach that will not put more work on *every single package maintainer*. Fabio ___ 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: RFC: Reduce number of packages that are built for i686
On Wed, Nov 17, 2021 at 10:53:30AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote: > > Fabio Valentini writes: > > > > > Since it's not practical to modify almost all Fedora packages to add > > > "ExcludeArch: %{ix86}" to them, we'd probably need a different > > > machanism for this. I have a vague idea: > > > > Is it really not? This seems the easiest way to go about it, honestly - > > just have it be permitted for maintainers to opt their stuff out of > > building on x86 and let the problem take care of itself recursively. > > Yeah, I think I'd go this way too. Instead of trying to maintain this > centrally in koji, do it at package level, using proven-packager privileges > to smooth the initial process. > > I.e. something like: OK, we don't want to build libreoffice for i686. > libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same time* > any packages which (transitively) BR:libreoffice, are also annotated. > (They don't even need to be rebuild.) > And then repeat for another "big" package. > > I think this way to go is OK because we mostly care about some of the > "big" packages that take a long time to build. Most low-level packages > build just fine on i686 so we don't care if they are built unnecessarily. > > And obviously the advantage is that this can be done now, and doesn't > require any new infra or maintenance. The only trick would be how to > figure out the transitive BR tree, but apparently there are some scripts > that people have. s/people/Fabio/ ;) > Zbyszek ___ 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: RFC: Reduce number of packages that are built for i686
On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote: > Fabio Valentini writes: > > > Since it's not practical to modify almost all Fedora packages to add > > "ExcludeArch: %{ix86}" to them, we'd probably need a different > > machanism for this. I have a vague idea: > > Is it really not? This seems the easiest way to go about it, honestly - > just have it be permitted for maintainers to opt their stuff out of > building on x86 and let the problem take care of itself recursively. Yeah, I think I'd go this way too. Instead of trying to maintain this centrally in koji, do it at package level, using proven-packager privileges to smooth the initial process. I.e. something like: OK, we don't want to build libreoffice for i686. libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same time* any packages which (transitively) BR:libreoffice, are also annotated. (They don't even need to be rebuild.) And then repeat for another "big" package. I think this way to go is OK because we mostly care about some of the "big" packages that take a long time to build. Most low-level packages build just fine on i686 so we don't care if they are built unnecessarily. And obviously the advantage is that this can be done now, and doesn't require any new infra or maintenance. The only trick would be how to figure out the transitive BR tree, but apparently there are some scripts that people have. Zbyszek ___ 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: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
On Wed, 17 Nov 2021 at 10:54, Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 17 November 2021 at 10:38, Iñaki Ucar wrote: > > On Wed, 17 Nov 2021 at 03:59, Kevin Kofler via devel > > wrote: > > > > > > > The Wireless Extensions support in the kernel has been long replaced > > > > by the mac80211/cfg80211 support. Disable the kernel options and > > > > retire the wireless-tools userspace utilities. Wireless Extensions > > > > only supports a minor subset of the wireless interfaces, predominently > > > > the WEP interface and userspace has been replaced by iw/libnl/ip > > > > interfaces which offer a lot more advanced features as well as modern > > > > 802.11 functionality like WPA. > > > > > > Users are going to miss the iwconfig tool. Not only is it still being used > > > out of habit (just like ifconfig from net-tools), but (also just like > > > ifconfig) it is also much more user-friendly. E.g., running "iwconfig" > > > without arguments prints a nice summary of the wireless devices and their > > > properties, such as access point ESSID and BSSID, bit rate, signal level, > > > etc., whereas running "iw" without arguments prints a 132-line help output > > > with around a hundred different commands (with no explanation as to what > > > they do, as that would require even more than 132 lines: the --help output > > > is 445 lines long). "iw" also exposes implementation details in the most > > > unfriendly way, by requiring the user to use "dev ", "phy > > > ", "wdev ", or "reg" prefixes depending on the individual > > > command (and it is entirely unclear to the user why something is a dev > > > property, a phy property, or both), whereas "iwconfig" takes the same > > > interface name for all commands. > > > > > > The new ip, iw, and route tools have clearly been designed by kernel > > > developers for kernel developers, not for end users or even system > > > administrators. The old ifconfig and iwconfig are much easier to use. > > > > Cannot agree more. > > I'm not sure what you're trying to accomplish by complaining here or 'me > too'-ing. Deprecated and unused subsystems should get removed. If you > don't like the way the current userland tools behave, open RFE's with > their respective upstreams instead of adding noise here. I didn't complain. I'm not opposing, yet I'm acknowledging that it is not true that iwconfig is unused. It is very much used, if not just for printing the nice summary that the tool provides when called without arguments. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
On Wednesday, 17 November 2021 at 10:38, Iñaki Ucar wrote: > On Wed, 17 Nov 2021 at 03:59, Kevin Kofler via devel > wrote: > > > > > The Wireless Extensions support in the kernel has been long replaced > > > by the mac80211/cfg80211 support. Disable the kernel options and > > > retire the wireless-tools userspace utilities. Wireless Extensions > > > only supports a minor subset of the wireless interfaces, predominently > > > the WEP interface and userspace has been replaced by iw/libnl/ip > > > interfaces which offer a lot more advanced features as well as modern > > > 802.11 functionality like WPA. > > > > Users are going to miss the iwconfig tool. Not only is it still being used > > out of habit (just like ifconfig from net-tools), but (also just like > > ifconfig) it is also much more user-friendly. E.g., running "iwconfig" > > without arguments prints a nice summary of the wireless devices and their > > properties, such as access point ESSID and BSSID, bit rate, signal level, > > etc., whereas running "iw" without arguments prints a 132-line help output > > with around a hundred different commands (with no explanation as to what > > they do, as that would require even more than 132 lines: the --help output > > is 445 lines long). "iw" also exposes implementation details in the most > > unfriendly way, by requiring the user to use "dev ", "phy > > ", "wdev ", or "reg" prefixes depending on the individual > > command (and it is entirely unclear to the user why something is a dev > > property, a phy property, or both), whereas "iwconfig" takes the same > > interface name for all commands. > > > > The new ip, iw, and route tools have clearly been designed by kernel > > developers for kernel developers, not for end users or even system > > administrators. The old ifconfig and iwconfig are much easier to use. > > Cannot agree more. I'm not sure what you're trying to accomplish by complaining here or 'me too'-ing. Deprecated and unused subsystems should get removed. If you don't like the way the current userland tools behave, open RFE's with their respective upstreams instead of adding noise here. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
On Wed, 17 Nov 2021 at 03:59, Kevin Kofler via devel wrote: > > > The Wireless Extensions support in the kernel has been long replaced > > by the mac80211/cfg80211 support. Disable the kernel options and > > retire the wireless-tools userspace utilities. Wireless Extensions > > only supports a minor subset of the wireless interfaces, predominently > > the WEP interface and userspace has been replaced by iw/libnl/ip > > interfaces which offer a lot more advanced features as well as modern > > 802.11 functionality like WPA. > > Users are going to miss the iwconfig tool. Not only is it still being used > out of habit (just like ifconfig from net-tools), but (also just like > ifconfig) it is also much more user-friendly. E.g., running "iwconfig" > without arguments prints a nice summary of the wireless devices and their > properties, such as access point ESSID and BSSID, bit rate, signal level, > etc., whereas running "iw" without arguments prints a 132-line help output > with around a hundred different commands (with no explanation as to what > they do, as that would require even more than 132 lines: the --help output > is 445 lines long). "iw" also exposes implementation details in the most > unfriendly way, by requiring the user to use "dev ", "phy > ", "wdev ", or "reg" prefixes depending on the individual > command (and it is entirely unclear to the user why something is a dev > property, a phy property, or both), whereas "iwconfig" takes the same > interface name for all commands. > > The new ip, iw, and route tools have clearly been designed by kernel > developers for kernel developers, not for end users or even system > administrators. The old ifconfig and iwconfig are much easier to use. Cannot agree more. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Update of rust-svgtypes
On Wed, Nov 17, 2021 at 6:47 AM Rémi Lauzier via devel wrote: > > Hi! I will push the update for rust-svgtypes, done in a sidetag, in two weeks > unless there is an objection. A member of the rust-sig will have to update > rust-ttf_parser. if need i can update rust-owned_ttf_parser too. So ... I assume you're talking about updating svgtypes to version 0.8.0? Maybe mention that next time, so that I don't have to dig that up myself :) > f36-build-side-47900 > f35-build-side-47902 > f34-build-side-47904 I have adapted rust-ttf-parser to this change, and built the package in all three side tags. Feel free to create the bodhi updates now. Note that I have not updated ttf-parser to version 0.13.x in the process, as all dependent crates in Fedora repositories (plotters, rusttype, ab_glyph) still require versions 0.12.x of both ttf-parser and owned_ttf_parser. Fabio ___ 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: RFC: Reduce number of packages that are built for i686
On 16/11/2021 20:47, Fabio Valentini wrote: Our current approach, which is to "build everything but ship almost nothing" - just to keep x86_64 / i686 multilib working - is, frankly, very wasteful of computing and storage resources, as well as a burden on maintainers of big packages, which frequently run up against limits of 32-bit architectures. +1. It's time to retire all 32-bit architectures. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure