Re: bugz.fedoraproject.org links
On Wed, Mar 15, 2023 at 02:34:07PM -0400, Ben Cotton wrote: > An issue was filed earlier today: > https://pagure.io/fedora-infrastructure/issue/11192 Amd fixed. ;) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39
On Thu, 16 Mar 2023 at 00:34, Ben Beasley wrote: > Thank you for helping dig into the details. What you’ve written makes > sense, and is consistent with the comments in absl/base/options.h regarding > ABSL_OPTION_USE_STD_STRING_VIEW: > > A value of 2 means to detect the C++ version being used to compile > Abseil, > and use an alias only if a working std::string_view is available. This > option is useful when you are building your program from source. It > should > not be used otherwise -- for example, if you are distributing Abseil > in a > binary package manager -- since in mode 2, absl::string_view will name > a > different type, with a different mangled name and binary layout, > depending on > the compiler flags passed by the end user. For more info, see > https://abseil.io/about/design/dropin-types. > > > https://github.com/abseil/abseil-cpp/blob/c8a2f92586fe9b4e1aff049108f5db8064924d8e/absl/base/options.h#L138 > For completeness, the reason the value of ABSL_OPTION_USE_STD_STRING_VIEW > changed from 2 to 1 since the previous release is an intentional upstream > change described as follows: > > Change `absl/base/options.h` at install time to reflect the ABI used > to compile the libraries, i.e., if Abseil was compiled with > C++ >= 17 then the `ABSL_OPTION_USE_STD_*` macros are set to `1`, > because then the C++ 17 types are embedded in the ABI of the installed > artifacts. > > Likewise, set the `target_compile_features()` of Abseil libraries > to reflect the C++ version used to compile them. If they the Abseil > libraries are compiled with C++ >= 17, then all downstream > dependencies must also be compiled with C++ >= 17. > > > https://github.com/abseil/abseil-cpp/commit/308bbf300fe9332130f4784c7a91fa2ad707d6e4 > > So the only way that dependent packages can use C++14 is if we > intentionally and explicitly downgrade the C++ standard used to compile > abseil-cpp from C++17 (the default) to C++14. > > Given all this, it appears to me that the best course is still to keep > abseil-cpp on the default C++17 standard and accept that dependent packages > cannot use C++14. However, I’m pleased to have a much better understanding > of what is happening, how, and why, and I’m still happy to consider any > proposals to proceed differently. > Agreed. We know why it's needed now, and so can explain it to any maintainers of packages that need to move to C++17. Thanks for humouring my curiosity about it! > On 3/15/23 6:29 PM, Jonathan Wakely wrote: > > > > On Wed, 15 Mar 2023 at 22:17, Jonathan Wakely wrote: > >> >> >> On Wed, 15 Mar 2023 at 22:14, Ben Beasley >> wrote: >> >>> Thank you for prompting me to look at this more closely. A quick >>> investigation reveals: >>> >>> “Abseil libraries require C++14 as the current minimum standard. When >>> compiled with C++17 (either because it is the compiler's default or >>> explicitly requested), then Abseil requires C++17.” >>> >>> >>> https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291 >>> >>> The abseil-cpp package in Fedora has been compiled as C++17 for some >>> time—at first explicitly, but this would also now be the default if the >>> spec file did not configure a particular standard—so it seems dependent >>> packages already technically needed C++17, and it is mere happenstance that >>> this particular release is revealing incompatibilities. >>> >> >> I'm not sure if that's true, see my other email which crossed with yours. >> In the previous release absl::string_view would work for both C++14 and >> C++17, because USE_STD_STRING_VIEW was defined to 2, so adapted to the >> headers that included it. >> >> In the new release it is hardcoded to only work for C++17. That seems >> like a new change in the new version, not something that was already >> present. >> > > Digging deeper, maybe it was true, and ilbc was just getting away with it > by chance. > > Several member functions of absl::string_view are defined out-of-line in > abseil-cpp-20220623.1/absl/strings/string_view.cc but if the library is > built as C++17 then those won't be defined (because absl::string_view is > just an alias for std::string_view, so all the members come from > libstdc++). So all clients of abseil-cpp shared libs do need to be compiled > as C++17 or later. It looks like libilbc.so.3.0.4 doesn't actually use any > libasbl_*.so libs, so only uses libabsl headers, and that's why it "worked" > when the header was adaptive w.r.t. the string-view definition. It doesn't > care that there are no definitions for those string_view member functions, > because it happens to not use those specific member 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:
Re: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39
Thank you for helping dig into the details. What you’ve written makes sense, and is consistent with the comments in absl/base/options.h regarding ABSL_OPTION_USE_STD_STRING_VIEW: A value of 2 means to detect the C++ version being used to compile Abseil, and use an alias only if a working std::string_view is available. This option is useful when you are building your program from source. It should not be used otherwise -- for example, if you are distributing Abseil in a binary package manager -- since in mode 2, absl::string_view will name a different type, with a different mangled name and binary layout, depending on the compiler flags passed by the end user. For more info, see https://abseil.io/about/design/dropin-types. https://github.com/abseil/abseil-cpp/blob/c8a2f92586fe9b4e1aff049108f5db8064924d8e/absl/base/options.h#L138 For completeness, the reason the value of ABSL_OPTION_USE_STD_STRING_VIEW changed from 2 to 1 since the previous release is an intentional upstream change described as follows: Change `absl/base/options.h` at install time to reflect the ABI used to compile the libraries, i.e., if Abseil was compiled with C++ >= 17 then the `ABSL_OPTION_USE_STD_*` macros are set to `1`, because then the C++ 17 types are embedded in the ABI of the installed artifacts. Likewise, set the `target_compile_features()` of Abseil libraries to reflect the C++ version used to compile them. If they the Abseil libraries are compiled with C++ >= 17, then all downstream dependencies must also be compiled with C++ >= 17. https://github.com/abseil/abseil-cpp/commit/308bbf300fe9332130f4784c7a91fa2ad707d6e4 So the only way that dependent packages can use C++14 is if we intentionally and explicitly downgrade the C++ standard used to compile abseil-cpp from C++17 (the default) to C++14. Given all this, it appears to me that the best course is still to keep abseil-cpp on the default C++17 standard and accept that dependent packages cannot use C++14. However, I’m pleased to have a much better understanding of what is happening, how, and why, and I’m still happy to consider any proposals to proceed differently. On 3/15/23 6:29 PM, Jonathan Wakely wrote: On Wed, 15 Mar 2023 at 22:17, Jonathan Wakely wrote: On Wed, 15 Mar 2023 at 22:14, Ben Beasley wrote: Thank you for prompting me to look at this more closely. A quick investigation reveals: “Abseil libraries require C++14 as the current minimum standard. When compiled with C++17 (either because it is the compiler's default or explicitly requested), then Abseil requires C++17.” https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291 The abseil-cpp package in Fedora has been compiled as C++17 for some time—at first explicitly, but this would also now be the default if the spec file did not configure a particular standard—so it seems dependent packages already technically needed C++17, and it is mere happenstance that this particular release is revealing incompatibilities. I'm not sure if that's true, see my other email which crossed with yours. In the previous release absl::string_view would work for both C++14 and C++17, because USE_STD_STRING_VIEW was defined to 2, so adapted to the headers that included it. In the new release it is hardcoded to only work for C++17. That seems like a new change in the new version, not something that was already present. Digging deeper, maybe it was true, and ilbc was just getting away with it by chance. Several member functions of absl::string_view are defined out-of-line in abseil-cpp-20220623.1/absl/strings/string_view.cc but if the library is built as C++17 then those won't be defined (because absl::string_view is just an alias for std::string_view, so all the members come from libstdc++). So all clients of abseil-cpp shared libs do need to be compiled as C++17 or later. It looks like libilbc.so.3.0.4 doesn't actually use any libasbl_*.so libs, so only uses libabsl headers, and that's why it "worked" when the header was adaptive w.r.t. the string-view definition. It doesn't care that there are no definitions for those string_view member functions, because it happens to not use those specific member 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39
On Wed, 15 Mar 2023 at 22:17, Jonathan Wakely wrote: > > > On Wed, 15 Mar 2023 at 22:14, Ben Beasley wrote: > >> Thank you for prompting me to look at this more closely. A quick >> investigation reveals: >> >> “Abseil libraries require C++14 as the current minimum standard. When >> compiled with C++17 (either because it is the compiler's default or >> explicitly requested), then Abseil requires C++17.” >> >> >> https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291 >> >> The abseil-cpp package in Fedora has been compiled as C++17 for some >> time—at first explicitly, but this would also now be the default if the >> spec file did not configure a particular standard—so it seems dependent >> packages already technically needed C++17, and it is mere happenstance that >> this particular release is revealing incompatibilities. >> > > I'm not sure if that's true, see my other email which crossed with yours. > In the previous release absl::string_view would work for both C++14 and > C++17, because USE_STD_STRING_VIEW was defined to 2, so adapted to the > headers that included it. > > In the new release it is hardcoded to only work for C++17. That seems like > a new change in the new version, not something that was already present. > Digging deeper, maybe it was true, and ilbc was just getting away with it by chance. Several member functions of absl::string_view are defined out-of-line in abseil-cpp-20220623.1/absl/strings/string_view.cc but if the library is built as C++17 then those won't be defined (because absl::string_view is just an alias for std::string_view, so all the members come from libstdc++). So all clients of abseil-cpp shared libs do need to be compiled as C++17 or later. It looks like libilbc.so.3.0.4 doesn't actually use any libasbl_*.so libs, so only uses libabsl headers, and that's why it "worked" when the header was adaptive w.r.t. the string-view definition. It doesn't care that there are no definitions for those string_view member functions, because it happens to not use those specific member 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39
On Wed, 15 Mar 2023 at 22:14, Ben Beasley wrote: > Thank you for prompting me to look at this more closely. A quick > investigation reveals: > > “Abseil libraries require C++14 as the current minimum standard. When > compiled with C++17 (either because it is the compiler's default or > explicitly requested), then Abseil requires C++17.” > > > https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291 > > The abseil-cpp package in Fedora has been compiled as C++17 for some > time—at first explicitly, but this would also now be the default if the > spec file did not configure a particular standard—so it seems dependent > packages already technically needed C++17, and it is mere happenstance that > this particular release is revealing incompatibilities. > I'm not sure if that's true, see my other email which crossed with yours. In the previous release absl::string_view would work for both C++14 and C++17, because USE_STD_STRING_VIEW was defined to 2, so adapted to the headers that included it. In the new release it is hardcoded to only work for C++17. That seems like a new change in the new version, not something that was already present. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39
On Wednesday, March 15, 2023, Jonathan Wakely wrote: > > > On Wednesday, March 15, 2023, Ben Beasley wrote: >> In one week (2023-03-22), or slightly later, I plan to update abseil-cpp[1] in Rawhide/F39 to the latest LTS release, which is currently 20230125.1. Release notes are available[2]. >> >> The most significant breaking change is that dependent packages are required to compile with C++14 or later, and I have found that users of absl::string_view need C++17 or later. > > Hmm, that seems odd. The release notes say C++14 is required but don't mention that C++17 is needed for some components. > > C++17 provides std::string_view so what's the point in using absl::string_view at all if it only works when std::string_view is already available? > >> This has already been adjusted in a couple of packages (thanks!) and I have one PR still open[3]. > > > The error you showed there says the problem is using std::string_view, which does indeed require C++17. That doesn't seem related to absl::string_view, unless there's a bug in abseil which causes absl::string_view to incorrectly use std::string_view in C++14 mode. > > I think something doesn't make sense here, and would beworth understanding. OK, abseil has a macro that says whether to define its own string_view or use the std one: https://github.com/abseil/abseil-cpp/blob/92ac33b99eb9735a23a5e10150a85ad9d4820065/absl/base/options.h#L127 As you can see in the source code there, the default value is 2, meaning "use std::string_view if available, but fallback to absl's own string_view otherwise" (see the comment for more explanation). In rawhide today, /usr/include/absl/base/options.h has the default value: #define ABSL_OPTION_USE_STD_STRING_VIEW 2 But in your new abseil-cpp-devel-20230125.1-1.fc39 package it has a different value: #define ABSL_OPTION_USE_STD_STRING_VIEW 1 This means that absl::string_view is hardcoded to be an alias for std::string_view, which means it requires C++17. See lines 135 and 136 at the link above: // A value of 1 means to use an alias to std::string_view. This requires that // all code using Abseil is built in C++17 mode or later. This means your new abseil is to blame for the C++17 requirement. For some reason, your new package hardcodes "the compiler supports C++17" to be true, which means it cannot be used by any packages that want to build as C++14. I think your pull request for ilbc is wrong and should not be merged. Instead you should figure out why abseil-cpp now hardcodes that macro to 1, and fix that. > > >> >> All dependent packages build successfully in COPR[4] (with any necessary C++17 PR’s applied). >> >> I will rebuild the following packages in the side tag myself as primary maintainer or as co-maintainer: >> >> - abseil-cpp (of course) >> >> - bear >> >> - fastnetmon >> >> - grpc >> >> - libarrow >> >> For the remaining packages that need to be rebuilt, when the new version of abseil-cpp and the rebuilt grpc are ready in the side tag, I will send an email to their maintainers asking them to rebuild into the side tag. After a few days, I will ask Rich Mattes, the primary abseil-cpp package maintainer, to use his provenpackager privileges to rebuild any remaining dependent packages (and merge the C++17 PR for ilbc if it is still open). He has already agreed to do so. >> >> If you maintain one of the affected packages and you want me to handle rebuilds in the future, you can grant me privileges on the project; collaborator on the rawhide branch should be sufficient. >> >> - bloaty >> >> - credentials-fetcher >> >> - fcitx5-mozc >> >> - frr >> >> - ilbc >> >> - libphonenumber >> >> - mozc >> >> - plasma-dialer >> >> - qmlkonsole >> >> - spacebar >> >> If you maintain one of the affected packages, you should find that you received this message directly (by BCC due to limitations on the number of CC recipients imposed by the devel mailing list). >> >> [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/10 >> >> [2] https://github.com/abseil/abseil-cpp/releases/tag/20230125.1 >> >> [3] https://src.fedoraproject.org/rpms/ilbc/pull-request/1 >> >> [4] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/ >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue >> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
Re: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39
Thank you for prompting me to look at this more closely. A quick investigation reveals: “Abseil libraries require C++14 as the current minimum standard. When compiled with C++17 (either because it is the compiler's default or explicitly requested), then Abseil requires C++17.” https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291 The abseil-cpp package in Fedora has been compiled as C++17 for some time—at first explicitly, but this would also now be the default if the spec file did not configure a particular standard—so it seems dependent packages already technically needed C++17, and it is mere happenstance that this particular release is revealing incompatibilities. On Wed, Mar 15, 2023, at 10:01 AM, Jonathan Wakely wrote: > On Wednesday, March 15, 2023, Ben Beasley wrote: >> In one week (2023-03-22), or slightly later, I plan to update abseil-cpp[1] >> in Rawhide/F39 to the latest LTS release, which is currently 20230125.1. >> Release notes are available[2]. >> >> The most significant breaking change is that dependent packages are required >> to compile with C++14 or later, and I have found that users of >> absl::string_view need C++17 or later. > > Hmm, that seems odd. The release notes say C++14 is required but don't > mention that C++17 is needed for some components. > > C++17 provides std::string_view so what's the point in using > absl::string_view at all if it only works when std::string_view is > already available? > >> This has already been adjusted in a couple of packages (thanks!) and I have >> one PR still open[3]. > > > The error you showed there says the problem is using std::string_view, > which does indeed require C++17. That doesn't seem related to > absl::string_view, unless there's a bug in abseil which causes > absl::string_view to incorrectly use std::string_view in C++14 mode. > > I think something doesn't make sense here, and would be worth understanding. > > >> >> All dependent packages build successfully in COPR[4] (with any necessary >> C++17 PR’s applied). >> >> I will rebuild the following packages in the side tag myself as primary >> maintainer or as co-maintainer: >> >> - abseil-cpp (of course) >> >> - bear >> >> - fastnetmon >> >> - grpc >> >> - libarrow >> >> For the remaining packages that need to be rebuilt, when the new version of >> abseil-cpp and the rebuilt grpc are ready in the side tag, I will send an >> email to their maintainers asking them to rebuild into the side tag. After a >> few days, I will ask Rich Mattes, the primary abseil-cpp package maintainer, >> to use his provenpackager privileges to rebuild any remaining dependent >> packages (and merge the C++17 PR for ilbc if it is still open). He has >> already agreed to do so. >> >> If you maintain one of the affected packages and you want me to handle >> rebuilds in the future, you can grant me privileges on the project; >> collaborator on the rawhide branch should be sufficient. >> >> - bloaty >> >> - credentials-fetcher >> >> - fcitx5-mozc >> >> - frr >> >> - ilbc >> >> - libphonenumber >> >> - mozc >> >> - plasma-dialer >> >> - qmlkonsole >> >> - spacebar >> >> If you maintain one of the affected packages, you should find that you >> received this message directly (by BCC due to limitations on the number of >> CC recipients imposed by the devel mailing list). >> >> [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/10 >> >> [2] https://github.com/abseil/abseil-cpp/releases/tag/20230125.1 >> >> [3] https://src.fedoraproject.org/rpms/ilbc/pull-request/1 >> >> [4] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/ >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Crypt-DES] PR #1: Fix C99 compatibility issue
djdelorie opened a new pull-request against the project: `perl-Crypt-DES` that you are following: `` Fix C99 compatibility issue `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Crypt-DES/pull-request/1 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bugz.fedoraproject.org links
An issue was filed earlier today: https://pagure.io/fedora-infrastructure/issue/11192 -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
bugz.fedoraproject.org links
URLs such as https://bugz.fedoraproject.org/ocaml-dune started returning an HTTP 403 Forbidden a few days ago. Is that permanent? I personally find those URLs very useful and have used them a lot in the past. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Non-responsive maintainer check for eclipseo
Thanks for the suggestion, but I do not use Twitter and don't want to create an account. On March 15, 2023 5:13:43 PM GMT+02:00, Fabio Valentini wrote: >On Wed, Mar 15, 2023 at 4:04 PM Mark E. Fuller >wrote: >> >> Hi, >> This is a non-responsive maintainer check for eclipseo. >> I am trying to contact him as the owner of >> golang-github-masterminds-semver[0]. >> There is one other open non-responsive maintainer check, filed ~2 weeks >> ago[1]. >> Does anyone know how to contact eclipseo? > >I haven't had luck with getting responses to bugs or emails either ... >Maybe reaching out on twitter could work? https://twitter.com/eclipseo10 > >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, report it: >https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nodejs broken?
On Wed, Mar 15, 2023 at 11:09 AM Jerry James wrote: > I see the same with a couple of my packages. A look at > https://src.fedoraproject.org/rpms/nodejs suggests that we shouldn't > be using BuildRequires: nodejs-devel anymore, but rather > nodejsXX-devel for an appropriate value of XX. It looks like "20" is > the only currently appropriate value for XX. I am unsure how that is > supposed to work going forward. Unfortunately, that doesn't fix the 2 cases I am looking at, because they use yarnpkg, and installing yarnpkg pulls nodejs and nodejs-libs into the buildroot, not nodejs20 and nodejs20-libs. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nodejs broken?
I see the same with a couple of my packages. A look at https://src.fedoraproject.org/rpms/nodejs suggests that we shouldn't be using BuildRequires: nodejs-devel anymore, but rather nodejsXX-devel for an appropriate value of XX. It looks like "20" is the only currently appropriate value for XX. I am unsure how that is supposed to work going forward. On Wed, Mar 15, 2023 at 10:35 AM Iñaki Ucar wrote: > > Hi, > > RStudio (which depends on nodejs-devel) is FTBFS since the latest > nodejs update. I see this in F37 and F38: > > Error: Transaction test error: > file /usr/lib64/libv8.so.10 conflicts between attempted installs of > nodejs-libs-1:18.14.2-5.fc37.x86_64 and > nodejs20-libs-1:19.7.0-13.fc37.x86_64 > file /usr/lib64/libv8_libbase.so.10 conflicts between attempted > installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and > nodejs20-libs-1:19.7.0-13.fc37.x86_64 > file /usr/lib64/libv8_libplatform.so.10 conflicts between attempted > installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and > nodejs20-libs-1:19.7.0-13.fc37.x86_64 > > Best, > -- > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
nodejs broken?
Hi, RStudio (which depends on nodejs-devel) is FTBFS since the latest nodejs update. I see this in F37 and F38: Error: Transaction test error: file /usr/lib64/libv8.so.10 conflicts between attempted installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and nodejs20-libs-1:19.7.0-13.fc37.x86_64 file /usr/lib64/libv8_libbase.so.10 conflicts between attempted installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and nodejs20-libs-1:19.7.0-13.fc37.x86_64 file /usr/lib64/libv8_libplatform.so.10 conflicts between attempted installs of nodejs-libs-1:18.14.2-5.fc37.x86_64 and nodejs20-libs-1:19.7.0-13.fc37.x86_64 Best, -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Non-responsive maintainer check for eclipseo
On Wed, Mar 15, 2023 at 4:04 PM Mark E. Fuller wrote: > > Hi, > This is a non-responsive maintainer check for eclipseo. > I am trying to contact him as the owner of > golang-github-masterminds-semver[0]. > There is one other open non-responsive maintainer check, filed ~2 weeks > ago[1]. > Does anyone know how to contact eclipseo? I haven't had luck with getting responses to bugs or emails either ... Maybe reaching out on twitter could work? https://twitter.com/eclipseo10 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Non-responsive maintainer check for eclipseo
Hi, This is a non-responsive maintainer check for eclipseo. I am trying to contact him as the owner of golang-github-masterminds-semver[0]. There is one other open non-responsive maintainer check, filed ~2 weeks ago[1]. Does anyone know how to contact eclipseo? Thanks, fuller [0] https://bugzilla.redhat.com/show_bug.cgi?id=2178685 [1] https://bugzilla.redhat.com/show_bug.cgi?id=2166945 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20230315.n.1 changes
OLD: Fedora-Rawhide-20230314.n.0 NEW: Fedora-Rawhide-20230315.n.1 = SUMMARY = Added images:2 Dropped images: 2 Added packages: 0 Dropped packages:1 Upgraded packages: 144 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:1.42 GiB Size of upgraded packages: 2.46 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -4.75 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server_KVM qcow2 aarch64 Path: Server/aarch64/images/Fedora-Server-KVM-Rawhide-20230315.n.1.aarch64.qcow2 Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20230315.n.1.aarch64.tar.xz = DROPPED IMAGES = Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230314.n.0.iso Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20230314.n.0.aarch64.raw.xz = ADDED PACKAGES = = DROPPED PACKAGES = Package: google-noto-cjk-fonts-20201206-7.fc38 Summary: Google Noto Sans CJK Fonts RPMs:google-noto-cjk-fonts google-noto-cjk-fonts-common google-noto-sans-cjk-hk-fonts google-noto-sans-cjk-jp-fonts google-noto-sans-cjk-kr-fonts google-noto-sans-cjk-sc-fonts google-noto-sans-cjk-tc-fonts google-noto-sans-cjk-ttc-fonts google-noto-sans-hk-fonts google-noto-sans-jp-fonts google-noto-sans-kr-fonts google-noto-sans-mono-cjk-hk-fonts google-noto-sans-mono-cjk-jp-fonts google-noto-sans-mono-cjk-kr-fonts google-noto-sans-mono-cjk-sc-fonts google-noto-sans-mono-cjk-tc-fonts google-noto-sans-sc-fonts google-noto-sans-tc-fonts google-noto-serif-cjk-jp-fonts google-noto-serif-cjk-kr-fonts google-noto-serif-cjk-sc-fonts google-noto-serif-cjk-tc-fonts google-noto-serif-cjk-ttc-fonts google-noto-serif-jp-fonts google-noto-serif-kr-fonts google-noto-serif-sc-fonts google-noto-serif-tc-fonts Size:1.42 GiB = UPGRADED PACKAGES = Package: R-broom-1.0.4-1.fc39 Old package: R-broom-0.7.7-6.fc38 Summary: Convert Statistical Objects into Tidy Tibbles RPMs: R-broom Size: 1.96 MiB Size change: 61.56 KiB Changelog: * Tue Mar 14 2023 Tom Callaway - 1.0.4-1 - update to 1.0.4 Package: R-openssl-2.0.6-1.fc39 Old package: R-openssl-2.0.3-2.fc38 Summary: Toolkit for Encryption, Signatures and Certificates Based on OpenSSL RPMs: R-openssl Size: 2.66 MiB Size change: 20.82 KiB Changelog: * Tue Mar 14 2023 Tom Callaway - 2.0.6-1 - 2.0.6 Package: R-pillar-1.8.1-1.fc39 Old package: R-pillar-1.8.0-4.fc38 Summary: Coloured Formatting for Columns RPMs: R-pillar Size: 671.04 KiB Size change: 1.05 KiB Changelog: * Tue Mar 14 2023 Tom Callaway - 1.8.1-1 - 1.8.1 Package: R-rlang-1.1.0-1.fc39 Old package: R-rlang-1.0.6-2.fc38 Summary: Functions for Base Types and Core R and 'Tidyverse' Features RPMs: R-rlang Size: 7.16 MiB Size change: 171.90 KiB Changelog: * Tue Mar 14 2023 Tom Callaway - 1.1.0-1 - update to 1.1.0 Package: R-testthat-3.1.7-1.fc39 Old package: R-testthat-3.1.6-1.fc39 Summary: Unit Testing for R RPMs: R-testthat Size: 6.54 MiB Size change: 15.66 KiB Changelog: * Tue Mar 14 2023 Tom Callaway - 3.1.7-1 - update to 3.1.7 Package: R-tibble-3.2.0-1.fc39 Old package: R-tibble-3.1.8-4.fc38 Summary: Simple Data Frames RPMs: R-tibble Size: 2.57 MiB Size change: -147.47 KiB Changelog: * Tue Mar 14 2023 Tom Callaway - 3.2.0-1 - 3.2.0 Package: SDL2-2.26.4-1.fc39 Old package: SDL2-2.26.3-1.fc38 Summary: Cross-platform multimedia library RPMs: SDL2 SDL2-devel SDL2-static Size: 10.12 MiB Size change: -5.31 KiB Changelog: * Tue Mar 14 2023 Tom Callaway - 2.26.4-1 - update to 2.26.4 Package: SDL2_mixer-2.6.3-1.fc39 Old package: SDL2_mixer-2.6.2-2.fc38 Summary: Simple DirectMedia Layer - Sample Mixer Library RPMs: SDL2_mixer SDL2_mixer-devel Size: 1012.04 KiB Size change: -539 B Changelog: * Wed Mar 15 2023 S??rgio Basto - 2.6.3-1 - Update SDL2_mixer to 2.6.3 (#2167934) Package: ack-3.7.0-1.fc39 Old package: ack-3.6.0-3.fc38 Summary: Grep-like text finder RPMs: ack Size: 85.55 KiB Size change: 836 B Changelog: * Tue Mar 14 2023 Robin Lee - 3.7.0-1 - Update to 3.7.0 (RHBZ#2173683) Package: acl-2.3.1-7.fc39 Old package: acl-2.3.1-6.fc38 Summary: Access control list utilities RPMs: acl libacl libacl-devel Size: 787.60 KiB Size change: 1.12 KiB Changelog: * Tue Mar 14 2023 Luk Zaoral - 2.3.1-7 - migrated to SPDX license Package: alembic-1.8.5-1.fc39 Old package: alembic-1.8.4-2.fc38 Summary: Open framework for storing and sharing scene data RPMs: alembic alembic-devel alembic-libs Size: 4.84 MiB Size change: 11.59 KiB
Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39
On Wednesday, March 15, 2023, Ben Beasley wrote: > In one week (2023-03-22), or slightly later, I plan to update abseil-cpp[1] in Rawhide/F39 to the latest LTS release, which is currently 20230125.1. Release notes are available[2]. > > The most significant breaking change is that dependent packages are required to compile with C++14 or later, and I have found that users of absl::string_view need C++17 or later. Hmm, that seems odd. The release notes say C++14 is required but don't mention that C++17 is needed for some components. C++17 provides std::string_view so what's the point in using absl::string_view at all if it only works when std::string_view is already available? > This has already been adjusted in a couple of packages (thanks!) and I have one PR still open[3]. The error you showed there says the problem is using std::string_view, which does indeed require C++17. That doesn't seem related to absl::string_view, unless there's a bug in abseil which causes absl::string_view to incorrectly use std::string_view in C++14 mode. I think something doesn't make sense here, and would be worth understanding. > > All dependent packages build successfully in COPR[4] (with any necessary C++17 PR’s applied). > > I will rebuild the following packages in the side tag myself as primary maintainer or as co-maintainer: > > - abseil-cpp (of course) > > - bear > > - fastnetmon > > - grpc > > - libarrow > > For the remaining packages that need to be rebuilt, when the new version of abseil-cpp and the rebuilt grpc are ready in the side tag, I will send an email to their maintainers asking them to rebuild into the side tag. After a few days, I will ask Rich Mattes, the primary abseil-cpp package maintainer, to use his provenpackager privileges to rebuild any remaining dependent packages (and merge the C++17 PR for ilbc if it is still open). He has already agreed to do so. > > If you maintain one of the affected packages and you want me to handle rebuilds in the future, you can grant me privileges on the project; collaborator on the rawhide branch should be sufficient. > > - bloaty > > - credentials-fetcher > > - fcitx5-mozc > > - frr > > - ilbc > > - libphonenumber > > - mozc > > - plasma-dialer > > - qmlkonsole > > - spacebar > > If you maintain one of the affected packages, you should find that you received this message directly (by BCC due to limitations on the number of CC recipients imposed by the devel mailing list). > > [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/10 > > [2] https://github.com/abseil/abseil-cpp/releases/tag/20230125.1 > > [3] https://src.fedoraproject.org/rpms/ilbc/pull-request/1 > > [4] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2178063] Add perl-MooseX-StrictConstructor to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178063 --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2023-fa06873253 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-fa06873253 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178063 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2178063] Add perl-MooseX-StrictConstructor to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178063 Petr Pisar changed: What|Removed |Added Fixed In Version||perl-MooseX-StrictConstruct ||or-0.21-20.el9 Status|ASSIGNED|MODIFIED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178063 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2178063] Add perl-MooseX-StrictConstructor to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178063 Petr Pisar changed: What|Removed |Added Assignee|emman...@seyman.fr |ppi...@redhat.com Status|NEW |ASSIGNED --- Comment #1 from Petr Pisar --- https://pagure.io/releng/fedora-scm-requests/issue/51983 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178063 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2178067] Add perl-VM-EC2-Security-CredentialCache to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178067 --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2023-40c1e35c83 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-40c1e35c83 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178067 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39
In one week (2023-03-22), or slightly later, I plan to update abseil-cpp[1] in Rawhide/F39 to the latest LTS release, which is currently 20230125.1. Release notes are available[2]. The most significant breaking change is that dependent packages are required to compile with C++14 or later, and I have found that users of absl::string_view need C++17 or later. This has already been adjusted in a couple of packages (thanks!) and I have one PR still open[3]. All dependent packages build successfully in COPR[4] (with any necessary C++17 PR’s applied). I will rebuild the following packages in the side tag myself as primary maintainer or as co-maintainer: - abseil-cpp (of course) - bear - fastnetmon - grpc - libarrow For the remaining packages that need to be rebuilt, when the new version of abseil-cpp and the rebuilt grpc are ready in the side tag, I will send an email to their maintainers asking them to rebuild into the side tag. After a few days, I will ask Rich Mattes, the primary abseil-cpp package maintainer, to use his provenpackager privileges to rebuild any remaining dependent packages (and merge the C++17 PR for ilbc if it is still open). He has already agreed to do so. If you maintain one of the affected packages and you want me to handle rebuilds in the future, you can grant me privileges on the project; collaborator on the rawhide branch should be sufficient. - bloaty - credentials-fetcher - fcitx5-mozc - frr - ilbc - libphonenumber - mozc - plasma-dialer - qmlkonsole - spacebar If you maintain one of the affected packages, you should find that you received this message directly (by BCC due to limitations on the number of CC recipients imposed by the devel mailing list). [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/10 [2] https://github.com/abseil/abseil-cpp/releases/tag/20230125.1 [3] https://src.fedoraproject.org/rpms/ilbc/pull-request/1 [4] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2178067] Add perl-VM-EC2-Security-CredentialCache to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178067 Petr Pisar changed: What|Removed |Added Fixed In Version||perl-VM-EC2-Security-Creden ||tialCache-0.25-24.el9 Status|ASSIGNED|MODIFIED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178067 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2178067] Add perl-VM-EC2-Security-CredentialCache to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178067 --- Comment #1 from Petr Pisar --- https://pagure.io/releng/fedora-scm-requests/issue/51982 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178067 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 38 compose report: 20230315.n.0 changes
OLD: Fedora-38-20230314.n.0 NEW: Fedora-38-20230315.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 6 Dropped packages:0 Upgraded packages: 57 Downgraded packages: 0 Size of added packages: 171.71 MiB Size of dropped packages:0 B Size of upgraded packages: 4.14 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 1012.97 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-38-20230315.n.0.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-38-20230315.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: godot3-3.5.2-1.fc38 Summary: Multi-platform 2D and 3D game engine with a feature-rich editor (version 3) RPMs:godot3 godot3-headless godot3-runner godot3-server Size:163.43 MiB Package: guvcview-2.0.8-5.fc38 Summary: GTK+ UVC Viewer and Capturer RPMs:guvcview guvcview-devel guvcview-libs Size:1.46 MiB Package: mathjax3-3.2.2-1.fc38 Summary: JavaScript library to render math in the browser RPMs:mathjax3 Size:2.12 MiB Package: python-oracledb-1.2.2-1.fc38 Summary: OracleDB Driver RPMs:python3-oracledb Size:4.08 MiB Package: regextester-1.1.1-5.fc38 Summary: Regex Tester for elementary OS RPMs:regextester Size:454.25 KiB Package: wslay-1.1.1-1.fc38 Summary: Lightweight WebSocket library in C RPMs:wslay wslay-devel Size:190.22 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: CuraEngine-1:5.3.0-1.fc38 Old package: CuraEngine-1:4.13.1-6.fc38 Summary: Engine for processing 3D models into G-code instructions for 3D printers RPMs: CuraEngine Size: 4.24 MiB Size change: 1.23 MiB Changelog: * Wed Mar 08 2023 Tom Callaway - 1:5.3.0-1 - update to 5.3.0 Package: anaconda-38.23.2-1.fc38 Old package: anaconda-38.23.1-1.fc38 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-webui anaconda-widgets anaconda-widgets-devel Size: 19.20 MiB Size change: -120.81 KiB Changelog: * Thu Mar 09 2023 Packit - 38.23.2-1 - Retranslate welcome screen more simply (vslavik) - Fix translations of the pre-release warning dialog (#2165762) (vponcova) - Update translations from Weblate Package: asio-1.26.0-1.fc38 Old package: asio-1.24.0-3.fc38 Summary: A cross-platform C++ library for network programming RPMs: asio-devel Size: 20.28 MiB Size change: 298.84 KiB Changelog: * Fri Mar 10 2023 Julian Sikorski - 1.26.0-1 - Update to 1.26.0 - Switch to bz2 sources Package: azote-1.10.1-1.fc38 Old package: azote-1.9.7-3.fc38 Summary: Wallpaper and color manager for Sway, i3 and some other WMs RPMs: azote Size: 4.44 MiB Size change: -72 B Changelog: * Sat Mar 11 2023 Bob Hepple - 1.10.1-1 - new version Package: bandit-1.7.5-1.fc38 Old package: bandit-1.7.4-5.fc38 Summary: A framework for performing security analysis of Python source code RPMs: bandit Size: 309.26 KiB Size change: 13.26 KiB Changelog: * Fri Mar 10 2023 Mikel Olasagasti Uranga - 1.7.5-1 - Update to 1.7.5 - Closes rhbz#2177107 Package: csdiff-3.0.0-1.fc38 Old package: csdiff-2.9.0-1.fc38 Summary: Non-interactive tools for processing code scan results in plain-text RPMs: csdiff python3-csdiff Size: 4.86 MiB Size change: 57.20 KiB Changelog: * Thu Feb 23 2023 Luk Zaoral - 2.9.0-2 - Rebuilt for Boost 1.81 (rhbz#2172687) * Fri Mar 10 2023 Kamil Dudka 3.0.0-1 - update to latest upstream release Package: cups-1:2.4.2-10.fc38 Old package: cups-1:2.4.2-9.fc38 Summary: CUPS printing system RPMs: cups cups-client cups-devel cups-filesystem cups-ipptool cups-libs cups-lpd cups-printerapp Size: 24.03 MiB Size change: 7.71 KiB Changelog: * Thu Mar 02 2023 Zdenek Dohnal - 1:2.4.2-10 - fix loading ippeveps in ippeveprinter if only the command name is provided - don't override color settings from print dialog - save the color settings between restarts - check for cmyk when figuring out default options Package: cura-1:5.3.0-1.fc38 Old package: cura-1:4.13.1-6.fc38 Summary: 3D printer / slicing GUI RPMs: cura Size: 35.42 MiB Size change: 7.69 MiB Changelog: * Thu Mar 09 2023 Tom Callaway - 1:5.3.0-1 - update to 5.3.0 Package: cura-fdm-materials-5.3.0-1.fc38 Old package: cura-fdm-materials-4.13.0-3.fc38 Summary: Cura FDM Material database RPMs: cura-fdm-materials Size: 111.28 KiB Size change: 3.61 KiB Changelog: * Thu Mar 09 2023 Tom Callaway - 5.3.0-1 - update to 5.3.0 Package: did-0.20-1.fc38 Old package: did
[Bug 2178068] Add perl-VM-EC2 to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178068 --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2023-26dedf30bf has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-26dedf30bf -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178068 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2178068] Add perl-VM-EC2 to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178068 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-VM-EC2-1.28-24.el9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178068 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2178068] Add perl-VM-EC2 to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178068 --- Comment #1 from Petr Pisar --- https://pagure.io/releng/fedora-scm-requests/issue/51981 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178068 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-XML-Writer] PR #3: Fix SPDX license
mspacek merged a pull-request against the project: `perl-XML-Writer` that you are following. Merged pull-request: `` Fix SPDX license `` https://src.fedoraproject.org/rpms/perl-XML-Writer/pull-request/3 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Status of AVIF support in Fedora
On Wed, 2023-03-15 at 07:54 -0400, Neal Gompa wrote: > On Wed, Mar 15, 2023 at 6:32 AM Sandro wrote: > > > > On 15-03-2023 00:34, Neal Gompa wrote: > > > On Tue, Mar 14, 2023 at 7:17 PM Sandro > > > wrote: > > > > > > > > Apologies for my late response. I have been swamped with other > > > > things... > > > > > > > > On 27-02-2023 16:05, Neal Gompa wrote: > > > > > On Mon, Feb 27, 2023 at 10:04 AM Sérgio Basto > > > > > wrote: > > > > > > > > > > > > On Sat, 2023-02-25 at 10:27 -0500, Neal Gompa wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > It looks like libheif now supports a plugin architecture, > > > > > > > so we could > > > > > > > move libheif to Fedora, while having the HEVC/H.265 > > > > > > > backend plugin in > > > > > > > RPM Fusion. > > > > > > > > > > > > > > Also, according to the CMake, the HEVC/H.265 plugins are > > > > > > > not built by > > > > > > > default anymore: > > > > > > > https://github.com/strukturag/libheif/blob/cdcc5b210879e0a0348032a594f8be52bb739c0d/CMakeLists.txt#L92-L98 > > > > > > > > > > > > > > So feel free to package it and bring it into Fedora. :) > > > > > > > > I'm willing to give it a try. Yet, just submitting the package > > > > and > > > > getting it into Fedora is probably not enough. Some co- > > > > ordination with > > > > RPMFusion would be needed, I guess. And consuming packages > > > > would need to > > > > be updated to properly use the new library. > > > > > > > > If anyone could guide/assist me with that, I'd be grateful. > > > > > > > > > > So we can build libheif without H.265 on Fedora but how you > > > > > > propose > > > > > > make H.265 available with one third repo ? just build the > > > > > > plugin on > > > > > > third repo as a freeworld package ? > > > > > > > > > > > > > > > > It may be possible to build the plugin independently and link > > > > > to > > > > > libheif, but at the minimum, that's what I expect. > > > > > > > > The above exchange I do not quite grasp. I guess this is about > > > > making > > > > libheif-av1 (the Av1 only libheif, yet to be packaged) play > > > > nicely > > > > together with the unfree libheif (providing HEIF/libde265) > > > > provided by > > > > RPMFusion. > > > > > > > > To set things in motion I will try my hands on building a AV1 > > > > only > > > > libheif package and take it from there. > > > > > > > > > > Actually, I've got this done already locally. I can put it up for > > > review and you can grab it? > > > > > > Then I can give you co-maintainer privileges for it. > > > > Sure. That will work. Thanks Neal! > > > > Here it is: https://bugzilla.redhat.com/show_bug.cgi?id=2178600 LGTM > > -- > 真実はいつも一つ！/ 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, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2177939] perl-Perl4-CoreLibs-0.005 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2177939 --- Comment #5 from Fedora Update System --- FEDORA-2023-c8206f5054 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c8206f5054 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2177939 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2177939] perl-Perl4-CoreLibs-0.005 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2177939 --- Comment #4 from Fedora Update System --- FEDORA-2023-42d65071b5 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-42d65071b5 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2177939 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2177939] perl-Perl4-CoreLibs-0.005 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2177939 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-2023-da8de27a58 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-da8de27a58 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2177939 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Status of AVIF support in Fedora
On Wed, Mar 15, 2023 at 6:32 AM Sandro wrote: > > On 15-03-2023 00:34, Neal Gompa wrote: > > On Tue, Mar 14, 2023 at 7:17 PM Sandro wrote: > >> > >> Apologies for my late response. I have been swamped with other things... > >> > >> On 27-02-2023 16:05, Neal Gompa wrote: > >>> On Mon, Feb 27, 2023 at 10:04 AM Sérgio Basto wrote: > > On Sat, 2023-02-25 at 10:27 -0500, Neal Gompa wrote: > >> > >> > >> > > > > It looks like libheif now supports a plugin architecture, so we could > > move libheif to Fedora, while having the HEVC/H.265 backend plugin in > > RPM Fusion. > > > > Also, according to the CMake, the HEVC/H.265 plugins are not built by > > default anymore: > > https://github.com/strukturag/libheif/blob/cdcc5b210879e0a0348032a594f8be52bb739c0d/CMakeLists.txt#L92-L98 > > > > So feel free to package it and bring it into Fedora. :) > >> > >> I'm willing to give it a try. Yet, just submitting the package and > >> getting it into Fedora is probably not enough. Some co-ordination with > >> RPMFusion would be needed, I guess. And consuming packages would need to > >> be updated to properly use the new library. > >> > >> If anyone could guide/assist me with that, I'd be grateful. > >> > So we can build libheif without H.265 on Fedora but how you propose > make H.265 available with one third repo ? just build the plugin on > third repo as a freeworld package ? > > >>> > >>> It may be possible to build the plugin independently and link to > >>> libheif, but at the minimum, that's what I expect. > >> > >> The above exchange I do not quite grasp. I guess this is about making > >> libheif-av1 (the Av1 only libheif, yet to be packaged) play nicely > >> together with the unfree libheif (providing HEIF/libde265) provided by > >> RPMFusion. > >> > >> To set things in motion I will try my hands on building a AV1 only > >> libheif package and take it from there. > >> > > > > Actually, I've got this done already locally. I can put it up for > > review and you can grab it? > > > > Then I can give you co-maintainer privileges for it. > > Sure. That will work. Thanks Neal! > Here it is: https://bugzilla.redhat.com/show_bug.cgi?id=2178600 -- 真実はいつも一つ！/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] Fedora 38 Branched 20230315.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 38 Branched 20230315.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 1.3: anaconda-38.23.1-1.fc38.src, 20230315.n.0: anaconda-38.23.2-1.fc38.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/38 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230315.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230315.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230315.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230315.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230315.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230315.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230315.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-XML-Writer] PR #3: Fix SPDX license
mspacek opened a new pull-request against the project: `perl-XML-Writer` that you are following: `` Fix SPDX license `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-XML-Writer/pull-request/3 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-XML-Writer] PR #2: Fix SPDX license
mspacek merged a pull-request against the project: `perl-XML-Writer` that you are following. Merged pull-request: `` Fix SPDX license `` https://src.fedoraproject.org/rpms/perl-XML-Writer/pull-request/2 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-XML-Writer] PR #2: Fix SPDX license
mspacek opened a new pull-request against the project: `perl-XML-Writer` that you are following: `` Fix SPDX license `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-XML-Writer/pull-request/2 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Status of AVIF support in Fedora
On 15-03-2023 01:04, Leigh Scott wrote: I can give sponsorship and acl's for the rpmfusion package. Thanks, Leigh. I take it that would be needed for updating the current libheif, of which you are one of the maintainers. I do have an RPMFusion Bugzilla account already and I will join the mailing list shortly. I believe we "met" before. ;) -- Sandro ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Status of AVIF support in Fedora
On 15-03-2023 00:34, Neal Gompa wrote: On Tue, Mar 14, 2023 at 7:17 PM Sandro wrote: Apologies for my late response. I have been swamped with other things... On 27-02-2023 16:05, Neal Gompa wrote: On Mon, Feb 27, 2023 at 10:04 AM Sérgio Basto wrote: On Sat, 2023-02-25 at 10:27 -0500, Neal Gompa wrote: It looks like libheif now supports a plugin architecture, so we could move libheif to Fedora, while having the HEVC/H.265 backend plugin in RPM Fusion. Also, according to the CMake, the HEVC/H.265 plugins are not built by default anymore: https://github.com/strukturag/libheif/blob/cdcc5b210879e0a0348032a594f8be52bb739c0d/CMakeLists.txt#L92-L98 So feel free to package it and bring it into Fedora. :) I'm willing to give it a try. Yet, just submitting the package and getting it into Fedora is probably not enough. Some co-ordination with RPMFusion would be needed, I guess. And consuming packages would need to be updated to properly use the new library. If anyone could guide/assist me with that, I'd be grateful. So we can build libheif without H.265 on Fedora but how you propose make H.265 available with one third repo ? just build the plugin on third repo as a freeworld package ? It may be possible to build the plugin independently and link to libheif, but at the minimum, that's what I expect. The above exchange I do not quite grasp. I guess this is about making libheif-av1 (the Av1 only libheif, yet to be packaged) play nicely together with the unfree libheif (providing HEIF/libde265) provided by RPMFusion. To set things in motion I will try my hands on building a AV1 only libheif package and take it from there. Actually, I've got this done already locally. I can put it up for review and you can grab it? Then I can give you co-maintainer privileges for it. Sure. That will work. Thanks Neal! -- Sandro ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
