Re: gstreamer-plugins-base revival
* Tom Callaway [22/08/2019 09:04] : > > I don't really want to own it, but I have dependent packages, so if no one > else does, I will claim it. Since this one is back, I'm planning to unretire perl-GStreamer and perl-GStreamer-Interfaces, which depended on this. Emmanuel ___ 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
[EPEL-devel] Re: TeamViewer on RHEL 8 and qt. Help needed
Hi, Working fine now. Thanks a lot. did dnf install qt5-qtwebchannel qt5-qtsensors qt5-qtlocation qt5-qtbase-gui qt5-qtx11extras qt5-qtdeclarative thanks. -- Thomas Stephen Lee On Tue, Sep 24, 2019 at 12:17 AM Troy Dawson wrote: > On Mon, Sep 23, 2019 at 10:53 AM Stephen John Smoogen > wrote: > > > > On Mon, 23 Sep 2019 at 12:31, Thomas Stephen Lee > wrote: > > > > > > Hi, > > > > > > download the tar version and extract > > > > > > https://download.teamviewer.com/download/linux/teamviewer_amd64.tar.xz > > > > > > cd to the folder > > > > > > run > > > > > > ./tv-setup checklibs > > > > > > the output shows > > > > > > - > > > Analyzing dependencies ... > > > libQt5Positioning.so.5 => not found > > > libQt5Sensors.so.5 => not found > > > libQt5WebChannel.so.5 => not found > > > > > > The libraries listed above seem to be missing. > > > > > > > You need to install qt5-qtwebchannel qt5-qtsensors qt5-qtlocation > > qt5-qtbase-gui qt5-qtx11extras qt5-qtdeclarative and probably a bunch > > others.. > > > > dnf repoquery --whatprovides=libQt5WebKitWidgets.so.5 > > > > and similar will tell you what is needed > > > > > -- > > > > > > and it also asks to run the command. > > > > > > dnf install 'libdbus-1.so.3()(64bit)' 'libQt5Gui.so.5()(64bit)' > 'libQt5Widgets.so.5()(64bit)' 'libQt5Qml.so.5()(64bit)' > 'libQt5Quick.so.5()(64bit)' 'libQt5WebKitWidgets.so.5()(64bit)' > 'libQt5X11Extras.so.5()(64bit)' 'libqtquick2plugin.so()(64bit)' > 'libwindowplugin.so()(64bit)' 'libqquicklayoutsplugin.so()(64bit)' > 'libqtquickcontrolsplugin.so()(64bit)' 'libdialogplugin.so()(64bit)' > > > > > > > From teh above the following don't seem available: > > > > libwindowplugin.so > > libqquicklayoutsplugin.so > > libdialogplugin.so > > > > but they don't show up in a Fedora 30 box either so I am guessing it > > needs something not listed. > > > > Correct. > This isn't a RHEL8 thing. > > > > > > > Ran the command on RHEL 8 and most libraries are missing > (epel-playground and epel-testing repos are enabled). > > > Is it something to do with RHEL 8 not supporting KDE? > > > > > > What is the solution to get TeamViewer working on RHEL 8? > > From the teamviewer page > https://www.teamviewer.com/en-us/download/linux/ > you can download an rpm designed for CentOS and Fedora > > https://www.teamviewer.com/en-us/teamviewer-automatic-download/?package=teamviewer=x86_64.rpm=linux > > That package seems to be able to install on both Fedora and RHEL8 with > epel8-playground enabled. > > > > > > > thanks. > > > > > > -- > > > Thomas Stephen Lee > > > ___ > > > 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 > > > > > > > > -- > > Stephen J Smoogen. > > ___ > > 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 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 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 1749268] [RFE] EPEL8 branch of perl-UNIVERSAL-require
https://bugzilla.redhat.com/show_bug.cgi?id=1749268 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-UNIVERSAL-require-0.18 ||-17.el8 Resolution|--- |ERRATA Last Closed||2019-09-24 03:48:43 --- Comment #4 from Fedora Update System --- perl-UNIVERSAL-require-0.18-17.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report. -- 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 1754281] [RFE] EPEL-8 branch for perl-Coro-Multicore
https://bugzilla.redhat.com/show_bug.cgi?id=1754281 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Coro-Multicore-1.03-3.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8f84208a63 -- 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 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-85b930849d blis-0.6.0-4.el8 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-cb6a4f8130 bird-2.0.6-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing git-secret-0.3.2-2.el8 git-tools-2018.10-2.el8 gramps-5.1.1-1.el8 mosh-1.3.2-1.el8 mup-6.7-1.el8 perl-Convert-Bencode-1.03-26.el8 perl-Coro-Multicore-1.03-3.el8 perl-Env-Sanctify-1.12-17.el8 perl-Module-Install-Repository-0.06-19.el8 perl-PPIx-QuoteLike-0.008-1.el8 perl-PPIx-Regexp-0.067-1.el8 perl-Regexp-Common-2017060201-11.el8 perl-SOAP-Lite-1.27-7.el8 perl-Spellunker-0.4.0-16.el8 perl-Test-LeakTrace-0.16-11.el8 perl-Test-Regexp-2017040101-10.el8 perl-Test-Synopsis-0.16-1.el8 perl-Test-Valgrind-1.19-12.el8 xrdp-0.9.11-5.el8 yapet-2.3-3.el8 Details about builds: git-secret-0.3.2-2.el8 (FEDORA-EPEL-2019-2c9a0f108b) A bash-tool to store your private data inside a git repository Update Information: remove sha256sum dependency as nothing provides it (in coreutils) 0.3.2 upgrade, clarify sha256sum dependency ChangeLog: * Sun Sep 22 2019 Gergely Gombos 0.3.2-2 - remove sha256sum dependency as nothing provides it (in coreutils) * Sun Sep 22 2019 Gergely Gombos 0.3.2-1 - 0.3.2 upgrade, clarify sha256sum dependency git-tools-2018.10-2.el8 (FEDORA-EPEL-2019-2a88d63c7d) Assorted git-related scripts and tools Update Information: Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild gramps-5.1.1-1.el8 (FEDORA-EPEL-2019-8cf624deca) Genealogical Research and Analysis Management Programming System Update Information: First EL-8 build. References: [ 1 ] Bug #1754291 - Request to build gramps for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1754291 mosh-1.3.2-1.el8 (FEDORA-EPEL-2019-701b91dff9) Mobile shell that supports roaming and intelligent local echo Update Information: Update to mosh 1.3.2 References: [ 1 ] Bug #1741280 - RFE: mosh: epel8 build request https://bugzilla.redhat.com/show_bug.cgi?id=1741280 mup-6.7-1.el8 (FEDORA-EPEL-2019-1c974830b9) A music notation program that can also generate MIDI files Update Information: Update to 6.7 perl-Convert-Bencode-1.03-26.el8 (FEDORA-EPEL-2019-138d9d0e5f) Functions for converting to/from bencoded strings Update Information: This is the first EPEL-8 build of perl-Convert-Bencode. perl-Coro-Multicore-1.03-3.el8 (FEDORA-EPEL-2019-8f84208a63) Make Coro threads on multiple cores with specially supported modules Update Information: This erratum brings perlmulticore-devel package. References: [ 1 ] Bug #1754281 - [RFE] EPEL-8 branch for perl-Coro-Multicore https://bugzilla.redhat.com/show_bug.cgi?id=1754281
[Bug 1744683] [RFE] EPEL8 branch for perl-SOAP-Lite
https://bugzilla.redhat.com/show_bug.cgi?id=1744683 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- perl-SOAP-Lite-1.27-7.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e93cbd7c35 -- 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 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3012c9e1ad bird-1.6.8-1.el6 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-04a99d9149 seamonkey-2.49.5-2.el6 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8901842b1a golang-1.13-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing mosh-1.3.2-1.el6 sympa-6.2.46-1.el6 Details about builds: mosh-1.3.2-1.el6 (FEDORA-EPEL-2019-2ac30e3cae) Mobile shell that supports roaming and intelligent local echo Update Information: Update to mosh 1.3.2 ChangeLog: * Sun Sep 22 2019 Alex Chernyakhovsky - 1.3.2-1 - Update to mosh 1.3.2 * Thu Jul 25 2019 Fedora Release Engineering - 1.3.0-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Fri Feb 1 2019 Fedora Release Engineering - 1.3.0-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Wed Nov 21 2018 Igor Gnatenko - 1.3.0-9 - Rebuild for protobuf 3.6 * Fri Jul 13 2018 Fedora Release Engineering - 1.3.0-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Thu Feb 8 2018 Fedora Release Engineering - 1.3.0-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Nov 29 2017 Igor Gnatenko - 1.3.0-6 - Rebuild for protobuf 3.5 * Mon Nov 13 2017 Igor Gnatenko - 1.3.0-5 - Rebuild for protobuf 3.4 * Thu Aug 3 2017 Fedora Release Engineering - 1.3.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild * Wed Jul 26 2017 Fedora Release Engineering - 1.3.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Tue Jun 13 2017 Orion Poplawski - 1.3.0-2 - Rebuild for protobuf 3.3.1 sympa-6.2.46-1.el6 (FEDORA-EPEL-2019-213ee8bd84) Powerful multilingual List Manager Update Information: - Rewritten data sources code. ChangeLog: * Mon Sep 23 2019 Xavier Bachelot 6.2.46-1 - Update to 6.2.46. - Unbundle foundation-icons font. - Add dependency on LWP::Protocol::https (RHBZ#1753111). - Don't unbundle js-respond on EL8 (yet). * Sat Jul 27 2019 Fedora Release Engineering - 6.2.44-3.1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild References: [ 1 ] Bug #1753111 - LWP::Protocol::https missing in dependencies https://bugzilla.redhat.com/show_bug.cgi?id=1753111 ___ 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 1749226] Please build perl-Test-Compile for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1749226 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Test-Compile-2.2.2-2.e ||l8 Resolution|--- |ERRATA Last Closed||2019-09-24 03:48:45 --- Comment #4 from Fedora Update System --- perl-Test-Compile-2.2.2-2.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report. -- 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 1749226] Please build perl-Test-Compile for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1749226 Bug 1749226 depends on bug 1749268, which changed state. Bug 1749268 Summary: [RFE] EPEL8 branch of perl-UNIVERSAL-require https://bugzilla.redhat.com/show_bug.cgi?id=1749268 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- 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 1752270] perl-Text-CSV_XS-1.40 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1752270 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Text-CSV_XS-1.40-1.fc3 |perl-Text-CSV_XS-1.40-1.fc3 |2 |2 ||perl-Text-CSV_XS-1.40-1.fc3 ||1 Resolution|--- |ERRATA Last Closed||2019-09-24 03:11:12 --- Comment #3 from Fedora Update System --- perl-Text-CSV_XS-1.40-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report. -- 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 1752235] perltidy-20190915 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1752235 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perltidy-20190915-1.fc32|perltidy-20190915-1.fc32 ||perltidy-20190915-1.fc31 Resolution|--- |ERRATA Last Closed||2019-09-24 03:11:10 --- Comment #5 from Fedora Update System --- perltidy-20190915-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report. -- 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 1754126] perl-CPAN-Perl-Releases-4.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754126 --- Comment #5 from Fedora Update System --- perl-CPAN-Perl-Releases-4.14-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-89e6e78ebd -- 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 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 --- Comment #7 from Fedora Update System --- perl-Module-CoreList-5.20190920-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d34643e2de -- 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
[Fedocal] Reminder meeting : Modularity Team (weekly)
Dear all, You are kindly invited to the meeting: Modularity Team (weekly) on 2019-09-24 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Team. More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/) The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open=Meeting). Source: https://apps.fedoraproject.org/calendar/meeting/9480/ ___ 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
[389-devel] 389 DS nightly 2019-09-24 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/09/24/report-389-ds-base-1.4.2.1-20190923git56ea32d.fc30.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[Bug 1747182] perl-Locale-Codes-3.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1747182 --- Comment #20 from Fedora Update System --- perl-5.28-3120190913071625.a5d38390 has been pushed to the Fedora 31 Modular stable repository. If problems still persist, please make note of it in this bug report. -- 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 1750082] perl-Archive-Zip-1.65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1750082 --- Comment #23 from Fedora Update System --- perl-5.28-3120190913071625.a5d38390 has been pushed to the Fedora 31 Modular stable repository. If problems still persist, please make note of it in this bug report. -- 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 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 --- Comment #6 from Fedora Update System --- perl-Module-CoreList-5.20190920-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3bacaa907d -- 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 1754126] perl-CPAN-Perl-Releases-4.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754126 --- Comment #4 from Fedora Update System --- perl-CPAN-Perl-Releases-4.14-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a1863cda60 -- 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 1754126] perl-CPAN-Perl-Releases-4.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754126 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-CPAN-Perl-Releases-4.14-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-8304d409ff -- 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 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- perl-Module-CoreList-5.20190920-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-fd1c851826 -- 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: Package build of usbauth-notifier and setxid whitelist
On Tue, 24 Sep 2019, Stefan Koch wrote: Hi My package usbauth-notifier has passed the review: https://bugzilla.redhat.com/show_bug.cgi?id=1554022 The package have a repositiory now: https://src.fedoraproject.org/rpms/usbauth-notifier I have created a build for my package: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c486836b68 There were some errors at build: https://taskotron.fedoraproject.org/artifacts/all/364ec852-dc8e-11e9-8845-5 2540077ca13/tests.yml/rpmgrill.json - "/usr/bin/usbauth-npriv": "Owned by group 'usbauth'; files in /usr/bin must be group 'root'" - "File /usr/bin/usbauth-npriv is setuid root but is not on the setxid whitelist." - "File /usr/libexec/usbauth-notifier/usbauth-notifier is setgid usbauth but is not on the setxid whitelist." Although there were errors, the package is now within the Rawhide Repository: https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Every thing/x86_64/os/Packages/u/usbauth-notifier-1.0-1.fc32.x86_64.rpm So is it needed to request adding it to the setxid whitelists? Is it needed do move the usbauth-npriv binary away from /usr/bin? It must be owned by the group usbauth, because of security architecture. For the rpmlint errors I have provided now a rpmlintrc file athttps://src.fedoraproject.org/rpms/usbauth-notifier/blob/master/f/usbauth-n otifier.rpmlintrc Is there a way to get the package into the existing Fedora 31, 30 and EPEL 8 repositories? I don't know much about setxid whitelists so I can't answer your questions there. On getting your package into development and stable releases, yes, that is possible. You first need to request branches be created using 'fedpkg request-branch". Then once those have been processed, you can merge your changes to those branches, create builds, then create updates with bodhi to get those builds pushed stable. 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
Fedora rawhide compose report: 20190923.n.1 changes
OLD: Fedora-Rawhide-20190922.n.1 NEW: Fedora-Rawhide-20190923.n.1 = SUMMARY = Added images:0 Dropped images: 7 Added packages: 13 Dropped packages:1 Upgraded packages: 92 Downgraded packages: 1 Size of added packages: 63.85 MiB Size of dropped packages:367.25 KiB Size of upgraded packages: 765.91 MiB Size of downgraded packages: 6.45 MiB Size change of upgraded packages: 18.19 MiB Size change of downgraded packages: -252.93 KiB = ADDED IMAGES = = DROPPED IMAGES = Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20190922.n.1.ppc64le.vmdk Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20190922.n.1.ppc64le.tar.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20190922.n.1.ppc64le.qcow2 Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20190922.n.1.iso Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20190922.n.1.ppc64le.raw.xz Image: Everything boot ppc64le Path: Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20190922.n.1.iso Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20190922.n.1.ppc64le.tar.xz = ADDED PACKAGES = Package: ecj-1:4.12-2.module_f32+6653+829af7fe Summary: Eclipse Compiler for Java RPMs:ecj Size:2.62 MiB Package: libbpf-1:0.0.3-1.fc32 Summary: Libbpf library RPMs:libbpf libbpf-devel libbpf-static Size:780.77 KiB Package: mingw-libsoup-2.68.0-1.fc32 Summary: MinGW library for HTTP and XML-RPC functionality RPMs:mingw32-libsoup mingw64-libsoup Size:693.37 KiB Package: php-phplang-scope-exit-1.0.0-2.fc32 Summary: Emulation of SCOPE_EXIT construct from C++ RPMs:php-phplang-scope-exit Size:10.32 KiB Package: php-scssphp-scssphp-1.0.4-1.fc32 Summary: Compiler for SCSS RPMs:php-scssphp-scssphp Size:70.41 KiB Package: php-swaggest-json-diff-3.7.0-1.fc32 Summary: JSON diff/rearrange/patch/pointer library for PHP RPMs:php-swaggest-json-diff Size:18.71 KiB Package: php-swaggest-json-schema-0.12.20-1.fc32 Summary: High definition PHP structures with JSON-schema based validation RPMs:php-swaggest-json-schema Size:49.61 KiB Package: policycoreutils-2.9-7.module_f32+6637+418cdc15 Summary: SELinux policy core utilities RPMs:policycoreutils policycoreutils-dbus policycoreutils-devel policycoreutils-gui policycoreutils-newrole policycoreutils-python-utils policycoreutils-restorecond policycoreutils-sandbox python3-policycoreutils Size:9.81 MiB Package: rust-zram-generator-0.1.1-4.module_f32+6664+96b02312 Summary: Systemd unit generator for zram devices RPMs:zram-generator Size:1.09 MiB Package: setools-4.2.0-1.module_f32+6637+418cdc15 Summary: Policy analysis tools for SELinux RPMs:python3-setools setools setools-console setools-console-analyses setools-gui Size:7.81 MiB Package: swig-3.0.12-24.module_f32+6641+74d4d6b5 Summary: Connects C/C++/Objective C to some high-level programming languages RPMs:ccache-swig swig swig-doc swig-gdb Size:11.68 MiB Package: tomcat-1:9.0.21-3.module_f32+6653+829af7fe Summary: Apache Servlet/JSP Engine, RI for Servlet 4.0/JSP 2.3 API RPMs:tomcat tomcat-admin-webapps tomcat-docs-webapp tomcat-el-3.0-api tomcat-jsp-2.3-api tomcat-jsvc tomcat-lib tomcat-servlet-4.0-api tomcat-webapps Size:6.74 MiB Package: zola-0.8.0-5.module_f32+6659+2316e7c7 Summary: Fast static site generator with everything built-in RPMs:zola Size:22.52 MiB = DROPPED PACKAGES = Package: octave-nnet-0.1.13-17.fc31 Summary: A feed forward multi-layer neural network RPMs:octave-nnet Size:367.25 KiB = UPGRADED PACKAGES = Package: ModemManager-1.10.6-2.fc32 Old package: ModemManager-1.10.4-2.fc31 Summary: Mobile broadband modem management service RPMs: ModemManager ModemManager-devel ModemManager-glib ModemManager-glib-devel ModemManager-vala Size: 10.68 MiB Size change: 31.72 KiB Changelog: * Mon Sep 23 2019 Lubomir Rintel - 1.10.6-1 - Update to 1.10.6 release * Mon Sep 23 2019 Lubomir Rintel - 1.10.6-2 - Don't grab cdc_ether devices on Sierra QMI modems Package: annobin-8.81-1.fc32 Old package: annobin-8.79-2.fc32 Summary: Binary annotation plugin for GCC RPMs: annobin annobin-annocheck Size: 1.03 MiB Size change: 1.83 KiB Changelog: * Mon Sep 23 2019 Nick Clifton - 8.81-1 - Improve detection of GO binaries. - Add gcc version information to annobin notes. - Do not complain about missing FORTIFY_SOURCE and GLIBCXX_ASSERTIONS in LTO compilations. Package: awscli-1.16.243-1.fc32 Old package: awscli-1.16.241-1.fc32 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.32 MiB Size
Re: RPM Fusion Bugzilla Bug 5307
...snip... I'm going to call this thread over with now, and have placed it on moderation. Interested parties are welcome to continue in private email or other forums. 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: RPM Fusion Bugzilla Bug 5307
On 9/23/19 5:12 PM, Solomon Peachy wrote: On Mon, Sep 23, 2019 at 04:20:37PM -0500, Ty Young wrote: Then you also understand the entire thread was made *because* Fedora was being in inconsiderate and disrespectful to both Nvidia, myself, and other developers, right? So far, you are the only one being disrespectful here. Yeah, no. Please, don't start with the "rules for me, not for thee" nonsense. So far, you are the only one asking for special treatment, and quite petulantly at that. I understand a basic level level of decency is required, but that decency goes both ways and it absolutely hasn't been. I'm glad you agree that your behavior here has been unacceptable. Meawnhile. Here is some suggested reading material: https://caddy.community/t/the-realities-of-being-a-foss-maintainer/2728 (Specifically "The Ugly" section) https://lwn.net/Articles/667610/ (Written about emacs, but applies to pretty much all Free Software) You just linked to an email from a guy who reportedly supports/defends pedophilia. Nice. Continue to bleed developers, crash, and burn then. That's the route you're heading in. You don't need users? Fine. Have fun dealing with all those lovely orphaned and retired packages. I'm sure being *inconsiderate* and *disrespectful* to both other developers and users will work out for you in the long run. Cheers, - Solomon ___ 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 ___ 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-20190923.n.1 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 6 of 45 required tests failed, 11 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 9/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20190922.n.1): ID: 456929 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/456929 ID: 456930 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/456930 Old failures (same test failed in Fedora-Rawhide-20190922.n.1): ID: 456931 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/456931 ID: 456933 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/456933 ID: 456996 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/456996 ID: 456999 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/456999 ID: 457009 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/457009 ID: 457061 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/457061 ID: 457062 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/457062 ID: 457075 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/457075 Soft failed openQA tests: 4/152 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20190922.n.1): ID: 456989 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/456989 Old soft failures (same test soft failed in Fedora-Rawhide-20190922.n.1): ID: 456973 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/456973 ID: 457063 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/457063 ID: 457068 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/457068 Passed openQA tests: 117/152 (x86_64) New passes (same test not passed in Fedora-Rawhide-20190922.n.1): ID: 457073 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/457073 Skipped gating openQA tests: 9/152 (x86_64) Old skipped gating tests (same test skipped in Fedora-Rawhide-20190922.n.1): ID: 456937 Test: x86_64 Server-dvd-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/456937 ID: 456938 Test: x86_64 Server-dvd-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/456938 ID: 456946 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/456946 ID: 456947 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/456947 ID: 456948 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING** URL: https://openqa.fedoraproject.org/tests/456948 ID: 456951 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/456951 ID: 456955 Test: x86_64 Server-dvd-iso server_role_deploy_database_server **GATING** URL: https://openqa.fedoraproject.org/tests/456955 ID: 456956 Test: x86_64 Server-dvd-iso server_database_client **GATING** URL: https://openqa.fedoraproject.org/tests/456956 ID: 456962 Test: x86_64 Server-dvd-iso server_firewall_default **GATING** URL: https://openqa.fedoraproject.org/tests/456962 Skipped non-gating openQA tests: 14 of 154 Installed system changes in test x86_64 Everything-boot-iso install_default@uefi: 4 packages(s) removed since previous compose: mozjs60, polkit, polkit-pkla-compat, timedatex 1 services(s) removed since previous compose: polkit.service Previous test data: https://openqa.fedoraproject.org/tests/456440#downloads Current test data: https://openqa.fedoraproject.org/tests/456963#downloads Installed system changes in test x86_64 Everything-boot-iso install_default: 4 packages(s) removed since previous compose: mozjs60, polkit, polkit-pkla-compat, timedatex 1 services(s) removed since previous compose: polkit.service Previous test data: https://openqa.fedoraproject.org/tests/456441#downloads Current test data: https://openqa.fedoraproject.org/tests/456964#downloads Installed system changes in
Re: RPM Fusion Bugzilla Bug 5307
On Mon, Sep 23, 2019 at 04:20:37PM -0500, Ty Young wrote: > Then you also understand the entire thread was made *because* Fedora was > being in inconsiderate and disrespectful to both Nvidia, myself, and other > developers, right? So far, you are the only one being disrespectful here. > Please, don't start with the "rules for me, not for thee" nonsense. So far, you are the only one asking for special treatment, and quite petulantly at that. > I understand a basic level level of decency is required, but that decency > goes both ways and it absolutely hasn't been. I'm glad you agree that your behavior here has been unacceptable. Meawnhile. Here is some suggested reading material: https://caddy.community/t/the-realities-of-being-a-foss-maintainer/2728 (Specifically "The Ugly" section) https://lwn.net/Articles/667610/ (Written about emacs, but applies to pretty much all Free Software) Cheers, - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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
Package build of usbauth-notifier and setxid whitelist
Hi My package usbauth-notifier has passed the review: https://bugzilla.redhat.com/show_bug.cgi?id=1554022 The package have a repositiory now: https://src.fedoraproject.org/rpms/usbauth-notifier I have created a build for my package: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c486836b68 There were some errors at build: https://taskotron.fedoraproject.org/artifacts/all/364ec852-dc8e-11e9-8845-52540077ca13/tests.yml/rpmgrill.json - "/usr/bin/usbauth-npriv": "Owned by group 'usbauth'; files in /usr/bin must be group 'root'" - "File /usr/bin/usbauth-npriv is setuid root but is not on the setxid whitelist." - "File /usr/libexec/usbauth-notifier/usbauth-notifier is setgid usbauth but is not on the setxid whitelist." Although there were errors, the package is now within the Rawhide Repository: https://ftp-stud.hs-esslingen.de/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/u/usbauth-notifier-1.0-1.fc32.x86_64.rpm So is it needed to request adding it to the setxid whitelists? Is it needed do move the usbauth-npriv binary away from /usr/bin? It must be owned by the group usbauth, because of security architecture. For the rpmlint errors I have provided now a rpmlintrc file at https://src.fedoraproject.org/rpms/usbauth-notifier/blob/master/f/usbauth-notifier.rpmlintrc Is there a way to get the package into the existing Fedora 31, 30 and EPEL 8 repositories? Thank you. Best regards Stefan Koch ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/23/19 3:22 PM, Ben Cotton wrote: Ty, I understand your frustration, but please consider whether your approach is constructive. "Friends" is one of the four foundations of the Fedora community and starting the thread with insults goes beyond the bounds of healthy disagreement. Please keep our Code of Conduct[1] in mind as you participate in Fedora. Then you also understand the entire thread was made *because* Fedora was being in inconsiderate and disrespectful to both Nvidia, myself, and other developers, right? Please, don't start with the "rules for me, not for thee" nonsense. I wasn't the first to start this, by far. I brought this issue up months ago *very* nicely and was basically told it's Nvidia's fault without anyone actually knowing what was going on. Fedora's unwillingness to play well with others who don't agree with their Open Source ideology has been a long standing issue and hypocritically breaks its own CoC. Maybe you should have a meeting about that? I understand a basic level level of decency is required, but that decency goes both ways and it absolutely hasn't been. If you find anything wrong with what is said, point the specific case out and do so publicly. I have idea what exact part of the CoC was broke and cannot make any changes as a result nor will I be intimidated by private email threats. These CoC's that your type like to use are just weapons of hypocrisy used to be abused by silencing others. Worse yet, they result in loss of productivity. Anyone else notice the Linux kernel's quality has went down since Linus started acting all nice? I sure have! IIRC, there was a nice bug that resulted in Steam not launching. What's the number one rule in the kernel? Don't break user space. Yeah, that went out the window real fast didn't it? It could be coincidence, but I've used Linux for many years before that and never had an issue. The kernel has always been the most well tested part of Linux by far. ...but I digress. [1] https://docs.fedoraproject.org/en-US/project/code-of-conduct/ -- 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
Re: RPM Fusion Bugzilla Bug 5307
Hey all: this is getting out of control and I don't think going anywhere productive. Please remember the Fedora "friends" foundation, the "be excellent to each other" guidance, and, of course, our code of conduct. Thank you. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RPM Fusion Bugzilla Bug 5307
On 23 September 2019 22:42:35 CEST, Ty Young wrote: > >On 9/23/19 3:16 PM, Markus Larsson wrote: >> >> >> On 23 September 2019 21:58:02 CEST, Ty Young >> wrote: >> > >> >On 9/23/19 1:53 PM, Markus Larsson wrote: >> >> You already have a solution. Use the solution you have. >> > >> > >> >Not a solution, it's a bandaid to a much larger problem. >> >> You said it works fine in Arch. So use Arch. > > >What if another user uses it on Fedora and then blames me or some other > >developer for it not working? That's BS. > > >If you think I'm upset now, I'll go full tilt if that ever happens. I >refuse to be blamed for some dumb decision Fedora made. I want to >support Fedora, but Fedora doesn't want to support me. I'm more than >doing my part to try to get this fixed. Why do you think anger will solve problems? Just point them towards Fedora and say that you can't do anything about it. > > >> You say that it can be configured easily in Fedora so do that and use > >> Fedora. > > >I never said that. I said the complete opposite of that. Learn to read, > >please. I'm sorry if I was mistaken. > > >> Those are solutions to your problem. > > >No. > > >> >> > >> > >> >> Fedora will not change to cater to this particular need. >> >> Your opinions does not dictate what Fedora should/shouldn't do. >> > >> > >> >Yet Fedora expects other distros/DEs, *including their own spins* to >> >cater to their decisions when those decisions aren't wanted or >> >technically possible to begin with. That's hypocritical. >> >> As a Fedora user I don't expect to be able to demand what defaults >> Void or Arch or Gentoo should have. > > >Fedora doesn't? Then why did Fedora upstream the non root X. Org >feature >then instead of custom patching it every release? Clearly no one cares >or wants it, as evident by the fact that X. Org is running as root(and >by extension, overclocking works) yet Fedora as the maintainers of X. >Org decided to make it the default? How is that not pushing your own >agenda on other distros? If they went out of their way to disable it >then they clearly don't want it. You and everyone else are free to fork if you don't agree with upstream. > > >And Fedora's own spins are impacted by this. It's not even consistent, >reliable behavior in Fedora. You can't even depend on it one way or the > >other. Applications that depend on X. Org. being root will literally >work just fine on a spin of Fedora but not the Gnome version. That's >unnecessary fragmentation in the same ecosystem. This has already been explained yet you act as if it hasn't. If only I could find something to say about reading proficiency to come of as friendly. > > > >> >> > >> > >> >> >> >> Your rants and all caps won't make anything change. Please try to >> >deal >> >> with it and move on from this rather dead thread. >> > >> > >> >My apologies for interrupting your daily mailing list programming of >> >package orphaning/retirement. I know everyone's waiting on their >seats >> >in anticipation of what packages are going orphaned/retired next, >but >> >the current discussion has evolved into something that very much >> >impacts >> >that very issue. >> >> How about not interrupting that with something that was very clearly >> explained to you about 50 mails ago? >> >> > >> > >> >Let me break it down for you: >> > >> > >> >1. More fragmentation means more work to maintain and test >everything. >> > >> > >> >2. More work to maintain and test everything requires more people. >> > >> > >> >3. More people means more roles that have to be filled which require >> >experience. >> > >> > >> >4. Different people have different ideas on approaching problems, >and >> >since they have experience, they use that experience to fragment the >> >desktop even more instead of compromising or working together. This >is >> >*Fedora* >> > >> > >> >5. More fragmentation angers developers who want to support the >> >platform >> >since they can't ensure that their software works remotely >> >consistently. >> >This is *me*. >> > >> > >> >6. Angry developers means less software for Linux. >> > >> > >> >7. Less software for Linux means less users. >> > >> > >> >8. Less users means a smaller pool of potential people to fill empty >> >roles. >> > >> > >> >9. Empty roles means things go stale, bugs go unfixed, and no one >has >> >experience. >> > >> > >> >Make any sense? I know it doesn't perfectly loop back at the end but >> >1-4 >> >does. >> >> No your unrelated 9 step venting does not make any sense unless of >> course your aim was to be rude in a new and slightly more amusing >way. > > >It wasn't rude, it was a fact. You can't gain experience doing >something >if you aren't doing it to begin with. I understood what you wrote. It just didn't in any way fit with the conversation. > > >> One thing peaked my interest though, what software is it that you >> wanted to "support the platform" with? > > >To put in your own words, how about not interrupting with
Re: libb2-0.98.1 on Rawhide
Am 23.09.19 um 19:06 schrieb Kevin Fenzi: Well, except that someone needs to rebuild borgbackup? Thank you for the reminder. I meant to do this but somehow I forgot to actually trigger a new build. New rawhide build in progress... Felix ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/23/19 3:16 PM, Markus Larsson wrote: On 23 September 2019 21:58:02 CEST, Ty Young wrote: > >On 9/23/19 1:53 PM, Markus Larsson wrote: >> You already have a solution. Use the solution you have. > > >Not a solution, it's a bandaid to a much larger problem. You said it works fine in Arch. So use Arch. What if another user uses it on Fedora and then blames me or some other developer for it not working? That's BS. If you think I'm upset now, I'll go full tilt if that ever happens. I refuse to be blamed for some dumb decision Fedora made. I want to support Fedora, but Fedora doesn't want to support me. I'm more than doing my part to try to get this fixed. You say that it can be configured easily in Fedora so do that and use Fedora. I never said that. I said the complete opposite of that. Learn to read, please. Those are solutions to your problem. No. > > >> Fedora will not change to cater to this particular need. >> Your opinions does not dictate what Fedora should/shouldn't do. > > >Yet Fedora expects other distros/DEs, *including their own spins* to >cater to their decisions when those decisions aren't wanted or >technically possible to begin with. That's hypocritical. As a Fedora user I don't expect to be able to demand what defaults Void or Arch or Gentoo should have. Fedora doesn't? Then why did Fedora upstream the non root X. Org feature then instead of custom patching it every release? Clearly no one cares or wants it, as evident by the fact that X. Org is running as root(and by extension, overclocking works) yet Fedora as the maintainers of X. Org decided to make it the default? How is that not pushing your own agenda on other distros? If they went out of their way to disable it then they clearly don't want it. And Fedora's own spins are impacted by this. It's not even consistent, reliable behavior in Fedora. You can't even depend on it one way or the other. Applications that depend on X. Org. being root will literally work just fine on a spin of Fedora but not the Gnome version. That's unnecessary fragmentation in the same ecosystem. > > >> >> Your rants and all caps won't make anything change. Please try to >deal >> with it and move on from this rather dead thread. > > >My apologies for interrupting your daily mailing list programming of >package orphaning/retirement. I know everyone's waiting on their seats >in anticipation of what packages are going orphaned/retired next, but >the current discussion has evolved into something that very much >impacts >that very issue. How about not interrupting that with something that was very clearly explained to you about 50 mails ago? > > >Let me break it down for you: > > >1. More fragmentation means more work to maintain and test everything. > > >2. More work to maintain and test everything requires more people. > > >3. More people means more roles that have to be filled which require >experience. > > >4. Different people have different ideas on approaching problems, and >since they have experience, they use that experience to fragment the >desktop even more instead of compromising or working together. This is >*Fedora* > > >5. More fragmentation angers developers who want to support the >platform >since they can't ensure that their software works remotely >consistently. >This is *me*. > > >6. Angry developers means less software for Linux. > > >7. Less software for Linux means less users. > > >8. Less users means a smaller pool of potential people to fill empty >roles. > > >9. Empty roles means things go stale, bugs go unfixed, and no one has >experience. > > >Make any sense? I know it doesn't perfectly loop back at the end but >1-4 >does. No your unrelated 9 step venting does not make any sense unless of course your aim was to be rude in a new and slightly more amusing way. It wasn't rude, it was a fact. You can't gain experience doing something if you aren't doing it to begin with. One thing peaked my interest though, what software is it that you wanted to "support the platform" with? To put in your own words, how about not interrupting with something that was very clearly explained to you about 50 mails ago? Speaking of 50 emails, that's an impressive number for a dead thread... > > >> >> Br >> M >> >> On 23 September 2019 20:38:13 CEST, Ty Young >> wrote: >> >> >> On 9/23/19 10:00 AM, Michael Catanzaro wrote: >>> On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro >>> wrote: You're wasting your time. We're not going to run the X server >as root just so you can overclock your GPU. Not a chance. >>> >> >> It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S >> SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak >> for an end user is cross-distro compatibility! >> >> >>> Anyway, while we won't do that Fedora... since you're clearly >>> interested in customizing your system, you can do so for >>> yourself. What you want to do is build gdm
Re: RPM Fusion Bugzilla Bug 5307
On 23 September 2019 21:58:02 CEST, Ty Young wrote: > >On 9/23/19 1:53 PM, Markus Larsson wrote: >> You already have a solution. Use the solution you have. > > >Not a solution, it's a bandaid to a much larger problem. You said it works fine in Arch. So use Arch. You say that it can be configured easily in Fedora so do that and use Fedora. Those are solutions to your problem. > > >> Fedora will not change to cater to this particular need. >> Your opinions does not dictate what Fedora should/shouldn't do. > > >Yet Fedora expects other distros/DEs, *including their own spins* to >cater to their decisions when those decisions aren't wanted or >technically possible to begin with. That's hypocritical. As a Fedora user I don't expect to be able to demand what defaults Void or Arch or Gentoo should have. > > >> >> Your rants and all caps won't make anything change. Please try to >deal >> with it and move on from this rather dead thread. > > >My apologies for interrupting your daily mailing list programming of >package orphaning/retirement. I know everyone's waiting on their seats >in anticipation of what packages are going orphaned/retired next, but >the current discussion has evolved into something that very much >impacts >that very issue. How about not interrupting that with something that was very clearly explained to you about 50 mails ago? > > >Let me break it down for you: > > >1. More fragmentation means more work to maintain and test everything. > > >2. More work to maintain and test everything requires more people. > > >3. More people means more roles that have to be filled which require >experience. > > >4. Different people have different ideas on approaching problems, and >since they have experience, they use that experience to fragment the >desktop even more instead of compromising or working together. This is >*Fedora* > > >5. More fragmentation angers developers who want to support the >platform >since they can't ensure that their software works remotely >consistently. >This is *me*. > > >6. Angry developers means less software for Linux. > > >7. Less software for Linux means less users. > > >8. Less users means a smaller pool of potential people to fill empty >roles. > > >9. Empty roles means things go stale, bugs go unfixed, and no one has >experience. > > >Make any sense? I know it doesn't perfectly loop back at the end but >1-4 >does. No your unrelated 9 step venting does not make any sense unless of course your aim was to be rude in a new and slightly more amusing way. One thing peaked my interest though, what software is it that you wanted to "support the platform" with? > > >> >> Br >> M >> >> On 23 September 2019 20:38:13 CEST, Ty Young >> wrote: >> >> >> On 9/23/19 10:00 AM, Michael Catanzaro wrote: >>> On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro >>> wrote: You're wasting your time. We're not going to run the X server >as root just so you can overclock your GPU. Not a chance. >>> >> >> It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S >> SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak >> for an end user is cross-distro compatibility! >> >> >>> Anyway, while we won't do that Fedora... since you're clearly >>> interested in customizing your system, you can do so for >>> yourself. What you want to do is build gdm using the configure >>> flag --disable-user-display-server. You can host your special >gdm >>> in a copr if you want to make it easier for other Nvidia >>> overclockers to use it. >> >> >> This is entirely unnecessary. You can enable root X. Org via the >> config option. A random user's COPR repo isn't a whole lot safer. >> >> >>> >>> See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights >>> for why this was changed (over five years ago!). The changes >were >>> made upstream, so there is nothing Fedora-specific here. If you >>> use GNOME on most other distros, you should see the same >behavior. >> >> >> Five years ago and yet no other DE besides Gnome supports it. >Five >> years and many distros that even use Gnome don't even have it >> enabled by default. Five years and Fedora has done nothing to >make >> other DEs support it despite the fact that Fedora is the only one >> that actually wants the change to begin with. >> >> >> Lets *actually read* that link, shall we? >> >> >> >The user experience will be unchanged >> >> >> This is a blatant lie. Breaking people's software absolutely >> impacts the user experience. >> >> >> >Desktop product: gdm, Ray Strode is working on this: ? >> >> >KDE spin: ? >> >> >XFCE spin: ? >> >> >LXDE spin: ? >> >> >> Look at that broad DE support. It's *almost* like no one cares or >> wants this, even after 5 years! There are still open bug reports >> on multiple distros/DEs that haven't been worked on or updated in >>
Fedora-31-20190923.n.0 compose check report
No missing expected images. Failed openQA tests: 4/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20190922.n.0): ID: 456834 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/456834 ID: 456840 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/456840 Old failures (same test failed in Fedora-31-20190922.n.0): ID: 456800 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/456800 ID: 456836 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/456836 ID: 456839 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/456839 Soft failed openQA tests: 2/152 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-31-20190922.n.0): ID: 456813 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/456813 ID: 456915 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/456915 Passed openQA tests: 146/152 (x86_64) New passes (same test not passed in Fedora-31-20190922.n.0): ID: 456823 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/456823 ID: 456835 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/456835 ID: 456846 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/456846 Skipped non-gating openQA tests: 1 of 154 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used mem changed from 887 MiB to 987 MiB System load changed from 0.54 to 1.24 Average CPU usage changed from 13.58095238 to 32.78095238 Previous test data: https://openqa.fedoraproject.org/tests/456288#downloads Current test data: https://openqa.fedoraproject.org/tests/456805#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used mem changed from 882 MiB to 1001 MiB Previous test data: https://openqa.fedoraproject.org/tests/456290#downloads Current test data: https://openqa.fedoraproject.org/tests/456807#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: 2 services(s) added since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service, pcscd.service 1 services(s) removed since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service System load changed from 1.07 to 2.60 Previous test data: https://openqa.fedoraproject.org/tests/456303#downloads Current test data: https://openqa.fedoraproject.org/tests/456820#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Average CPU usage changed from 6.42857143 to 30.89047619 Previous test data: https://openqa.fedoraproject.org/tests/456305#downloads Current test data: https://openqa.fedoraproject.org/tests/456822#downloads Installed system changes in test x86_64 universal install_package_set_kde: System load changed from 2.22 to 0.85 Previous test data: https://openqa.fedoraproject.org/tests/456368#downloads Current test data: https://openqa.fedoraproject.org/tests/456885#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 31 compose report: 20190923.n.0 changes
OLD: Fedora-31-20190922.n.0 NEW: Fedora-31-20190923.n.0 = SUMMARY = Added images:9 Dropped images: 0 Added packages: 0 Dropped packages:1 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:367.25 KiB Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190923.n.0.s390x.raw.xz Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-31-20190923.n.0.iso Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-31-20190923.n.0-sda.raw.xz Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190923.n.0.s390x.vmdk Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-31-20190923.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-31-20190923.n.0.s390x.tar.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190923.n.0.s390x.qcow2 Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-31-20190923.n.0.s390x.tar.xz Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-31-20190923.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: octave-nnet-0.1.13-17.fc31 Summary: A feed forward multi-layer neural network RPMs:octave-nnet Size:367.25 KiB = UPGRADED PACKAGES = = DOWNGRADED 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
Re: RPM Fusion Bugzilla Bug 5307
On 9/23/19 1:53 PM, Markus Larsson wrote: You already have a solution. Use the solution you have. Not a solution, it's a bandaid to a much larger problem. Fedora will not change to cater to this particular need. Your opinions does not dictate what Fedora should/shouldn't do. Yet Fedora expects other distros/DEs, *including their own spins* to cater to their decisions when those decisions aren't wanted or technically possible to begin with. That's hypocritical. Your rants and all caps won't make anything change. Please try to deal with it and move on from this rather dead thread. My apologies for interrupting your daily mailing list programming of package orphaning/retirement. I know everyone's waiting on their seats in anticipation of what packages are going orphaned/retired next, but the current discussion has evolved into something that very much impacts that very issue. Let me break it down for you: 1. More fragmentation means more work to maintain and test everything. 2. More work to maintain and test everything requires more people. 3. More people means more roles that have to be filled which require experience. 4. Different people have different ideas on approaching problems, and since they have experience, they use that experience to fragment the desktop even more instead of compromising or working together. This is *Fedora* 5. More fragmentation angers developers who want to support the platform since they can't ensure that their software works remotely consistently. This is *me*. 6. Angry developers means less software for Linux. 7. Less software for Linux means less users. 8. Less users means a smaller pool of potential people to fill empty roles. 9. Empty roles means things go stale, bugs go unfixed, and no one has experience. Make any sense? I know it doesn't perfectly loop back at the end but 1-4 does. Br M On 23 September 2019 20:38:13 CEST, Ty Young wrote: On 9/23/19 10:00 AM, Michael Catanzaro wrote: On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro wrote: You're wasting your time. We're not going to run the X server as root just so you can overclock your GPU. Not a chance. It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user is cross-distro compatibility! Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special gdm in a copr if you want to make it easier for other Nvidia overclockers to use it. This is entirely unnecessary. You can enable root X. Org via the config option. A random user's COPR repo isn't a whole lot safer. See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes were made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same behavior. Five years ago and yet no other DE besides Gnome supports it. Five years and many distros that even use Gnome don't even have it enabled by default. Five years and Fedora has done nothing to make other DEs support it despite the fact that Fedora is the only one that actually wants the change to begin with. Lets *actually read* that link, shall we? >The user experience will be unchanged This is a blatant lie. Breaking people's software absolutely impacts the user experience. >Desktop product: gdm, Ray Strode is working on this: ? >KDE spin: ? >XFCE spin: ? >LXDE spin: ? Look at that broad DE support. It's *almost* like no one cares or wants this, even after 5 years! There are still open bug reports on multiple distros/DEs that haven't been worked on or updated in years. >Having the xserver not run as root reduces Fedora's attack surface. ...which few other Linux distro cares about and is seemingly just a boogeyman used to fearmonger since no one can pin point actual malicious software that takes advantage of it to begin with. If you're so afraid of the X. Org as root boogeyman then oh boy, allow me to turn it up a notch by telling you just *some* of the things possible with basic *user* account permissions. You can: -reboot/shutdown -silently lockup the system by spawning too many threads -hard lock the system by passing allowed but unsupported values -fill up memory, resulting in HDD thrashing and potentially killing your SSD -create other processes(pop up windows) -kill other processes -upload all your files in your home directory to a personal private server -delete all your files in your home directory
Re: RPM Fusion Bugzilla Bug 5307
On Mon, Sep 23, 2019 at 1:03 PM Ty Young wrote: > > Throwing the baby out with the bathwater, really? Wayland doesn't even > work on a large selection of hardware(Nvidia) and has many missing > features deemed to be vital for some people which X. Org does have. This > has been a common criticism of Wayland and every advocates and > developers put their fingers in their ears and ignore it. People are > just going to continue to use X. Org, if this is they way you're going > to do things, you realize? https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/ There are improvements happening in both Wayland and XWayland to address each of your concerns. If some projects want to keep using X, that's their choice, but the X developers are the Wayland developers, and they're pretty much completely done with X. It's on life support. So if people who haven't been maintaining X expect others to keep doing that work, they're going to be disappointed. They need to be using what resources they have to make sure their stuff at least works on XWayland if not natively on Wayland. This is not news, by the way. It's been a long time coming. -- Chris Murphy ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/23/19 2:02 PM, Solomon Peachy wrote: On Mon, Sep 23, 2019 at 01:38:13PM -0500, Ty Young wrote: ...among a whole lot else I'm probably forgetting. You're forgetten one very important thing: https://web.archive.org/save/_embed/http://safr.kingfeatures.com/idn/ck3/email/zone.php?r=a%3A5%3A%7Bs%3A32%3A%2254d8566c10474186daf7afad5e278446%22%3Bs%3A4%3A%22yEzN%22%3Bs%3A32%3A%22db39b16217194b9c4572eaee71c6d9d4%22%3Bs%3A8%3A%22%3D%3DgMxITM%22%3Bs%3A32%3A%22e423795a96f7ae758972343e1e1abe63%22%3Bs%3A12%3A%22%3DcTMzAjNxAjM%22%3Bs%3A32%3A%22d455c859707761b953418a1a46638948%22%3Bs%3A4%3A%22%3D%3DQM%22%3Bs%3A32%3A%22157e8ad5f0a597dbf7f9c967dfc889dd%22%3Bs%3A24%3A%22%3D02bj5SbvR2Zul2azNWat92Y%22%3B%7D As the old saying goes, "You catch more flies with honey than vinegar" The saying is true but given the context there is more complexity to the story. If a user runs a malicious program as their account you might not have the keys to the kingdom but you still have the keys to the front door. This is especially true if they are the only user on the system. The user account is the lowest hanging fruit which takes the least effort to compromise and do malicious things with. The Gentoo wiki even stated this to be the case. Sure you might(?, I've never set an application to launch on startup under Linux myself...) not be able to be persistent across reboots but you need to be? Maybe the user rarely shuts down their computer. Does being persistent even matter at that point? - Solomon ___ 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 ___ 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: RPM Fusion Bugzilla Bug 5307
On Sat, 2019-09-21 at 22:24 -0400, Neal Gompa wrote: > > > > We still offer Workstation. Just use that. :) > > > > The unreliable update servers affect Workstation too. Again, upgrades on > > workstation take forever. Silverblue is much faster. > > > > > > ...but I digress... again. > > > > > > We also do have regular respins of the media for the latest release: > https://dl.fedoraproject.org/pub/alt/live-respins/ > > I'm not sure why we don't publicize them, but they are made on a regular > basis. Because they're not really official and they're subject to only limited testing. They are built by a volunteer and aren't built entirely the same way we build official images. We don't do fully official respins on the basis that the time it would cost releng to build them, QA to test them and developers to fix any issues that showed up would not be worth it. Yes, it is entirely possible for things to go out as updates that work fine *as updates* but cause issues in the "produce working installer/live images" process. We have rather *better* releng and testing systems in place now than we did when the decision not to do regular official respins was made, so it's a decision that could be revisited at some point. But that's where we are right now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: RPM Fusion Bugzilla Bug 5307
On Mon, Sep 23, 2019 at 01:38:13PM -0500, Ty Young wrote: > ...among a whole lot else I'm probably forgetting. You're forgetten one very important thing: https://web.archive.org/save/_embed/http://safr.kingfeatures.com/idn/ck3/email/zone.php?r=a%3A5%3A%7Bs%3A32%3A%2254d8566c10474186daf7afad5e278446%22%3Bs%3A4%3A%22yEzN%22%3Bs%3A32%3A%22db39b16217194b9c4572eaee71c6d9d4%22%3Bs%3A8%3A%22%3D%3DgMxITM%22%3Bs%3A32%3A%22e423795a96f7ae758972343e1e1abe63%22%3Bs%3A12%3A%22%3DcTMzAjNxAjM%22%3Bs%3A32%3A%22d455c859707761b953418a1a46638948%22%3Bs%3A4%3A%22%3D%3DQM%22%3Bs%3A32%3A%22157e8ad5f0a597dbf7f9c967dfc889dd%22%3Bs%3A24%3A%22%3D02bj5SbvR2Zul2azNWat92Y%22%3B%7D As the old saying goes, "You catch more flies with honey than vinegar" - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. 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: RPM Fusion Bugzilla Bug 5307
On 9/23/19 12:55 PM, Neal Gompa wrote: On Mon, Sep 23, 2019 at 1:49 PM Ty Young wrote: On 9/23/19 9:56 AM, Neal Gompa wrote: On Sun, Sep 22, 2019 at 11:03 PM Ty Young wrote: On 9/22/19 9:09 PM, Neal Gompa wrote: On Sun, Sep 22, 2019 at 7:25 PM Ty Young wrote: On 9/22/19 5:51 PM, Samuel Sieb wrote: On 9/22/19 3:10 PM, Ty Young wrote: I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again. I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora. No, I meant the package manager GUI front-end won't work: https://imgur.com/a/Dajf28T I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else. If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora It's fine, I completely understand. I just happened to pick the Cinnamon spin since I knew it and MATE used LightDM and I don't use Fedora so I don't know if I can be of any help. Also, Spanish(?) confirm prompt when rest of GUI is English: https://imgur.com/a/7ashccO ...and proof X.Org on Cinnamon is running as root: https://imgur.com/a/UcLjjKT Yet on Gnome Fedora it isn't: https://imgur.com/a/DlXwcdK So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here. Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME. How would you propose we fix this bug, as you call it? Well, what exactly was the old behavior before? I know for a fact X. Org was running as root during the beta. Is X. Org as root during beta periods only the norm? Neither of the two other major distro families, Arch Linux and Ubuntu with Gnome, have X. Org as root disabled, at least not when running the Nvidia binary. Are there any malicious software that even exists that exploit X. Org being ran as root? If no one else sees that as an issue then why does Fedora? And is disabling root X. Org worth breaking people's software that would otherwise work? Clearly few DM(s) other than Gnome supports it despite earlier claims, so it isn't even standard behavior. Fedora supports multiple spins including DM(s) that don't support it, so you're just fragmenting your own ecosystem if it is enabled on Gnome Fedora only. That's not a great idea. So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe. The problem with that is that if we did it that way, nobody would adapt to the change. Much in the same manner that we're moving to cgroups v2 in Fedora 31, if we didn't do it, we can't suss out breakages and fix them (if possible). And if third parties that don't keep up with these changes (especially one that happened in 2013 for Fedora GNOME!), there's not much that can be done. Fedora is not Linux. You are not the sole arbiters of what gets changed in the Linux ecosystem. You all need to get that through your damn heads. No other distro/DE besides Gnome supports this and it doesn't look like that's ever going to change. We are not, sure. But the Fedora distribution is allowed to have the opinion to do new things and see how it goes. How it went was awful. No other distro/DE supported it and it breaks user applications. Each of the spins are allowed to work towards implementing this whenever they want. I suspect at this point we're mostly waiting to move to Wayland on the spins rather than doing work on Xorg stuff. Throwing the baby out with the bathwater, really? Wayland doesn't even work on a large selection of hardware(Nvidia) and has many missing features deemed to be vital for some people
Re: Fedora 32 Self-Contained Change proposal: Better Thermal Management for the Workstation
On Mon, Sep 23, 2019 at 11:50 am, Chris Murphy wrote: On my commodity HP Spectre laptop, when thermald is running, it causes four kidle-inject process to totally soak spare CPU. And now I'm not able to play even a single youtube video, and any appreciable effort in Firefox also causes these processes to tamp down, making everything super sluggish and basically terrible. OK, sounds like either thermald developers should find time to sit down with you and get this fixed, or else thermald isn't ready for Workstation. ___ 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: RPM Fusion Bugzilla Bug 5307
You already have a solution. Use the solution you have. Fedora will not change to cater to this particular need. Your opinions does not dictate what Fedora should/shouldn't do. Your rants and all caps won't make anything change. Please try to deal with it and move on from this rather dead thread. Br M On 23 September 2019 20:38:13 CEST, Ty Young wrote: > >On 9/23/19 10:00 AM, Michael Catanzaro wrote: >> On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro >> wrote: >>> You're wasting your time. We're not going to run the X server as >root >>> just so you can overclock your GPU. Not a chance. >> > >It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, >EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user >is >cross-distro compatibility! > > >> Anyway, while we won't do that Fedora... since you're clearly >> interested in customizing your system, you can do so for yourself. >> What you want to do is build gdm using the configure flag >> --disable-user-display-server. You can host your special gdm in a >copr >> if you want to make it easier for other Nvidia overclockers to use >it. > > >This is entirely unnecessary. You can enable root X. Org via the config > >option. A random user's COPR repo isn't a whole lot safer. > > >> >> See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for >> why this was changed (over five years ago!). The changes were made >> upstream, so there is nothing Fedora-specific here. If you use GNOME >> on most other distros, you should see the same behavior. > > >Five years ago and yet no other DE besides Gnome supports it. Five >years >and many distros that even use Gnome don't even have it enabled by >default. Five years and Fedora has done nothing to make other DEs >support it despite the fact that Fedora is the only one that actually >wants the change to begin with. > > >Lets *actually read* that link, shall we? > > > >The user experience will be unchanged > > >This is a blatant lie. Breaking people's software absolutely impacts >the >user experience. > > >>Desktop product: gdm, Ray Strode is working on this: ? > >>KDE spin: ? > > >XFCE spin: ? > > >LXDE spin: ? > > >Look at that broad DE support. It's *almost* like no one cares or wants > >this, even after 5 years! There are still open bug reports on multiple >distros/DEs that haven't been worked on or updated in years. > > > >Having the xserver not run as root reduces Fedora's attack surface. > > >...which few other Linux distro cares about and is seemingly just a >boogeyman used to fearmonger since no one can pin point actual >malicious >software that takes advantage of it to begin with. > > >If you're so afraid of the X. Org as root boogeyman then oh boy, allow >me to turn it up a notch by telling you just *some* of the things >possible with basic *user* account permissions. You can: > > >-reboot/shutdown > > >-silently lockup the system by spawning too many threads > > >-hard lock the system by passing allowed but unsupported values > > >-fill up memory, resulting in HDD thrashing and potentially killing >your SSD > > >-create other processes(pop up windows) > > >-kill other processes > > >-upload all your files in your home directory to a personal private >server > > >-delete all your files in your home directory > > >-encrypt all your files in your home directory. > > >...among a whole lot else I'm probably forgetting. > > >Point is, at some point you need to let the security crap go. No one >else cares besides Fedora and Gnome. > > > >> The only distro I know of that uses --disable-user-display-server is >> Endless. >> >> Michael >> >> ___ >> 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 ___ 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: RPM Fusion Bugzilla Bug 5307
On Mon, Sep 23, 2019 at 1:38 pm, Ty Young wrote: This is entirely unnecessary. You can enable root X. Org via the config option. A random user's COPR repo isn't a whole lot safer. Oh nice. Then you can change that and stop complaining. 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
[EPEL-devel] Re: TeamViewer on RHEL 8 and qt. Help needed
On Mon, Sep 23, 2019 at 10:53 AM Stephen John Smoogen wrote: > > On Mon, 23 Sep 2019 at 12:31, Thomas Stephen Lee wrote: > > > > Hi, > > > > download the tar version and extract > > > > https://download.teamviewer.com/download/linux/teamviewer_amd64.tar.xz > > > > cd to the folder > > > > run > > > > ./tv-setup checklibs > > > > the output shows > > > > - > > Analyzing dependencies ... > > libQt5Positioning.so.5 => not found > > libQt5Sensors.so.5 => not found > > libQt5WebChannel.so.5 => not found > > > > The libraries listed above seem to be missing. > > > > You need to install qt5-qtwebchannel qt5-qtsensors qt5-qtlocation > qt5-qtbase-gui qt5-qtx11extras qt5-qtdeclarative and probably a bunch > others.. > > dnf repoquery --whatprovides=libQt5WebKitWidgets.so.5 > > and similar will tell you what is needed > > > -- > > > > and it also asks to run the command. > > > > dnf install 'libdbus-1.so.3()(64bit)' 'libQt5Gui.so.5()(64bit)' > > 'libQt5Widgets.so.5()(64bit)' 'libQt5Qml.so.5()(64bit)' > > 'libQt5Quick.so.5()(64bit)' 'libQt5WebKitWidgets.so.5()(64bit)' > > 'libQt5X11Extras.so.5()(64bit)' 'libqtquick2plugin.so()(64bit)' > > 'libwindowplugin.so()(64bit)' 'libqquicklayoutsplugin.so()(64bit)' > > 'libqtquickcontrolsplugin.so()(64bit)' 'libdialogplugin.so()(64bit)' > > > > From teh above the following don't seem available: > > libwindowplugin.so > libqquicklayoutsplugin.so > libdialogplugin.so > > but they don't show up in a Fedora 30 box either so I am guessing it > needs something not listed. > Correct. This isn't a RHEL8 thing. > > > > Ran the command on RHEL 8 and most libraries are missing (epel-playground > > and epel-testing repos are enabled). > > Is it something to do with RHEL 8 not supporting KDE? > > > > What is the solution to get TeamViewer working on RHEL 8? From the teamviewer page https://www.teamviewer.com/en-us/download/linux/ you can download an rpm designed for CentOS and Fedora https://www.teamviewer.com/en-us/teamviewer-automatic-download/?package=teamviewer=x86_64.rpm=linux That package seems to be able to install on both Fedora and RHEL8 with epel8-playground enabled. > > > > thanks. > > > > -- > > Thomas Stephen Lee > > ___ > > 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 > > > > -- > Stephen J Smoogen. > ___ > 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 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
Re: RPM Fusion Bugzilla Bug 5307
On 9/23/2019 10:55 AM, Neal Gompa wrote: On Mon, Sep 23, 2019 at 1:49 PM Ty Young wrote: On 9/23/19 9:56 AM, Neal Gompa wrote: The problem with that is that if we did it that way, nobody would adapt to the change. Much in the same manner that we're moving to cgroups v2 in Fedora 31, if we didn't do it, we can't suss out breakages and fix them (if possible). And if third parties that don't keep up with these changes (especially one that happened in 2013 for Fedora GNOME!), there's not much that can be done. Fedora is not Linux. You are not the sole arbiters of what gets changed in the Linux ecosystem. You all need to get that through your damn heads. No other distro/DE besides Gnome supports this and it doesn't look like that's ever going to change. We are not, sure. But the Fedora distribution is allowed to have the opinion to do new things and see how it goes. Each of the spins are allowed to work towards implementing this whenever they want. I suspect at this point we're mostly waiting to move to Wayland on the spins rather than doing work on Xorg stuff. This is true, but somewhat sidesteps the very real point that "Fedora Linux" has a larger-than-normal impact on the Linux ecosystem as a whole, as well as that it's essentially the branching upstream of RHEL, and thus all EL-derivatives. IMHO it's entirely justified to criticize Fedora for questionable decisions or decision-making when those decisions impact non- "Fedora Linux" users. Disallowing that smacks of wanting to have one's cake and eat it too when it comes to influence. (See also: Fedora v. FreeDesktop decision-making) -jc ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/23/19 10:00 AM, Michael Catanzaro wrote: On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro wrote: You're wasting your time. We're not going to run the X server as root just so you can overclock your GPU. Not a chance. It isn't just to overclock my GPU, you're *BREAKING PEOPLE'S SOFTWARE, EVEN IF THEY ARE FLATPAK*. The whole point of Flatpak for an end user is cross-distro compatibility! Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special gdm in a copr if you want to make it easier for other Nvidia overclockers to use it. This is entirely unnecessary. You can enable root X. Org via the config option. A random user's COPR repo isn't a whole lot safer. See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes were made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same behavior. Five years ago and yet no other DE besides Gnome supports it. Five years and many distros that even use Gnome don't even have it enabled by default. Five years and Fedora has done nothing to make other DEs support it despite the fact that Fedora is the only one that actually wants the change to begin with. Lets *actually read* that link, shall we? >The user experience will be unchanged This is a blatant lie. Breaking people's software absolutely impacts the user experience. Desktop product: gdm, Ray Strode is working on this: ? KDE spin: ? >XFCE spin: ? >LXDE spin: ? Look at that broad DE support. It's *almost* like no one cares or wants this, even after 5 years! There are still open bug reports on multiple distros/DEs that haven't been worked on or updated in years. >Having the xserver not run as root reduces Fedora's attack surface. ...which few other Linux distro cares about and is seemingly just a boogeyman used to fearmonger since no one can pin point actual malicious software that takes advantage of it to begin with. If you're so afraid of the X. Org as root boogeyman then oh boy, allow me to turn it up a notch by telling you just *some* of the things possible with basic *user* account permissions. You can: -reboot/shutdown -silently lockup the system by spawning too many threads -hard lock the system by passing allowed but unsupported values -fill up memory, resulting in HDD thrashing and potentially killing your SSD -create other processes(pop up windows) -kill other processes -upload all your files in your home directory to a personal private server -delete all your files in your home directory -encrypt all your files in your home directory. ...among a whole lot else I'm probably forgetting. Point is, at some point you need to let the security crap go. No one else cares besides Fedora and Gnome. The only distro I know of that uses --disable-user-display-server is Endless. Michael ___ 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 ___ 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: RPM Fusion Bugzilla Bug 5307
On Mon, Sep 23, 2019 at 1:49 PM Ty Young wrote: > > > On 9/23/19 9:56 AM, Neal Gompa wrote: > > On Sun, Sep 22, 2019 at 11:03 PM Ty Young wrote: > >> > >> On 9/22/19 9:09 PM, Neal Gompa wrote: > >>> On Sun, Sep 22, 2019 at 7:25 PM Ty Young wrote: > On 9/22/19 5:51 PM, Samuel Sieb wrote: > > On 9/22/19 3:10 PM, Ty Young wrote: > >> I couldn't actually install the drivers because the update GUI in the > >> cinnamon spin is broken and/or the repo/update servers are down. Again. > > I don't know why you're having so much trouble with updates. But just > > in case you're referring to rpmfusion as you have in other emails, I > > hope you're aware that Redhat has nothing to do with them. They are > > an independent third-party repo not managed by Fedora. They host > > packages that can't, for various reasons, be distributed by Fedora. > No, I meant the package manager GUI front-end won't work: > > > https://imgur.com/a/Dajf28T > > > >>> I'm sorry that dnfdragora isn't quite working properly on your system. > >>> As one of the developers of dnfdragora and dnfdaemon, I'm aware of > >>> some of those quirks, and myself and the other developer have been > >>> trying to work on fixing these problems. It's difficult though, as > >>> both of us are working on it in our spare time. We're committed to > >>> improving it, but I have to find time for it, among everything else. > >>> > >>> If you'd like to help, we'd appreciate it. The project is here: > >>> https://github.com/manatools/dnfdragora > >> > >> It's fine, I completely understand. I just happened to pick the Cinnamon > >> spin since I knew it and MATE used LightDM and I don't use Fedora so I > >> don't know if I can be of any help. > >> > >> > Also, Spanish(?) confirm prompt when rest of GUI is English: > > > https://imgur.com/a/7ashccO > > > ...and proof X.Org on Cinnamon is running as root: > > > https://imgur.com/a/UcLjjKT > > > Yet on Gnome Fedora it isn't: > > > https://imgur.com/a/DlXwcdK > > > So is Fedora going to admit it's a bug in Gnome Fedora or are we going > to keep being salty that Nvidia doesn't support or have an Open Source > driver by pointing the finger at them? Actually fixing the bug would be > the more productive option here. > > >>> Well, the rootless X thing is from gnome-session down, so that's a > >>> GNOME thing. I'm aware that not all DEs do this, the work was > >>> primarily done in GNOME. > >>> > >>> How would you propose we fix this bug, as you call it? > >> > >> Well, what exactly was the old behavior before? I know for a fact X. Org > >> was running as root during the beta. Is X. Org as root during beta > >> periods only the norm? > >> > >> > >> Neither of the two other major distro families, Arch Linux and Ubuntu > >> with Gnome, have X. Org as root disabled, at least not when running the > >> Nvidia binary. Are there any malicious software that even exists that > >> exploit X. Org being ran as root? If no one else sees that as an issue > >> then why does Fedora? And is disabling root X. Org worth breaking > >> people's software that would otherwise work? > >> > >> > >> Clearly few DM(s) other than Gnome supports it despite earlier claims, > >> so it isn't even standard behavior. Fedora supports multiple spins > >> including DM(s) that don't support it, so you're just fragmenting your > >> own ecosystem if it is enabled on Gnome Fedora only. That's not a great > >> idea. > >> > >> > >> So, IMO, the correct behavior here would be to disable until at least > >> other DM(s) support it and other distros enabled it by default so that > >> Fedora is at least following standards. Once it *actually* gets adopted > >> *maybe* Nvidia will allow overclocking on non root X. Org but that could > >> just be wishful thinking. At minimum there should always be an option to > >> disable security features, especially if it results in performance > >> loss(e.g. Specter) or, in this case, application compatibility problems > >> easily... and editing a config file isn't that easy, obvious, or in some > >> cases even safe. > >> > > The problem with that is that if we did it that way, nobody would > > adapt to the change. Much in the same manner that we're moving to > > cgroups v2 in Fedora 31, if we didn't do it, we can't suss out > > breakages and fix them (if possible). And if third parties that don't > > keep up with these changes (especially one that happened in 2013 for > > Fedora GNOME!), there's not much that can be done. > > > Fedora is not Linux. You are not the sole arbiters of what gets changed > in the Linux ecosystem. You all need to get that through your damn > heads. No other distro/DE besides Gnome supports this and it doesn't > look like that's ever going to change. > We are not, sure. But the Fedora distribution is allowed to have the opinion to
[EPEL-devel] Re: TeamViewer on RHEL 8 and qt. Help needed
On Mon, 23 Sep 2019 at 12:31, Thomas Stephen Lee wrote: > > Hi, > > download the tar version and extract > > https://download.teamviewer.com/download/linux/teamviewer_amd64.tar.xz > > cd to the folder > > run > > ./tv-setup checklibs > > the output shows > > - > Analyzing dependencies ... > libQt5Positioning.so.5 => not found > libQt5Sensors.so.5 => not found > libQt5WebChannel.so.5 => not found > > The libraries listed above seem to be missing. > You need to install qt5-qtwebchannel qt5-qtsensors qt5-qtlocation qt5-qtbase-gui qt5-qtx11extras qt5-qtdeclarative and probably a bunch others.. dnf repoquery --whatprovides=libQt5WebKitWidgets.so.5 and similar will tell you what is needed > -- > > and it also asks to run the command. > > dnf install 'libdbus-1.so.3()(64bit)' 'libQt5Gui.so.5()(64bit)' > 'libQt5Widgets.so.5()(64bit)' 'libQt5Qml.so.5()(64bit)' > 'libQt5Quick.so.5()(64bit)' 'libQt5WebKitWidgets.so.5()(64bit)' > 'libQt5X11Extras.so.5()(64bit)' 'libqtquick2plugin.so()(64bit)' > 'libwindowplugin.so()(64bit)' 'libqquicklayoutsplugin.so()(64bit)' > 'libqtquickcontrolsplugin.so()(64bit)' 'libdialogplugin.so()(64bit)' > From teh above the following don't seem available: libwindowplugin.so libqquicklayoutsplugin.so libdialogplugin.so but they don't show up in a Fedora 30 box either so I am guessing it needs something not listed. > > Ran the command on RHEL 8 and most libraries are missing (epel-playground and > epel-testing repos are enabled). > Is it something to do with RHEL 8 not supporting KDE? > > What is the solution to get TeamViewer working on RHEL 8? > > thanks. > > -- > Thomas Stephen Lee > ___ > 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 -- Stephen J Smoogen. ___ 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
Re: Fedora 32 Self-Contained Change proposal: Better Thermal Management for the Workstation
On Mon, Sep 23, 2019 at 8:21 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > == Summary == > Better thermal management and peak performance on Intel CPUs by > including thermald in the default install. > > == Owner == > * Name: [[User:benzea| Benjamin Berg]] > * Email: bb...@redhat.com > > * Name: [[User:ckellner| Christian J. Kellner]] > * Email: ckell...@redhat.com > * Product: Workstation > * Responsible WG: Workstation > > == Detailed Description == > > Modern Intel-based systems provide sensors and methods to monitor and > control temperature of its CPUs. The Thermal daemon will use those > sensors to monitor the temperature and use the best available method > to keep the CPU in the right temperature envelop. On certain systems > this is needed to reach the maximal performance. For optimal > performance a per-model thermald configuration should be created, this > can either be done by using dptfxtract (available from rpmfusion) or > we could ship static configuration files for a set of known models. I generally like the idea, but my concern is with my experience having run thermald out of the box (both upstream as well as the Federa packaged version). On my commodity HP Spectre laptop, when thermald is running, it causes four kidle-inject process to totally soak spare CPU. And now I'm not able to play even a single youtube video, and any appreciable effort in Firefox also causes these processes to tamp down, making everything super sluggish and basically terrible. I reported this experience a year ago not knowing at the time it was thermald that was causing this behavior. It took me a while to make the connection. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BK2DVB4PA37FMB2DTMUI4YBM7YDGSJTK/ That definitely cannot happen by default for anyone. It's so non-obvious what's causing it, and such a bad experience, that I'm not willing to foist it on a single person. I'd sooner foist it on hundreds, at least the screaming will be loud enough everyone will figure out what's going on. -- Chris Murphy ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/23/19 9:56 AM, Neal Gompa wrote: On Sun, Sep 22, 2019 at 11:03 PM Ty Young wrote: On 9/22/19 9:09 PM, Neal Gompa wrote: On Sun, Sep 22, 2019 at 7:25 PM Ty Young wrote: On 9/22/19 5:51 PM, Samuel Sieb wrote: On 9/22/19 3:10 PM, Ty Young wrote: I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again. I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora. No, I meant the package manager GUI front-end won't work: https://imgur.com/a/Dajf28T I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else. If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora It's fine, I completely understand. I just happened to pick the Cinnamon spin since I knew it and MATE used LightDM and I don't use Fedora so I don't know if I can be of any help. Also, Spanish(?) confirm prompt when rest of GUI is English: https://imgur.com/a/7ashccO ...and proof X.Org on Cinnamon is running as root: https://imgur.com/a/UcLjjKT Yet on Gnome Fedora it isn't: https://imgur.com/a/DlXwcdK So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here. Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME. How would you propose we fix this bug, as you call it? Well, what exactly was the old behavior before? I know for a fact X. Org was running as root during the beta. Is X. Org as root during beta periods only the norm? Neither of the two other major distro families, Arch Linux and Ubuntu with Gnome, have X. Org as root disabled, at least not when running the Nvidia binary. Are there any malicious software that even exists that exploit X. Org being ran as root? If no one else sees that as an issue then why does Fedora? And is disabling root X. Org worth breaking people's software that would otherwise work? Clearly few DM(s) other than Gnome supports it despite earlier claims, so it isn't even standard behavior. Fedora supports multiple spins including DM(s) that don't support it, so you're just fragmenting your own ecosystem if it is enabled on Gnome Fedora only. That's not a great idea. So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe. The problem with that is that if we did it that way, nobody would adapt to the change. Much in the same manner that we're moving to cgroups v2 in Fedora 31, if we didn't do it, we can't suss out breakages and fix them (if possible). And if third parties that don't keep up with these changes (especially one that happened in 2013 for Fedora GNOME!), there's not much that can be done. Fedora is not Linux. You are not the sole arbiters of what gets changed in the Linux ecosystem. You all need to get that through your damn heads. No other distro/DE besides Gnome supports this and it doesn't look like that's ever going to change. The ONLY reason Plymouth(from my understanding, a Fedora initiative) and Flicker Free boot was/is being adopted by other distros is because Fedora did the work for them. Since Fedora isn't putting in the work to ensure DEs on their own distro support it, no one cares and won't adopt it universally. And hey, all of those DEs are Open Source. It's almost like being Open Source doesn't increase the rate that something gets fixed. Imagine that. Maybe provide an optional rootless login session option in Gnome's login screen? Again, it doesn't force things to change in the ecosystem, and worse, it makes it more difficult for QA and release verification, as we add
Re: How to subscribe to Bugzilla components?
On Mon, Sep 23, 2019 at 11:50:44AM -0500, Michael Catanzaro wrote: > Hi, > > Do anyone know how to subscribe to Bugzilla bugs for a particular component? > > I'm trying to watch glib-networking bugs. I'm already watching issues and > PRs at https://src.fedoraproject.org/rpms/glib-networking, but that only > watches for Pagure issues, not Bugzilla. On src.fedoraproject.org 'issues' are bugzilla bugs, so it should add you to CC on any new bugs if you are watching the component there. Note that that only means new bugs (It won't go back and add you to existing bugs), and the script that does this sync runs once per day. > I'm already watching webkit2gtk3 package issues on Bugzilla and this works > exactly as I would expect, but I think I configured that long ago with pkgdb > back when pkgdb still existed. > > This seems pretty basic, so it shouldn't be hard. Any ideas? I don't see you watching that component directly, only via the gnome-sig group. (So bug copies would go to gnome-...@lists.fedoraproject.org). > Michael 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: libb2-0.98.1 on Rawhide
On Sat, Sep 21, 2019 at 08:41:09AM +0200, Felix Schwarz wrote: > Am 19.09.19 um 19:59 schrieb Antonio Trande: > > libb2-0.98.1 built > > Thanks - test suite for borgbackup still passes so I think we're fine :-) Well, except that someone needs to rebuild borgbackup? Problem 2: problem with installed package borgbackup-1.1.10-4.fc32.x86_64 - package borgbackup-1.1.10-4.fc32.x86_64 requires libb2.so.0()(64bit), but none of the providers can be installed - libb2-0.98-4.20171225git60ea749.fc31.x86_64 does not belong to a distupgrade repository 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: How to subscribe to Bugzilla components?
On 9/23/19 9:50 AM, Michael Catanzaro wrote: Do anyone know how to subscribe to Bugzilla bugs for a particular component? Hover on your name at the top-right, then click preferences. There's a tab for "Component Watching". Direct link: https://bugzilla.redhat.com/userprefs.cgi?tab=component_watch ___ 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
How to subscribe to Bugzilla components?
Hi, Do anyone know how to subscribe to Bugzilla bugs for a particular component? I'm trying to watch glib-networking bugs. I'm already watching issues and PRs at https://src.fedoraproject.org/rpms/glib-networking, but that only watches for Pagure issues, not Bugzilla. I'm already watching webkit2gtk3 package issues on Bugzilla and this works exactly as I would expect, but I think I configured that long ago with pkgdb back when pkgdb still existed. This seems pretty basic, so it shouldn't be hard. Any ideas? Michael ___ 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
Summary/Minutes from today's FESCo Meeting (2019-09-23)
= #fedora-meeting-1: FESCO (2019-09-23) = Meeting started by contyk at 15:00:22 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-23/fesco.2019-09-23-15.00.log.html Meeting summary --- * init process (contyk, 15:00:29) * #2149 Proposal to change non-responsive maintainer policy (contyk, 15:02:54) * LINK: https://pagure.io/fesco/issue/2149 (contyk, 15:02:57) * #2003 Modules in buildroot enablement (contyk, 15:04:49) * LINK: https://pagure.io/fesco/issue/2003 (contyk, 15:04:51) * Let's reuse #2003 to discuss this potential dependency; the modularity team will focus tomorrow's meeting on the topic, too (contyk, 15:25:48) * #2227 Nonresponsive maintainer: Henrik Nordström hno (contyk, 15:26:16) * LINK: https://pagure.io/fesco/issue/2227 (contyk, 15:26:18) * AGREED: Orphan bzr next week unless the maintainer does it before then (+8, 0, -0) (contyk, 15:32:28) * #2225 F32 Self-Contained Change: Switch mingw32 toolchain to dwarf-2 exceptions (contyk, 15:33:21) * LINK: https://pagure.io/fesco/issue/2225 (contyk, 15:33:23) * AGREED: F32 Self-Contained Change: Switch mingw32 toolchain to dwarf-2 exceptions is approved (+8, 1, -0) (contyk, 15:37:33) * #2230 FESCo blocker bug: Broken upgrades via libgit2 (contyk, 15:37:47) * LINK: https://pagure.io/fesco/issue/2230 (contyk, 15:37:49) * AGREED: The upgrade issue identified here is significant enough for FESCo to declare it a blocker. FESCo will vote to determine if a proposed solution or workaround is sufficient to unblock the release. At minimum, we require that a non-expert user is provided sufficient information to accomplish the upgrade without resorting to Google (+7, 0, -0) (contyk, 16:08:01) * Next week's chair (contyk, 16:08:25) * ACTION: sgallagh will chair the next meeting (contyk, 16:10:32) * Open floor (contyk, 16:10:35) Meeting ended at 16:12:08 UTC. Action Items * sgallagh will chair the next meeting Action Items, by person --- * sgallagh * sgallagh will chair the next meeting People Present (lines said) --- * mhroncok (78) * contyk (77) * sgallagh (62) * bookwar (24) * nirik (23) * zodbot (15) * jforbes (10) * otaylor (9) * bcotton (5) * zbyszek (4) * adamw (1) * ignatenkobrain (0) signature.asc Description: Digital 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
[EPEL-devel] TeamViewer on RHEL 8 and qt. Help needed
Hi, download the tar version and extract https://download.teamviewer.com/download/linux/teamviewer_amd64.tar.xz cd to the folder run ./tv-setup checklibs the output shows - Analyzing dependencies ... libQt5Positioning.so.5 => not found libQt5Sensors.so.5 => not found libQt5WebChannel.so.5 => not found The libraries listed above seem to be missing. -- and it also asks to run the command. dnf install 'libdbus-1.so.3()(64bit)' 'libQt5Gui.so.5()(64bit)' 'libQt5Widgets.so.5()(64bit)' 'libQt5Qml.so.5()(64bit)' 'libQt5Quick.so.5()(64bit)' 'libQt5WebKitWidgets.so.5()(64bit)' 'libQt5X11Extras.so.5()(64bit)' 'libqtquick2plugin.so()(64bit)' 'libwindowplugin.so()(64bit)' 'libqquicklayoutsplugin.so()(64bit)' 'libqtquickcontrolsplugin.so()(64bit)' 'libdialogplugin.so()(64bit)' Ran the command on RHEL 8 and most libraries are missing (epel-playground and epel-testing repos are enabled). Is it something to do with RHEL 8 not supporting KDE? What is the solution to get TeamViewer working on RHEL 8? thanks. -- Thomas Stephen Lee ___ 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
Re: Unresponsive maintainers: Alex Chernyakhovsky & Othman Madjoudj
Alex Chernyakhovsky writes: > Yeah, I have no idea how I missed that bug. But I've uploaded 1.3.2 > for all active branches and requested an epel8 branch, so that's all I > can do for now :) Appreciated. Thanks, --Robbie 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: RPM Fusion Bugzilla Bug 5307
On Mon, Sep 23, 2019 at 9:50 am, Michael Catanzaro wrote: You're wasting your time. We're not going to run the X server as root just so you can overclock your GPU. Not a chance. Anyway, while we won't do that Fedora... since you're clearly interested in customizing your system, you can do so for yourself. What you want to do is build gdm using the configure flag --disable-user-display-server. You can host your special gdm in a copr if you want to make it easier for other Nvidia overclockers to use it. See https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights for why this was changed (over five years ago!). The changes were made upstream, so there is nothing Fedora-specific here. If you use GNOME on most other distros, you should see the same behavior. The only distro I know of that uses --disable-user-display-server is Endless. Michael ___ 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: RPM Fusion Bugzilla Bug 5307
On Sun, Sep 22, 2019 at 11:03 PM Ty Young wrote: > > > On 9/22/19 9:09 PM, Neal Gompa wrote: > > On Sun, Sep 22, 2019 at 7:25 PM Ty Young wrote: > >> > >> On 9/22/19 5:51 PM, Samuel Sieb wrote: > >>> On 9/22/19 3:10 PM, Ty Young wrote: > I couldn't actually install the drivers because the update GUI in the > cinnamon spin is broken and/or the repo/update servers are down. Again. > >>> I don't know why you're having so much trouble with updates. But just > >>> in case you're referring to rpmfusion as you have in other emails, I > >>> hope you're aware that Redhat has nothing to do with them. They are > >>> an independent third-party repo not managed by Fedora. They host > >>> packages that can't, for various reasons, be distributed by Fedora. > >> > >> No, I meant the package manager GUI front-end won't work: > >> > >> > >> https://imgur.com/a/Dajf28T > >> > >> > > I'm sorry that dnfdragora isn't quite working properly on your system. > > As one of the developers of dnfdragora and dnfdaemon, I'm aware of > > some of those quirks, and myself and the other developer have been > > trying to work on fixing these problems. It's difficult though, as > > both of us are working on it in our spare time. We're committed to > > improving it, but I have to find time for it, among everything else. > > > > If you'd like to help, we'd appreciate it. The project is here: > > https://github.com/manatools/dnfdragora > > > It's fine, I completely understand. I just happened to pick the Cinnamon > spin since I knew it and MATE used LightDM and I don't use Fedora so I > don't know if I can be of any help. > > > > > >> Also, Spanish(?) confirm prompt when rest of GUI is English: > >> > >> > >> https://imgur.com/a/7ashccO > >> > >> > >> ...and proof X.Org on Cinnamon is running as root: > >> > >> > >> https://imgur.com/a/UcLjjKT > >> > >> > >> Yet on Gnome Fedora it isn't: > >> > >> > >> https://imgur.com/a/DlXwcdK > >> > >> > >> So is Fedora going to admit it's a bug in Gnome Fedora or are we going > >> to keep being salty that Nvidia doesn't support or have an Open Source > >> driver by pointing the finger at them? Actually fixing the bug would be > >> the more productive option here. > >> > > Well, the rootless X thing is from gnome-session down, so that's a > > GNOME thing. I'm aware that not all DEs do this, the work was > > primarily done in GNOME. > > > > How would you propose we fix this bug, as you call it? > > > Well, what exactly was the old behavior before? I know for a fact X. Org > was running as root during the beta. Is X. Org as root during beta > periods only the norm? > > > Neither of the two other major distro families, Arch Linux and Ubuntu > with Gnome, have X. Org as root disabled, at least not when running the > Nvidia binary. Are there any malicious software that even exists that > exploit X. Org being ran as root? If no one else sees that as an issue > then why does Fedora? And is disabling root X. Org worth breaking > people's software that would otherwise work? > > > Clearly few DM(s) other than Gnome supports it despite earlier claims, > so it isn't even standard behavior. Fedora supports multiple spins > including DM(s) that don't support it, so you're just fragmenting your > own ecosystem if it is enabled on Gnome Fedora only. That's not a great > idea. > > > So, IMO, the correct behavior here would be to disable until at least > other DM(s) support it and other distros enabled it by default so that > Fedora is at least following standards. Once it *actually* gets adopted > *maybe* Nvidia will allow overclocking on non root X. Org but that could > just be wishful thinking. At minimum there should always be an option to > disable security features, especially if it results in performance > loss(e.g. Specter) or, in this case, application compatibility problems > easily... and editing a config file isn't that easy, obvious, or in some > cases even safe. > The problem with that is that if we did it that way, nobody would adapt to the change. Much in the same manner that we're moving to cgroups v2 in Fedora 31, if we didn't do it, we can't suss out breakages and fix them (if possible). And if third parties that don't keep up with these changes (especially one that happened in 2013 for Fedora GNOME!), there's not much that can be done. > > Maybe provide an optional rootless login session option in Gnome's login > screen? > Again, it doesn't force things to change in the ecosystem, and worse, it makes it more difficult for QA and release verification, as we add another codepath to everything by doing this. > > FWIW, even if the application uses Flatpak, rootless X. Org still breaks > the application. Would it be possible to grant individual applications > privileged root access on a case by case basis? > That's a Flatpak/Flathub thing, not really under our control unfortunately. > > > > > >> Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to > >> the left of the
Re: Fedora 32 Self-Contained Change proposal: Better Thermal Management for the Workstation
On Mon, Sep 23, 2019 at 2:21 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > == Summary == > Better thermal management and peak performance on Intel CPUs by > including thermald in the default install. > > == Owner == > * Name: [[User:benzea| Benjamin Berg]] > * Email: bb...@redhat.com > > * Name: [[User:ckellner| Christian J. Kellner]] > * Email: ckell...@redhat.com > * Product: Workstation > * Responsible WG: Workstation > > == Detailed Description == > > Modern Intel-based systems provide sensors and methods to monitor and > control temperature of its CPUs. The Thermal daemon will use those > sensors to monitor the temperature and use the best available method > to keep the CPU in the right temperature envelop. On certain systems > this is needed to reach the maximal performance. For optimal > performance a per-model thermald configuration should be created, this > can either be done by using dptfxtract (available from rpmfusion) or > we could ship static configuration files for a set of known models. > > For a more details explanation please consult Intel's > [https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > introduction] to thermald. > > == Benefit to Fedora == > > Better out-of-the-box experience due to improved cooling methods and > performance on Intel systems. > > == Scope == > * Proposal owners: > - Include the thermald package in the default Workstation install > - Optionally provide patches for thermald to be able to read hardware > specific configuration data To me this looks like a wrong order of operations: - Upstream patches to read hardware-specific configuration data - Include the thermald package in the default Workstation install Or maybe there could be a wrapper script that does the detection and generates a configuration accordingly? Carrying downstream patches without an explicit plan about upstreaming them sounds contrary to our usual upstream-first principle. > - Optionally collect hardware specific configuration data and ship it I don't understand the second optional item. > * Other developers: N/A (not a System Wide Change) > * Release engineering: > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > > Install the packages and use e.g. turbostat to monitor the > performance. Improvements may only be visible if the non-free > dptfxtract package is also installed. > > == User Experience == > - Better performance on certain hardware > - Better cooling of CPUs on certain hardware > > -- > 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 ___ 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: RPM Fusion Bugzilla Bug 5307
On Sun, Sep 22, 2019 at 10:02 pm, Ty Young wrote: So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe. You're wasting your time. We're not going to run the X server as root just so you can overclock your GPU. Not a chance. ___ 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: Orphaned a number of Eclipse pacakges
On Mon, Sep 23, 2019 at 3:53 PM Miro Hrončok wrote: > > On 23. 09. 19 15:34, Aleksandar Kurtakov wrote: > > As eclipse module is the supported way to get eclipse now... > > So why do we keep everything around in Fedora and crate this duality? Looking at koschei [0], eclipse packages are going to be FTBFS-cleaned up in a few months anyway. Fabio [0]: https://apps.fedoraproject.org/koschei/search?q=eclipse > -- > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Better Thermal Management for the Workstation
On Mon, Sep 23, 2019 at 4:22 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > == Summary == > Better thermal management and peak performance on Intel CPUs by > including thermald in the default install. > > == Owner == > * Name: [[User:benzea| Benjamin Berg]] > * Email: bb...@redhat.com > > * Name: [[User:ckellner| Christian J. Kellner]] > * Email: ckell...@redhat.com > * Product: Workstation > * Responsible WG: Workstation > > == Detailed Description == > > Modern Intel-based systems provide sensors and methods to monitor and > control temperature of its CPUs. The Thermal daemon will use those > sensors to monitor the temperature and use the best available method > to keep the CPU in the right temperature envelop. On certain systems > this is needed to reach the maximal performance. For optimal > performance a per-model thermald configuration should be created, this > can either be done by using dptfxtract (available from rpmfusion) or > we could ship static configuration files for a set of known models. So what are we going to do about this in F32? Are we going to create configuration files or we will provide some page how to create it yourself? Does Intel provide one? > For a more details explanation please consult Intel's > [https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > introduction] to thermald. > > == Benefit to Fedora == > > Better out-of-the-box experience due to improved cooling methods and > performance on Intel systems. > > == Scope == > * Proposal owners: > - Include the thermald package in the default Workstation install > - Optionally provide patches for thermald to be able to read hardware > specific configuration data > - Optionally collect hardware specific configuration data and ship it > > * Other developers: N/A (not a System Wide Change) > * Release engineering: > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > > Install the packages and use e.g. turbostat to monitor the > performance. Improvements may only be visible if the non-free > dptfxtract package is also installed. So what is the point of a change if improvements are visible only if non-free package is installed? > == User Experience == > - Better performance on certain hardware > - Better cooling of CPUs on certain hardware > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.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
Fedora 32 Self-Contained Change proposal: Better Thermal Management for the Workstation
https://fedoraproject.org/wiki/Changes/ThermalManagementWS == Summary == Better thermal management and peak performance on Intel CPUs by including thermald in the default install. == Owner == * Name: [[User:benzea| Benjamin Berg]] * Email: bb...@redhat.com * Name: [[User:ckellner| Christian J. Kellner]] * Email: ckell...@redhat.com * Product: Workstation * Responsible WG: Workstation == Detailed Description == Modern Intel-based systems provide sensors and methods to monitor and control temperature of its CPUs. The Thermal daemon will use those sensors to monitor the temperature and use the best available method to keep the CPU in the right temperature envelop. On certain systems this is needed to reach the maximal performance. For optimal performance a per-model thermald configuration should be created, this can either be done by using dptfxtract (available from rpmfusion) or we could ship static configuration files for a set of known models. For a more details explanation please consult Intel's [https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon introduction] to thermald. == Benefit to Fedora == Better out-of-the-box experience due to improved cooling methods and performance on Intel systems. == Scope == * Proposal owners: - Include the thermald package in the default Workstation install - Optionally provide patches for thermald to be able to read hardware specific configuration data - Optionally collect hardware specific configuration data and ship it * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == Install the packages and use e.g. turbostat to monitor the performance. Improvements may only be visible if the non-free dptfxtract package is also installed. == User Experience == - Better performance on certain hardware - Better cooling of CPUs on certain hardware -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org
Fedora 32 Self-Contained Change proposal: Better Thermal Management for the Workstation
https://fedoraproject.org/wiki/Changes/ThermalManagementWS == Summary == Better thermal management and peak performance on Intel CPUs by including thermald in the default install. == Owner == * Name: [[User:benzea| Benjamin Berg]] * Email: bb...@redhat.com * Name: [[User:ckellner| Christian J. Kellner]] * Email: ckell...@redhat.com * Product: Workstation * Responsible WG: Workstation == Detailed Description == Modern Intel-based systems provide sensors and methods to monitor and control temperature of its CPUs. The Thermal daemon will use those sensors to monitor the temperature and use the best available method to keep the CPU in the right temperature envelop. On certain systems this is needed to reach the maximal performance. For optimal performance a per-model thermald configuration should be created, this can either be done by using dptfxtract (available from rpmfusion) or we could ship static configuration files for a set of known models. For a more details explanation please consult Intel's [https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon introduction] to thermald. == Benefit to Fedora == Better out-of-the-box experience due to improved cooling methods and performance on Intel systems. == Scope == * Proposal owners: - Include the thermald package in the default Workstation install - Optionally provide patches for thermald to be able to read hardware specific configuration data - Optionally collect hardware specific configuration data and ship it * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == Install the packages and use e.g. turbostat to monitor the performance. Improvements may only be visible if the non-free dptfxtract package is also installed. == User Experience == - Better performance on certain hardware - Better cooling of CPUs on certain hardware -- 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
[Bug 1754281] [RFE] EPEL-8 branch for perl-Coro-Multicore
https://bugzilla.redhat.com/show_bug.cgi?id=1754281 --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2019-8f84208a63 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8f84208a63 -- 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 1754281] [RFE] EPEL-8 branch for perl-Coro-Multicore
https://bugzilla.redhat.com/show_bug.cgi?id=1754281 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Coro-Multicore-1.03-3. ||el8 -- 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: Orphaned a number of Eclipse pacakges
On ma, 23 syys 2019, Miro Hrončok wrote: On 23. 09. 19 15:34, Aleksandar Kurtakov wrote: As eclipse module is the supported way to get eclipse now... So why do we keep everything around in Fedora and crate this duality? Because you cannot include modules in buildroot, I guess. -- / Alexander Bokovoy ___ 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: Orphaned a number of Eclipse pacakges
On Mon, Sep 23, 2019 at 4:53 PM Miro Hrončok wrote: > On 23. 09. 19 15:34, Aleksandar Kurtakov wrote: > > As eclipse module is the supported way to get eclipse now... > > So why do we keep everything around in Fedora and crate this duality?oo > Good question. There are other packages that require Eclipse (e.g. swt and equinox) so keeping parts of eclipse only make sense for these other packages. But most of the leave packages can go out now. > -- > 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 > -- Alexander Kurtakov Red Hat Eclipse Team ___ 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: aarch64 test systems implementation
"Richard W.M. Jones" writes: > On Thu, Sep 19, 2019 at 11:27:21AM +0100, Dave Love wrote: >> (Is there a way to tell?) > > virt-what ! I guess if I'd read the man page I'd have seen that the "kvm" I saw was distinct from "qemu"; apologies for the noise. ___ 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: Orphaned a number of Eclipse pacakges
On 23. 09. 19 15:34, Aleksandar Kurtakov wrote: As eclipse module is the supported way to get eclipse now... So why do we keep everything around in Fedora and crate this duality? -- 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
Orphaned a number of Eclipse pacakges
As eclipse module is the supported way to get eclipse now and there are a number of FTBFS for me as a package I've just orphaned the following: * eclipse-tm-terminal * eclipse-swtbot * cbi-plugins * eclipse-dtp * eclipse-ecf * eclipse-eclemma * eclipse-egit-github * eclipse-linuxtools * eclipse-moreunit * eclipse-mylyn * eclipse-mpc * eclipse-pydev * eclipse-packagekit Most of them are leaf packages so can go freely - only critical parts if one wants to keep eclipse srpm in is eclipse-ecf and cbi-plugins. -- Alexander Kurtakov Red Hat Eclipse Team ___ 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: Building for EPEL 8 -- missing kernel-headers-4.18.0-80.11.1.el8_0.x86_64.rpm
On Mon, 23 Sep 2019 at 04:49, Jan Pazdziora wrote: > > On Fri, Sep 20, 2019 at 09:21:21AM -0400, Stephen John Smoogen wrote: > > On Fri, 20 Sep 2019 at 06:53, Jan Pazdziora wrote: > > > > > > my attempt to (scratch) build an EPEL 8 package failed with > > > > > > > > > https://kojipkgs.fedoraproject.org//work/tasks/9259/37759259/root.log > > > > > > DEBUG util.py:593: Error: Error downloading packages: > > > DEBUG util.py:593:Status code: 404 for > > > https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-80.11.1.el8_0.x86_64.rpm > > > DEBUG util.py:741: Child return code was: 1 > > > > > > I assume it's not something I could affect from my fedpkg side. > > > > > > Is that a known issue? What is the best way to report it? > > > > > > > It isn't a known issue.. I would report it as a releng issue so > > whatever I wrote to try and make this work can be fixed. > > > > Looking at the tree > > > > -rw-r--r--. 1 root sysadmin-main 434036 2019-09-20 09:25 > > latest/x86_64/RHEL-8-001/non_modular/kernel-4.18.0-80.11.2.el8_0.x86_64.rpm > > [...] > > > latest/x86_64/RHEL-8-001/non_modular/kernel-tools-libs-devel-4.18.0-80.11.2.el8_0.x86_64.rpm > > > > So the .2 kernel is the one which should be used. I don't see a > > timestamp in the file you provided so I am not sure if this build > > problem occurred near the 09:25 listed above or not. > > Thanks Stephen for looking at it. I don't see the same problem today > and I was able to build the package. > What I think might be happening is that due to the time it takes to download repos from CDN, and then rebuild the repository there is a window where the build can break. In an ideal (aka this wasn't done in spare time and actually had a budget and staff), the script would see if there were builds for EPEL going, tell koji to not let any more on, wait until the last one was cleared, then move the link to the latest repo, then tell koji to rebuild its cache and finally let EPEL builds start again. -- Stephen J Smoogen. ___ 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via releng issues: https://pagure.io/releng/issues Full report available at: https://churchyard.fedorapeople.org/orphans-2019-09-23.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change PyRTF orphan 2 weeks ago R-ALL orphan 4 weeks ago R-AnnotationDbi orphan 4 weeks ago R-BSgenomeorphan 4 weeks ago R-BSgenome.Celegans.UCSC.ce2 orphan 4 weeks ago R-Biobase orphan 4 weeks ago R-BiocGenericsorphan 4 weeks ago R-Biostrings orphan 4 weeks ago R-BufferedMatrix orphan 4 weeks ago R-BufferedMatrixMethods orphan 4 weeks ago R-DynDoc orphan 4 weeks ago R-GenomicFeatures orphan 4 weeks ago R-GenomicRanges orphan 4 weeks ago R-IRanges orphan 4 weeks ago R-ROC orphan 4 weeks ago R-affyorphan 4 weeks ago R-affydataorphan 4 weeks ago R-affyio orphan 4 weeks ago R-fibroEset orphan 4 weeks ago R-hgu133acdf orphan 4 weeks ago R-hgu95av2cdf orphan 4 weeks ago R-hgu95av2probe orphan 4 weeks ago R-maanova orphan 4 weeks ago R-multtestalexlan, orphan 4 weeks ago R-pls orphan 4 weeks ago R-preprocessCore orphan 4 weeks ago R-statmod orphan 4 weeks ago R-tkWidgets orphan 4 weeks ago R-widgetTools orphan 4 weeks ago RackTablesorphan 2 weeks ago TeXamator orphan 2 weeks ago XmlSchema msimacek, orphan 2 weeks ago Xnee orphan 5 weeks ago access-modifier-annotationmizdebsk, orphan 3 weeks ago accumulo ctubbsii, milleruntime, 5 weeks ago mizdebsk, orphan acegisecurity mizdebsk, orphan 3 weeks ago adevs orphan 5 weeks ago akuma orphan 3 weeks ago alacarte alexl, caillon, caolanm, 1 weeks ago johnp, mbarnes, orphan, rhughes, ssp annotation-indexermizdebsk, orphan 3 weeks ago anyremote orphan 2 weeks ago apache-commons-csvmizdebsk, orphan, spike 3 weeks ago apache-commons-discovery lkundrak, mizdebsk, orphan, 3 weeks ago spike apache-commons-el fnasser, mizdebsk, orphan, 3 weeks ago spike apache-commons-launcher orphan 2 weeks ago apache-mina orphan 3 weeks ago apache-sshd gil, orphan 3 weeks ago arptools jhrozek, orphan 3
Orphaned tagsoup
tagsoup was maintained byt he Stewardship SIG and is no longer required by any of our packages. I have orphaned it. I don't know much about the package, but several other Java stuff requires it: icedtea-web-0:1.8.2-3.fc31.src icedtea-web-0:1.8.2-3.fc31.x86_64 javadocofflinesearch-0:2.2-9.fc31.noarch javadocofflinesearch-0:2.2-9.fc31.src xom-0:1.2.10-13.fc31.src It was updated to the current 1.2.1 version in 2012 and upstream has either moved or died. -- 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
Re: Some Java packages in need of new permanent maintainer(s)
On Sun, Sep 8, 2019 at 8:50 PM Fabio Valentini wrote: > > Hello packagers, > > The Stewardship SIG is currently providing only bare-minimum > maintenance for some Java packages, and none of our packages depend on > them anymore. > So, we're looking for someone to take better care of them, preferably > someone who actively uses these packages or maintains a package that > depends on them. (snip) > The packages are: > > - java-base64 > - jboss-jstl-1.2-api > - jetty-version-maven-plugin > - stringtemplate4 > - tagsoup It's been two weeks, and nobody volunteered to take any of these packages. I will orphan them now. Fabio > Directly dependent packages of java-base64: > - Java-WebSocket > - elasticsearch > - gherkin2-java > - java-vash > - java-xmlbuilder > - jets3t > - rescu > - smack > - sshj > > Directly dependent packages of jboss-jstl-1.2-api: > - jboss-jsf-2.1-api > - jboss-jsf-2.2-api > > Directly dependent packages of jetty-version-maven-plugin: > - jetty8 > > Directly dependent packages of stringtemplate4: > - antlr3 > - antlr4 > - eclipselink > - gs-collections > > Directly dependent packages of tagsoup: > - icedtea-web > - javadocofflinesearch > - tika > - xom > > > If you received this email directly, you're a (co-)maintainer of one > of these packages, and would probably be best qualified to take care > of the package in question. > > If you want to take one, some, or all of them off our hands, just fill > out the "package_adoption_request" template here, and we will transfer > the package to you. https://www.pagure.io/stewardship-sig/new_issue > > If nobody claims the packages within the next two weeks, we will > orphan them again, setting them on their course towards retirement in > about two months. > > Thanks, > Fabio (decathorpe), for the Stewardship SIG ___ 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: Upcoming change for adopting orphaned packages and anitya integration
On Tue, Sep 17, 2019 at 06:39:08PM +0200, Pierre-Yves Chibon wrote: > On Tue, Sep 17, 2019 at 10:21:31AM +0200, Till Hofmann wrote: > > > > > > On 9/13/19 12:32 PM, Pierre-Yves Chibon wrote: > > > ## Anitya integration > > > > > > Currently if you want to tweak the setting for the anitya integration, > > > you need > > > to open a pull-request on the fedora-scm-requests project at > > > https://pagure.io/releng/fedora-scm-requests/ > > > That git repo is pretty big and once your pull-request is finally open, > > > you > > > still have to wait for someone to merge it. > > > > > > This is also going to change, new versions of pagure and pagure-dist-git > > > offer a > > > drop-down menu on the left hand side menu to see and adjust the monitoring > > > status of the project. > > > > > > This is also live in staging and you can see an example of a project who > > > has set > > > its monitoring status to "monitoring": > > > https://src.stg.fedoraproject.org/rpms/0ad > > > > > > (The status in staging have been imported from the fedora-scm-requests > > > repo) > > > > > > This is great to here! Would it be possible to have a page that shows > > the monitoring status of all my packages? Does that even exist already? > > I find myself repeatedly going through all my packages one-by-one to > > check the monitoring status, and I still miss a package once in a while. > > (This will already get easier with the new buttons, though). > > No page but writing a script for this should be straight forward. > I am mostly AFK this week but I can cook up something for this next week :) Here it is: https://pingou.fedorapeople.org/get_monitoring_status.py Small introduction and example output at: http://blog.pingoured.fr/index.php?post/2019/09/23/Retrieving-the-monitoring-statuses-of-someone-s-packages Hoping this helps :) Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Looking for a maintainer for freemedforms
On Mon, Sep 23, 2019 11:34:18 +0200, Kevin Kofler wrote: > Ankur Sinha wrote: > > It does not currently build in f31+ and may require dialogue with > > upstream to fix. > > https://bugzilla.redhat.com/show_bug.cgi?id=1735221#c7 > > This build failure (at least the one in the logs posted here) is due to > broken dependencies in OpenCV at the time of the build and not freemedforms' > fault at all. Sure, but I no longer have the resources to actively look into what causes the build failures---whatever they may be. > > Please let me know if you would like to take it up, otherwise I will > > retire it from Fedora on Friday (27th September). It will get > > orphaned/retired as part of the FTBFS process otherwise anyway. > > I don't see why you want to explicitly retire the package on such a short > notice (1 week) instead of letting the regular processes take care of it. Because it can only be retired from F31 before Final Freeze---and that for F31 is on 2019-10-08 https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Procedure Have I misunderstood this? > If you want somebody else to pick up the package, please orphan it rather > than retiring it, so people at least get 6 weeks to fix it (or, since it > also FTBFS, the time frame left in the FTBFS process, whichever is shorter, > but this is an F31 FTBFS, so the 6 weeks from the orphaning process will be > the shorter deadline). > > We already have retirement processes with pretty short deadlines. Please do > not explicitly retire packages even sooner, at least not without a good > reason to do so. An FTBFS due to a broken buildroot is no such reason. Thanks for your input. I always appreciate it. However, I'm the maintainer here so it would not be wrong to assume that I decide whether the reason is good enough or not. In this case: - upstream maintains and supports the package officially on Debian---they even provide paid support: https://freemedforms.com/en/downloads/root - upstream no longer makes the development code available (for reasons that are not worth discussing here): https://freemedforms.com/en/downloads/sources So, I would prefer it be retired, but fine I've orphaned it and will let the process retire it eventually. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: Problem with F30 module packages that are built in F32 buildroot (?)
On 2019-09-22, Till Hofmann wrote: > We have an odd issue with a module build of sway for F30: It looks like > the module was actually built with a F32 buildroot. > > BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1754167 > Here's the build: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1376355 > > The modulemd file contains: >dependencies: >- buildrequires: >platform: [f30] > requires: >platform: [f30] > > But then, it built packages with f32 in the package version: >artifacts: > rpms: > - mako-0:1.4-1.module_f32+6140+eb754d2b.src > - mako-0:1.4-1.module_f32+6140+eb754d2b.x86_64 > - mako-debuginfo-0:1.4-1.module_f32+6140+eb754d2b.x86_64 > - mako-debugsource-0:1.4-1.module_f32+6140+eb754d2b.x86_64 There was a bug in Module Build Service that added F32 packages into non-f32 platform build roots. The bug was fixed and owners of two affected builds notified that the build will be retired in MBS and they will have to rebuild them again. Maybe the sway module slipped through the craks. Or the bug reoccurred. I cannot find the ticket where this issue was resolved. Since the build is already in a stable repository, the only option is probably bumping Release numbers in the spec files and building the module again. -- Petr ___ 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
Schedule for Mondays's FESCo Meeting (2019-09-23)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-09-23 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = request to sponsor my bot account "rhcontainerbot" into the packager group https://pagure.io/fesco/issue/2228 APPROVED (+4, 1, -0) = Followups = #topic #2149 Proposal to change non-responsive maintainer policy https://pagure.io/fesco/issue/2149 #topic #2003 Modules in buildroot enablement https://pagure.io/fesco/issue/2003 = New business = #topic #2227 Nonresponsive maintainer: Henrik Nordström hno https://pagure.io/fesco/issue/2227 #topic #2225 F32 Self-Contained Change: Switch mingw32 toolchain to dwarf-2 exceptions https://pagure.io/fesco/issue/2225 #topic #2230 FESCo blocker bug: Broken upgrades via libgit2 https://pagure.io/fesco/issue/2230 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: Digital 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: Intent to orphan dblatex (asciidoc dependency)
Okay, more news: There's a repo for the porting efforts, with NF's and my patches combined and split into logical chunks: https://github.com/mjg/dblatex-py3 Let's hope upstream can work with that ;) There's a cor rep where I've built dblatex with py3, and where I am rebuilding all packages which BR dblatex against that dblatex: https://copr.fedorainfracloud.org/coprs/mjg/dblatex/monitor/ Things looking OK so far, but I haven't compared the actual build products (docs) for consistency. Note that some of these packages (build-) require python2 for other reasons; gimp-help even requires py2 to build but does not BR it. Will FTBFS on F32 as is. ___ 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
orphaning nodejs-flot and js-excanvas
I'm orphaning nodejs-flot. Originally, I picked it up to unbundle it from one of my own packages, but I really have no NodeJS expertise to maintain it and I didn't have time to keep it up to date with all the recent upstream activity this year. The package build-depends on jarjar which is orphaned already and js-excanvas, which I'm orphaning as well. If nobody steps up within a week, I'll orphan these two. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Looking for a maintainer for freemedforms
Ankur Sinha wrote: > It does not currently build in f31+ and may require dialogue with > upstream to fix. https://bugzilla.redhat.com/show_bug.cgi?id=1735221#c7 This build failure (at least the one in the logs posted here) is due to broken dependencies in OpenCV at the time of the build and not freemedforms' fault at all. > Please let me know if you would like to take it up, otherwise I will > retire it from Fedora on Friday (27th September). It will get > orphaned/retired as part of the FTBFS process otherwise anyway. I don't see why you want to explicitly retire the package on such a short notice (1 week) instead of letting the regular processes take care of it. If you want somebody else to pick up the package, please orphan it rather than retiring it, so people at least get 6 weeks to fix it (or, since it also FTBFS, the time frame left in the FTBFS process, whichever is shorter, but this is an F31 FTBFS, so the 6 weeks from the orphaning process will be the shorter deadline). We already have retirement processes with pretty short deadlines. Please do not explicitly retire packages even sooner, at least not without a good reason to do so. An FTBFS due to a broken buildroot is no such reason. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1744711] [RFE] EPEL8 branch of perl-IO-SessionData
https://bugzilla.redhat.com/show_bug.cgi?id=1744711 --- Comment #7 from Jan Pazdziora --- Thank you! -- 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 1754281] [RFE] EPEL-8 branch for perl-Coro-Multicore
https://bugzilla.redhat.com/show_bug.cgi?id=1754281 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Petr Pisar --- https://pagure.io/releng/fedora-scm-requests/issue/17087 https://pagure.io/releng/fedora-scm-requests/issue/17088 -- 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via releng issues: https://pagure.io/releng/issues Full report available at: https://churchyard.fedorapeople.org/orphans-2019-09-23.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change PyRTF orphan 2 weeks ago R-ALL orphan 4 weeks ago R-AnnotationDbi orphan 4 weeks ago R-BSgenomeorphan 4 weeks ago R-BSgenome.Celegans.UCSC.ce2 orphan 4 weeks ago R-Biobase orphan 4 weeks ago R-BiocGenericsorphan 4 weeks ago R-Biostrings orphan 4 weeks ago R-BufferedMatrix orphan 4 weeks ago R-BufferedMatrixMethods orphan 4 weeks ago R-DynDoc orphan 4 weeks ago R-GenomicFeatures orphan 4 weeks ago R-GenomicRanges orphan 4 weeks ago R-IRanges orphan 4 weeks ago R-ROC orphan 4 weeks ago R-affyorphan 4 weeks ago R-affydataorphan 4 weeks ago R-affyio orphan 4 weeks ago R-fibroEset orphan 4 weeks ago R-hgu133acdf orphan 4 weeks ago R-hgu95av2cdf orphan 4 weeks ago R-hgu95av2probe orphan 4 weeks ago R-maanova orphan 4 weeks ago R-multtestalexlan, orphan 4 weeks ago R-pls orphan 4 weeks ago R-preprocessCore orphan 4 weeks ago R-statmod orphan 4 weeks ago R-tkWidgets orphan 4 weeks ago R-widgetTools orphan 4 weeks ago RackTablesorphan 2 weeks ago TeXamator orphan 2 weeks ago XmlSchema msimacek, orphan 2 weeks ago Xnee orphan 5 weeks ago access-modifier-annotationmizdebsk, orphan 3 weeks ago accumulo ctubbsii, milleruntime, 5 weeks ago mizdebsk, orphan acegisecurity mizdebsk, orphan 3 weeks ago adevs orphan 5 weeks ago akuma orphan 3 weeks ago alacarte alexl, caillon, caolanm, 1 weeks ago johnp, mbarnes, orphan, rhughes, ssp annotation-indexermizdebsk, orphan 3 weeks ago anyremote orphan 2 weeks ago apache-commons-csvmizdebsk, orphan, spike 3 weeks ago apache-commons-discovery lkundrak, mizdebsk, orphan, 3 weeks ago spike apache-commons-el fnasser, mizdebsk, orphan, 3 weeks ago spike apache-commons-launcher orphan 2 weeks ago apache-mina orphan 3 weeks ago apache-sshd gil, orphan 3 weeks ago arptools jhrozek, orphan 3
[Bug 1754235] perl-Test-Directory-0.050 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754235 Petr Pisar changed: What|Removed |Added Link ID||CPAN 130559 --- Comment #1 from Petr Pisar --- 0.050 release uses overloading in a bad way. Postponing the upgrade until resolving CPAN RT#130559. -- 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 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 --- Comment #4 from Fedora Update System --- FEDORA-2019-d34643e2de has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d34643e2de -- 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: Renewing the Modularity objective
Hello, Could you please also resolve breaking upgrade paths for people who never run `dnf module` command? I'll try to explain what happened to me. As I wrote above I never run `dnf module` until I was forced to run `dnf module reset` to fix my issue. I'm running Fedora 30. If I understand correctly what happened was that my zanata-client package switched to module (or maybe dependencies, not sure) and then the module was removed and replaced by packages. It happened like this: 1) `dnf update` updated zanata to use module 2) module was removed 3) `dnf update` has conflict with module packages because it tried to update to non module packages which were in conflict with the module installed ones 4) Had to call my first module command and that was `dnf module reset` 5) Call `dnf distrosync` to remove the packages from a non-existing module 6) Finally working `dnf update` This is really not nice user experience to start with the modules from a user perspective. Could you please prevent this issue for future. There should be a way how to remove module without blocking upgrade path, especially when the module was automatically dragged in by a normal update. What I missed in the above for simplification is that I used the ` --best --allowerasing` with a hope that I will be able to install the new zanata then. By doing that I've effectively blocked zanata-client from being installed on my laptop. I also want to thank DNF team, they helped me to fix my NB otherwise I wouldn't be able to make a new releases thanks to the missing zanata- client. Best regards, Jirka On Wed, 2019-09-18 at 15:30 -0400, Ben Cotton wrote: > Now that Modularity is available for all Fedora variants, it's time > to > address issues discovered and improve the experience for packagers > and > users. The Modularity team identified a number of projects that will > improve the usefulness of Modularity and the experience of creating > modules for packagers. Thoe team is proposing a renewed objective to > the Fedora Council. > > You can read the proposal at: > https://pagure.io/Fedora-Council/council-docs/pull-request/61#request_diff > > The Council will vote on this in two weeks. > > This is also posted to the Community Blog: > https://communityblog.fedoraproject.org/renewing-the-modularity-objective/ > > -- > 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 ___ 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 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 --- Comment #3 from Fedora Update System --- FEDORA-2019-fd1c851826 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fd1c851826 -- 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 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 --- Comment #2 from Fedora Update System --- FEDORA-2019-3bacaa907d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-3bacaa907d -- 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: Building for EPEL 8 -- missing kernel-headers-4.18.0-80.11.1.el8_0.x86_64.rpm
On Fri, Sep 20, 2019 at 09:21:21AM -0400, Stephen John Smoogen wrote: > On Fri, 20 Sep 2019 at 06:53, Jan Pazdziora wrote: > > > > my attempt to (scratch) build an EPEL 8 package failed with > > > > > > https://kojipkgs.fedoraproject.org//work/tasks/9259/37759259/root.log > > > > DEBUG util.py:593: Error: Error downloading packages: > > DEBUG util.py:593:Status code: 404 for > > https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/kernel-headers-4.18.0-80.11.1.el8_0.x86_64.rpm > > DEBUG util.py:741: Child return code was: 1 > > > > I assume it's not something I could affect from my fedpkg side. > > > > Is that a known issue? What is the best way to report it? > > > > It isn't a known issue.. I would report it as a releng issue so > whatever I wrote to try and make this work can be fixed. > > Looking at the tree > > -rw-r--r--. 1 root sysadmin-main 434036 2019-09-20 09:25 > latest/x86_64/RHEL-8-001/non_modular/kernel-4.18.0-80.11.2.el8_0.x86_64.rpm [...] > latest/x86_64/RHEL-8-001/non_modular/kernel-tools-libs-devel-4.18.0-80.11.2.el8_0.x86_64.rpm > > So the .2 kernel is the one which should be used. I don't see a > timestamp in the file you provided so I am not sure if this build > problem occurred near the 09:25 listed above or not. Thanks Stephen for looking at it. I don't see the same problem today and I was able to build the package. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ 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 1744683] [RFE] EPEL8 branch for perl-SOAP-Lite
https://bugzilla.redhat.com/show_bug.cgi?id=1744683 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2019-e93cbd7c35 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e93cbd7c35 -- 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 1754124] perl-Module-CoreList-5.20190920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754124 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Module-CoreList-5.2019 ||0920-1.fc32 --- Comment #1 from Petr Pisar --- An enhancement release suitable for all Fedoras. -- 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: About to orphan FreeGLUT
All right. You were the only one interested in taking FreeGLUT. It should be yours now. Thank you. --ts On Tue, 17 Sep 2019 18:10:21 + Gwyn Ciesla via devel wrote: > Happy to have you. :) > > > -- > Gwyn Ciesla > she/her/hers > > in your fear, seek only peace > in your fear, seek only love > -d. bowie > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, September 17, 2019 1:09 PM, Adam Jackson > wrote: > > > On Tue, 2019-09-17 at 15:12 +, Gwyn Ciesla via devel wrote: > > > > > > I'd love to see this not go away. If you can't find another volunteer > > > before you orphan, I'll take it, FAS: limb. If someone with more > > > experience with it steps up, give it to them. > > > > > I can't have mesa-demos break so I'm happy to comaintain. > > > > > - ajax > -- Tomáš Smetana OpenShift Engineering, Red Hat ___ 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 1754415] New: Upgrade perl-Server-Starter to 0.35
https://bugzilla.redhat.com/show_bug.cgi?id=1754415 Bug ID: 1754415 Summary: Upgrade perl-Server-Starter to 0.35 Product: Fedora Version: rawhide Status: NEW Component: perl-Server-Starter Assignee: rc040...@freenet.de Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.34 version. Upstream released 0.35. When you have free time, please upgrade it. -- 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 1754414] New: Upgrade perl-HTML-Scrubber to 0.18
https://bugzilla.redhat.com/show_bug.cgi?id=1754414 Bug ID: 1754414 Summary: Upgrade perl-HTML-Scrubber to 0.18 Product: Fedora Version: rawhide Status: NEW Component: perl-HTML-Scrubber Assignee: tcall...@redhat.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, perl-devel@lists.fedoraproject.org, tcall...@redhat.com Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.17 version. Upstream released 0.18. When you have free time, please upgrade it. -- 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 1754126] perl-CPAN-Perl-Releases-4.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1754126 --- Comment #1 from Fedora Update System --- FEDORA-2019-8304d409ff has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8304d409ff -- 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
