Re: Media key support in F32 / Gnome / systemd
On Sat, Aug 8, 2020 at 2:57 PM Samuel Sieb wrote: > > On 8/8/20 11:30 AM, Christopher wrote: > > Thanks for the sanity check and for setting me on the right path. This > > isn't a great user experience, but at least it is *possible* to > > configure things the way I want. > > Well, for most users, it's a great experience because the keys do what > they say they do. I'm very happy that my suspend key works. :-) And I > don't expect to be able to easily map any random key on my keyboard to > something else. That's a fair point. However, this keyboard specifically markets itself as having the ability to modify the behavior of the keys, so purchasers of this keyboard *should* expect to be able to easily map the media keys to something else. I think this is a mainstream expectation nowadays for standard media keys. And, a quick search online of this problem will find many people frustrated by the placement of this key nearby other keys (it sits between the email and calculator keys), and desire to re-map it to avoid accidentally shutting down their computer when all they want to do is open their email (with numerous outdated answers about how to do it in previous versions of Gnome that don't work anymore). I will modify my previous statement about not being a great experience to this longer observation: the *initial* experience (until I learned more about Gnome configuration and the implications) was *slightly* less than great *if* you don't like the default behavior. The initial experience could be improved dramatically if the previous bindings were automatically removed when a new binding is set in gnome-control-center keyboard shortcuts. Also, it would be nice if all available bindings were shown in the GUI, instead of some only available hidden in dconf-settings/gsettings. It would also be great if I could search by value in dconf-editor to be able to find all mappings of XF86Sleep or another button when I don't know the configuration key name. Feature-wise, the fact that everything works as labeled out of the box, and the fact that you can make changes, is great. Usability-wise, there's room for some improvement. Overall, it's still great, even though it could be better. Thanks again, Christopher ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1852297] ack-3.4.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1852297 --- Comment #4 from Fedora Update System --- FEDORA-2020-6f238c5662 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6f238c5662` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6f238c5662 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. ___ 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2b702ad070 rpki-client-6.7p1-1.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88b5647c18 radare2-4.5.0-1.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6ba549ab3a ark-19.12.2-2.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing aha-0.5-1.el8 git-cola-3.7-1.el8 python3-saml-1.9.0-3.el8 vrms-rpm-2.2-1.el8 Details about builds: aha-0.5-1.el8 (FEDORA-EPEL-2020-222b80d2a2) Convert terminal output to HTML Update Information: Initial build for EPEL8 ChangeLog: git-cola-3.7-1.el8 (FEDORA-EPEL-2020-fd51ad60f9) A sleek and powerful git GUI Update Information: Build for EPEL8 ChangeLog: References: [ 1 ] Bug #1805827 - git-cola for RHEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1805827 python3-saml-1.9.0-3.el8 (FEDORA-EPEL-2020-1a5c1898d8) Add SAML support to your Python software using this library Update Information: Add python3-saml to EPEL8 ChangeLog: vrms-rpm-2.2-1.el8 (FEDORA-EPEL-2020-ed2a23babb) Report non-free software Update Information: Initial build and bodhi update for EPEL8 (v2.2) ChangeLog: ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-87ccee83b4 hylafax+-7.0.3-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing vrms-rpm-2.2-1.el6 Details about builds: vrms-rpm-2.2-1.el6 (FEDORA-EPEL-2020-24c7f4e8fa) Report non-free software Update Information: Update to upstream release v2.2 ChangeLog: * Sat Aug 8 2020 Artur Iwicki - 2.2-1 - Update to upstream release v2.2 ___ 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 725 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 465 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 174 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 19 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2c80eb66b5 libASL-0.1.7-6.el7 matio-1.5.17-3.el7 openmeeg-2.4-0.4.rc4.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-32e4ca563b rpki-client-6.7p1-1.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2a93add193 python34-3.4.10-6.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5d276cc1c4 hylafax+-7.0.3-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing python-pytest-xdist-1.17.1-4.el7 vrms-rpm-2.2-1.el7 Details about builds: python-pytest-xdist-1.17.1-4.el7 (FEDORA-EPEL-2020-08ce6bee45) py.test plugin for distributed testing and loop-on-failing modes Update Information: Rebuild to get python3-pytest-xdist Provide (#1866696) ChangeLog: * Sat Aug 8 2020 Scott Talbert - 1.17.1-4 - Rebuild to get python3-pytest-xdist Provide (#1866696) References: [ 1 ] Bug #1866696 - Package don't provides python3-pytest-xdist https://bugzilla.redhat.com/show_bug.cgi?id=1866696 vrms-rpm-2.2-1.el7 (FEDORA-EPEL-2020-561781f15e) Report non-free software Update Information: Update to upstream release v2.2 ChangeLog: * Sat Aug 8 2020 Artur Iwicki - 2.2-1 - Update to upstream release v2.2 ___ 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
[Bug 1852297] ack-3.4.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1852297 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-2020-c3f6e29213 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c3f6e29213` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c3f6e29213 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. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Using a side tag
On Sat, Aug 08, 2020 at 08:52:22PM -0400, Scott Talbert wrote: > I'm trying to use a side tag to rebuild a package (wxGTK) and its dependent > (CubicSDR) due to an soname bump. > > I rebuilt wxGTK and then once it completed, I started a build for CubicSDR. > However, CubicSDR's build still used the old version of wxGTK. I can see > that the new wxGTK has been tagged into my side tag, however, is there > something else I have to do to actually get it to be usable by CubicSDR? Do > I have to submit a buildroot override for it? Or do I need to wait for some > background process to complete? Yes, you need to wait for kojira to fire off a newrepo and have that complete. You can wait for this with: koji wait-repo --build=wxGTK-3.1.4-1.fc33 f33-build-side-26816 Once that completes successfully, you can do the next builds in the side-tag. 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
Using a side tag
I'm trying to use a side tag to rebuild a package (wxGTK) and its dependent (CubicSDR) due to an soname bump. I rebuilt wxGTK and then once it completed, I started a build for CubicSDR. However, CubicSDR's build still used the old version of wxGTK. I can see that the new wxGTK has been tagged into my side tag, however, is there something else I have to do to actually get it to be usable by CubicSDR? Do I have to submit a buildroot override for it? Or do I need to wait for some background process to complete? Thanks, Scott ___ 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
[python-engineio] test failures on F33 koji
I am trying to fix FTBFS and upgrade engineio to 3.13 (current version in rawhide is 3.11). Some tests keep failing on koji [0] but not when I build locally using mock. This is what I see in build log - _ ERROR collecting tests/common/test_async_eventlet.py _ /usr/lib/python3.9/site-packages/dns/resolver.py:743: in read_resolv_conf f = stack.enter_context(open(f)) E FileNotFoundError: [Errno 2] No such file or directory: '/etc/resolv.conf' During handling of the above exception, another exception occurred: E dns.resolver.NoResolverConfiguration: Resolver configuration could not be read or specified no nameservers. Pointers to fix this will be greatly appreciated. Thanks! [0] https://koji.fedoraproject.org/koji/taskinfo?taskID=48843424 signature.asc Description: OpenPGP digital signature ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Re: Help needed to fix a FTBFS (shaderc)
On Saturday, 8 August 2020 23:10:25 CEST Jeff Law wrote: > On Sat, 2020-08-08 at 17:27 +0200, Robert-André Mauchin wrote: > > > Hello, > > > > shaderc was FTBFS due to the cmake change, however fixing it does not > > solve everything. I've got a long list of new errors: > > > > > > == > > = [29/29] : && /usr/lib64/ccache/g++ -O2 -flto=auto -ffat-lto-objects > > - fexceptions -g -grecord-gcc-switches -pipe -Wall > > -Werror=format-security -Wp,- D_FORTIFY_SOURCE=2 > > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/ redhat-hardened-cc1 > > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/ redhat-annobin-cc1 > > -m64 -mtune=generic -fasynchronous-unwind-tables -fstack- > > clash-protection -fcf-protection -Wimplicit-fallthrough -O2 -g -DNDEBUG > > -Wl,- z,relro -Wl,--as-needed -Wl,-z,now > > -specs=/usr/lib/rpm/redhat/redhat- hardened-ld-rdynamic > > glslc/CMakeFiles/glslc_exe.dir/src/main.cc.o -o glslc/glslc > > glslc/libglslc.a libshaderc_util/libshaderc_util.a libshaderc/ > > libshaderc.a libshaderc_util/libshaderc_util.a -lSPIRV-Tools-opt > > -lSPIRV- Tools -lglslang -lOSDependent -lOGLCompiler -lglslang > > -lOSDependent - lOGLCompiler -lSPIRV -lHLSL -lpthread && : > > FAILED: glslc/glslc > > > > : && /usr/lib64/ccache/g++ -O2 -flto=auto -ffat-lto-objects -fexceptions > > : -g - > > > grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,- > > D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/ > > redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/ > > redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables > > -fstack- clash-protection -fcf-protection -Wimplicit-fallthrough -O2 -g > > -DNDEBUG -Wl,- z,relro -Wl,--as-needed -Wl,-z,now > > -specs=/usr/lib/rpm/redhat/redhat- hardened-ld-rdynamic > > glslc/CMakeFiles/glslc_exe.dir/src/main.cc.o -o glslc/glslc > > glslc/libglslc.a libshaderc_util/libshaderc_util.a libshaderc/ > > libshaderc.a libshaderc_util/libshaderc_util.a -lSPIRV-Tools-opt > > -lSPIRV- Tools -lglslang -lOSDependent -lOGLCompiler -lglslang > > -lOSDependent - lOGLCompiler -lSPIRV -lHLSL -lpthread && : > > /usr/bin/ld: /tmp/glslc.KMUNIm.ltrans0.ltrans.o: in function `main': > > /builddir/build/BUILD/shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86 > > _64- redhat-linux-gnu/../libshaderc_util/src/compiler.cc:124: undefined > > reference to `glslang::InitializeProcess()' > > /usr/bin/ld: /tmp/glslc.KMUNIm.ltrans1.ltrans.o: in function > > `shaderc_util::GlslangInitializer::~GlslangInitializer() [clone > > .constprop. 0]': > > /builddir/build/BUILD/shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86 > > _64- redhat-linux-gnu/../libshaderc_util/src/compiler.cc:136: undefined > > reference to `glslang::FinalizeProcess()' > > /usr/bin/ld: /tmp/glslc.KMUNIm.ltrans1.ltrans.o: in function > > `shaderc_util::Compiler::Compile(shaderc_util::string_piece const&, > > EShLanguage, std::__cxx11::basic_string, > > std::allocator > const&, char const*, std::function > (std::ostream*, shaderc_util::string_piece const&)> const&, > > shaderc_util::CountingIncluder&, shaderc_util::Compiler::OutputType, > > std::ostream*, unsigned long*, unsigned long*) const [clone > > .constprop.0]': > > /builddir/build/BUILD/shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x8 > > 6_64- redhat-linux-gnu/../libshaderc_util/src/compiler.cc:267: undefined > > reference to `glslang::TShader::TShader(EShLanguage)' > > /usr/bin/ld: /builddir/build/BUILD/ > > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/. > > ./ libshaderc_util/src/compiler.cc:271: undefined reference to > > `glslang::TShader::setStringsWithLengthsAndNames(char const* const*, int > > const*, char const* const*, int)' > > /usr/bin/ld: /builddir/build/BUILD/ > > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/. > > ./ libshaderc_util/src/compiler.cc:274: undefined reference to > > `glslang::TShader::setEntryPoint(char const*)' > > /usr/bin/ld: /builddir/build/BUILD/ > > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/. > > ./ libshaderc_util/src/compiler.cc:275: undefined reference to > > `glslang::TShader::setAutoMapBindings(bool)' > > /usr/bin/ld: /builddir/build/BUILD/ > > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/. > > ./ libshaderc_util/src/compiler.cc:276: undefined reference to > > `glslang::TShader::setAutoMapLocations(bool)' > > /usr/bin/ld: /builddir/build/BUILD/ > > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/. > > ./ libshaderc_util/src/compiler.cc:278: undefined reference to > > `glslang::TShader::setShiftImageBinding(unsigned int)' > > /usr/bin/ld: /builddir/build/BUILD/ > > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/. > > ./ libshaderc_util/src/compiler.cc:279: undefined
Re: LTO and the F33 mass rebuild
On Sat, Aug 8, 2020 at 10:03 PM Jeff Law wrote: > So I've done two passes over the F33 build failures here: Thank you for taking ownership and responsibility for those things that you can control. It is a model for other change owners to attempt to achieve. ___ 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
LTO and the F33 mass rebuild
So I've done two passes over the F33 build failures here:
https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html
For any package which was failing and LTO appeared to be a factor, I've assigned
the package's associated FTBFS BZ to me to address the LTO component. Some of
those I've already fixed and either closed the BZ or handed it back to the
default assignee for non-LTO issues that need to be resolved.
Thus if you have a package on the failing packages list and its still failing,
it's unlikely to be an LTO issue. I don't mind if you reach out, but start from
the assumption LTO isn't the triggering event. You can use %define _lto_cflags
%{nil} in your .spec file to disable LTO for testing purposes.
Having said that, I do expect some LTO issues to still pop up. For example it's
likely we'll continue to see the cmake issues get resolved in various packages
and I wouldn't be surprised if after fixing a package to work with the new cmake
macros that a small number will trip LTO issues. I'm obviously here to help
with
those too.
It's also possible there are packages that are failing and which are not on that
list. One was passed along to me yesterday (libaio). Again, happy to help with
analyzing those too.
Anyway, the immediate actions are to find a near term resolution for the LTO
issues which I've assigned to myself in BZ. There aren't that many and I'm
confident we'll be able to close them out in a reasonable timeframe.
After that I'll be reviewing all the opt-outs to see which we can move forward,
which require upstream GCC bug reports, etc.
Jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Respinning rawhide images every filesystem update?
On Thu, Aug 06, 2020 at 12:02:09PM -0400, Alex Scheel wrote: > - Original Message - > > From: "Stephen John Smoogen" > > To: "Development discussions related to Fedora" > > > > Sent: Thursday, August 6, 2020 10:55:51 AM > > Subject: Re: Respinning rawhide images every filesystem update? > > > > On Thu, 6 Aug 2020 at 10:05, Alex Scheel wrote: > > > > > > - Original Message - > > > > From: "Stephen John Smoogen" > > > > To: "Development discussions related to Fedora" > > > > , asch...@redhat.com > > > > Sent: Thursday, August 6, 2020 9:55:17 AM > > > > Subject: Re: Respinning rawhide images every filesystem update? > > > > > > > > On Thu, 6 Aug 2020 at 09:36, Alex Scheel wrote: > > > > > > > > > > I'm bumping this thread. This is still broken. > > > > > > > > > > > > > Please open a ticket at > > > > https://pagure.io/fedora-infrastructure/new_issue and open new issue > > > > with an explanation of what is broken and where you are pulling from. > > > > If it is a fedora registry then infrastructure can work on a fix. If > > > > it is from docker.io or quay or elsewhere we can try to find the > > > > people who fix it and let them know. > > > > > > Opened: > > > > > > https://pagure.io/fedora-infrastructure/issue/9208 > > > > > > This was also posted to devel to hopefully get the attention of the > > > filesystem maintainer. > > > > > > > > > They seem to have ignored 1548403 since 2018. :-) > > > > > > > > > > OK so this ticket clarifies the problem because I thought this was a > > problem with the filesystem in the container image with how it is spun > > or delivered. It is instead with the package filesystem. Here is the > > ticket contents (since most people don't follow links in emails). > > There's three ways to solve this: > > 1) Make the filesystem upgrade nicely in a container, or > 2) Have the container runtime/user namespace system/... support the > type of change that upgrading the filesystem package makes, or > 3) Just respin the container image quickly whenever this happens; this > hides the problem from users without solving the problem. > > 1 isn't happening because the maintainer isn't involved. > 2 isn't happening because the container runtime maintainers punted on it. > 3 is the easiest left to accomplish. But I am confused, because as far as I can tell this is already happening. > If I had a choice, I'd be really happy with 3. I don't know what > all is involved to respin container images with a new package. I'm > sure it takes time, but I'd imagine it'd be mostly automated. The > problem gets fixed eventually anyways. It is automated. It happens every compose of rawhide. I am not sure why you are not seeing the new images. Are you pulling from registry.fedoraproject.org? 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
Re: Still problems with s390x builds
On Sat, Aug 08, 2020 at 05:57:07PM +0200, Andrea Musuruane wrote: > On Sat, Aug 8, 2020 at 5:46 PM José Abílio Matos wrote: > > > On Saturday, 8 August 2020 16.26.39 WEST Andrea Musuruane wrote: > > > > > Can someone please check? > > > > > > > > > > Thanks! > > > > > > > > > > Andrea > > > > > > > > When that happens I issue another rebuild and the problem is solved. In > > other words this is a transient problem. > > > > > > > I submitted another build. It failed with the same error: > https://koji.fedoraproject.org/koji/taskinfo?taskID=48924234 There was some upstream to us work in the iad2 datacenter today: https://pagure.io/fedora-infrastructure/issue/9200 Please retry now and see if things are better. 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
Re: Help needed to fix a FTBFS (shaderc)
On Sat, 2020-08-08 at 17:27 +0200, Robert-André Mauchin wrote: > Hello, > > shaderc was FTBFS due to the cmake change, however fixing it does not solve > everything. I've got a long list of new errors: > > > === > [29/29] : && /usr/lib64/ccache/g++ -O2 -flto=auto -ffat-lto-objects - > fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,- > D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/ > redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/ > redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack- > clash-protection -fcf-protection -Wimplicit-fallthrough -O2 -g -DNDEBUG -Wl,- > z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat- > hardened-ld-rdynamic glslc/CMakeFiles/glslc_exe.dir/src/main.cc.o -o > glslc/glslc glslc/libglslc.a libshaderc_util/libshaderc_util.a libshaderc/ > libshaderc.a libshaderc_util/libshaderc_util.a -lSPIRV-Tools-opt -lSPIRV- > Tools -lglslang -lOSDependent -lOGLCompiler -lglslang -lOSDependent - > lOGLCompiler -lSPIRV -lHLSL -lpthread && : > FAILED: glslc/glslc > : && /usr/lib64/ccache/g++ -O2 -flto=auto -ffat-lto-objects -fexceptions -g - > grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,- > D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/ > redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/ > redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack- > clash-protection -fcf-protection -Wimplicit-fallthrough -O2 -g -DNDEBUG -Wl,- > z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat- > hardened-ld-rdynamic glslc/CMakeFiles/glslc_exe.dir/src/main.cc.o -o > glslc/glslc glslc/libglslc.a libshaderc_util/libshaderc_util.a libshaderc/ > libshaderc.a libshaderc_util/libshaderc_util.a -lSPIRV-Tools-opt -lSPIRV- > Tools -lglslang -lOSDependent -lOGLCompiler -lglslang -lOSDependent - > lOGLCompiler -lSPIRV -lHLSL -lpthread && : > /usr/bin/ld: /tmp/glslc.KMUNIm.ltrans0.ltrans.o: in function `main': > /builddir/build/BUILD/shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64- > redhat-linux-gnu/../libshaderc_util/src/compiler.cc:124: undefined reference > to `glslang::InitializeProcess()' > /usr/bin/ld: /tmp/glslc.KMUNIm.ltrans1.ltrans.o: in function > `shaderc_util::GlslangInitializer::~GlslangInitializer() [clone .constprop. > 0]': > /builddir/build/BUILD/shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64- > redhat-linux-gnu/../libshaderc_util/src/compiler.cc:136: undefined reference > to `glslang::FinalizeProcess()' > /usr/bin/ld: /tmp/glslc.KMUNIm.ltrans1.ltrans.o: in function > `shaderc_util::Compiler::Compile(shaderc_util::string_piece const&, > EShLanguage, std::__cxx11::basic_string, > std::allocator > const&, char const*, std::function (std::ostream*, shaderc_util::string_piece const&)> const&, > shaderc_util::CountingIncluder&, shaderc_util::Compiler::OutputType, > std::ostream*, unsigned long*, unsigned long*) const [clone .constprop.0]': > /builddir/build/BUILD/shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64- > redhat-linux-gnu/../libshaderc_util/src/compiler.cc:267: undefined reference > to `glslang::TShader::TShader(EShLanguage)' > /usr/bin/ld: /builddir/build/BUILD/ > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../ > libshaderc_util/src/compiler.cc:271: undefined reference to > `glslang::TShader::setStringsWithLengthsAndNames(char const* const*, int > const*, char const* const*, int)' > /usr/bin/ld: /builddir/build/BUILD/ > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../ > libshaderc_util/src/compiler.cc:274: undefined reference to > `glslang::TShader::setEntryPoint(char const*)' > /usr/bin/ld: /builddir/build/BUILD/ > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../ > libshaderc_util/src/compiler.cc:275: undefined reference to > `glslang::TShader::setAutoMapBindings(bool)' > /usr/bin/ld: /builddir/build/BUILD/ > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../ > libshaderc_util/src/compiler.cc:276: undefined reference to > `glslang::TShader::setAutoMapLocations(bool)' > /usr/bin/ld: /builddir/build/BUILD/ > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../ > libshaderc_util/src/compiler.cc:278: undefined reference to > `glslang::TShader::setShiftImageBinding(unsigned int)' > /usr/bin/ld: /builddir/build/BUILD/ > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../ > libshaderc_util/src/compiler.cc:279: undefined reference to > `glslang::TShader::setShiftSamplerBinding(unsigned int)' > /usr/bin/ld: /builddir/build/BUILD/ > shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../ > libshaderc_util/src/compiler.cc:280: undefined reference to >
Re: Help needed to fix a FTBFS (shaderc)
On Sat, 2020-08-08 at 22:04 +0200, Robert-André Mauchin wrote: > On Saturday, 8 August 2020 21:53:57 CEST Jeff Law wrote: > > More likely it's uninstantiated templates > > I don't know about this, did we change something within Fedora that could > trigger this issue while it was working before? Template instantiation issues are sensitive to inlining heuristics in the compiler. Subtle changes in those heuristics can change what gets inlined where. This is a common source level issue. THe fact that it worked before does not mean it was correct. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help needed to fix a FTBFS (shaderc)
On Saturday, 8 August 2020 21:53:57 CEST Jeff Law wrote: > More likely it's uninstantiated templates I don't know about this, did we change something within Fedora that could trigger this issue while it was working before? Thanks Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help needed to fix a FTBFS (shaderc)
On Sat, 2020-08-08 at 15:51 -0400, Neal Gompa wrote: > On Sat, Aug 8, 2020 at 3:47 PM Robert-André Mauchin wrote: > > On Saturday, 8 August 2020 17:27:54 CEST you wrote: > > > And so on. > > > Tons of errors regarding undefined reference to glslang::. > > > I don't know if this is due to a new Glslang or if something has been > > > changed wrt the build system, or if system-wide libraries are not > > > supported > > > anymore. > > > > > > Any help for figuring out what happened would be greatly appreciated. > > > > > > Best regards, > > > > > > Robert-André > > > > > > > I have the same issue with another FTBFS, soundkonverter: > > > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:215: undefined reference to `TagLib::String::String(char > > const*, TagLib::String::Type)' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:215: undefined reference to `TagLib::String::~String()' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:216: undefined reference to `TagLib::String::String(char > > const*, TagLib::String::Type)' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:216: undefined reference to `TagLib::String::~String()' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:217: undefined reference to `TagLib::String::String(char > > const*, TagLib::String::Type)' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:217: undefined reference to `TagLib::String::~String()' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:220: undefined reference to `TagLib::String::String(char > > const*, TagLib::String::Type)' > > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function > > `readXiphTags(TagLib::Ogg::XiphComment*)': > > /usr/include/c++/10/bits/stl_function.h:386: undefined reference to > > `TagLib::String::operator<(TagLib::String const&) const' > > /usr/bin/ld: /usr/include/c++/10/bits/stl_function.h:386: undefined > > reference > > to `TagLib::String::operator<(TagLib::String const&) const' > > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function > > `readXiphTags(TagLib::Ogg::XiphComment*)': > > /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/MetaReplayGain.cpp: > > 220: undefined reference to `TagLib::String::~String()' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:222: undefined reference to `TagLib::String::String(char > > const*, TagLib::String::Type)' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:222: undefined reference to `TagLib::String::~String()' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:223: undefined reference to `TagLib::String::String(char > > const*, TagLib::String::Type)' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:223: undefined reference to `TagLib::String::~String()' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:224: undefined reference to `TagLib::String::String(char > > const*, TagLib::String::Type)' > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > > MetaReplayGain.cpp:224: undefined reference to `TagLib::String::~String()' > > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function > > `TagLib::Map::~Map() [clone > > .lto_priv.0]': > > /usr/include/c++/10/bits/stl_pair.h:211: undefined reference to > > `TagLib::StringList::~StringList()' > > /usr/bin/ld: > > /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o:/usr/include/c++/10/ > > bits/stl_pair.h:211: undefined reference to `TagLib::String::~String()' > > > > Is it related to the cmake change? Am I missing something obvious? > > > > That looks like failures related to LTO? No. I've already check that one. You'll get the same effective failures without LTO. More likely it's uninstantiated templates (which is a common source issue, not a compiler issue) jeff > > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help needed to fix a FTBFS (shaderc)
On Sat, Aug 8, 2020 at 3:47 PM Robert-André Mauchin wrote: > > On Saturday, 8 August 2020 17:27:54 CEST you wrote: > > > > And so on. > > Tons of errors regarding undefined reference to glslang::. > > I don't know if this is due to a new Glslang or if something has been > > changed wrt the build system, or if system-wide libraries are not supported > > anymore. > > > > Any help for figuring out what happened would be greatly appreciated. > > > > Best regards, > > > > Robert-André > > > > I have the same issue with another FTBFS, soundkonverter: > > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:215: undefined reference to `TagLib::String::String(char > const*, TagLib::String::Type)' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:215: undefined reference to `TagLib::String::~String()' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:216: undefined reference to `TagLib::String::String(char > const*, TagLib::String::Type)' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:216: undefined reference to `TagLib::String::~String()' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:217: undefined reference to `TagLib::String::String(char > const*, TagLib::String::Type)' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:217: undefined reference to `TagLib::String::~String()' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:220: undefined reference to `TagLib::String::String(char > const*, TagLib::String::Type)' > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function > `readXiphTags(TagLib::Ogg::XiphComment*)': > /usr/include/c++/10/bits/stl_function.h:386: undefined reference to > `TagLib::String::operator<(TagLib::String const&) const' > /usr/bin/ld: /usr/include/c++/10/bits/stl_function.h:386: undefined reference > to `TagLib::String::operator<(TagLib::String const&) const' > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function > `readXiphTags(TagLib::Ogg::XiphComment*)': > /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/MetaReplayGain.cpp: > 220: undefined reference to `TagLib::String::~String()' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:222: undefined reference to `TagLib::String::String(char > const*, TagLib::String::Type)' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:222: undefined reference to `TagLib::String::~String()' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:223: undefined reference to `TagLib::String::String(char > const*, TagLib::String::Type)' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:223: undefined reference to `TagLib::String::~String()' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:224: undefined reference to `TagLib::String::String(char > const*, TagLib::String::Type)' > /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ > MetaReplayGain.cpp:224: undefined reference to `TagLib::String::~String()' > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function > `TagLib::Map::~Map() [clone .lto_priv.0]': > /usr/include/c++/10/bits/stl_pair.h:211: undefined reference to > `TagLib::StringList::~StringList()' > /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o:/usr/include/c++/10/ > bits/stl_pair.h:211: undefined reference to `TagLib::String::~String()' > > Is it related to the cmake change? Am I missing something obvious? > That looks like failures related to LTO? -- 真実はいつも一つ！/ 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
Re: Help needed to fix a FTBFS (shaderc)
On Saturday, 8 August 2020 17:27:54 CEST you wrote: > > And so on. > Tons of errors regarding undefined reference to glslang::. > I don't know if this is due to a new Glslang or if something has been > changed wrt the build system, or if system-wide libraries are not supported > anymore. > > Any help for figuring out what happened would be greatly appreciated. > > Best regards, > > Robert-André > I have the same issue with another FTBFS, soundkonverter: /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:215: undefined reference to `TagLib::String::String(char const*, TagLib::String::Type)' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:215: undefined reference to `TagLib::String::~String()' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:216: undefined reference to `TagLib::String::String(char const*, TagLib::String::Type)' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:216: undefined reference to `TagLib::String::~String()' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:217: undefined reference to `TagLib::String::String(char const*, TagLib::String::Type)' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:217: undefined reference to `TagLib::String::~String()' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:220: undefined reference to `TagLib::String::String(char const*, TagLib::String::Type)' /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function `readXiphTags(TagLib::Ogg::XiphComment*)': /usr/include/c++/10/bits/stl_function.h:386: undefined reference to `TagLib::String::operator<(TagLib::String const&) const' /usr/bin/ld: /usr/include/c++/10/bits/stl_function.h:386: undefined reference to `TagLib::String::operator<(TagLib::String const&) const' /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function `readXiphTags(TagLib::Ogg::XiphComment*)': /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/MetaReplayGain.cpp: 220: undefined reference to `TagLib::String::~String()' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:222: undefined reference to `TagLib::String::String(char const*, TagLib::String::Type)' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:222: undefined reference to `TagLib::String::~String()' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:223: undefined reference to `TagLib::String::String(char const*, TagLib::String::Type)' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:223: undefined reference to `TagLib::String::~String()' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:224: undefined reference to `TagLib::String::String(char const*, TagLib::String::Type)' /usr/bin/ld: /builddir/build/BUILD/soundkonverter-3.0.1/src/metadata/ MetaReplayGain.cpp:224: undefined reference to `TagLib::String::~String()' /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o: in function `TagLib::Map::~Map() [clone .lto_priv.0]': /usr/include/c++/10/bits/stl_pair.h:211: undefined reference to `TagLib::StringList::~StringList()' /usr/bin/ld: /tmp/soundkonverter.4HzRaR.ltrans3.ltrans.o:/usr/include/c++/10/ bits/stl_pair.h:211: undefined reference to `TagLib::String::~String()' Is it related to the cmake change? Am I missing something obvious? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Media key support in F32 / Gnome / systemd
On 8/8/20 11:30 AM, Christopher wrote: Thanks for the sanity check and for setting me on the right path. This isn't a great user experience, but at least it is *possible* to configure things the way I want. Well, for most users, it's a great experience because the keys do what they say they do. I'm very happy that my suspend key works. :-) And I don't expect to be able to easily map any random key on my keyboard to something else. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Media key support in F32 / Gnome / systemd
On Sat, Aug 8, 2020 at 1:38 PM Samuel Sieb wrote: > > On 8/8/20 3:52 AM, Christopher wrote: > > Does anybody know what the current state of media key support is in > > F32 / Gnome / systemd? > > Is it currently broken? > > It works great. That wasn't my experience, but knowing it works for others helps me narrow down whether the problem is on my end or not. > > > I recently bought a Logitech MK270 wireless mouse/keyboard (pretty > > common), which has a "power" media key, which seems to put my Fedora > > 32 system to sleep, and it doesn't seem to be possible to disable it > > in Gnome or in systemd-logind settings. It's possible I'm doing > > something wrong, but I'm now questioning whether this is just broken > > in Fedora right now, since nothing I've tried works. > > That sounds to me like it's doing exactly what it should. What are you > expecting it to do? If you go into the Gnome settings Power panel, you > could try changing the power key action, but that might only affect the > hard power button on the case. An alternative is to use dconf-editor > and change the suspend key setting in > /org/gnome/settings-daemon/plugins/media-keys/. What I was expecting was the ability to disable it. After your response, and another half hour of troubleshooting, I have learned that: 1. There is no GUI to change the setting. 2. The logind.conf settings have no effect on the media keys. 3. The key is XF86Sleep (and not XF86Suspend). 4. The key is assigned to the 'suspend-static' behavior in dconf-editor / gsettings 5. Changing the assignment in dconf-editor / gsettings requires logging out and back in to take effect And most importantly, 6. It is *not* enough to assign the XF86Sleep button to another action in the keyboard shortcuts. You have to *also* remove it from the 'suspend-static' action, or it will suspend the computer instead of performing the other assigned action. This last bit was the part that was the most frustrating, since everything else I did had no effect. Now that I have unassociated 'XF86Sleep' from the 'suspend-static' action, I can now re-assign it to do other things. Thanks for the sanity check and for setting me on the right path. This isn't a great user experience, but at least it is *possible* to configure things the way I want. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Media key support in F32 / Gnome / systemd
On 8/8/20 3:52 AM, Christopher wrote: Does anybody know what the current state of media key support is in F32 / Gnome / systemd? Is it currently broken? It works great. I recently bought a Logitech MK270 wireless mouse/keyboard (pretty common), which has a "power" media key, which seems to put my Fedora 32 system to sleep, and it doesn't seem to be possible to disable it in Gnome or in systemd-logind settings. It's possible I'm doing something wrong, but I'm now questioning whether this is just broken in Fedora right now, since nothing I've tried works. That sounds to me like it's doing exactly what it should. What are you expecting it to do? If you go into the Gnome settings Power panel, you could try changing the power key action, but that might only affect the hard power button on the case. An alternative is to use dconf-editor and change the suspend key setting in /org/gnome/settings-daemon/plugins/media-keys/. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20200808.n.0 changes
OLD: Fedora-Rawhide-20200807.n.0 NEW: Fedora-Rawhide-20200808.n.0 = SUMMARY = Added images:6 Dropped images: 1 Added packages: 2 Dropped packages:1 Upgraded packages: 246 Downgraded packages: 0 Size of added packages: 8.62 MiB Size of dropped packages:991.42 KiB Size of upgraded packages: 3.96 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -81.64 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20200808.n.0-sda.raw.xz Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20200808.n.0-sda.raw.xz Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20200808.n.0-sda.raw.xz Image: Xfce raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-armhfp-Rawhide-20200808.n.0-sda.raw.xz Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-armhfp-Rawhide-20200808.n.0-sda.raw.xz Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20200808.n.0.iso = DROPPED IMAGES = Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20200807.n.0.iso = ADDED PACKAGES = Package: e-antic-0.1.8-1.fc33 Summary: Real Embedded Algebraic Number Theory In C RPMs:e-antic e-antic-devel Size:632.54 KiB Package: golang-gvisor-20200804.0-1.20200805git1d6b9c1.fc33 Summary: A container sandbox runtime focused on security, efficiency, and ease of use RPMs:golang-gvisor golang-gvisor-devel Size:8.00 MiB = DROPPED PACKAGES = Package: ktoblzcheck-1.49-4.fc33 Summary: A library to check account numbers and bank codes of German banks RPMs:ktoblzcheck ktoblzcheck-devel Size:991.42 KiB = UPGRADED PACKAGES = Package: CheMPS2-1.8.9-10.fc33 Old package: CheMPS2-1.8.9-9.fc33 Summary: A spin-adapted implementation of DMRG for ab initio quantum chemistry RPMs: CheMPS2 CheMPS2-devel Size: 3.65 MiB Size change: 1.41 KiB Changelog: * Fri Aug 07 2020 I??aki ??car - 1.8.9-10 - https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager Package: Coin4-4.0.0-7.fc33 Old package: Coin4-4.0.0-5.fc32 Summary: High-level 3D visualization library RPMs: Coin4 Coin4-devel Coin4-doc Size: 53.83 MiB Size change: 138.47 KiB Changelog: * Mon Jul 27 2020 Fedora Release Engineering - 4.0.0-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sat Aug 01 2020 Fedora Release Engineering - 4.0.0-7 - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild Package: DSDP-5.8-26.fc33 Old package: DSDP-5.8-25.fc33 Summary: Software for semidefinite programming RPMs: DSDP DSDP-devel DSDP-examples Size: 8.68 MiB Size change: 871 B Changelog: * Fri Aug 07 2020 I??aki ??car - 5.8-26 - https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager Package: GMT-6.1.0-4.fc33 Old package: GMT-6.1.0-3.fc33 Summary: Generic Mapping Tools RPMs: GMT GMT-common GMT-devel GMT-doc Size: 65.70 MiB Size change: -558 B Changelog: * Fri Aug 07 2020 Orion Poplawski - 6.1.0-4 - https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager - Use new cmake macros Package: aespipe-2.4e-4.fc33 Old package: aespipe-2.4e-4.fc32 Summary: AES-based encryption tool for tar/cpio and loop-aes imagemore RPMs: aespipe Size: 254.06 KiB Size change: -860 B Package: armadillo-9.900.2-5.fc33 Old package: armadillo-9.900.2-4.fc33 Summary: Fast C++ matrix library with syntax similar to MATLAB and Octave RPMs: armadillo armadillo-devel Size: 10.93 MiB Size change: 1.26 KiB Changelog: * Wed Aug 05 2020 Jos?? Matos - 9.900.2-5 - add upstream patch to support flexiblas - enable tests Package: arpack-3.7.0-8.fc33 Old package: arpack-3.7.0-7.fc33 Summary: Fortran 77 subroutines for solving large scale eigenvalue problems RPMs: arpack arpack-devel arpack-doc arpack-static Size: 2.07 MiB Size change: 1.95 KiB Changelog: * Fri Aug 07 2020 I??aki ??car - 3.7.0-8 - https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager Package: bolt-0.9-3.fc33 Old package: bolt-0.9-1.fc33 Summary: Thunderbolt device manager RPMs: bolt Size: 932.91 KiB Size change: -41.78 KiB Changelog: * Mon Jul 27 2020 Fedora Release Engineering - 0.9-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sat Aug 01 2020 Fedora Release Engineering - 0.9-3 - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild Package: candy-icon-theme-0-16.20200731git5df1fcdf.fc33 Old package: candy-icon-theme-0-15.20200704git8c144f59.fc33 Summary: Sweet
bug on display DPI , Component cinnamon.
I haven't completed a bug in a while. Now with the new badge system, I suspect it is even more complex to add to the contribution of each user. I did not find any indication of how to proceed for the badge. 1. Maybe someone will help me and tell me if I have to go somewhere else. 2. The bug can be found at https://bugzilla.redhat.com/show_bug.cgi?id=1867313 Thank you. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Still problems with s390x builds
On Sat, Aug 8, 2020 at 5:46 PM José Abílio Matos wrote: > On Saturday, 8 August 2020 16.26.39 WEST Andrea Musuruane wrote: > > > Can someone please check? > > > > > > Thanks! > > > > > > Andrea > > > > When that happens I issue another rebuild and the problem is solved. In > other words this is a transient problem. > > > I submitted another build. It failed with the same error: https://koji.fedoraproject.org/koji/taskinfo?taskID=48924234 Regards, Andrea ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Still problems with s390x builds
On Saturday, 8 August 2020 16.26.39 WEST Andrea Musuruane wrote: > Can someone please check? > > Thanks! > > Andrea When that happens I issue another rebuild and the problem is solved. In other words this is a transient problem. -- José Abílio___ 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
Help needed to fix a FTBFS (shaderc)
reference to
`glslang::TShader::setShiftUboBinding(unsigned int)'
/usr/bin/ld: /builddir/build/BUILD/
shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
libshaderc_util/src/compiler.cc:282: undefined reference to
`glslang::TShader::setShiftSsboBinding(unsigned int)'
/usr/bin/ld: /builddir/build/BUILD/
shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
libshaderc_util/src/compiler.cc:284: undefined reference to
`glslang::TShader::setShiftUavBinding(unsigned int)'
/usr/bin/ld: /builddir/build/BUILD/
shaderc-7c2aa93903558f017f31b35df163bce5fe849f45/x86_64-redhat-linux-gnu/../
libshaderc_util/src/compiler.cc:286: undefined reference to
`glslang::TShader::setHlslIoMapping(bool)'
===
And so on.
Tons of errors regarding undefined reference to glslang::.
I don't know if this is due to a new Glslang or if something has been changed
wrt the build system, or if system-wide libraries are not supported anymore.
Any help for figuring out what happened would be greatly appreciated.
Best regards,
Robert-André
Here's the SPEC: https://src.fedoraproject.org/rpms/shaderc/tree/master
===
# Force out of source build
%undefine __cmake_in_source_build
# Release 2020.1
%global commit 7c2aa93903558f017f31b35df163bce5fe849f45
%global shortcommit %(c=%{commit}; echo ${c:0:7})
%global snapshotdate20200808
# Glslang revision from packaged version
%global glslang_version SDK-candidate-2-11-gc9b28b9f
Name: shaderc
Version:2020.1
Release:1%{?dist}
Summary:A collection of tools, libraries, and tests for Vulkan shader
compilation
License:ASL 2.0
URL:https://github.com/google/shaderc
Source0:%url/archive/%{commit}/%{name}-%{shortcommit}.tar.gz
# https://github.com/google/shaderc/pull/463
Patch0: 0001-Fix-the-link-order-of-libglslang-and-libHLSL.patch
# Patch to unbundle 3rd party code
Patch1: 0001-Drop-third-party-code-in-CMakeLists.txt.patch
BuildRequires: cmake3
BuildRequires: gcc-c++
BuildRequires: ninja-build
BuildRequires: python3-devel
BuildRequires: glslang-devel
BuildRequires: spirv-headers-devel
BuildRequires: spirv-tools
BuildRequires: spirv-tools-devel
%description
A collection of tools, libraries and tests for shader compilation.
Shaderc aims to to provide:
- a command line compiler with GCC- and Clang-like usage, for better
integration with build systems
- an API where functionality can be added without breaking existing clients
- an API supporting standard concurrency patterns across multiple
operating systems
- increased functionality such as file #include support
%package-n glslc
Summary:A command line compiler for GLSL/HLSL to SPIR-V
%description -n glslc
A command line compiler for GLSL/HLSL to SPIR-V.
%package-n libshaderc
Summary:A library for compiling shader strings into SPIR-V
%description -n libshaderc
A library for compiling shader strings into SPIR-V.
%package -n libshaderc-devel
Summary:Development files for libshaderc
Requires: libshaderc%{?_isa} = %{version}-%{release}
%description -n libshaderc-devel
A library for compiling shader strings into SPIR-V.
Development files for libshaderc.
%package -n libshaderc-static
Summary:A library for compiling shader strings into SPIR-V (static
libraries)
%description -n libshaderc-static
A library for compiling shader strings into SPIR-V.
Static libraries for libshaderc.
%prep
%autosetup -p1 -n %{name}-%{commit}
rm -rf third_party
# Stolen from Gentoo
# Create build-version.inc since we want to use our packaged
# SPIRV-Tools and glslang
echo \"shaderc $(grep -m1 -o '^v[[:digit:]]\{4\}\.[[:digit:]]\(-dev\)\?
[[:digit:]]\{4\}-[[:digit:]]\{2\}-[[:digit:]]\{2\}$' CHANGES)\" \
> glslc/src/build-version.inc
echo \"spirv-tools $(grep -m1 -o '^v[[:digit:]]\{4\}\.[[:digit:]]\(-dev\)\?
[[:digit:]]\{4\}-[[:digit:]]\{2\}-[[:digit:]]\{2\}$' /usr/share/doc/spirv-
tools/CHANGES)\" \
>> glslc/src/build-version.inc
echo \"glslang %{glslang_version}\" >> glslc/src/build-version.inc
# Point to correct include
sed -i 's|SPIRV/GlslangToSpv.h|glslang/SPIRV/GlslangToSpv.h|' libshaderc_util/
src/compiler.cc
%build
# We disable the tests because they don't work with our unbundling of 3rd
party.
# See https://github.com/google/shaderc/issues/470
%cmake3 -DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_SKIP_RPATH=True \
-DSHADERC_SKIP_TESTS=True \
-DPYTHON_EXE=%{__python3} \
-GNinja
%cmake3_build
%install
%cmake3_install
%check
ctest -V
%files -n glslc
%doc glslc/README.asciidoc
%license LICENSE
%{_bindir}/glslc
%files -n libshaderc
%doc AUTHORS CHANGES CONTRIBUTORS README.md
%license LICENSE
Still problems with s390x builds
Hi guys, I was updating gcompris-qt for the newer cmake but I got this error on the s390x builder: GenericError: Downloaded rpm http://kojipkgs-cache01.s390.fedoraproject.org/work/tasks/4182/48924182/gcompris-qt-0.97-6.fc33.src.rpm is corrupted: rpm's header can't be extracted: /var/tmp/koji/tasks/4188/48924188/local/work/tasks/4182/48924182/gcompris-qt-0.97-6.fc33.src.rpm (rpm error: error reading package header) Can someone please check? Thanks! Andrea ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1828915] perl-Net-ARP-1.0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1828915 Robin Lee changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Net-ARP-1.0.11-1.fc33 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-08-08 13:09:11 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1852297] ack-3.4.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1852297 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-2020-6f238c5662 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6f238c5662 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[HEADS UP] pytest update to 6.0.x is approaching
Hello, recently we have updated pytest to 5, but version 6 is out and I feel confident that the update is safe, hence I plan to merge and ship pytest 6.0.1 in Fedora 33+ in couple days: https://src.fedoraproject.org/rpms/pytest/pull-request/17 I've analyzed the build failures with pytest 6.0.0rc1: https://src.fedoraproject.org/rpms/pytest/pull-request/17#comment-50314 And later with 6.0.1: https://src.fedoraproject.org/rpms/pytest/pull-request/17#comment-52937 Most of the failures are caused by PytestDeprecationWarning treated as error. If your package FTBFS, you should see the reason in one of the comments there ^ As a short term mitigation, you can disable this treatment, see https://docs.pytest.org/en/stable/changelog.html#breaking-changes PytestDeprecationWarning are now errors by default. Following our plan to remove deprecated features with as little disruption as possible, all warnings of type PytestDeprecationWarning now generate errors instead of warning messages. The affected features will be effectively removed in pytest 6.1, so please consult the Deprecations and Removals section in the docs for directions on how to update existing code. https://docs.pytest.org/en/latest/deprecations.html In the pytest 6.0.X series, it is possible to change the errors back into warnings as a stopgap measure by adding this to your pytest.ini file: [pytest] filterwarnings = ignore::pytest.PytestDeprecationWarning But this will stop working when pytest 6.1 is released. If you have concerns about the removal of a specific feature, please add a comment to https://github.com/pytest-dev/pytest/issues/5584 And if nothing else works, you can still use pytest 4, see: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/ZZTI6MJJBTPST35DZG22YIUC4JBMCJXN/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
[HEADS UP] pytest update to 6.0.x is approaching
Hello, recently we have updated pytest to 5, but version 6 is out and I feel confident that the update is safe, hence I plan to merge and ship pytest 6.0.1 in Fedora 33+ in couple days: https://src.fedoraproject.org/rpms/pytest/pull-request/17 I've analyzed the build failures with pytest 6.0.0rc1: https://src.fedoraproject.org/rpms/pytest/pull-request/17#comment-50314 And later with 6.0.1: https://src.fedoraproject.org/rpms/pytest/pull-request/17#comment-52937 Most of the failures are caused by PytestDeprecationWarning treated as error. If your package FTBFS, you should see the reason in one of the comments there ^ As a short term mitigation, you can disable this treatment, see https://docs.pytest.org/en/stable/changelog.html#breaking-changes PytestDeprecationWarning are now errors by default. Following our plan to remove deprecated features with as little disruption as possible, all warnings of type PytestDeprecationWarning now generate errors instead of warning messages. The affected features will be effectively removed in pytest 6.1, so please consult the Deprecations and Removals section in the docs for directions on how to update existing code. https://docs.pytest.org/en/latest/deprecations.html In the pytest 6.0.X series, it is possible to change the errors back into warnings as a stopgap measure by adding this to your pytest.ini file: [pytest] filterwarnings = ignore::pytest.PytestDeprecationWarning But this will stop working when pytest 6.1 is released. If you have concerns about the removal of a specific feature, please add a comment to https://github.com/pytest-dev/pytest/issues/5584 And if nothing else works, you can still use pytest 4, see: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZTI6MJJBTPST35DZG22YIUC4JBMCJXN/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Media key support in F32 / Gnome / systemd
Does anybody know what the current state of media key support is in F32 / Gnome / systemd? Is it currently broken? I recently bought a Logitech MK270 wireless mouse/keyboard (pretty common), which has a "power" media key, which seems to put my Fedora 32 system to sleep, and it doesn't seem to be possible to disable it in Gnome or in systemd-logind settings. It's possible I'm doing something wrong, but I'm now questioning whether this is just broken in Fedora right now, since nothing I've tried works. Anybody have any insight into this? Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
