Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
On Mon, Jul 08, 2024 at 12:50:52PM +, Tim Landscheidt wrote: > Developers might not want to work for a project any longer > that engages in behaviour that is perceived as being at odds > with why they chose to work for that project in the first > place. Well... yeah? That sounds like a self-correcting problem. If it is indeed a problem. > (https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-to-collect.md), > the "peasants" who do not form part of the majority of the > users might indeed worry about how bug reports, etc. are > processed if they (objectively) only affect x % of all in- > stallations. So given (very!) limited resources, what criteria do you propose for prioritizing which bug reports to tackle? Are you saying that "bugs affecting more users" shouldn't be prioiritized over those that affect fewer users? If you want *your* bugs resolved first, then you have _always_ had to either (1) DoItYourself(tm), or (2) pay (or otherwise convince) someone else to do it for you. For a related example dear to me, Gutenprint just announced that it is completely dropping MacOS support, and it has not been received well. It is undoubtedly quite important for those users, but complaints don't magically make suitably skilled developers appear [1], much less make them stick around for what is an endless grind of trying to keep up with Apple's forced obselesence and other platform-level shenenigans. [1] The former MacOS maintiner walked away in early 2021. Nobody left even has _access_ to a Mac, much less the necessary skills to solve the outstanding issues. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
On Mon, Jul 08, 2024 at 11:03:53AM +, Tim Landscheidt wrote: > But with that knowledge comes the ability to work for a va- > riety of organizations who will spend many resources on > nudging their users to behave in a way that is not necessar- > ily in their best interests. What does "a developer's ability to choose who they work for" have to do with end-user's ability to trust (and verify!) what data is being sent (or not) to Fedora? Because what you're describing is a complete non-sequiter, and represents what has been the status quo for most of Humanity's history. No metrics necessary, because who cares what the peasants actually want? - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F39 to F40
On Wed, Feb 21, 2024 at 08:11:49AM +0100, Miroslav Suchý wrote: > Do you want to make Fedora 40 better? Please spend 1 minute of your time and > try to run: From the Fedora systems I have immediate access to: Well-used F39 Workstation: Problem: problem with installed package blender-1:4.0.2-1.fc39.x86_64 - blender-1:4.0.2-1.fc39.x86_64 from @System does not belong to a distupgrade repository - nothing provides libopenvdb.so.10.1()(64bit) needed by blender-1:4.0.2-1.fc40.x86_64 from fedora Fairly standard F39 Server: Problem: package emacs-nox-1:29.2-2.fc39.x86_64 from @System requires emacs-common = 1:29.2-2.fc39, but none of the providers can be installed - emacs-common-1:29.2-2.fc39.x86_64 from @System does not belong to a distupgrade repository - problem with installed package emacs-nox-1:29.2-2.fc39.x86_64 (Very) Special Snowflake F38 shell server: Problem 1: problem with installed package python3-vdirsyncer-0.18.0-8.fc38.noarch - python3-vdirsyncer-0.18.0-8.fc38.noarch from @System does not belong to a distupgrade repository - nothing provides (python3.12dist(aiostream) < 0.5~~ with python3.12dist(aiostream) >= 0.4.3) needed by python3-vdirsyncer-0.19.2-1.fc40.noarch from fedora Problem 2: package mozjs78-78.15.0-10.fc38.x86_64 from @System requires libicui18n.so.72()(64bit), but none of the providers can be installed - package mozjs78-78.15.0-10.fc38.x86_64 from @System requires libicuuc.so.72()(64bit), but none of the providers can be installed - libicu-72.1-2.fc38.x86_64 from @System does not belong to a distupgrade repository - problem with installed package mozjs78-78.15.0-10.fc38.x86_64 Problem 3: package pipenv-2022.10.25-2.fc38.noarch from @System requires python(abi) = 3.11, but none of the providers can be installed - python3-3.11.7-2.fc38.x86_64 from @System does not belong to a distupgrade repository - problem with installed package pipenv-2022.10.25-2.fc38.noarch Problem 4: package khal-0.11.2-6.fc40.noarch from fedora requires vdirsyncer >= 0.8.1-2, but none of the providers can be installed - problem with installed package khal-0.11.2-4.fc38.noarch - package vdirsyncer-0.19.2-1.fc40.noarch from fedora requires python3-vdirsyncer = 0.19.2, but none of the providers can be installed - vdirsyncer-0.18.0-8.fc38.noarch from @System does not belong to a distupgrade repository - khal-0.11.2-4.fc38.noarch from @System does not belong to a distupgrade repository - nothing provides (python3.12dist(aiostream) < 0.5~~ with python3.12dist(aiostream) >= 0.4.3) needed by python3-vdirsyncer-0.19.2-1.fc40.noarch from fedora Problem 5: package vdirsyncer-0.18.0-8.fc38.noarch from @System requires python3-vdirsyncer = 0.18.0, but none of the providers can be installed - problem with installed package vdirsyncer-0.18.0-8.fc38.noarch - package python3-vdirsyncer-0.18.0-8.fc38.noarch from @System requires python3.11dist(atomicwrites) >= 0.1.7, but none of the providers can be installed - package vdirsyncer-0.19.2-1.fc40.noarch from fedora requires python3-vdirsyncer = 0.19.2, but none of the providers can be installed - python3-atomicwrites-1.4.1-2.fc38.noarch from @System does not belong to a distupgrade repository - nothing provides (python3.12dist(aiostream) < 0.5~~ with python3.12dist(aiostream) >= 0.4.3) needed by python3-vdirsyncer-0.19.2-1.fc40.noarch from fedora Additionally, One other F39 workstation, two minimal F39 headless systems, one F39 server, and one F38 server went smoothly. All in all, a pretty small pile of issues from what I normally see. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, Feb 20, 2024 at 03:54:54PM +0100, Kevin Kofler via devel wrote: > the smaller one and letterboxing the larger one as it should.) So this means > 1. Wayland will never be suitable for my notebook, and 2. one of these days > I am going to have to port Plasma Mobile to X11. Or, uh, (3) Port/add this functionality to Plasma/Wayland? (There's nothing in Wayland that precludes this from working; just nobody's bothered to implement it) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Wed, Feb 07, 2024 at 01:21:15PM +0100, Peter Boy wrote: > Unfortunately, some Fedora maintainers seem to take their cue from the > missionaries and conquistadors of the 16th and 17th centuries and try > fire and sword and coercion. A bad strategy in a free world. Congratulations, you just conflated volunteer Free Software package maintainers with literal genocidal rapists and murders. ...That is a bad strategy in _any_ world. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Update on the Modern C initiative
On Fri, Dec 22, 2023 at 10:27:55PM +0100, Florian Weimer wrote: > >> gutenprint jpopelka jridky twaugh zdohnal > > ...FWIW as of a few minutes ago this should be resolved upstream. > > Thanks, I can confirm this fixes the issue for the Fedora package as > well. Should I push this to rawhide? It makes tracking easier for us. Yes please! There's no good reason for not having rawhide track Gutenprint upstream. IMO it should get pulled into current Fedora versions too; the first thing I tell anyone reporting an issue is to rebuild from current sources. (Granted most of those users are on EL/LTS-type distros..) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Update on the Modern C initiative
On Fri, Dec 22, 2023 at 02:18:54PM +0100, Florian Weimer wrote: > gutenprint jpopelka jridky twaugh zdohnal ...FWIW as of a few minutes ago this should be resolved upstream. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning all my packages
On Tue, Oct 03, 2023 at 08:50:53PM +0200, Leon Fauster via devel wrote: > If a bumped version of a package fixes an issue (stream variant of > CentOS) e.g 2.2, and a released package (rhel variant) has a > backported fix for e.g. 2.1, that doesn't mean that the code is also > in the stream git just because both code fragments fixes the same > issue. The backported code can be very different, and its not in the > git branch of the stream variant. So, that code is not available in > git, and to cite Michael "and never will be." However, this has _always_ been the situation for RHEL. Only the sources for the _latest_ point release (eg RHEL 7.4) were ever made available to the general public; updates/fixes backported to prior versions (eg RHEL 7.3) never saw the precise corresponding sources released (directly) to the public. Pre-Stream CentOS therefore only ever received updates for the _latest_ point release of RHEL. (Of course, actual RH customers can always download the corresponding SRPMs, and RH will send the sources to any third party who makes a request in writing, for $5) So, yeah. Complaining _now_ about what's been the operating policy for two decades seems pretty silly. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Mon, Sep 11, 2023 at 09:26:44AM -0700, Kevin Fenzi wrote: > I think we need to figure out the way forward, but... I don't think we > should do it here and now. Please go test f39. ;) While I'm personally glad that the forced-onto-proprietary-gitlab migration has effectively stalled indefinitely, the fact remains is said migration is still the plan of record. So, if it's effectively dead, let's make it official? - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Mon, Sep 11, 2023 at 07:58:03AM -0500, Michael Catanzaro wrote: > No? All of our packages are on https://src.fedoraproject.org/ and our > Fedora-specific source code goes on https://pagure.io/. These are both > Pagure, not GitLab. It is open source. https://lwn.net/Articles/817426/ https://communityblog.fedoraproject.org/making-a-git-forge-decision/ "After evaluating over 300 user stories from multiple stakeholders, the Community Platform Engineering (CPE) team have aligned on a decision for the git forge that CPE will operate for the coming years. We are opting for GitLab for our dist git and project hosting and will continue to run pagure.io with community assistance." That was back in 2020. Clearly this hasn't happened yet, but there's been almost no communication about the status of this migration since then. The way it was presented was that this was already a done deal, and we could either accept it or GTFO. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Mon, Sep 11, 2023 at 04:35:50AM +0200, Kevin Kofler via devel wrote: > +1, Fedora MUST NOT rely on proprietary infrastructure. IMHO, it is a > mistake that Red Hat is doing so, and Fedora should not follow that > unfortunate move. Not to retread old drama, but doesn't Fedora now rely on a proprietary version of Gitlab? - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F38 to F39
On Fri, Aug 25, 2023 at 09:08:23PM -0700, Samuel Sieb wrote: > No, it's a demonstration of applications that aren't being properly > maintained when they're still using functions that have been deprecated for > 6 releases which is also that many years. Python core is very stable. So... you're saying that the fact that *every* python release in the past decade carries backwards-incompatible core changes is somehow an indication of its "stability"? (If you want "stability" in python you have to pin absolutely everything in a per-applicaiton venv, including every [sub-]dependency and the interpreter version. And $deity help you if you need some relatively-bleeding-edge modules or have dependencies with conflicting version needs. I spent the majority of my time at $dayjob-1 keeping on top of the constant CI failures caused by the turtles-all-the-way-down dependencies changing out from under us) If you want a platform that is actually stable, take perl. They have an explicit policy of never breaking existing software even if it means carrying bugs forward indefinitely, and scripts/modules have to explicitly opt into behavioral changes. I have twenty-year-old perl scripts that still work just fine, but in my experience, even couple-years-old python code most likely won't. If perl is "write once, read nowhere" python is "write once, fix forever". /rant - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F38 to F39
On Fri, Aug 25, 2023 at 06:55:17PM -0700, Adam Williamson wrote: > It's a lot of output, but not *so* many problems when you boil it down. Yeah, it's ultimately another example (or four) of how Python is utterly worthless as a "stable" application platform. > I suppose we could just vendor asynchat and asyncore back into > fail2ban, but that feels pretty ugly. Maybe worth doing in extremis if > upstream can't get it ported before F39 Final, since I think fail2ban > is quite popular? Everything is important to someone, but I would think that fail2ban would result in some serious teeth-gnashing if it got dropped. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F38 to F39
On Wed, Aug 23, 2023 at 08:22:42PM +0200, Miroslav Suchý wrote: > Do you want to make Fedora 39 better? Please spend 1 minute of your time and > try to run: I ran this on a bunch of my fleet, lots of problems, and they all seem to be related to the Python 3.12 bump. F38 Workstation #1: Problem 1: problem with installed package openocd-0.12.0-2.fc38.x86_64 - openocd-0.12.0-2.fc38.x86_64 from @System does not belong to a distupgrade repository - nothing provides libjim.so.0.81()(64bit) needed by openocd-0.12.0-0.rc1.fc38.2.x86_64 from fedora - nothing provides libjim.so.0.81()(64bit) needed by openocd-0.12.0-0.rc1.fc38.2.x86_64 from fedora-modular - nothing provides libjim.so.0.81()(64bit) needed by openocd-0.12.0-0.rc1.fc38.2.x86_64 from updates-modular - nothing provides libjim.so.0.81()(64bit) needed by openocd-0.12.0-0.rc1.fc38.2.x86_64 from updates-testing-modular Problem 2: package python3-PyDrive-1.3.1-21.fc37.noarch from @System requires python(abi) = 3.11, but none of the providers can be installed - python3-3.11.4-1.fc38.x86_64 from @System does not belong to a distupgrade repository - problem with installed package python3-PyDrive-1.3.1-21.fc37.noarch Problem 3: problem with installed package python3-pathtools-0.1.2-30.fc38.noarch - package python3-pathtools-0.1.2-30.fc38.noarch from @System requires python(abi) = 3.11, but none of the providers can be installed - package python3-pathtools-0.1.2-30.fc38.noarch from fedora requires python(abi) = 3.11, but none of the providers can be installed - package python3-pathtools-0.1.2-30.fc38.noarch from fedora-modular requires python(abi) = 3.11, but none of the providers can be installed - package python3-pathtools-0.1.2-30.fc38.noarch from updates-modular requires python(abi) = 3.11, but none of the providers can be installed - package python3-pathtools-0.1.2-30.fc38.noarch from updates-testing-modular requires python(abi) = 3.11, but none of the providers can be installed - package python3-3.11.4-1.fc38.x86_64 from @System requires python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed - python3-libs-3.11.4-1.fc38.x86_64 from @System does not belong to a distupgrade repository Problem 4: problem with installed package python3-devel-3.11.4-1.fc38.x86_64 - package python3-devel-3.12.0~rc1-1.fc39.x86_64 from fedora conflicts with python3 < 3.12.0~rc1-1.fc39 provided by python3-3.11.4-1.fc38.x86_64 from @System - package python3-devel-3.12.0~rc1-1.fc39.x86_64 from fedora-modular conflicts with python3 < 3.12.0~rc1-1.fc39 provided by python3-3.11.4-1.fc38.x86_64 from @System - package python3-devel-3.12.0~rc1-1.fc39.x86_64 from updates-modular conflicts with python3 < 3.12.0~rc1-1.fc39 provided by python3-3.11.4-1.fc38.x86_64 from @System - package python3-devel-3.12.0~rc1-1.fc39.x86_64 from updates-testing-modular conflicts with python3 < 3.12.0~rc1-1.fc39 provided by python3-3.11.4-1.fc38.x86_64 from @System - problem with installed package python3-async-generator-1.10-16.fc38.noarch - package python3-async-generator-1.10-16.fc38.noarch from @System requires python(abi) = 3.11, but none of the providers can be installed - package python3-async-generator-1.10-16.fc38.noarch from fedora requires python(abi) = 3.11, but none of the providers can be installed - package python3-async-generator-1.10-16.fc38.noarch from fedora-modular requires python(abi) = 3.11, but none of the providers can be installed - package python3-async-generator-1.10-16.fc38.noarch from updates-modular requires python(abi) = 3.11, but none of the providers can be installed - package python3-async-generator-1.10-16.fc38.noarch from updates-testing-modular requires python(abi) = 3.11, but none of the providers can be installed - python3-devel-3.11.4-1.fc38.x86_64 from @System does not belong to a distupgrade repository F38 Workstation #2: Problem 1: problem with installed package python3-pathtools-0.1.2-30.fc38.noarch - package python3-pathtools-0.1.2-30.fc38.noarch from @System requires python(abi) = 3.11, but none of the providers can be installed - package python3-pathtools-0.1.2-30.fc38.noarch from fedora requires python(abi) = 3.11, but none of the providers can be installed - package python3-pathtools-0.1.2-30.fc38.noarch from fedora-modular requires python(abi) = 3.11, but none of the providers can be installed - package python3-pathtools-0.1.2-30.fc38.noarch from updates-modular requires python(abi) = 3.11, but none of the providers can be installed - package python3-pathtools-0.1.2-30.fc38.noarch from updates-testing-modular requires python(abi) = 3.11, but none of the providers can be installed - python3-3.11.4-1.fc38.x86_64 from @System does not belong to a distupgrade repository Problem 3: problem with installed package python3-async-generator-1.10-16.fc38.noarch - package python3-async-generator-1.10-16.fc38.noarch from @System requir
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
On Wed, Jul 26, 2023 at 04:36:13PM +0200, Ralf Corsépius wrote: > My (older) lenovo laptop and my HPE Micro-Server are obviously not. The laptop is a T495 (introduced late 2019), but the workstation is an older HP Z440 (introduced in late 2014!) > This is the second time, somebody mentions Samsung NVMEs were supported. > Well, what shall I say. I wouldn't go so far as to say _all_ Samsung NVMEs are supported, but the unit in my laptop had an update published, though it appears that Lenovo was the one that submitted it. > I have several of them (and Samsung SATA SSDs), but so far, I always had to > resort to other means of updating their firmware (Windows+Magician or > iso-images), because fwupd would not want to update. None of the other SSDs I have deployed (Samsung and Crucual SATA) are updatable via LVFS, unfortunately. But, hilariously, both Samsung and Crucial's official updaters appear to be self-contained linux ISOs. So clearly the technical capability is there... - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
On Wed, Jul 26, 2023 at 11:48:36AM +0300, Alexander Ploumistos wrote: > That would require people volunteering to potentially brick their > machines in order to test the updates. If something goes wrong, the > equipment (and the knowledge) necessary to reprogram a chip is rather > scarce. I'm afraid the way forward is to _convince_ vendors to make > use of the service, starting with those who already have test > accounts. I've been debating contributing some code to fwupd to handle several different vendors' families of printers, but there's a snowball's chance in hell that said vendors will ever embrace lvfs given that they steadfastly refuse to publicly acknowledge that Linux exists, despite invariably selling a Linux-based print server appliance of some sort. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
On Wed, Jul 26, 2023 at 09:45:13AM +0200, Ralf Corsépius wrote: > It could be "my bubble", but for me, in all these fwupd is around, it has > never, ever worked on any piece of HW for me. Most of the stuff I have that is updated through fwupd are peripherals [1] that are independent of the system vendor. That said, my two primary systems are a Lenovo laptop and an HP workstation that are fully supported by fwupd/lvfs, and the UEFI dbx stuff works on all of the remaining physical systems (including servers) I still have deployed. Things will only get better from here. [1] Off the top of my head: Logitech wireless stuff, Jabra conference speaker, synaptics fingerprint sensor, (Samsung?) NVME storage, and probably more.. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Mon, Jul 24, 2023 at 04:51:38PM +0100, Richard W.M. Jones wrote: > You don't actually need to do any of this if you're using libguestfs, > because the worst that can happen is the filesystem will pwn the > kernel inside the KVM appliance (which is just a userspace process, so > you can kill it). But if that kernel is pwn3d, won't that still allow arbitrary data to be passed out to the host? (I confess to knowing very little about the guts of libguestfs) > A bit in the superblock marks the filesystem as clean or dirty, and > that has nothing to do with whether it is malicious. Yep. I'm just saying that if the filesystem is marked as dirty, then prompting the user what to do is a good idea -- After all, we *know* the filesystem integrity is questionable, and mounting it might cause unintented side effects. (ie not p3nage, but instead the far more common threat of corruption or data loss) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Mon, Jul 24, 2023 at 04:00:21PM +0100, Daniel P. Berrangé wrote: > If I have a USB flash stick I plug in every day, it shouldn't ask me > about that after the first time I use it. Based on this "threat model" all an attacker has to do then is snag/modify/replace your existing drive and then they can pwn your system. That's probably much easier to accomplish than getting you to insert a previously-unseen device (the latter has a lot of awareness around it, but the "of course I trust this one, it's mine!" will get you pwned.) (Besides, how are you to distinguish the exact stick? Most of the stuff I have lying around here reports the same generic vendor/product/serial number. And drive/volume labels are notoriously unreliable.) > If I acquire a new USB flash stick I've never plugged in before, I > don't want it auto-mounting before I can wipe & reformat it. Honestly, what makes more sense to me is treat this whole thing purely as a usability problem. Upon insertion, prompt the user to "mount, mount reat-only, check, ignore", because at least then we'd get an really easy method of fscking a disk without having to do the whole unmount dance. It also provides a mechanism to supply user feedback (eg showing fsck results, or the XFS case where you _have_ to mount the filesystem to replay the journal before an fsck can be safely run) If the filesystem is dirty, the dialog always is displayed (with an appropriate message recommending fsck), but if it's clean, the user can dismiss the dialog with prejudice and have it always accept that drive in the future. We can also provide a hot-key (eg hold down shift when inserting the drive) to tell the system to always show the prompt even for previously whitelisted devices. This IMO improves the general usability of the system, instead of making things universally worse, while simultaneously providing the hooks necessary to implement better security. Again, let's be realistic about the threat models here -- the overwhelmingly common situations are accidental corruption due to improper shutdown/ejection, and malicious files on a well-formed filesystem (eg ransomware or something that's banking on users having we passwordless sudo in place, or curl https://url/setup.sh | sudo bash) So let's make things better for those before worry about mitigating APTs that need lots of system-specific awareness in order for an attack to succeed? - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal Gompa wrote: > > If the system administrator wants to mount $UNCOMMONFS, they should be > > able to do so without hassle, but that doesn't mean that a normal user > > who got handed a sketchy USB stick at a conference should be able to do > > so with no restrictions at all. > > > > So then some kind of configuration to udisks2 to have a similar effect? And we're right back at square one, with the *overwhelmingly* common case of a single-user system whose "admin" is sitting in front of the system. Of _course_ they want to mount the disk. It's why they plugged it in, and they don't give two hoots if it's a "common filesystem" or not. (FFS, most of the stuff I personally plug in these days is ext4 or ntfs, because fat32 sucks and I can't rely on exfat on all systems I need to interoperate with) And let's be realistic here -- the overwhelmingly common threat model here is that there are untrusted files on a correctly-formed filesystem. Bad guys rarely need or care to get root on the system; what they're after requires normal, non-elevated user permissions. Prompting users 'are you sure you want to use this device' will turn a "yes" into an automatic reflex. Not automounting by default will just add another thing to the "things to change on default fedora installations" lists out there (ie right after the "enable freshrpms and install modern video codecs" step), becuase it's a usability nightmare. In the "usability vs security" tradeoff, usability/convenience *always* wins unless you're at a place that has armed guards at the door with instructions to shoot first. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Red Hat & Fedora -- largely stepping out of this ecosystem
On Fri, Jun 30, 2023 at 01:41:18PM +, Leslie Satenstein via devel wrote: > What should I do, if the person I gave the software to, removes my > copyright, rebrands the software and sells my software as their own? > Is it right? And when I release a bug fix, they take it, insert the > fix into the rebranded copy they are selling, and they quietly say, > "Screw You, Leslie". In some jurstictions (eg the US) removing your copyright identification is infringement all on its own, and you can go after them for statutory damages. (See 17 USC 1202 (b) and (c), and 17 USC 1203 (c) (2)) But that's not what has happened here. Nobody is claiming that they are selling RHEL, and nobody has stripped away RH's copyrights. Now the RH *trademarks* are another matter, but RH themselves did that stripping, with what they uploaded to CentOS Stream (and CentOS before that). > What right does a company have the right to clone and rebrand my > product and resell it? Under the gpl3, they have an unenforceable > obligation to provide me with bug reports. They do not have a moral > right to redistribute my software as their own, and for remuneration. Under the GPLv3, there is no "obligation" to provide you, as the author, with anything, bug reports or otherwise. Their only obligations are to ensure that everyone they send binaries to also receives the complete corresponding source code to those binaries, all under the terms of the GPLv3. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: UW-IMAP
On Thu, Jun 29, 2023 at 10:27:49AM -0400, David Both wrote: > I also spent about 4 days trying to get Dovecot to work with SendMail in > a test VM setup. I'm either missing one or more important bits or its > just too complex for me. I've been running a dovecot + sendmail setup on Fedora for over 15 years. Of the two, sendmail (or rather, making it robust against incoming spam) has proven to be a far greater ongoing headache; dovecot has pretty much JustWorked(tm). At the end of the day the only coordination between dovecot and sendmail (+procmail) is ensuring they both are set up to use the same place for the users' mail spool. So I'm curious as to the problems you're running into with dovecot specifically, and I may be able to help. (I switched from UW-IMAP to dovecot to facilitate a migration to Maildir) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Thu, Apr 27, 2023 at 10:47:15AM -0700, Kevin Fenzi wrote: > Our discourse instance is hosted for us by discourse. > We shouldn't have to do maint on it, but we will have to do moderation, > etc. So... if maintaining discourse is too much overhead but it's okay to pay someone else to handle, why can't that be done for our mailing list infrastructure too? Even if that service offering is proprietary? (hosted enterprise gitlab, anyone?) And, for that matter, what of the other services currently owned/hosted/maintained under the RH/Fedora roof? (For example, we're going to be having this conversation again in the not-so-distant future once RH finishes switching over to Jira and stops funding our Bugzilla instance's upkeep..) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Thu, Apr 27, 2023 at 07:01:15AM -0400, Stephen Smoogen wrote: > breaking mail altogether. My frustration and anger comes from the fact that > I spent most of the last 5 years assuming that it was somebody else's > problem and they would take care of it so I could focus on keeping other > things running. This is a very important point -- Is RH/Fedora prepared to properly handle the maintainence, administrative, moderation, etc burden of scaling up the Discourse instance? Or will all of Fedora's customizations make it into another special snowflake instance that results in very painful upgrade paths, leaving it to become yet another service left to coast along under its own inertia until this cycle repeats itself again? I mean, it's all fine to say "but Discourse is actively developed" -- if you never actually upgrade/update it to match upstream, it's no different than the situation we have with our mailman3 today, where we're literally years behind the curve. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Wed, Apr 26, 2023 at 02:42:56PM +0200, Kevin Kofler via devel wrote: > And as I already answered, I think this is completely backwards. If you want > to newly join a project, you learn their way to do things and adapt to it. > If, on the other hand, you are already involved in a project and have > workflows that work for you, any forced change to something perceived as a > regression will annoy you and make you want to leave. In nearly all professions, "mastery of the tools of the trade" is considered to be an important milestone, necessary if you're wanting to excel in that endeavor. Unfortunately, for some reason, in this profession, "tool mastery" is actively looked down upon. Nevermind that this mastery (which includes continuing to adapt, refine, and improve those tools) is the basis of the "10x developer" that so many claim to want. > As I see it, the main roadblocks for new packagers are: I think one of the legitimate points Matthew (and others) are making is that "contributor != packager" > * accepting the FPCA, > * getting sponsored, FWIW I never made it past this point. But at the same time I've not really needed to. > * learning the Packaging Guidelines, and > * getting their package(s) through review, But this is a _very_ high hurdle, as there's a _ton_ of policy and fedora-specific process that has nothing to do with email or forums or any "common" communication platform that would-be contributors would ever be expected to be familiar with. But as I already mentioned, this only applies to packagers; there are many other avenues for contributors. That said, are those other avenues relevant for this particular mailing list? > Guidelines are actually followed and as another check that nothing malicious > sneaks in), but they are the barrier to entry, not the communication > platform. I completely agree, at least on the "packagers" side. I don't know what barriers non-packaging contributors face, but I presume each sub-category has its own barriers to entry. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Tue, Apr 25, 2023 at 02:59:22PM -0400, Josh Boyer wrote: > That's certainly a choice one could make. Personally, I would not > prioritize keeping my bespoke email setup intact over working with a > community on a project I care about. My "besoke email setup" benefits *me* and my productivity/workflow far more than the ability to interact with Fedora. I might add that "email" as a whole remains a _lot_ more important than Fedora too. For nearly all of us, Fedora is means to an end, not the end in of itself. Please keep that in mind that most of us are _not_ paid or otherwise compensated for our participation here, and that there are very real costs (if "only" time and attention) associated with this participating. By increasing those costs (real and perceived) many will reasonably determine the benefits are no longer worth the higher costs. > If there's even a remote possibility moving to Discourse will attract > more contributors to Fedora then I'd happily learn how to deal with > it. Change is difficult, but in the end it's something we're all > capable of. What's good for "Fedora" isn't necessarily good for many (or even most) of the individuals that already participate. Again, this is a matter of deciding, at the project leadership level, what level of effort should go into keeping more of the current contributors versus the possibility of attracting new ones. As things stand, the leadership is tryting hard to understand the objections to/problems with this proposal and mitigate them "well enough" Honestly, if a "how to configure discourse to mimic the MUA-managed mailing list experience (ie not having to log into a web site after the initial configuration)" document is produced, that's probaby sufficient to overcome most of these objections, because then the setup cost is one-off, and the ongoing "interact with Fedora-devel" cost won't be any greater than it already is. (It's not the setup cost that's a problem, it's the per-transaction/interaction cost, which is currently _higher_) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 04:38:28PM -0400, Ben Cotton wrote: > There are a lot of questions left unanswered by this quick analysis, > but there's a clear trend in fewer participants over time. In fact, > last month had the second smallest participant count (tied with > October 2022). Of course, these charts don't show _why_, but they do > support the assertion that folks are dropping out of the conversation > faster than others are joining. One obvious question: How does "sending mail to -devel" correlate with any other "contributing to Fedora" metric? Eg numbers of folks with Fedora accounts, number of packagers (or active packagers), git commiters/commits, and so forth? Or even numbers of installations, which to this way we can only kinda hand-wave about? (I wonder how that also correlates to the likes of Debian?) We also might be a victim of our own success here; things generally _work_ quite well, so there's not as much to go on about as there once was, and our various upstreams are increasingly driving our headliner features rather than the other way around. So people simply don't _need_ to participate in "developing Fedora" like they once did to ensure their interests were represented, and instead get to focus more fully on the stuff they build on top. That's a good thing, I think, but it also takes away what was probably the primary participation funnel. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 05:07:28PM +0200, Aleksandra Fedorova wrote: > No, not really. I advised you to look into it, because you may actually get > more from it personally, than you currently expect. I haven't proposed it to > become a required Fedora activity, I gave you the unsolicited advice. Which > maybe I shouldn't have. What kicked off this thread was a proposal to make "checking out" (and then actually utilizing) discussion.f.o a *required* activity to participate in Fedora development. > And now you try to tell me that "coolness" is defined by numbers. Sorry, I > don't agree. I don't need everyone in the world to work on Linux > distribution. I don't want majority of people to work on Linux distribution. > I don't even need "more than in Ubuntu" people to work on Fedora Linux > distribution. That is not the point at all, and it is not what makes things > cool. Numbers/engagement/etc was one of the justifications behind this proposal to ditch mailing lists, and my point was that "numbers" was a pretty worthless metric because of the very reasons you just listed. That said, I don't think anyone can reasonably disagree that the "coolness" factor strongly affects the numbers, because people follow the funding. Distros, like most(all) other infrastructure, were never "cool" in that big-picture context. I think that's a good thing, as it means those participating are more likely to have a genuine passion for it. > But with my Fedora Ambassador hat on I can tell you that the problem we see > right now is not that we don't have people coming to Fedora. We have a > problem helping people to connect to where the work is happening in a way > that they can contribute. Of course. But this also goes for those that are _already_ contributing. > And this includes both mentoring them to be able to contribute, but also > accepting the fact that new people can bring new ideas, and we should > provide them space to work on them and not just expect them to follow and do > what they were told to do. This also goes for those that are already contributing. It's not just about the new people. > The middle doesn't magically appear out of nowhere. It appears when you > build paths for newbies to grow into it. And it it sort of responsibility of > the current middle to grow the next one. I disagree; it's the _responsibility_ of the *leaders* to grow (and sustain!) the middle. Ultimately this comes down to defining the sort of culture the community is expected to have -- and the tools must be chosen to support/enable that culture. (It's not the middle's responsibility because they are acting mostly individually and mostly powerless; their main power comes from the ballot box, except in rare situations where someone rises up through sheer volume of meritocrous contributions) > We think the communication channels change is one of the initiatives which > helps with that. Mentorship is the other. Mentorship is necessary (from leaders to the middle, and the middle to the newbs) but doesn't scale well due to the mutual time committment necessary. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 04:55:00PM +0200, Emmanuel Seyman wrote: > I agree there's a huge lack of netiquette in Fedora's mailing lists, > with wholesale quoting, top-posting, subjects not being updated, etc but > changing mediums seems far more expensive than asking people to post > emails that are easier to read. Not to mention these problems won't go away just because it's now hosted on a web page.. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 08:24:14AM +0300, Benson Muite wrote: > As such, simply adopting it because it can be deployed may leave out > many contributors, in particular those who drive development forward. I have made this point several times in other contexts; a new tool/workflow has to yield tangible improvements for the _existing_ contributor base. Otherwise you're just going to trade away _current_ contributors for the _possibility_ of attracting new ones. (In a volunteer context, that is) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 11:42:20AM +0200, Aleksandra Fedorova wrote: > That's a slight exaggeration of course, but so is your statement. People > come to Fedora via many ways. But I doubt any of it starts with e-mail > nowadays. And the fact that you don't see newcomers _here_ actually proves > the point, isn't it? Correlation is not causation. Distro building isn't "fun", or sexy. There are much more immediately (and fiscally) rewarding things for "newcomers" to mess with. > Let's not get into a "who would you miss more" competition and work on a > solution which actually helps us to bridge the gap and allows us to > compromise between different use cases. Oh, I know my contributions here are miniscule, but my point is that we'd lose a ton of voices that collectively represent a ton of experience and use cases. > In all seriousness, I would advise you to hang out at the current > discussion.fedoraproject.org and feel the vibe a bit. You kinda just demonstrated my point -- "hanging out at and feel the vibe" is going to take time, attention, and distruption. My total available time/attention is fixed, which means this "hanging out" will have to come at the cost of something else that frankly matters _more_. And I won't personally gain anything from the effort -- at _best_ it will break even vs what I have now. > Distributions _are_ cool and sexy. And people have ideas and interest in > them. Some of them are totally wrong and misplaced, some may be very old, > and some are better. But that's how it should be. I'm sorry, the numbers are _not_ on your side here, not just with Fedora itself but the bigger picture of distributions in general. It's not "email" that is keeping folks away, it's the nature of the work. And _work_ it absolutely is. (And I say this as someone who has spent most of the past couple of decades working on low-level infrastructure-type stuff. Sure, I find it fun/enjoyable but I freely acknowledge I am several standard deviations from the mean) > It seems you feel like you are cornered, but it is you who put yourself in > the corner by ignoring the part of the community, which actually can and > wants to support you. By that same token bananas could make themselves more appealing to people that like oranges if they'd only be more orange-like. This isn't me "putting myself in a corner", it's Fedora moving the tent that I was underneath and expecting me to move with it. (Because they either don't understand _why_ anyone wouldn't want to move, or understand, and do it anyway. I can actually respect the latter position, even if I think it's not going to yield the expected results. But I think this is yet another case of the former) But whatever, I won't lose any sleep over this. As I already mentioned, I have plenty of other things to do, both in the F/OSS world and in (gasp) meatspace where I won't have to look at yet another screen. > > [1] Splitting into the "core" developers (ie those paid/compensated for > > participating) and an endless summer of newbs seeking help/support; > > the middle gets completely hollowed out. FWIW, I stand by this analogy. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Thu, Apr 20, 2023 at 07:21:54PM -0400, Simo Sorce wrote: > Hi Matthew, you say: "We're missing people", and I think, "who?". > And who are you going to miss if you move to discourse? Again and again I have seen this "we're missing people" sentiment be used to justify scrapping "old" workflows, and *not once* has it ever resulted in "more people" coming out of the woodwork that would have happily contributed in the past, but were turned off/away by the need to use archaic email. (FFS, If we're going to follow this to its logical conclusion, we should just scrap all of this email/discourse/whatever and just move everything to github, or even facebook, as that's clearly where the most numbers of people are. "but no, our custom tooling makes things better for us" is the inevitable pushback, which arguably applies just as much to email-based flows!) > The mailing list make messages land in my client, on which I am very > efficient, therefore I can check all messages once a day, and respond > if I find a worthy topic. ...and the very nature of Discourse or various other Forums pretty much make this sort of workflow impossible; that is to say you're all but forced to manually poll every site you care about in a way that all but makes automation impossible. In other words, it's locally optimal for any given site, but is utterly incapable of scaling if you care about more than a small handful of sites. Calling myself semi-active here would be quite generous, but I can uneqvocibly state that if I have to manually poll a discourse site or whatever, that will be the end of my participating in anything Fedora, except to report bugs via abrt (assuming I don't have to keep logging in for new API keys) I suspect I'm far from the only one in that respect. > Unless this discourse has some great mail bridge (it doesn't) or maybe > an rss feed (I do not use those at work, but I guess I could ?) So > that I can skim messages on my terms, I think I (and those like me) > will be the next "missing people". RSS doesn't scale for higher volumes unless you're literally polling every few minutes or the feed includes a large number of entries. > Btw I could make exactly the same quote about any forum that Major made > for Mailing lists, messy discussions are messy and a forum does not > make them easier to follow by any means (perhaps except for those that > chose inferior email readers). Yeah. > Your own post communicates to me (whether you intended it or not) that > in the end the thread that will be generated by this post won't matter, > because this is just a courtesy post and you already think that the > opinion of the "minority of self selected mailing list lovers and > dinosaurs" does not matter much. Unfortunately, I have to agree with this perception. Perhaps it's because I've seen so many other formerly e-mail based communities bifrucate [1] chasing after "engagagement" that never occurs, or even RH/Fedora's near-perfect abysmal record of framing core infrastructure changes like this as a "discussion" when the decision has already been made and will happen no matter what the masses have to say about it. At the end of the day, distro development, like most other infrastructure, isn't sexy or glamorous, and the humongous effort that goes into it is rarely rewarded with anything other than abuse. "Who cares about distros? I just use Docker containers!" [1] Splitting into the "core" developers (ie those paid/compensated for participating) and an endless summer of newbs seeking help/support; the middle gets completely hollowed out. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changes to Bugzilla API key requirements
On Fri, Feb 24, 2023 at 05:55:55AM +0100, Kevin Kofler via devel wrote: > Ah right, I had forgotten about that issue. I do not think I will ever > understand the fascination some projects have for JIRA. It is proprietary, > and IMHO the web UI for users to report bugs in JIRA is very confusing at > times. (The Bugzilla one can be confusing at times as well, but at least it > is familiarly confusing. ;-) ) Middle management *LOVES LOVES LOVES* Jira. As for everyone else... let's just say that it's not repeatable in polite company. (I admit I'm surprised that "Free Software for Everything" Red Hat is chosing to base something so fundamental to their business on a highly proprietary tool. I suppose O365 is just a matter of time...) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Test upgrades from F37 to F38 - it will take you just a minute
On Wed, Feb 22, 2023 at 10:30:40AM +0100, Miroslav Suchý wrote: > dnf --releasever=38 --setopt=module_platform_id=platform:f38 \ > --enablerepo=updates-testing \ > $(rpm -q fedora-repos-modular >/dev/null && echo > --enablerepo=updates-testing-modular) \ > --assumeno distro-sync F36 snowflake server: Error: Problem: package python3-PyDrive-1.3.1-19.fc36.noarch requires python(abi) = 3.10, but none of the providers can be installed - python3-3.10.9-1.fc36.x86_64 does not belong to a distupgrade repository - problem with installed package python3-PyDrive-1.3.1-19.fc36.noarch (as an aside, this is the cleanest upgrade I can remember this server seeing...) F37 workstation: Error: Problem 1: package opencolorio1-1.1.1-3.fc37.x86_64 requires libyaml-cpp.so.0.6()(64bit), but none of the providers can be installed - yaml-cpp-0.6.3-7.fc37.x86_64 does not belong to a distupgrade repository - problem with installed package opencolorio1-1.1.1-3.fc37.x86_64 Problem 2: package blender-1:3.4.1-11.fc38.x86_64 requires libembree3.so.3()(64bit), but none of the providers can be installed - problem with installed package blender-1:3.4.1-2.fc37.x86_64 - embree-3.13.5-3.fc37.x86_64 does not belong to a distupgrade repository - blender-1:3.4.1-2.fc37.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) F37 laptop: Success, but with these downgrades: fwupd x86_64 1.8.10-1.fc38fedora 1.8 M fwupd-plugin-flashrom x86_64 1.8.10-1.fc38fedora 26 k fwupd-plugin-modem-manager x86_64 1.8.10-1.fc38fedora 60 k fwupd-plugin-uefi-capsule-data x86_64 1.8.10-1.fc38fedora 1.8 M inxinoarch 3.3.24-2.fc38fedora 493 k libmsi1 x86_64 0.101.32-3.fc36 fedora 110 k msitoolsx86_64 0.101.32-3.fc36 fedora 551 k python3-xlsxwriter noarch 3.0.7-1.fc38 fedora 327 k F37 server #1 & #2 Success! (same fwupd downgrade as above) I have a few other systems but they're buried/offline in preparation for a home office move. Only one that's remotely unusual is an RPi3. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changes to Bugzilla API key requirements
On Wed, Feb 22, 2023 at 10:46:12AM -0500, Ben Cotton wrote: > Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You > must replace your API keys at least once a year. Additionally, any API > key that is not used for 30 days will be suspended but can be > re-enabled on the account's preferences tab. I suspect this is going to lead to a lot of grumbling roughly every six months, as there's likely to be big spikes in abrt-generated stuff after each Fedora release. Or every three-ish months as major new kernels come out. Or, more likely, this is going to lead to far fewer ABRT submissions from folks that aren't actively developing/maintaining Fedora, as "I have to log in *yet again* to get ABRT to work" adds a signigficant impediment to the former "set it up once and forget" status quo. (It's not like we have any meaningful control over how often ABRT is tripped and needs to send a report to the mothership...) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
