Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Am Mittwoch, 24. Juli 2024 02:52:44 CEST schrieb Gary Buhrmaster: On Tue, Jul 23, 2024 at 10:38 PM Kevin Kofler via devel wrote: And this one is yet another case of FESCo rubberstamping a change without even any dissenting vote despite loads of negative mailing list feedback. How can one determine "loads"? Since the feedback itself is opt-in, no statistically valid conclusion can be reached based on the feedback received(*). FESCo needs to review the feedback that was received, and use their best judgement as to whether to approve or disapprove, and no one should expect there to be a dissenting vote just because of negative feedback. I would actually expect FESCo to unanimously vote against the feature if the feedback on the mailing list is overwhelmingly negative. Or at least a majority of FESCo, if it is controversial. But unanimous approval shows that the feedback on the mailing list has been completely ignored, making the feedback process entirely useless. (*) And in addition, there is lots of cases where only those with negative feedback will decide to "opt-in" to offer an opinion, as they are motivated. If there are not enough people motivated enough to comment in favor of the Change, this shows that the Change is not valuable enough to be implemented. If in addition, enough people object to the Change for good reasons, it follows that the Change should be rejected. The big issue with the process is that there is this ground assumption in Fedora that change is inherently good, and hence any Change should be approved by default. But IMHO, Fedora used to already be almost perfect, to the point where changing anything could only possibly make it worse. And, again IMHO, make it worse the Changes did. Some Changes globally increased the size of the distribution (though admittedly a lot of the creeping bloat also comes from upstream feature creep beyond the Fedora Project's control). Some Changes needlessly broke backwards compatibility, making existing software users were still relying on suddenly break. (The "Retire Python 2.7" Change is in that category.) Some Changes replaced working technologies with incomplete and/or buggy replacements that do not work for users' workflows. Sometimes, an opt-out is possible (and then I end up opting out on my machines more often than not, making my setup diverge more and more from the default), sometimes the replacement is unconditionally forced onto all users (and sometimes the opt-out gets silently discontinued in a later release without even a new Change). Some Changes were about gradually making native distribution packages second-class citizens, second to inferior technologies such as atomic images, containerized applications (Flatpak, Docker, …), etc. Some Changes are a threat to users' privacy. (The "Opt-In Metrics for Fedora Workstation" Change is in that category. All the more if the opt-in process uses the planned weasel wording to trick users into "opting in".) Some Changes are a threat to users' freedom, e.g., by offering proprietary software for download through various means. And there are probably more reasons I and others objected to Changes. Those objections were unfortunately never treated by FESCo as a reason to reject the Change. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Am Mittwoch, 24. Juli 2024 02:41:12 CEST schrieb Gary Buhrmaster: And, FWIW, it appears that qtwebkit has been FTBFS since F39, so qtwebkit could end up being a moot point. It built fine in the F39 mass rebuild, only started failing in the F40 one. So it is NOT in the list of packages to be retired in this cycle. I will try to fix the FTBFS ASAP, but the unilateral removal of Python 2 is going to make it a lot harder to get this package to build again. The current error is just due to an incompatible libxslt change requiring a "const" to be added somewhere: https://bugzilla.redhat.com/show_bug.cgi?id=2261634#c4 Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Zbigniew Jędrzejewski-Szmek wrote: > #3242 Change: Opt-In Metrics for Fedora Workstation > https://pagure.io/fesco/issue/3242 > APPROVED (+6, 0, 0) And this one is yet another case of FESCo rubberstamping a change without even any dissenting vote despite loads of negative mailing list feedback. I really wonder what we give feedback for at all if FESCo OKs any and all changes (except ones that propose to replace GNOME as the default desktop environment) anyway. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
Zbigniew Jędrzejewski-Szmek wrote: > #3244 Change: Retire Python 2.7 > https://pagure.io/fesco/issue/3244 > APPROVED (+8, 0, 0) This is going to break the build of a whole bunch of compatibility packages, which will in turn break a lot of software in Fedora. Do you expect packages to do what Qt5WebEngine did for EPEL and bundle their own copy of Python 2 to be used at build time? This just does not make any sense whatsoever. For Qt5WebEngine, there is now a patch from Arch Linux to make it build with Python 3 that we could apply, but both the Qt 4 and 5 QtWebKit require Python 2 to build. As do several other packages, I am pretty sure. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
Julian Sikorski wrote: > Germany uses their own implementation too: > https://src.fedoraproject.org/rpms/AusweisApp2 > To add insult to injury, it requires the use of custom EC curves, which > are bound to stop working at any moment: > https://bugzilla.redhat.com/show_bug.cgi?id=2259403 At which point you should probably just bundle a static OpenSSL with AusweisApp2. As unfortunate as it is, there appears to be little other choice to keep the package running here, and bundling forked libraries is no longer against Fedora packaging guidelines. And there are other packages already bundling forked versions of OpenSSL (e.g., Chromium and derivatives all bundle some version of "BoringSSL"). And at least the German stuff (and the Italian, Portuguese, and Estonian ones) is Free Software. The Austrian ID Austria app is entirely proprietary. Though, as far as I know, you can buy physical FIDO2 hardware, then go register that with the ID Austria office, and then log in on the ID Austria website with any FIDO2 enabled browser and the hardware you bought. But the default workflow goes through a proprietary smartphone app. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
Marián Konček wrote: > I had the same question and I don't exactly remember the most important > reason, but it was something like there were large differences between > versions which made the builds more difficult. Now I see it also uses > Kotlin, maybe that is also a reason. Upstream projects tend to just > bundle their own Gradle with them for building. Bootstrapping is one issue. As you noticed, Gradle now depends on Kotlin, which in turn requires Gradle to build, a circular dependency. Another is that, as was already mentioned by Fabio Valentini, neither Gradle projects nor Gradle itself are designed to be built without Internet access, which is a requirement for Fedora. Upstream's (Google's) idea of bootstrapping is that Gradle just downloads prebuilt JARs of all the dependencies from the Internet at build time, which violates both the "no Internet access" and the "no binary blobs" rule in Fedora. The first of which is a requirement for the package to build at all in Koji, the second a MUST-level Packaging Guideline. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
Germano Massullo wrote: > 1. please switch to CMake build system completely: some parts of the > software need to be built through Eclipse, I.E. cie-pkcs11. CMake should > be the only build system in the project. CMake will also enable CIE > Middleware being built for all Linux distributions, Mac OS, Windows; As much as I like CMake, I would not recommend it here. CMake has only limited support for Java. Maven (mvn) makes more sense to use here. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
Germano Massullo wrote: > It worths also mentioning that both the Windows and Mac OS versions do > not contain any Java source. > Moreover, the Windows version contains some C# sources > https://github.com/italia/cie-middleware > and the Mac OS version contains some Objective C sources > https://github.com/italia/cie-middleware-macos > They should have just used Qt libraries like the Estonian ID card > software stack > https://github.com/open-eid This implementation looks like they just had the requirement to make a "Linux version" on their requirement sheet, but no actual GNU/Linux developers. So they just used what they knew, which unfortunately is Java. Whereas the proprietary operating systems get nice native applications in one of the operating system's preferred programming languages. Sad. I wonder whether unofficial software (e.g., a port of any of those 3 implementations to C++/Qt) would be allowed or whether there would be legal risks in attempting to use them. (Hopefully, at least exercising the Free Software rights under the license of the official software ought to be safe!) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
Marián Konček wrote: > You will do the others a great service if you use the English > language in GitHub commits and READMEs. I doubt this will be used outside of Italy, except perhaps by Italian citizens abroad (like me), who should also understand the Italian language. It looks like every single country does its own NIH solution for electronic identity cards, as Christian Le pointed out: Cristian Le wrote: > Re: Sergio, so far it seems all Italian, Portuguese and Estonian are > using different infrastructures. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The future Fedora Copr "rolling" chroot cleanup policy
Pavel Raiskup wrote: > Yes, I believe there are high chances to accept this (much harder will > to prioritize the feature). If you know what you are doing, the point > should not be to make the prolonging process click-expensive - which it > admittedly is now, if you maintain dozens of long-term projects. Note > that OTOH I still think that *we all* should actively push our users to > evacuate EOL Fedora releases. > > IMO, the point is to keep the maintainer active, and get the response > periodically. But sure, once we have the RFE, we'll have a proper place > to discuss it with the rest of the Copr team. OK, I have filed the RFE: https://github.com/fedora-copr/copr/issues/ I would have marked it with the RFE label, but I am not allowed to set labels as the reporter, only team members can do that. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The future Fedora Copr "rolling" chroot cleanup policy
Pavel Raiskup wrote: > Have you considered to submit an RFE for this "Extend All" feature? > I think this convenience button (or even with API, if reasonably easy to > implement) sounds like an acceptable compromise to me. I remember having once suggested that on this mailing list and having received a quite negative reply from a Copr team member, saying that they deliberately did not want to make it that easy to extend everything. But if you think the RFE has a serious chance of being considered, I can file one. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The future Fedora Copr "rolling" chroot cleanup policy
Pavel Raiskup wrote: > This is a gentle heads-up (at least a year in advance) that we plan to > address Fedora Copr storage consumption related to Fedora Rawhide > builds. Currently, Rawhide build results are kept indefinitely, but > this is going to change in the future. > > For the full story, see the blog post: > https://fedora-copr.github.io/posts/cleanup-rawhide-builds > > TL;DR: We plan to start monitoring build activity in Copr projects. > If no builds appear for a long time in these "rolling" chroots (such as > Fedora Rawhide), we'll disable such chroots, preserve the built results > for a while, and then delete them if no action is taken by the user. > > Hope this isn't going to cause too much inconvenience. Feel free to > discuss this here or under the blog post. So Copr is going even further with this broken approach of deleting user data to "address storage consumption". As I have already stated several times, deleting user data by default (on an opt-out basis) is NEVER acceptable. Even more so if the opt-out requires one to fight Copr's dark patterns deliberately making it a pain in the neck: One has to log into Copr every so often, and each time click a whole bunch of "Extend" buttons one at a time. There is no way to opt out permanently nor even for a longer time period than the default, nor even an "Extend All" button. The real issue still appears to be that "Disk storage is the commodity that incurs the highest cloud costs.", which means that cloud might not be the right technology to use here. Or at least the particular cloud implementation you are using (which last I checked was from Amazon). I understand that (also last I checked) the cloud infrastructure was donated to you for free. But that donation is not of much use if it does not include a workable amount of storage for something like Copr nor an offer to extend the storage at a reasonable price (which Amazon's list price is apparently not). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sbin-merge: what to do?
Kevin Fenzi wrote: > I guess you are talking about live images here? > > If so, they shouldn't need rpm as they don't install using it... The live images MUST contain the rpm executable because their contents are installed to disk (HDD/SSD/whatever) when installing the live image, and at that point, rpm is needed to update the system. There are also use cases where users want to install some package into the transient overlay in RAM, or even just run some rpm -q query on the running live image. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sbin-merge: what to do?
Zbigniew Jędrzejewski-Szmek wrote: > So… the question now: should I pull the plug on the change for F41, > dump the side tag, Yes please! > and try again for F42? No thanks! Please just dump this broken idea into the trashcan it belongs in. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sbin-merge: what to do?
Frank R Dana Jr. wrote: > I do not envy you this work. The documentation fallout alone... So WHY again are we doing this then? All this is achieving is causing breakage, for zero user-visible benefit. IMHO, the sbin merge should NOT be merged/pushed from the side tag into Rawhide. Instead, the changes should be reverted in dist-git and the Change dropped for F41 and forever. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
Kevin Kofler via devel wrote: > That said, it is not sufficient to reject adding Fedora downstream > spyware. Fedora also needs a policy that upstream "telemetry" spyware is > not allowed and needs to be disabled at compile time or patched out. We > have several packaged applications wanting to "phone home" for this kind > of "anonymized usage statistics". This should not be allowed in a > privacy-concious distribution. PS (sorry, just read this right now): The most recent offender: https://gladtech.social/@cuchaz/112775302929069283 (This is not the first anti-user misfeature Firefox has been implementing, but this one is particularly bad.) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intent to retire pkpgcounter
Ohms, Jannis wrote: > I Inherited a legacy Project using this tool to count pages. I use this > tool as part of a tea4cups hook . are you aware of any substitutes for > pkpgcounter There is this fork: https://github.com/berghetti/pkpgcounter-1 that at least claims to support Python 3. (It is a fork of the lynxis/pkpgcounter fork that adds Python 3 support, but the lynxis fork was abandoned and there is at least one showstopper bug that is not fixed there, as can be seen in the issues. That bug is fixed in the berghetti fork, at least I see the change that should fix the bug in the code changes in the commit history. Note that I have NOT tested any of the versions.) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
mkol...@redhat.com wrote: > To only change that could impact spins is that we would ideally like to > drop the X11-only libXklavier library we have used for keaboard > handling so far and replace it with the universal localed keyboard > handling API. IIRC Jiri Konecny already notified all spin owners and > started some discussions about this. Unfortunately, the "universal localed keyboard handling API" is not as universal as your wording appears to imply. At least, not yet. Historically, the API was primarily intended to set the systemwide default locale and the systemwide default keyboard layout, requiring a reboot to apply. So getting the changes picked up in real time is something the desktop has to support explicitly. (And that support may also have to be enabled explicitly, e.g., KWin requires the --locale1 option.) I also wonder how this is expected to work in a multi-user setup (where some users may want to use different locale, keyboard layout, etc. settings than the system default), though in the context of installation, that is probably a non-issue. This of course also affects installers other than Anaconda, e.g., see also the discussion under: https://github.com/calamares/calamares/pull/2180 Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
Michael Catanzaro wrote: > We don't have proposed wording yet. We should of course be reasonable > and not write something misleading, but I think the question should be > something along the lines of "help improve Fedora" (e.g. "Help improve > Fedora by sending anonymous usage data" plus maybe "Fedora will never > collect identifiable data"). I believe that that is exactly the kind of euphemistic wording that Gary Buhrmaster was worried about. At least it looks very much suggestive to me. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
Mattia Verga via devel wrote:
> BTW, it's not really different on how the kde-sig managed to drop x11
> support - they wanted to do so and they have not stopped until they got
> what they want, addressing most of the concerns raised by the community.
But the main concern was that the community does not want X11 dropped to
begin with, so there was no way to address that concern while still dropping
X11 support from Plasma. Which is also why there are now the separate -x11
packages I maintain.
It is pretty much the same here: The main concern here is that we do NOT
want ANY spyware ("metrics", "telemetry") in Fedora, neither opt-in nor opt-
out. No amount of changes to the proposal will address that concern. The
only reasonable course of action is to reject this Change with prejudice
(i.e., reject it with the clear understanding that any refilings will be
summarily rejected without even getting announced or discussed again – there
is no point in beating a dead horse).
That said, it is not sufficient to reject adding Fedora downstream spyware.
Fedora also needs a policy that upstream "telemetry" spyware is not allowed
and needs to be disabled at compile time or patched out. We have several
packaged applications wanting to "phone home" for this kind of "anonymized
usage statistics". This should not be allowed in a privacy-concious
distribution.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: libdisplay-info soname bump
Am Mittwoch, 3. Juli 2024 06:15:04 CEST schrieb Aleksei Bavshin: All the prep work has been finished and the side-tag is ready. Please, rebuild your packages with 'fedpkg build --target=f41-build-side-91835'. I have rebuilt kwin and kwin-x11 in the above side tag. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F411 Change Proposal: KDE Plasma Mobile Spin and Fedora Kinoite Mobile (Self-Contained)
Aoife Moloney wrote: > This change is for Fedora Linux 41, and not 411 as the typo in the heading > suggests :) Glad that we do not have to wait 185 years ((411-41)/2=185) for this feature. ;-) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance on individual packages requiring x86_64-v2 baseline ?
Gary Buhrmaster wrote: > Please provide your audited (by a 3rd party) data that shows > that MANY (i.e. significant percentage of) people on x86_64-v1 > users have a need for qemu. "Many people" was just an estimate considering that QEMU is a popular package, so it is more likely to be used in general than some obscure niche package, so it is also statistically more likely to be used on any particular class of hardware, even old hardware. Also, "many people" does NOT mean "significant percentage of", but a significant absolute number. If QEMU is used by, say, 1 million people, and, say, only 1% of those uses old "x86_64-v1" hardware (those are NOT actual numbers, just an example with hypothetical numbers to illustrate the computation involved, which is mathematically just a simple multiplication), that would still mean 1 users are affected, which fits my definition of "many people". But in the end, it does not matter. The policy is that ALL packages are supposed to comply with the distrowide baseline architecture, no matter how many or what percentage of users of the package actually use a computer old enough to support only the baseline. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Remove ifcfg support in NetworkManager (system-wide)
> This change proposal aims at removing NetworkManager support for ifcfg > files in Fedora. [snip] > * Proposal owners: drop the following packages: > ** `NetworkManager-initscripts-ifcfg-rh` containing the ifcfg plugin Huh? This contradicts the following paragraph in the simultaneously filed https://fedoraproject.org/wiki/Changes/NetworkScriptsRemoval: > Old ifcfg network configuration should still work thanks > to NetworkManager-initscripts-ifcfg-rh package. No > migration is needed, but it is recommended to migrate from > ifcfg to keyfiles configuration. So if this feature is also accepted for F41, the above paragraph will need to be updated. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance on individual packages requiring x86_64-v2 baseline ?
Daniel P. Berrangé wrote: > It isn't as simple as changing the CFLAGS. QEMU used to check for > the CPU feature at startup, set a flag, and then later use that flag > to choose different codepaths, but this logic was removed. Avoiding > the flag check in hot-paths makes a perf difference. > > So we would have to revert the whole patch series in Fedora. That's > doable today, but I'm not confident carrying a local only revert over > time. But it is the ONLY approach that is compatible with Fedora policies, and as such should be required. ESPECIALLY for a package like QEMU that many people are using. If forward-porting the reverts stops being doable, then we will have to keep the old version of QEMU or fork the project. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS-UP] GStreamer 1.24 landing in Fedora 40 soon
Fabio Valentini wrote: > We requested an exception to the Updates Policy, which was granted by > FESCo: https://pagure.io/fesco/issue/3204 Quoting from there: > Now the Multimedia SIG has been approached by GStreamer upstream > developers - why Fedora 40 is shipping without the latest version of > GStreamer (missing out on new features, big performance improvements for > GTK4-based video players, etc.). Uh, the last time an upstream has complained about "Fedora 40 is shipping without the latest version of" their software and "missing out on new features", it turned out that said "new features" mainly consisted of a dangerous backdoor (xz CVE-2024-3094)… Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to unretire and rename pyftpdlib
Sandro wrote: > I was probably overthinking this. In practice it will turn out to be a > new package submission indeed. Moreover, the last remaining active > branch of the retired package (F38) is now EOL. > > I've submitted the review [1] without any Obsoletes. Since we support upgrades from Fedora n to n+2, there SHOULD be Obsoletes in place until at least the F40 EOL. I would recommend just keeping the Obsoletes forever. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changing desktop file name in a stable release
Julian Sikorski wrote: > are there guidelines advising how to handle upstream desktop filename > change in a stable fedora release? For gnumeric I just followed upstream > [1], which led to a bug report [2]. Now I am facing similar situation > with pavucontrol [3]. Should I rename the desktop file to what it used > to be, or just forgo the updates altogether? Thanks in advance. The gnumeric bug report was about the icon .png getting renamed, not the .desktop file. I think it is OK if the .desktop file gets renamed during a release, but some people are probably going to complain there too. I guess that is what we have CLOSED NOTABUG for. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Debugging fun (wrt C modernization change)
Michael J Gruber wrote: >> %patchlist and %auto* should just go away, or at least banned from Fedora >> by a git hook rejecting such specfiles. > > We also have unnumbered patch source definition lines, don't we? IIRC, unnumbered Source: or Patch: just defaults to Source0: resp. Patch0:. But it should not be used. Use Source0/Patch0 instead. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: New Fedora Planet
Pedro Moura wrote: > To add blog posts in Fedora Planet you basically need to update RSS URL > field at https://accounts.fedoraproject.org/ Which means that basically all blogs are going to vanish from Fedora Planet unless people re-add them manually. There are 809 blogs on the old Planet Fedora, the new one currently has 30 (should be at least 31 soon when it picks up my RSS URL that I have just added to accounts.fedoraproject.org). That is less than 4%. More than 96% of the blogs will be gone. This is not helpful. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
Neal Gompa wrote: > I have the question of why is dnf5 running as if "--allow-erasing" is > always passed to it? Older versions of DNF explicitly didn't do that > because we get weird behaviors like this. Without --allow-erasing (which was actually passed explicitly, as Petr Pisar pointed out), the intended resolution: > a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and > remove add-determinism-nopython could also not possibly work because: > remove add-determinism-nopython Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Debugging fun (wrt C modernization change)
Panu Matilainen wrote: > Patch and source numbers start from zero, that goes for automatically > numbered patches too. So there's an off by one in the application, and > the latter %autopatch which is supposed to apply patches >= 2 simply has > nothing to do, and falls through silently. That's a bug of course in > itself, filed now: > https://github.com/rpm-software-management/rpm/issues/3093 And then they say the automagic is a good idea because it prevents people from accidentally forgetting to apply a patch, LOL. %patchlist and %auto* should just go away, or at least banned from Fedora by a git hook rejecting such specfiles. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Adam Williamson wrote:
> The shortest syntax is just to use Patch: foo.patch , and %autosetup .
That is not a syntax to apply a patch, it is an automagic that blindly
applies all patches in numeric order. Cannot reorder patches, cannot apply
them conditionally (e.g., based on the 0%{?fedora} version), cannot specify
a -b backup file extension for each patch. So it is not a fair comparison.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Florian Festi wrote: > We have an even easier solution for you: You can just run the script at > [3] with -n on your own spec files to get them changed to the %patch N > variant. If you do that right now they will not break nor will they be > touched during the mass change. > > As I said the %patch -PN syntax is the one with the best compatibility - > reaching back into the dark ages. I am not advocating for people to use > it. Anyone is free and encouraged to move to something more modern - > before or after the change. We are using this variant so spec files > continue to work on older distributions and the chance of breakage is > minimized. This way packagers that don't care don't have to. What I do not understand is why RPM is discontinuing the most commonly used syntax and breaking hundreds of specfiles. This also leaves us with only the choice between a backwards-incompatible syntax (added only in RPM 4.18) and an ugly and redundantly verbose syntax (the -P syntax). And even the modern syntax is 1 character (space) longer for every patch. The shortest syntax was the one being dropped. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Neal Gompa wrote: > On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel > wrote: >> >> Am 06.05.24 um 13:56 schrieb Florian Festi: >> > Hi everyone, >> > >> > RPM has deprecated the %patchN syntax in favor of %patch -PN where N is >> > the patch number for a year now. See the RPM documentation for more >> > information [1]. In current RPM versions, this syntax only emits a >> > deprecation warning, but support for this syntax has been removed >> > completely in the upcoming RPM 4.20 release. As it will be added in >> > Fedora soon [2] it is time to switch over to the new syntax now. >> > >> > There are around 1800 packages that still use the old syntax. Later >> > this week/next week, we will run this script [3] over the affected >> > packages >> > [4][5] to update them to the modern patch syntax. For example, the >> > script will change: >> > >> > %patch0 -p1 → %patch -P0 -p1 >> > %patch0005 -p2 → %patch -P0005 -p2 >> > >> >> >> Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)? >> > > Yes. It's been supported for a very long time. %patch -P is already documented in the 1997 First Edition of Maximum RPM. Here is the link in the 2000 online edition: https://ftp.osuosl.org/pub/rpm/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-WHICH-PATCH-TAG Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
Carlos Rodriguez-Fernandez wrote: > How could that be expressed so that those are caught quickly at build > time? Someone wants to depend on a java lib that has been tested only in > JRE 8 to 11, but wants to build the package with JRE 17+, or vice-versa, > for example. Perhaps, the only feasible way to detect that case is with > CI. IMHO, the library should have a: Requires: (java-devel >= 1:8 with java-devel < 1:11) Sure, this will not per se prevent you from attempting to use the library with the Java 17 compiler, but if you do not have Java 8 or 11 installed, installing the library attempting to install it as a dependency should raise a red flag. As a quick check, you could write a specfile for your application with: BuildRequires: java-devel >= 1:17 BuildConflicts: java-devel < 1:17 and then run mock on that. The latter line should prevent the old version from being installed in parallel. One annoyance is that older OpenJDK packages currently drop that virtual Provides, presumably in an attempt to get all Java packages systematically built with a newer JDK. That is something that ought to get fixed. (If we switch to building with the oldest possible Java as I suggest, it will have to get fixed anyway.) As is, you may need to explicitly: BuildConflicts: java-1.8.0-devel BuildConflicts: java-11-devel Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
Christopher wrote: > So, I actually think that building with the *latest* JDK that we ship, > and using the `--release` flag during compilation is actually safer > than building against the lowest that we support, because it is most > likely to strictly enforce correct byte code generation for the target > JRE. The problem is, without ALSO installing the JDK for the targeted version AND explicitly pointing -bootclasspath to that JDK, this does NOT catch code trying to use class library features (as opposed to language or bytecode features) from the newer JDK, and worse, in rare occasions, even if the source code is in principle compatible with the targeted older Java, when compiled with a newer compiler and older target release, it will fail to actually run (!) with the latter (because the compiler picks up a subclass override of a method added in the newer Java instead of the baseclass method that was always available and, for performance reasons, tries calling the override explicitly rather than going through the virtual method lookup). One example of that latter issue is NetBeans, where versions 12.5 and 12.6 were supposed to be compatible with Java 8, but some upstream-published binaries of 12.5 and all of 12.6 do not actually work properly on it because they were built with Java 11 in "-release 8" mode: some editor features fail with runtime exceptions. See https://issues.apache.org/jira/browse/NETBEANS-6349 for details. (They "fixed" it by just requiring Java 11 in NetBeans 13 and newer. No fixed 12.x release was ever issued.) So I am AGAINST systematically using "-release" without "-bootclasspath", even though that works in most cases and is often successfully used in production (me and my employer use it, too, but on projects we control where we will fix the source code or add a workaround to it if any issues come up from that, not systematically on repackaging third-party projects). The compiler even warns about the missing "-bootclasspath". And the potential to cause subtle misbehavior that is a pain to debug is just too high, especially if we have the actual older JDK available and could just BuildRequire the correct version. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
Carlos Rodriguez-Fernandez wrote: > Regarding the proposal as a whole, I think the proposal idea makes a lot > of sense, but for apps depending on system jar libraries, there should > be a way to specify that the app depends on a specific java bytecode > version range. System libraries packages could provide compatibility > packages, so couldn't those apps just depend on those compatibility > packages instead? That can become a maintenance burden for those libs, > though. The safest approach for library JARs would be to always build them against the lowest possible Java version (the oldest JDK branch that we still ship if the library supports that, otherwise the oldest the library supports). And IMHO, if the library is built against a higher version than the lowest we ship, it needs a versioned Requires on the JRE. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: pipenv removal in F40
Miro Hrončok wrote: > If you wish to help, I guess you can send a pull request to the release > notes... Or Mattia could simply unretire and adopt the package. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: how to do minor bump using %autorelease?
Fabio Valentini wrote: > No, that's just wrong. > The "upgrade path" (wrt/ NVRs) is no longer enforced across release > boundaries. AFAIK, all supported release-upgrade methods now use > distro-sync or something equivalent, so NVR-based "upgrade path" is just > not important any more. That just does not make sense: We enforce upgrade paths from Rawhide to Rawhide (!) requiring lots of unnecessary Epoch bumps when things need to be reverted (which is normal for a development running release), but we happily allow the ones that actually matter to end users to break? All this just so that lazy packagers do not have to increment a number (in most cases a single-character change, in some cases (such as a minor bump or every 10 major bumps) a two-character change, rarely more) when doing a new build. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: how to do minor bump using %autorelease?
Michael J Gruber wrote:
> A minor bump (as in %{?dist}[.]) only comes into play
> if a "lower" branch needs to move forward without creating a version
> ahead of a "higher" branch. And (independent of autorelease) you cannot
> do that unless you use divergent git branches and cherry-picks in
> dist-git, in which case "version" makes sense per branch only anyways.
But Release MUST maintain the upgrade path from one release to the next.
Also, no, you do not necessarily need to allow the branches to diverge. If
you keep your branches fast-forwarded, you can just fast-forward the
"rebuild for libfoo in Fn" commit with the minor bump to all branches, but
build it only in the fn branch where it is relevant. The minor bump ensures
that doing that maintains the correct upgrade path, so you do not have to
push unnecessary rebuilds to releases where it is not relevant.
> In a dist-git where you work with release branches "contained" in
> rawhide - and use macros extensively - you automatically have commits
> which you merge down but which don't affect all branches, e.g. rebuild
> commits for dependencies or mass rebuilds. I'm not saying this is the best
> way of doing things (we should do it differently), but it's a common
> pattern. So you can have the "f40 mass rebuild" commit in an f39 branch.
> And in a world where you have and accept that, you can also push a
> "rebuild for libfoo" to rawhide and merge down to f40 if that is what
> you need to have f40 versions <= rawhide versions.
Sure, but as I explained above, this only works properly if you do a minor
bump rather than a full bump to Release. Otherwise you have to rebuild
everywhere or you break the upgrade path.
> But as others have pointed out, in the light of distrosync and
> macro-determined differences etc. we may just as well give up the
> illusion that "-5" means the same in different branches, and
> consequently lift the sorting policy between different branches.
But that breaks the upgrade path, so it is a no go.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: how to do minor bump using %autorelease?
Julian Sikorski wrote: > I need to rebuild mame on F40 only for qt-6.7. On rawhide, > mame-0.265-1.fc41 is already built against it so I only need to build > mame-0.265-1.fc40.1. Can it be done using %autorelease? No, which is why you should not be using %autorelease. I would just replace %autorelease with a correctly manually bumped Release in the specfile as part of doing the rebuild. Just letting %autorelease do its thing and ending up with a full bump would be incorrect, so it should not even be considered as an option. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: systemd 256~rc1 in rawhide
Adam Williamson wrote: > Well, it really wants to write to /lib , not to /usr. But of course, on > Fedora, /lib is /usr/lib . Sigh… Time for a UsrUnmerge? :-) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is there a policy for branches being merged or not
Julian Sikorski wrote:
> In this case defaulting to cherry-picking would be a safer bet. Branches
> unintentionally separated can be merged, but branches unintentionally
> merged cannot be unmerged.
This is only true if you are talking about merge-commit merges. Not if we
are keeping the branches fast-forwarded (and using %{?fedora} conditionals
in the rare event something really needs to differ between the releases). A
linear history cannot be remade truly linear once it was diverged by a
cherry-pick (or simply a separate bump from running rpmdev-bumpspec
separately on each branch, as scripted rebuilds often do). The best we can
do to restore fast-forwardability is to merge one way and then "merge back",
which will fast-forward the other branch to the same merge commit. This
still leaves an ugly knot in the history, but at least the branches can then
be fast-forwarded again. But a clean linear history is no longer possible
after someone did an unwanted cherry pick instead of a fast-forward merge.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
David Abdurachmanov wrote: > We currently use a symlink (as Richard) mentioned, but it's not ideal > and causes problems (e.g. meson generates wrong paths breaking some > packages [one example: libplacebo]). Which I would say is a bug in Meson and should be fixed there. I do not think having /usr/lib64/lp64d be a symlink to /usr/lib64 is in violation of any standard. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)
Nathan Scott wrote: > - it could be advantageous if the new compat sub-package contained > the redis binary symlinks & not the primary valkey package (this could > allow valkey and redict packages to coexist, for example). Long-term > we may want to drop those entirely (along with the compat package, to > complete the transition away from Redis). I do not see why we need a separate compat subpackage at all. Valkey should just Obsolete/Provide redis and include all the compat symlinks in the main package. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Kilian Hanich via devel wrote: > The fact that you can share the keys is actually part of the design and > wanted. Apple for exmaple has (or wants to) implement easy sharing of > passkeys via AirDrop. So the Apple Cloud can see your private key, but you cannot? Sounds like GREAT "security", LOL… Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Gary Buhrmaster wrote: > [2] As I understand it, the issue is the > lack of the required trusted environment > in generic Linux. There are software > implementations that do not have the > hardware enclave protections, And to be honest, I do not see the problem there. I will use whatever will let me pass the Fedora security theater checks without investing in extra hardware. (This also means that if I am offered the choice, I will pick TOTP over FIDO2 any day, because TOTP does not require me to emulate a fake hardware crypto device like FIDO2 does.) And in my view, the fact that, in those implementations, there is no Treacherous Computing hardware preventing me from doing what I want with my own private key (e.g., just copying the same key to all my devices, as I can also do with TOTP) is actually a feature, even if it goes against the "security" model. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
Richard W.M. Jones wrote: > As gcc -Os was mentioned too, that is -O2 with the following > optimizations disabled: > > -falign-functions -falign-jumps > -falign-labels -falign-loops > -fprefetch-loop-arrays -freorder-blocks-algorithm=stc Last I checked, there were also some hardcoded if (optimize_size) peppered throughout various GCC optimizations and even target files (to choose between faster or smaller instructions). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
Neal Gompa wrote: > I would like for us to consider evaluating a global change to -O3. I > am not convinced that there's a good reason anymore to remain at -O2. > > If we get this kind of benefit from Python, I would be interested in > seeing what we'd get elsewhere. How much larger is Python at -O3 compared to -O2? And other packages? I would like to see -Os as the default. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Adam Williamson wrote: > Also, these days, most authenticator apps support some kind of backup > mechanism. FreeOTP lets you back up to a file (which you should, of > course, keep somewhere safe and ideally encrypted). Google > Authenticator can backup To The Cloud. If you use Keysmith, you can just SFTP your ~/.config/org.kde.keysmith/Keysmith.conf from/to all your GNU/Linux computers including the PinePhone or equivalent, and they will all be able to generate the same TOTP keys with the same master key. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Zbigniew Jędrzejewski-Szmek wrote: > So… this is what I'm talking about: there is no obvious way to > figure out what to set. Looking at the logs and trying to figure out > some variables from that is not very attractive. The comments at the top of the relevant Find*.cmake module are the best source for which variables you are supposed to set directly. But there is also cmake-gui that can show you all the available options in a pretty Qt GUI. > Nevertheless, for me, CMake and autotools are outdated technologies > that shouldn't be used in new projects. And for me, Meson is just a poor Not Invented Here imitation of CMake, with fewer features and in a slower programming language. :-) And the kind of automagic you complain about is something all 3 major build systems do (and plenty of obscure ones, too). Maybe not for the specific case of the Python executable, but there are plenty of other cases where autotools and Meson also do automagic, which is why building outside of a chroot is such a bad idea. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
Zbigniew Jędrzejewski-Szmek wrote: > And sorry, but saying to "process pull requests quickly" is just naive. > Busy packages often have many different pull requests concurrently, and > some of them need discussion and fixes and work in other places before > they can be merged. Generally, there should be no room for discussion there. Either the pull request is good, then merge it immediately, or it is not, then reject it immediately. People who want to contribute to Fedora packaging ought to know what they are doing, if not, just reject and let them submit a new pull request when they have done their homework. > I guess we'll just have to agree to disagree. In the other part of the > thread, a proposal that was floated to allow opt-out. I hope that's > acceptable. You have received a lot of all-negative feedback and one single message of support. So for me there is a clear consensus to NOT implement your proposal at all, not even with an opt-out option. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
Zbigniew Jędrzejewski-Szmek wrote: > I'm revisting the topic of rpmautospec because I was doing some work > on various packages, and it's annoying that some packages are using > rpmautospec and others are not. The fix for that inconsistency would be to ban rpmautospec. It just makes everything more complicated. > All my packages have been converted, so in day-to-day work, I don't > even think about %changelog. When working with other packages, I'll > forget to update the Relase and/or %changelog. Today I was rebasing > some pull requests in pagure, and the _only_ conflicts that I had were > about Release and %changelog. Generally, it helps to keep all your branches in sync (and with that, I mean, fast-forwarded to the exact same commit hash – no, it is not a problem if the changelog for a Fedora release includes an entry for a Rawhide mass rebuild made after that Fedora release branched, it explains why the Release number has increased and is otherwise harmless) if you are building the same versions for all releases (which is typically the one case where you bother backporting specfile updates across releases at all), and to process pull requests quickly, before you or rel-eng or another pull request bump the specfile in Rawhide. Then you rarely have conflicts in %changelog to begin with. > I think it's time to switch to rpmautospec completely. > Thus, the proposal: > - new packages MUST use rpmautospec > - packagers SHOULD convert their packages > - provenpackagers MAY convert existing packages > (e.g. when they want to push some fix or separately from other >work) > - people submitting pull requests against src.fp.o MAY also > include a conversion in the pull request and packagers SHOULD > merge it. I am opposed to every part of this proposal. Allowing provenpackagers to convert existing packages (that they do not explicitly comaintain) would be particularly rude. I do NOT want any of this automagic (also the various %auto* macros such as %autosetup) in my specfiles, it just makes my life harder for no benefit whatsoever. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
Emmanuel Seyman wrote: > I've noticed a trend in proposed changes in the way Fedora works. I am fed up of this salami tactic as well. When we complain about the new stuff, we invariably get told "don't worry, you don't have to use it, it's all optional", but the plan is always to make it mandatory later. See also 2FA that they are now trying to force on us, taking as an excuse an incident that was demonstrably NOT stopped by 2FA. > They start off as as things packagers will not have to use if they do > not want to and, over time, become default/forced (Matrix vs IRC, To be fair, part of the blame there is to be put on Libera.Chat that unilaterally turned off their Matrix bridge. (Yes, they did give Matrix some time to address the demands they had, but when Matrix told them it was not feasible in such a short time frame, they just first suspended, then permanently blocked the Matrix bridge.) But, and here is where I blame Fedora, instead of just letting the chans on Libera.Chat die and moving everything to Matrix, they should have moved the IRC chans to a network with a working Matrix bridge, such as OFTC (or pretty much anything other than Libera.Chat – I guess even Freenode under its new owners might be an option), then we could still be happily using both technologies interoperably. Instead, we get told to just use Matrix and shut up, which I do not consider acceptable. > Discourse, ...). There too, I do not see why some discussions are now being directed to Discourse instead of the mailing list. And it is not even working. Most of the pertinent feedback for new Changes still comes on this list, not on Discourse. The developers use this list, Discourse is only for users who do not know how to use a mailing list. > Perhaps it's time to discuss imposing financial and/or legal penalties > when the opt-in nature of the change goes away. Who would impose those? And from whom to whom would the money flow? I do not think this can work. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
I wrote:
> On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> wrote:
>> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
>> detection of python, and it found /usr/bin/python3.13t that I have
>> installed, and subsequently it got all the paths wrong.
>
> That's why you should never build packages outside of mock.
PS: Autotools also loves to autodetect random libraries that happen to be
installed on the system. It is in no way specific to CMake.
>> How do I override this?
>> ('cmake -LAH' doesn't yield anything useful.)
Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake for
the variables it uses. (First, try to figure out whether RPM is using a
system-installed FindPython or its own custom version, so you look at the
correct version.) But the safest (for all build systems) is to always build
in a mock chroot with only the expected BuildRequires installed, as I have
written.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
That's why you should never build packages outside of mock.
Kevin Kofler
On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
wrote:
On Sat, Mar 30, 2024 at 10:15:47PM +, Zbigniew
Jędrzejewski-Szmek wrote:
One particular issue I have with CMake as a downstream maintainer is
it's often very hard to override linking or compilation options
or when the project is using one of the cmake find scripts that gets
something wrong… It's possible that those projects are "doing
cmake wrong",
but it seems that CMake makes it easy to do things wrong.
I just had to interact with CMake, so let's use that as example:
I'm rebuilding rpm.rpm with some local patches using 'fedpkg local'
in F40.
The build fails with:
Directory not found:
/home/zbyszek/rpmbuild/BUILDROOT/rpm-4.19.1.1-2.fc41.x86_64/usr/lib64/python3.12/site-packages/rpm
Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
detection of
python, and it found /usr/bin/python3.13t that I have installed, and
subsequently
it got all the paths wrong. How do I override this?
('cmake -LAH' doesn't yield anything useful.)
(When compiling a python module, any other alternative would be
better.
The build uses %python3, i.e. /usr/bin/python3.12, so there's no need
to detect anything, the location of python is known and all this
binary
can be called to print all paths. Otherwise, either call
'python3-config' or 'pkgconf python', don't do you own
reimplementation.)
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Peter Boy wrote: > Well, a switch from Gnome to KDE would require a lot of changes in > everyday applications, e.g. Mail. That is not required when you update > from Gnome 2 to Gnome 3. Well, in principle, GNOME applications will usually work under Plasma and the other way round. But in practice of course most default applications on the Edition would change along with the desktop environment. So if you are one of those users who never upgrades, but always reinstalls from scratch, or at least installs everything in the Edition's group on upgrades, you will be in for a few surprises indeed. > Provide a reliable solution which includes a non breaking evolvement of > the Edition. I would argue that people upgrading to a newer Fedora should just upgrade in place with the packages they have installed, ignoring the new defaults of the Edition, so they would remain on GNOME and GNOME applications if that is what the release they had initially installed was shipping. Though of course then there will be some people complaining that an upgraded Workstation is completely different from a freshly installed Workstation. But IMHO, that would be a feature, not a bug. > Too bad, an explicit scientific desktop edition might have helped me > propagate a Linux desktop in our University research cluster of excellence > a good decade ago. Scientific Linux for Servers was a great success. We tried, but it was deemed not distinctive enough to warrant an Edition, our application was rejected on those grounds. After all, it was still a desktop spin, just with some scientific applications preinstalled on top of it. So it was accepted just as yet another Spin (next to the regular KDE Spin), and eventually the Labs category was created for this and other use- case-specific (former) Spins. So a Scientific Spin (now Scientific Lab) did in fact exist around a decade ago, but maybe "a good decade ago" was slightly too early, just before it was created. In addition, there was also pushback against this suggested compromise (having the Plasma Edition be a Scientific Edition) from non-scientific KDE users who understandably did not want to have to install a Scientific Edition and then uninstall lots of niche apps they will never use from it. But that discussion became moot because the Edition application was rejected anyway. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Leslie Satenstein via devel wrote: > The Cellphone user is very comfortable with Gnome. So much so, that I > believe that if he was given KDE as the interface, two things would > happen. a) The user will switch to Gnome, or b) The user will find a way > to add his favourite applications to the desktop. b) is actually very easy on modern Plasma (I tried it on Plasma 5), just right-click on the application in the menu and click "Add to desktop" in the context menu. KDE upstream has long given up trying to deprecate desktop icons (as they tried to do in early Plasma 4 releases, though even those allowed you to put a folder view widget displaying the Desktop folder (and hence, icons) on the desktop). In Plasma 6, the desktop is always a folder view. Or the user can just switch the menu type to something icon-based and very similar to the menu in GNOME Shell with right-click on the menu button, "Show Alternatives…" and "Application Dashboard". And if the user really wants a smartphone UI with a smartphone-style menu, always-maximized windows, etc., they should use Plasma Mobile, not Plasma Desktop. But a customized Plasma Desktop as described above is probably a better fit for traditional desktop/notebook computers. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Tomasz Torcz wrote: > GNOME (Mutter) maximizes windows if they initially take 80% of more > screen space. And I believe that that, too, was a refinement added in later releases. IIRC, GNOME 3.0 just maximized everything. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Peter Boy wrote: > I'm probably not the right person to comment on this, because I completely > abandoned Fedora Desktop when it was hit (badly) by Gnome 3. That > destroyed my daily workflow and work routines and made it unusable (for > me), or at least barely usable for serious professional work not related > to software development (and I ended up using MacOS to this day). Which is exactly why I proposed back then to make Plasma (which actually operates more similarly to GNOME 2 than GNOME 3 does) the default. :-) >> == Summary == >> Switch the default desktop experience for Workstation to KDE Plasma. >> The GNOME desktop is moved to a separate spin / edition, retaining >> release-blocking status. > > This is an absolute no-go! It would break everyone’s usage of Fedora > Workstation It would be a major change, yes. Though not really different from the aforementioned upgrade to GNOME 3 with its completely redesigned user experience, which was also done. If Workstation were never allowed to change its user experience, it would be shipping MATE nowadays, not GNOME. > and is in irreconcilable contradiction to the characteristics of an > „Edition" as defined with Fedora.next. How so? > And that is not „just“ a technical issue (the FESCo domain), but a basic > Fedora principle. If you believe a basic Fedora principle is being violated, please bring that up with the Council. > Another proposal is to make it an „Edition“. But basically, a merely KDE > Desktop is not „edition-able“. Among others, an edition is meant to cover > a specific use case and a long-term and (more or less) perfectly designed > and engineered solution for this. So we have desktop (Workstation) and > server. Among server we have several Editions, the universal Fedora > Server, container centric CoreOS, edge centric IoT and Cloud. Each of the > server-like Editions covers a destined, specific use case without > overlapping. > > For the desktop area I don’t see a non-overlapping use case between Gnome > and KDE. It’s just a different tool for the same use case. This exact argument was already used 10 years ago to reject our (that was before I left the KDE SIG, though this issue was one of the triggers for me leaving the SIG) request for a Plasma Edition. 10 years later, we still have no way out of this dilemma. The definition of an Edition needs to be refined or completely replaced to get out of this catch-22. As part of the process to look for a non-overlapping use case, there was an attempt to focus specifically on scientific applications, which eventually lead to the Scientific Lab, but that did not make it to an Edition either, just to a Lab. The overlap issue is also going to hinder other deliverables' efforts to become Editions. E.g., Silverblue mostly overlaps with Workstation and CoreOS: Workstation for the general use cases (workstation/desktop usage), CoreOS for the atomic and container-oriented use cases. > And if we are willing to accept an exception and accept KDE desktop as an > Edition, I don’t see that the current SIG qualifies as an edition-capable > working group. Given the recent discussion about Wayland / X11, I don’t > see any obligation/commitment to ensure long-term reliability and > trouble-free usability. Instead, I see in the discussion an unbridled > desire to introduce something new (that's good) without regard for > backwards compatibility and uninterrupted usability (that's bad, we need > both). And obviously the resources to manage both (Wayland and X11) in one > working group are also lacking (and given the schism, possibly also the > willingness to do so). That particular concern, however, is one that I also share. The working group should be required to accept at least one of us plasma-workspace-x11 maintainers (it can be Sérgio M. Basto or Steven A. Falco if they do not accept me) into the working group. > That may change and can change, of course. But that’s nothing for F42, > rather for F52. It just requires creating a new working group. That can be done instantly. > This is a failure to understand (or to commit to) what we have decided to > do with Fedora.next. We don't want to DIY piece together a solution. But one of the big strengths of Fedora is that you can do exactly that. > And it is a plain false promise. You can't install CoreOS, IoT, silverblue > with it, not even Server, which is offered in the menu (because a lot of > presets are missing). The presets thing is something that should be fixed. Maybe an entry "server presets" in the list of checkboxes that will install a metapackage that then uses boolean Requires to drag in the individual preset packages for whatever the user actually installs during or after the installation. The inability to install an atomic system using Everything is inherent to what atomic systems are and what the Everything ISO is, and should be obvious to anyone who actually understands what they want to install. >
Re: Three steps we could take to make supply chain attacks a bit harder
I wrote: > That is exactly the problem with autotools code, almost nobody understands > what the heck it does, almost everybody just copies and pastes somebody > else's snippet hoping it does not do bad things. And gnulib is a > particularly ugly piece of the puzzle. PS: Here is a pretty good post summarizing the issues with autotools, both generally and in the context of the xz vulnerability: https://felipec.wordpress.com/2024/04/04/xz-backdoor-and-autotools-insanity/ Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Neal Gompa wrote: > By default, GNOME only presents the close window button. The other > buttons are missing, and there isn't really an intuitive way to > discover the other window management actions. In the version I tried, and judging from end user reports, for several years, it did not even present that, leading to fun issues such as some KDE dialogs that could not be closed at all (because they were missing a "Close" button and relying on the window decoration exclusively). >> "the shut down options in the mouse menu hidden behind a keyboard dead >> key, etc.)" this is also not the case for ages, or at least not in its >> completeness. > > Yes, this did change a few GNOME releases ago. Of course, having only tried GNOME 3 once, I could not know this. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Leon Fauster via devel wrote: > 10 minutes is not enough to do a remodeling of the "familiar" > experience, so that you reaches the so called realm of intuition. > The latter is something that we learn over time and the desktop > environment does not offer this on its own. It provides only a > framework where this can happen. But that is exactly the issue with the GNOME design: It is really arrogant to expect me to unlearn decades of learned familiar experience and retrain to something completely different that in the end has at most minor advantages, it is not significantly better, just different. I want the software to ideally behave the way I am used to (i.e., the way Windows 95 worked, see below) out of the box, or if not, at least have an "old-school mode" toggle in the preferences that makes it work that way (and I will almost certainly use that toggle). > PS: Imagine the first CLI steps and the corresponding bad > experience, but we have not given up :-)! Oh, my first computer was actually an XT clone running IBM PC-DOS 3.3. So I actually started with a CLI. :-) Then Windows 95 on a Pentium 120 (MHz). And on that Pentium, I also got started with versions of Red Hat Linux of the time (not sure what the first one was), first from CD-ROMs bundled with computer magazines, then the downloadable FTP edition. And I also tried one magazine CD-ROM with an edition of Caldera "OpenLinux" (which was actually much less open than RHL, and Caldera eventually became the infamous SCO) with the at the time brand new KDE 1 (version 1.1.1). Having used DOS, the bash CLI was not that bad to work with, but the distros at the time already came with GUI environments (FVWM95, then came KDE 1 and GNOME 1). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kilian Hanich via devel wrote: > About the release cycle: After the initial release of Plasma 6 when dust > has mostly settled down (approx. 2 point releases), they want to switch > over to a release cycle which would align (which is likely also the > reason why F42 was choosen in this proposal). Interesting point. And there I thought it was only because the answer is always 42. ;-) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Gordon Messmer wrote: > If RPM's ELF dependency generator were better, the importance of > stability would be debatable, but as it is, I really think Fedora should > be more stable than it is, especially for whatever it defines as "the > OS." Today, dnf/rpm will happily allow users to install an application > that will not run because that application actually depends on newer > versions of dependencies than are installed on the system. If a > significant portion of the standard desktop regularly rebased in the > middle of a release, I expect that would be a more common problem. Symbol versioning helps with this, because the ELF dependency generator extracts the symbol versions (though not the individual symbols, only the versions) that are required. And, e.g., Qt uses symbol versioning. The KDE packages also often have explicit versioned Requires on the dependencies where it matters. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Gordon Messmer wrote: > "When you are using the Linux mark pursuant to a sublicense, it should > never be used as a verb or noun. It should be used only as an adjective > followed by the generic name/noun. In other words, “Super Dooper Linux > OS” is okay, but “Super Dooper Linux” isn’t." > > https://www.linuxfoundation.org/legal/the-linux-mark Kinda the same recommendation that also applies to the Fedora trademark, by the way. But everyone only cares about their own trademark. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Aaron Rainbolt wrote: > Still, one could make some case for this. Plasma is, for one, obviously > going to be more familiar to newcomers to the Linux world simply by > virtue of the fact that the paradigms presented by its initial > configuration are more familiar to those coming from the Windows or > ChromeOS worlds, and (hopefully) those paradigms aren't sufficiently > different from MacOS to be too uncomfortable for a user coming from the > Apple world. You make a good point there. The thing is, GNOME tries really hard to design for new users, whom they define as a user who has never before used a computer. Such users are basically on the edge of extinction. A paradigm that works great for someone seeing a computer for the first time in their life does not necessarily work all that great for someone trained to use different paradigms used in the operating system(s) they have used for decades. As you point out, for users switching from a different operating system, which is a much more likely scenario, the GNOME Shell design is really confusing and disruptive, and GNOME's reluctance to make it easy to switch some things back (instead requiring you to install shell extensions for any such change) does not help. Even if the other operating systems' patterns happen to be counterintuitive if you have never seen them before, once trained to them, you will not only be able to work efficiently with them, but also be confused by GNOME's intuitive design that they carefully usability-tested on people with little to no computer experience. That leaves GNU/Linux power users who have used nothing but GNU/Linux for decades. I am in that category, like many regulars of this mailing list. (Well, I am particularly extreme in that even my smartphone runs GNU/Linux, but that is a different story.) And I would argue that GNOME is also a very bad default for users in that category because of its deliberate lack of configurability. Not to mention that the same (concept familiarity) concerns applying to people switching from other operating systems also apply to people switching from any other GNU/Linux desktop environment. Personally, when I tried GNOME 3 once, it took me less than 10 minutes to decide that this is just completely unusable for me personally. So I think it is pretty clear that we do NOT "have two equally good options" as Adam Williamson wrote (in the post to which you were replying). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Leon Fauster via devel wrote: > I already had RHL installed on a Sun IPX with Gnome, so I'm biased. Interesting that you were not put off by the changes that have happened to GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was actually pretty good. (It was very configurable back then. Remember when it shipped Enlightenment as the window manager, how many options that had?) Then GNOME 2 came, removing much of the configurability of GNOME 1. And then GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME 2, leading to a very hardcoded experience. GNOME 2 was already too much for me, and I switched back to KDE, back because I had already tried KDE 1.1.1 on another distro. And I have never looked back. Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it out once. But it took less than 10 minutes for me to realize that it is not for me. The user experience is just too unfamiliar (the unified application menu and open window selector (launch menu AND task bar replacement), the always maximized windows, the lack of a system tray, the shut down options in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does not make it easy for you to change it. (You can actually get a pretty standard desktop experience nowadays if you install a lot of "unbreak this", "unbreak that" GNOME Shell extensions, but that kinda defeats the point of GNOME.) The default experience felt pretty much unusable to me personally. KDE Plasma not only has more familiar defaults (actually looking and feeling much more similar to GNOME 1 than GNOME 3 does), but also lets you easily change those defaults that you do not like. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Stephen Smoogen wrote: > Downloads are very hard to measure because too many things are grabbing > everything from mirrors for different reasons. [Plus various people seem > to think manipulating the stats for their particular spin on the number of > downloads will make it more popular (I am looking at the several dozen ips > which were downloading the same spin every ten minutes). The countme > stats for 'running' systems > https://data-analysis.fedoraproject.org/csv-reports/countme/ can probably > give you the data on number of active systems. Countme stats do not tell you though how many of those users actually downloaded their Edition from fedoraproject.org vs. getting it preinstalled by some cloud/VPS/dedicated server provider. If people are not going to fedoraproject.org to download, say, the Cloud Edition or the Server Edition, then it is pointless to feature that particular Edition prominently on fedoraproject.org. That is why I was asking for download statistics specifically. And is there a statistical evaluation of that data somewhere? Downloading 350 MiB (!) of raw CSV data does not sound to me like a convenient way to work with it. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > Another route would be to go the Ubuntu route, if you really don't want to > stop having Workstation as the default: Spin (pun intended) the KDE spin > on it's own branding. Though I do understand that is an undertaking on > it's own. It would still be Fedora, about as much as Kubuntu is Ubuntu. > (Though, I don't know about 'Kedora' as it has absolutely no meaning XD) > Though I feel like we should really only go this route if the other ideas > get completely exhausted... That is what I tried with Kannolo. Success was… limited, to say the least. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Andreas Tunek wrote: > From Red Hat's POV it is not Fedora Gnome Workstation ( > https://blogs.gnome.org/uraeus/2020/05/07/gnome-is-not-the-default-for-fedora-workstation/ > ). TL;DR: "We do not want 'GNOME' in the name because we want to only support GNOME in Workstation, whereas 'GNOME Workstation' would imply that there are other Workstations." I am not sure I buy this argument. By the same argument, we should also not call the OS "Fedora Linux" because it implies there is also a "Fedora BSD" or "Fedora Hurd" or even "Fedora Windows" ;-) or something. Giving a product a clear name does not imply existence of another product. (And that is not even arguing the premise of the "one single Workstation that happens to use GNOME" concept, only the branding implications!) > One of the best things with Fedora Workstation is that it is a complete > user facing OS (like Windows, macOS and iOS) that you actually can develop > applications for (if you want to). You don't have to target the extremely > fluffy "Linux desktop", you can target Fedora Workstation. This proposal > would totally eliminate the good points of having this single OS and app > platform. That "conveniently" ignores the existence of that pesky thing called "other distributions". The GNU/Linux version of vendor lock-in. Thanks Red Hat! And besides, a standalone application (as opposed to a desktop widget or similar) developed for one of the Fedora desktop deliverables (Workstation Edition, desktop Spins) is also going to work on any of the others. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kevin Fenzi wrote: > to you? They are quite relevent to others... I would really like to see what the proportion of users downloading the Server, IoT, Cloud, and CoreOS Editions is compared to Workstation or the Spins. I would not expect it to be very high. Most Fedora users are desktop users. And server or cloud users will mostly install Fedora by picking "Fedora" in a combo box at their commercial cloud, VPS, and/or dedicated server provider's web interface, not from fedoraproject.org. I would be surprised if the percentage of users both running a home server or a private cloud (as opposed to a hosted commercial offering in a remote datacenter) AND picking Fedora as the OS to run on it (as opposed to a more conservative OS such as Rocky/Alma or Debian stable) were significant. CoreOS is also mostly a server thing, desktop users get pointed to Atomic Desktop variants (Silverblue/Kinoite/"… Atomic") instead. And IoT is just completely niche. So why do you expect those Editions to be more relevant to users downloading Fedora from fedoraproject.org than the Spins? Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Luis Correia wrote: > I'm mostly a user and I can accept a change from GNOME to KDE, IF and only > if I'm not forced to use Wayland. > > For me it isn't usable in my setup and most things are plain broken. As the maintainer of plasma-workspace-x11 and kwin-x11, I can assure you that that will not be the case. I have been through a whole FESCo debate just to be allowed to maintain those packages. 1. sudo dnf install plasma-workspace-x11 2. Select "Plasma (X11)" as the session type in your display manager. 3. Enjoy! (It is also possible to force SDDM to itself use X11 rather than Wayland, if even SDDM does not work properly under Wayland for you.) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Peter Boy wrote:
> We would be pretty silly if we did that. This differentiation and the
> associated quality and safeguarding criteria are a model for success and
> one of our differentiation criteria.
I think that is a quite pointless "differentiation criteria". Most users do
not even understand the difference between an "Edition" and a "Spin" or
"Lab". And technically, there is none. I do not see how Fedora's success has
anything to do with such an implementation detail.
All this differentiation achieves is creating first-class ("Edition") and
second-class ("Spin" or "Lab") spins, for no benefit whatsoever.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Joe Orton wrote: > Given that the ENGINE API is deprecated upstream since OpenSSL 3.0, the > API is optional upstream, and its use has produced compiler warnings > since it was introduced in Fedora 36, it seems perfectly reasonable to > disable this API in Fedora 41. I disagree. Disabling an API that is still widely used and for which there is still no complete replacement (several replies have pointed out issues still preventing "providers" from working in all use cases in which "engines" work) is NOT reasonable. > We have to deal with a very large numbers of FTBFS bugs from e.g. Python > API breaks every other release cycle, or the latest compiler flag > tuning. The fact that the transition creates work for other package > maintainers is obviously not a reasonable blocker for a Fedora Change. And that is exactly the kind of cultural issue we need to solve. The Python 3 transition is exactly an example of a transition that was handled horribly, kicking out lots of useful packages from Fedora just because they were not ported to Python 3. Python 2, or a fork like Tauthon (which has the advantage that it supports some Python 3 features, so some Python-3-only libraries / library versions can be backported to Tauthon more easily than to stock Python 2), should have been retained as a compatibility platform in Fedora. (There is technically still a "python27" package, but the modules available for it are intentionally limited and there are strict rules on what packages are allowed to depend on it.) It should NEVER be considered reasonable to break other people's work. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > Putting aside that i heard from Neal Gompa that anaconda cannot > accommodate a « multi-flavor » media, can you imagine how big that iso > would be? Forget 4gb, it’d probably be closer to 20gb! We used to have multiboot live images that let you pick the live image flavor to boot and then install. At one point (for one or two, maybe three, releases only, then came "Fedora.next" and the Ambassadors were pressured to hand out only "Workstation"), we even handed DVDs with those (yes, in those good old days, a multiboot live image still fit on a DVD… then bloat happened!) out at events. (I even did a custom one once for the Vienna event in May 2015, which dual-booted the latest Fedora 21 KDE live-respin with Plasma 4 and the Fedora 22 Beta KDE live with Plasma 5. I did not put Workstation on those because we had tons of pressed Fedora 21 Workstation DVDs anyway.) Unfortunately, the scripts that generated those were unable to keep up with all the complications caused by UEFI and so-called "Secure Boot". (They used to work back when everything still booted in legacy BIOS mode.) So some engineering effort will probably be needed, and a lot of testing on different hardware will definitely be needed, to make the multiboot generator work (reliably) again. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Eric Blake wrote: > The upstream autoconf discussion says that 'autoreconf -fi' behavior > on which 'serial NN' .m4 files to update is determined by automake, > not autoconf, in part inspired by semantics desired in gnulib. And > the automake and gnulib developers have argued that the upstream > behavior is intentional: > > https://lists.gnu.org/archive/html/bug-autoconf/2024-04/msg5.html Don't you love intentional bugs? Yet another reason to avoid autotools at all costs. By the way, the documentation of the serials "feature" actually warns about this (and seems to imply that even without serials, --force does not work as advertised for those files): https://www.gnu.org/software/automake/manual/html_node/Serials.html | Finally, note that the --force option of aclocal has absolutely no effect | on the files installed by --install. For instance, if you have modified | your local macros, do not expect --install --force to replace the local | macros by their system-wide versions. If you want to do so, simply erase | the local macros you want to revert, and run ‘aclocal --install’. But the documentation of "autoreconf --force" does not include that warning. And this also makes "--force" pretty much useless as it stands. We and Debian both need to patch aclocal downstream immediately to make --force actually work. And then of course Fedora needs to actually always run autoreconf -i -f as Debian already does, or the patch will not do much good. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kevin Fenzi wrote: > Why not the opposite: > > Download Workstation > > [I'm a linux user and know what I want, just show me the full list of > downloads, click here]? Because that still leads people to click that "Download Workstation" link before even seeing the options. "I do not want to have to choose" should be a concious choice, also considering that the mostly unconfigurable (by design) GNOME is very likely to be the wrong option for anybody not in that category. And besides: > (Which is pretty much what we have now) Well, not quite, it is more like: [LOGO Workstation (Download Now) (Learn More)] [LOGO Server (Download Now) (Learn More)] [LOGO IoT (Download Now) (Learn More)] [LOGO Cloud (Download Now) (Learn More)] [LOGO CoreOS (Download Now) (Learn More)] Want more Fedora options? Atomic Desktops (Learn More) ← no frame nor logo nor mention of "download" Fedora Spins (Learn More) ← no frame nor logo nor mention of "download" Fedora Labs (Learn More) ← no frame nor logo nor mention of "download" Fedora ALT Downloads (Learn More) ← no frame nor logo So you get offered a lot of (most likely) irrelevant (to you) options (Server, IoT, Cloud, CoreOS) before even being told that there are more options than those (and Workstation), the "Workstation" link does not tell you that (even though those are clearly workstation/desktop-targeted options too), and you also do not see the full list of options anywhere, but just a list of lists. You actually have to click on "Learn More" after "Fedora Spins" to even see what desktop environments are available. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Adam Williamson wrote:
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next
That was for Fedora 21 in 2014! As you stated it, I know you and I have been
around forever and 2014 feels like yesterday, but it was really quite a long
time ago. ;-)
Now we are planning for Fedora 2*21, which would be a good time to revisit
this decision.
> which was explicitly based around making it much more focused and less of
> a choose-your-own-adventure, specifically including making the download
> page much more opinionated.
Which is exactly what we (KDE users) are complaining about and have been
complaining about for those 10 years. And we know many users have complained
about it, too. If they even found out Fedora supports KDE/Plasma at all,
which not all of them did.
The download page now is not as horrible as it was 10 years ago, but the
main issue (the featuring of the Editions at the expense of everything else,
making the GNOME "Workstation Edition" much more prominent than the other
desktop environment options) is by design and thus still present.
> AFAIR, the numbers Matthew tracks strongly indicate this was associated
> with a very significant immediate bump in Fedora usage.
There is no evidence that this was a consequence of the change itself and
not of the massive marketing done around it. Media loves announcing when
something changes. So if Fedora changes things again to make Editions and
Spins equal, and comes up with a fancy codename (like the old "Fedora.next")
for that ("Fedora.equality"? "Fedora.flexible"? "Fedora.choice"? "Your
Fedora"? Or whatever the marketers can come up with), I expect that we will
get lots of media coverage and another bump in downloads from that.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > Sorry, that's pretty much how things are right now, is that what you were > trying to demonstrate? > > I'm not really following. Not really. The current design is better than those old designs that immediately served you an ISO when you clicked "Download now", but the focus is still on the Editions (which are framed and have logos) at the expense of the Spins and the other options (which have neither frames nor logos). Clicking on Workstation then gives you a selection of architectures, but not of desktop environments; for those, you have to find and pick the (much less prominent) Spins option on the front page instead. I think the first thing to offer users should be the Spins (including the "Workstation Edition" which is technically no different from a Spin). Most users are looking for a desktop distribution. The non-desktop options should come last, after all the desktop-ish (desktop, mobile, lab, and atomic) options. Fedora 21 has introduced the Editions vs. Spins distinction, Fedora 2*21=42 would be a good time to retire it. And selecting a desktop/workstation download should require you to select the desktop environment, with a skip option clearly labeled something like "I do not want to choose" or "Options confuse me" (or "I HATE OPTIONS!" as I had called it somewhat hyperbolically), which happens to be a pretty good description of the GNOME design philosophy. Or maybe even just: (·) GNOME (default) A desktop environment focused on ease of use **Pick this option if questions like this one confuse you.** ( ) KDE Plasma Desktop A highly customizable desktop environment ( ) Xfce A lightweight desktop environment etc. But there should be no link directly to any GNOME Edition/Spin/whatever (except Labs, if that specific Lab exists only as a GNOME-based version) without a clearly visible selection of desktop environments (which is unfortunately what the current "Workstation" link is). (And for Labs, the selection should at least visibly state somewhere what desktop environment they are based on, an information which some Labs now put in their description, requiring an extra click to see it, and some not even there.) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kevin Fenzi wrote: > Ok, thats obvously somewhat tounge in cheek, but if we promote multiple > things, we need some way to describe them to uses who might not know the > history of things and do it in a quick enough way that they won't decide > it's all confusing and go do something else. It is actually quite simple: Here are your options: [I HATE OPTIONS, JUST GIVE ME SOMETHING WITH NO OPTIONS!] (big button) → downloads GNOME x86_64 DESKTOP SPINS: Desktop: ( ) GNOME (Workstation) ( ) KDE Plasma Desktop ( ) Xfce etc. Architecture: ( ) x86_64 (64-bit x86/AMD64) ( ) aarch64 (64-bit ARM) etc. [DOWNLOAD SELECTED] MOBILE SPINS: Mobile Environment: ( ) Phosh etc. Architecture: ( ) aarch64 (64-bit ARM) etc. [DOWNLOAD SELECTED] LABS: Lab: ( ) Astronomy etc. Architecture: etc. [DOWNLOAD SELECTED] ATOMIC DESKTOPS: Desktop: ( ) GNOME (Silverblue) ( ) KDE Plasma Desktop (Kinoite) ( ) Sway (Atomic) ( ) Budgie (Atomic) Architecture: etc. [DOWNLOAD SELECTED] OTHER EDITIONS: Edition: ( ) Server etc. Architecture: etc. [DOWNLOAD SELECTED] Of course there is going to be a lot of bikeshedding about the order of the options. I would put them in that order, because I think desktop spins are most likely to be downloaded by a new user, then mobile, then use-case- specific labs, then experiments like Atomic, and then non-desktop stuff like Server. But the most important feature is the "I HATE OPTIONS!" button, because it serves exactly the users you think will be confused by the options and will give them a desktop environment designed exactly for them. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > We essentially just want more visibility on the website, if that makes > sense. Back when I was still a KDE SIG member, whenever we brought that up with the Websites Team, they would just point us to the Board (what is now the Council), and the Board would point us back to the Websites Team. That fingerpointing was very effective at preventing any change. And the Websites Team has always been really creative at hiding the KDE Spin the best they could, hiding it behind extra "Additional options" links in fine print, even with a grayed-out "Spins" icon (looking as if they were somehow unavailable), while having a huge "Download" button on the front page immediately serving you a GNOME ISO for a default architecture (for a long time i686 even though many people already actually wanted x86_64, then x86_64 even while 32-bit was still supported) with no further confirmation. Any reasonable Free Software project does not have the download link on the front page serve directly an arbitrary file, but a download page with explanations and a choice of download options, but the Fedora Websites Team insisted that "'Download' means 'Download'" and that a button with a verb must trigger an immediate action. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Adam Williamson wrote: > Change proposals can be, and frequently are, rejected. If you look at the statistics, they very rarely are. A lot of bad changes with lots of criticism on the mailing list were waved through by FESCo. But if they dare touching a Red Hat holy cow such as the dogma of defaulting to GNOME everywhere, they are likely to be rejected. (Been there, done that.) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Richard W.M. Jones wrote: > Yes, in this case the attacker had set the serial number to 30, but > the latest upstream serial number was 3. autoreconf won't replace the > file in this case unless it is deleted. There really should be an > "always replace if you can" option in autoreconf. Is that not what -f is supposed to do? At least, the documentation claims so, but the implementation does not actually do what is documented. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]
Gary Buhrmaster wrote: > And, more importantly, the industry has agreed > to use the term supply chain. Is the term > perhaps overloaded, or perhaps too > ill-defined/imprecise? Sure. But if one wants > to use a different term one would need to work > across the industry to change the term, and > that is not going to happen. Well, one could argue that Free Software is a community, not an industry, so "the industry" cannot agree on anything, and "supply chain" as an industrial term obviously does not apply. And also that it is called "Free Software" and not "Open Source". :-) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Adam Williamson wrote: > It occurs to me - maybe you don't agree, but this is how it looks to me > - that, ironically, you and I usually argue the exact *opposite* side > of this case, no? I argue in *favor* of somewhat-arbitrary delays to > packages appearing in 'stable', and you argue *against* them. :D I have never argued against updates-testing existing or that all packages should skip updates-testing. "Please pick up this new upstream version, it has some great new features" as was done here is exactly the kind of changes that SHOULD go through updates-testing. But if the maintainer has something urgent to push out, such as an important regression fix or a critical security fix (e.g., a fix for a backdoor like this one), they should be allowed to decide to skip testing and not be treated as being too incompetent for that (while at the same time allowing any other person, with no other credentials than a FAS account, to +1 the package, allowing it to be autopushed to stable – everyone except the one person most qualified to make that decision). THAT is what I have been arguing for all this time, and I do not see how this contradicts my position here in any way. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Gordon Messmer wrote: > Purely as trivia, and as I haven't seen it discussed elsewhere, the > malware steals a different set of symbols on Fedora, where > RSA_public_decrypt doesn't seem to appear in the GOT at all. This proves again that this is a very targeted attack that carefully analyzed the individual targeted distributions, the distributions whose packaging tools the build script attempts to detect were not just picked because they are known to link OpenSSH to liblzma, but also individually tested and targeted. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Aoife Moloney wrote: > Switch the default desktop experience for Workstation to KDE Plasma. > The GNOME desktop is moved to a separate spin / edition, retaining > release-blocking status. It is funny that the KDE SIG is proposing that now. I have a sense of déjà- vu: https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default Back then, the KDE SIG was NOT willing to support my proposal (even though the timing would have been ideal, given that GNOME was badly hit at the time by the GNOME 3 transition and users disappointed by the radical cuts in customizability). Now they are refloating it as their own, without even citing my original proposal. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Chris Adams wrote: > However, it's a good trigger to review Fedora's security approach in > general (like 2FA use). Using such an issue that made it through upstream 2FA and would also have made it through any 2FA enforcement in Fedora as an excuse to force 2FA on us is just pure nonsense. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Matthew Miller wrote: > I sometimes see unit test failures. The developer ran the tests, but not > on S390. Why would I want a test failure on such an exotic architecture to fail my build? The only reason Fedora supports that architecture at all is pressure from IBM. Basically nobody uses it. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
Lennart Poettering wrote: > It *literally* is just sending a text string "READY=1" in an AF_UNIX > datagram to a socket whose path is provided to you in the > $NOTIFY_SOCKET env var. I see so many ways one can get this wrong. E.g., using some abstraction for the socket write that can also write to regular files, without checking that "$NOTIFY_SOCKET" is really a socket (or checking it with a TOCTOU vulnerability), introducing an arbitrary file overwrite vulnerability. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Adam Williamson wrote: >> * Deleting ALL files automatically generated or imported by autotools in >> %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it >> would NOT have done the right thing here. Delete the files, THEN run >> autoreconf.) > > No. This would not have avoided the attack, because it would not have > regenerated the malicious file. We have already established that. Just running autoreconf would not. As I wrote: "DO NOT trust autoreconf, it would NOT have done the right thing here." Deleting the file with an explicit rm -f in %prep, and THEN running autoreconf would have regenerated (reimported, actually, this comes from gnulib and is copied unchanged, but in any case it would NOT have contained the malicious additions) the file. That said, autoreconf needs fixing too, because -f is supposed to regenerate all files that can be regenerated, which is not happening. But if you explicitly delete the files before running autoreconf, then it has to regenerate them no matter what. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Adam Williamson wrote: > I would argue there's a danger of getting too tied up in very specific > technical details of this attack. But the fact is: What WOULD have stopped this attack: (one or more of:) * Deleting ALL unit tests in %prep (and then of course not trying to run them later). * Deleting ALL files automatically generated or imported by autotools in %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it would NOT have done the right thing here. Delete the files, THEN run autoreconf.) * NOT patching OpenSSH downstream to link it against libsystemd against upstream's recommendation. What WOULD have greatly reduced the impact of this attack: * NOT enabling updates-testing by default for Branched releases. What WOULD NOT have stopped this attack: (any or all of:) * 2FA. GitHub already enforces 2FA. It did NOT stop this attack. * Any stricter vetting of Fedora contributions. The attack was performed upstream, NOT in Fedora. * More distrust of new Fedora contributors. The offending upgrade was imported by a TRUSTED Fedora contributor. The untrusted new person operated upstream, NOT in Fedora. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Adam Williamson wrote: > Maybe this needs to go on the growing pile of reasons why the > traditional Linux model *does* need to go away. Maybe Fedora, with its > foundation of First, should be kind of at the forefront of making that > happen. Switching to a container-based model is just going to introduce more different library versions (in the worst case, one per container) with a higher probability that one of them is compromised. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Adam Williamson wrote: > Do we require 2FA for provenpackager yet? No. I am a provenpackager and do not have 2FA enabled (nor do I want it to be). > People would say, justifiably so, that it was absolutely unacceptable for > us to be allowing single-factor authentication for contributors to a > general-purpose operating system in 2024. It is. This is nonsense propaganda. Most 2FA implementations cannot even guarantee that the second factor is not stored right next to the first factor. Open standards that do not depend on commercial hardware or telecommunication operators, such as TOTP, cannot guarantee it by design. Any 2FA app that works on my PinePhone is also going to work directly on my computer, so you have no way to enforce that I use a different device for the second factor. 2FA is pointless security theater that just makes it a pain to contribute, when we are all this time talking about lowering, not rising, the barrier to entry. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
Neal Gompa wrote: > Well, an easy solution is to make it so "dnf update" is coerced to > "dnf distro-sync" for development releases. That would not have helped containing this vulnerability. Keeping updates- testing disabled by default would have. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Obsoleted packages in F40
Otto Liljalaakso wrote: > So, I would actually much prefer if package retirement automatically > added the package to fedora-obsolete-packages. Perhaps there are special > cases where that would not be a good idea - if there are some, `fedpkg > retire` could have a flag to prevent that from happening. We have had this discussion several times on this list. The compromise that was agreed upon is that packages should be added to fedora-obsolete-packages ONLY if having those packages installed BREAKS something, e.g., prevents upgrading some other package due to broken dependencies, or causes a file conflict with some other package. Being retired is by itself NOT a reason to forcefully remove a package that users may depend on from their systems. So that is what should be documented, not your personal wishes. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Adam Williamson wrote: > 1. We *still don't have compulsory 2FA for Fedora packagers*. We *still > don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE > COMPULSORY 2FA FOR FEDORA PACKAGERS*. This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for contributors for a while, starting with "important" projects, then getting stricter and stricter. It has done absolutely nothing to stop this attack. How could it, when the backdoor was apparently introduced by the authorized maintainer? (Or if not, the attacker must have had access to their 2FA secret as well.) So, 2FA DOES NOT SOLVE THIS PROBLEM! STOP FORCING 2FA ON US! And especially DO NOT abuse this incident as an excuse to force 2FA down our throats, since 2FA DOES NOT SOLVE THIS PROBLEM. Sorry for being repetitive, but you were, too. THIS 2FA NONSENSE NEEDS TO STOP! > 2. Our process for vetting packagers is, let's face it, from a security > perspective almost *comically* patchy. There are 140 sponsors in the > packager FAS group. Any one of those people - or someone who > compromises any one of those 140 accounts - can grant any other person > on earth Fedora packager status. Our policy on how they should do this > is > https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Sponsor_a_New_Contributor/#sponsoring_someone_for_fedora_package_collection > . The words "trust" and "identity" do not appear in it. There is, > AFAIK, no policy or procedure by which inactive sponsors have this > power removed. There is no mandatory 2FA policy for sponsors. We already have a manpower problem, how is removing sponsors going to improve the situation? > 3. We have no mechanism to flag when J. Random Packager adds > "Supplements: glibc" to their random leaf node package. As a reminder, > *we are a project that allows 1,601 minimally-vetted people to deliver > arbitrary code executed as root on hundreds of thousands of systems*, > and this mechanism allows any one of those people to cause the package > they have complete control over to be automatically pulled in as a > dependency on virtually every single one of those systems. This would get noticed pretty quickly, when that package comes up in update transactions for no reason. I believe this has never happened so far. It is just too obvious. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
Kevin Fenzi wrote: > Branched enables updates-testing... so if you installed f40 anytime, you > will have it enabled and if you then applied updates it would be in them Yet another thing I always said was a bad idea, and this incident proves it. This would have been filtered before reaching most people if we made people only test what actually ends up in the composed Beta and Final images, i.e., updates that made it out to stable. In addition, having updates-testing enabled makes it unsafe to upgrade a Beta installation to Final because suddenly updates-testing gets disabled, but people still have packages from updates-testing (such as the backdoored xz, but also tons of untested packages or ones that explicitly failed testing) installed. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
