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 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: 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: 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
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: 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: 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, 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) @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: 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: 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: 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: 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 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: 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: 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: 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: 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
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: 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.
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: 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: 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
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: 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: 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
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: 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
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 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
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: 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
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
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: 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
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: 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
[Bug 2020174] F36FailsToInstall: dropbox-api-command
https://bugzilla.redhat.com/show_bug.cgi?id=2020174 Miro Hrončok changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |CLOSED Last Closed||2021-11-17 12:23:17 --- Comment #1 from Miro Hrončok --- Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhron...@redhat.com). All subpackages of a package against which this bug was filled are now installable or removed from Fedora 36. Thanks for taking care of it! -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2020174 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
On 17. 11. 21 19:50, Troy Dawson wrote: I'd say open a ticket. At this point, I don't know what the status is. Some step(s) have not been done. https://pagure.io/fedscm-admin/issue/73 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: DNF replacement in EL 9?
On Wed, 17 Nov 2021 at 12:57, Neal Gompa wrote:
>
> On Wed, Nov 17, 2021 at 12:53 PM Richard Shaw wrote:
> >
> > I was talking to a software vendor about there install instructions using
> > yum instead of dnf for EL 8 and he took the feedback back to the
> > development team but the response was that dnf was "going away" in EL 9...
> >
> > Did I miss something?
> >
>
> RHEL product folks hate the name "DNF", so they always call it "YUM
> powered by DNF technology". Consequently, the documentation uses "yum"
> instead of "dnf", even if it's the same thing ("yum" is a symlink to
> "dnf").
I am going to call that an inaccurate and misleading statement which I
have corrected you once before on. The product folk really really
wanted to call it dnf in the run up and to remove yum name in EL8 and
they would have loved to do so in EL9. The main issue is that the
majority of the customer base for Enterprise Linux are on the Late
Majority and later group who complained a lot about the fact that they
had just finished changing all their documentation from up2date to yum
and were not happy about doing it for a tool which used the same
command arguments as 'yum'. These are companies which move large
numbers of systems across multiple releases and want a consolidated
documentation for all the 'supported' releases. As such, yum is
probably going to be around for decades even if RHEL moved to .deb
packages.
--
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
Looks like not yet. My branch requests are also getting rejected. On Wed, Nov 17, 2021 at 10:35 AM Miro Hrončok wrote: > On 09. 11. 21 16:07, Troy Dawson wrote: > > The people on the rel-eng team that do the branches need to have their > > fedscm-admin updated with the correct patches. I'm told that should > happen > > today or tomorrow. > > Did this actually happen? > > My branch request was closed repeatedly: > > https://pagure.io/releng/fedora-scm-requests/issue/37456 > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: DNF replacement in EL 9?
On Wed, Nov 17, 2021 at 01:43:59PM -0500, Josh Boyer wrote: > Further RHEL 9 documentation will center around the 'dnf' moniker, > eventually transitioning away from yum. Thus completing my long, slow loss of this argument. :) Oh well! dnf it is! -- Matthew Miller Fedora Project Leader ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
On 09. 11. 21 16:07, Troy Dawson wrote: The people on the rel-eng team that do the branches need to have their fedscm-admin updated with the correct patches. I'm told that should happen today or tomorrow. Did this actually happen? My branch request was closed repeatedly: https://pagure.io/releng/fedora-scm-requests/issue/37456 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
On 17. 11. 21 19:41, Troy Dawson wrote: Looks like not yet. My branch requests are also getting rejected. I see this comment: https://pagure.io/fedscm-admin/pull-request/72#comment-157918 It seems like a release is needed. Should I open a ticket? Or a backport PR to https://src.fedoraproject.org/rpms/fedscm-admin? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
I'd say open a ticket. At this point, I don't know what the status is. Some step(s) have not been done. On Wed, Nov 17, 2021 at 10:44 AM Miro Hrončok wrote: > On 17. 11. 21 19:41, Troy Dawson wrote: > > Looks like not yet. My branch requests are also getting rejected. > > I see this comment: > > https://pagure.io/fedscm-admin/pull-request/72#comment-157918 > > It seems like a release is needed. Should I open a ticket? > Or a backport PR to https://src.fedoraproject.org/rpms/fedscm-admin? > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1986164] perl-Test2-Suite-0.000141 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1986164 --- Comment #9 from Fedora Update System --- FEDORA-2021-71ba85f6b8 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-71ba85f6b8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-71ba85f6b8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1986164 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2023554] perl-Test2-Suite-0.000142 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2023554 --- Comment #7 from Fedora Update System --- FEDORA-2021-038ad5ed5f has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-038ad5ed5f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-038ad5ed5f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2023554 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2023554] perl-Test2-Suite-0.000142 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2023554 --- Comment #6 from Fedora Update System --- FEDORA-2021-71ba85f6b8 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-71ba85f6b8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-71ba85f6b8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2023554 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2021296] perl-HTTP-Message-6.34 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2021296 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-HTTP-Message-6.34-1.fc ||34 Resolution|--- |ERRATA Last Closed||2021-11-18 01:06:30 --- Comment #6 from Fedora Update System --- FEDORA-2021-1dd42c7968 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2021296 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2021296] perl-HTTP-Message-6.34 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2021296 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-HTTP-Message-6.34-1.fc |perl-HTTP-Message-6.34-1.fc |34 |34 ||perl-HTTP-Message-6.34-1.fc ||35 --- Comment #7 from Fedora Update System --- FEDORA-2021-231f86b976 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2021296 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing:
Age URL
6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-8e8cdfca46
js-jquery-ui-1.13.0-1.el8
6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a21f8fb6c8
java-latest-openjdk-17.0.1.0.12-3.rolling.el8
The following builds have been pushed to Fedora EPEL 8 updates-testing
holland-1.2.8-1.el8
opensmtpd-6.8.0p2-3.el8
snapd-2.53.2-1.el8
Details about builds:
holland-1.2.8-1.el8 (FEDORA-EPEL-2021-b57cc7440d)
Pluggable Backup Framework
Update Information:
Latest upstream release
ChangeLog:
* Wed Nov 17 2021 survi...@fedoraproject.org - 1.2.8-1
- Latest upstream release.
opensmtpd-6.8.0p2-3.el8 (FEDORA-EPEL-2021-fceea1c7eb)
Free implementation of the server-side SMTP protocol as defined by RFC 5321
Update Information:
opensmtpd: smtpd spool directory layout
ChangeLog:
* Tue Nov 16 2021 Denis Fateyev - 6.8.0p2-3
- Fixed smtpd spool directory layout
References:
[ 1 ] Bug #2023945 - Starting service opensmtpd fails with latest EPEL version
https://bugzilla.redhat.com/show_bug.cgi?id=2023945
snapd-2.53.2-1.el8 (FEDORA-EPEL-2021-06fd644359)
A transactional software package manager
Update Information:
Update to 2.53.2
ChangeLog:
* Wed Nov 17 2021 Maciek Borzecki - 2.53.2-1
- Release 2.53.2 to Fedora
* Mon Nov 15 2021 Ian Johnson
- New upstream release 2.53.2
- interfaces/builtin/block_devices: allow blkid to print block
device attributes/run/udev/data/b{major}:{minor}
- cmd/libsnap-confine-private: do not deny all devices when reusing
the device cgroup
- interfaces/builtin/time-control: allow pps access
- interfaces/u2f-devices: add Trezor and Trezor v2 keys
- interfaces: timezone-control, add permission for ListTimezones
DBus call
- interfaces/apparmor/template.go: allow udevadm from merged usr
systems
- interface/modem-manager: allow connecting to the mbim/qmi proxy
- interfaces/network-manager-observe: Update for libnm client
library
- cmd/snap-seccomp/syscalls: update syscalls to match libseccomp
abad8a8f4
- sandbox/cgroup: freeze and thaw cgroups related to services and
scopes only
- o/hookstate: print cohort with snapctl refresh --pending
- cmd/snap-confine: lazy set up of device cgroup, only when devices
were assigned
- tests: ensure systemd-timesyncd is installed on debian
- tests/lib/pkgdb: install strace on Debian 11 and Sid
- tests/main/snapd-sigterm: flush, use retry
- tests/main/snapd-sigterm: fix race conditions
- release-tools/repack-debian-tarball.sh: fix c-vendor dir
- data/selinux: allow snap-confine to read udev's database
- interfaces/dsp: add more ambarella things* interfaces/dsp: add
more ambarella things
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] EPEL8 buildroot removed CentOS Devel repo
Since the CentOS Devel repo was first created, it has been a part of the EPEL8 buildroot. It supplied some of the missing devel packages that were not in any of the RHEL 8 public repos. It was a good concept, and did help some, but it didn't completely fix the problem. EPEL eventually came up with another solution[1], and the CentOS Devel repo has been used less and less with each RHEL release. We had been wondering when to remove it, and now we have. The fact that it is now empty helped with the decision. If you find that you cannot build because you were relying on one of the devel packages in that repo, please follow the steps in the EPEL Documentation[1]. Thank You Troy Dawson [1] - https://docs.fedoraproject.org/en-US/epel/epel-faq/#rhel_8_has_binaries_in_the_release_but_is_missing_some_corresponding__devel_package._how_do_i_build_a_package_that_needs_that_missing__devel_package ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing:
Age URL
61 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-f005e1b879
debmirror-2.35-1.el7
6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6d0e7309d6
wordpress-5.1.11-1.el7
The following builds have been pushed to Fedora EPEL 7 updates-testing
openssl11-1.1.1k-2.el7
snapd-2.53.2-1.el7
Details about builds:
openssl11-1.1.1k-2.el7 (FEDORA-EPEL-2021-70fe95babd)
Utilities from the general purpose cryptography library with TLS implementation
Update Information:
- backport from 1.1.1k-5: CVE-2021-3712 openssl: Read buffer overruns processing
ASN.1 strings. Resolves: rhbz#2005400
ChangeLog:
* Wed Nov 17 2021 Robert Scheck 1.1.1k-2
- backport from 1.1.1k-5: CVE-2021-3712 openssl: Read buffer overruns
processing ASN.1 strings.
Resolves: rhbz#2005400
References:
[ 1 ] Bug #1995634 - CVE-2021-3712 openssl: Read buffer overruns processing
ASN.1 strings
https://bugzilla.redhat.com/show_bug.cgi?id=1995634
snapd-2.53.2-1.el7 (FEDORA-EPEL-2021-217a4fc000)
A transactional software package manager
Update Information:
Update to 2.53.2
ChangeLog:
* Wed Nov 17 2021 Maciek Borzecki - 2.53.2-1
- Release 2.53.2 to Fedora
* Mon Nov 15 2021 Ian Johnson
- New upstream release 2.53.2
- interfaces/builtin/block_devices: allow blkid to print block
device attributes/run/udev/data/b{major}:{minor}
- cmd/libsnap-confine-private: do not deny all devices when reusing
the device cgroup
- interfaces/builtin/time-control: allow pps access
- interfaces/u2f-devices: add Trezor and Trezor v2 keys
- interfaces: timezone-control, add permission for ListTimezones
DBus call
- interfaces/apparmor/template.go: allow udevadm from merged usr
systems
- interface/modem-manager: allow connecting to the mbim/qmi proxy
- interfaces/network-manager-observe: Update for libnm client
library
- cmd/snap-seccomp/syscalls: update syscalls to match libseccomp
abad8a8f4
- sandbox/cgroup: freeze and thaw cgroups related to services and
scopes only
- o/hookstate: print cohort with snapctl refresh --pending
- cmd/snap-confine: lazy set up of device cgroup, only when devices
were assigned
- tests: ensure systemd-timesyncd is installed on debian
- tests/lib/pkgdb: install strace on Debian 11 and Sid
- tests/main/snapd-sigterm: flush, use retry
- tests/main/snapd-sigterm: fix race conditions
- release-tools/repack-debian-tarball.sh: fix c-vendor dir
- data/selinux: allow snap-confine to read udev's database
- interfaces/dsp: add more ambarella things* interfaces/dsp: add
more ambarella things
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
