Anaconda Web UI is postponed to Fedora 42
Hello everyone, I would like to announce that the Anaconda team has decided to postpone Web UI System Wide change[0] from Fedora 41 to 42. Reason is that we don't have time required to get the project into shape which we would like to deliver to users based on the feedback we were able to collect[1]. We also have other Fedora 41 and CentOS Stream 10 work[2] we would like to deliver which is again reducing our capacity for the Web UI project. We, FESCO and Fedora QE need to decide how to handle this in Rawhide. If we keep Web UI in Rawhide or revert it. Sorry for keeping you waiting even longer. I really hope you will love the Web UI when it's ready! [0]: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation [1]: https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995/58 [2]: https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Application Best Regards, Jirka and the Anaconda team -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Looking for Feedback: Anaconda Web UI partitioning
Hi everyone, I would like to use this mail to invite you to the discussion https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995 which was created as reaction on https://pagure.io/fesco/issue/3169 which is FESCO decision resulted in postponing the web UI from Fedora 40. Unfortunately, the ticket is missing clear requirements for having the FESCO and Fedora users satisfied with the web UI solution. We would like to use the discussion above to find out the requirements to satisfy FESCO and Fedora users and to be able to propose given change below. Best Regards, Jirka -- ___ 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: Possible deprecation/removal of Initial Setup from Fedora
Hi, Good point, I forget about these deliverables are present. Best Regards, Jirka Dne 27. 11. 23 v 10:32 Gerd Hoffmann napsal(a): On Fri, Nov 24, 2023 at 01:38:27PM +0100, Jiri Konecny wrote: Hi, I wonder, I thought that the server images are usually using Anaconda to create a user during installation. Am I missing something? Well, if you boot the install.iso and go through an anaconda install, then yes, users are created as part of that. But that is not the only way to deploy servers, there are also ready-to-use qcow2 + raw images which you can just boot without going through the anaconda install process. take care, Gerd -- ___ 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: Possible deprecation/removal of Initial Setup from Fedora
Hi, I wonder, I thought that the server images are usually using Anaconda to create a user during installation. Am I missing something? Best Regards, Jirka Dne 22. 11. 23 v 13:53 Gerd Hoffmann napsal(a): On Tue, Nov 21, 2023 at 08:07:06AM -0800, Davide Cavalca wrote: On 2023-11-21 04:34, Jiri Konecny wrote: Is Anaconda Initial Setup important for your project or workflow? What functionality is absolutely necessary for you? Do you use the text mode or the graphical mode? Are you aware of any alternatives? Is there anything that would prevent you from migrating to one of the proposed alternatives? Also please feel free to share this mail to any relevant groups. The Fedora Asahi Remix uses initial-setup (in text mode) for our Server and Minimal variants. I think this is used by *all* server images. It offers to set the root password and add users, so without that you simply can't login ... take care, Gerd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Possible deprecation/removal of Initial Setup from Fedora
Hi Simon, I guess I'm not able to answer this question well. I'm not part of the Gnome Initial Setup development. We should probably ask Gnome Initial Setup maintainers and other maintainers. Best Regards, Jirka Dne 21. 11. 23 v 13:48 Simon de Vlieger napsal(a): Hi Jiri, On Tue, Nov 21, 2023, at 1:34 PM, Jiri Konecny wrote: Hello everyone, * There are already alternatives: Gnome Initial Setup, systemd-firstboot, and preparation for KDE solution of initial setup. So the ecosystem changed from the time when Initial Setup was introduced. How about functionality loss for spins and editions that do not run a desktop environment which provides its own initial setup? Are any of the things (currently) being done by Anaconda Initial Setup unsupported by Gnome Initial Setup or its counterparts? Regards, Simon -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Possible deprecation/removal of Initial Setup from Fedora
Hello everyone, We (anaconda team) are considering discontinuation of the Anaconda's Initial Setup[0] tool, which is not related to Gnome Initial Setup. Here is a list of the reasons: * The relationship between the installer and the Initial Setup is very fragile. It is easy to break the Initial Setup by changes in the installer or break the installer while we are trying to fix the support for the Initial Setup. The shared code is complex as a result and it complicates development and maintenance of both projects. * As we had higher priority items to work on, the codebase is not in an ideal state and the upstream repository doesn't even have a proper automated CI. Fixing all these issues would take a lot of our resources that we would like to spent on improving the installer instead. * The Initial Setup tool is unnecessarily complicated. Since it shares code with the installer, it has to adapt to many limitations and requirements of the installation environment. It doesn't use the full potential of the installed system, because the installer can't. It postpones all actions until the end of the configuration, because the installer has to. It doesn't offer the best user experience for the first boot configuration, because it is designed to reuse parts of an installer. It drags Anaconda into the installed systems. * There are already alternatives: Gnome Initial Setup, systemd-firstboot, and preparation for KDE solution of initial setup. So the ecosystem changed from the time when Initial Setup was introduced. We think that these alternatives are able to give you a better solution. Before taking any action, we would like to understand your use-cases to find out how we can help you to make the transition smoother and also to find out how much time you would need for migration. Is Anaconda Initial Setup important for your project or workflow? What functionality is absolutely necessary for you? Do you use the text mode or the graphical mode? Are you aware of any alternatives? Is there anything that would prevent you from migrating to one of the proposed alternatives? Also please feel free to share this mail to any relevant groups. [0]: https://github.com/rhinstaller/initial-setup Best Regards, Anaconda team -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
Dne 02. 07. 23 v 23:54 Demi Marie Obenour napsal(a): On 6/26/23 12:00, Aoife Moloney wrote: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only. == Owner == * Name: Anaconda team ([[User:jkonecny| Jiří Konečný]]) * Email: jkone...@redhat.com * Name: Fedora Workstation SIG * Email: desk...@lists.fedoraproject.org == Detailed Description == The Anaconda team has been working on a new web-based UI for the OS installer for some time. We would like to give users the fruits of our work and get feedback so that we know what we need to improve or where we should focus. To make the adoption as painless as possible, the Fedora Workstation was chosen as the first target so we have better control over the environment and can have a focus. Also, Fedora Workstation has a smaller featureset than other installation media. The adoption for the other media later is planned too, but the exact date will be based on feedback and our capacity allowance. What is the reason for using a web-based UI instead of continuing to use GTK? Hi, the reasons are mainly these: - faster development (we don't have to reboot the machine for each change but just reload a page) - great CI support from the cockpit team (pixel tests support and we use their test suite with their infrastructure) - consistency with the other projects who use Pattern Fly (mainly around RHEL but not only) as Cockpit, Image Builder and more - possibility to share modules and code with the Cockpit project - great support from the Cockpit team - great support from the Pattern Fly team In overall these benefits should allow us better cooperation between teams, better integration and more stable product at the end. Best Regards, Jirka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
Hi Vit, Dne 27. 06. 23 v 12:43 Vít Ondruch napsal(a): Dne 26. 06. 23 v 18:00 Aoife Moloney napsal(a): https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only. == Owner == * Name: Anaconda team ([[User:jkonecny| Jiří Konečný]]) * Email: jkone...@redhat.com * Name: Fedora Workstation SIG * Email: desk...@lists.fedoraproject.org == Detailed Description == The Anaconda team has been working on a new web-based UI for the OS installer for some time. We would like to give users the fruits of our work and get feedback so that we know what we need to improve or where we should focus. To make the adoption as painless as possible, the Fedora Workstation was chosen as the first target so we have better control over the environment and can have a focus. Also, Fedora Workstation has a smaller featureset than other installation media. The adoption for the other media later is planned too, but the exact date will be based on feedback and our capacity allowance. === What will '''not''' change with the new Web UI? === The new UI will mostly use already existing functional code (some modifications are necessary), so the stability should be similar. The Anaconda specific kernel boot parameters are also staying almost unchanged. The Anaconda team aims to reduce functionality that is not used but still put a maintenance burden on the team. This should result in much easier future extensions and stability of the installer. The current approach is to start from what is known to be required and used, then add future features based on the feedback. === What is going to change with the new Web UI? === The new web UI is not just a change of the UI technology, which is based on the React and Cockpit framework, but also a complete overhaul of the user experience. The new UI is trying to be easier to use by removing most of the complexities but still leaving possibilities to do everything you might need to do. We are trying to achieve a state where even users who don’t have previous experience with the Linux operating system will be able to do the installation smoothly. List of what is part of the new UI: * Wizard solution instead of hub and spoke I am sad to see the "hub and spoke" to go away :( I understand your point and honestly I felt the same way. However, I see it as improvement after working with that a few times. Our ultimate goal (not target right now) is to enable users to skip unnecessary steps so we would get to similar level of what we had but easily understandable. Jirka Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
Hi Adam, Dne 26. 06. 23 v 22:25 Adam Williamson napsal(a): On Mon, 2023-06-26 at 17:00 +0100, Aoife Moloney wrote: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only. I am in favor of giving the web UI a shot, but I do think this is a pretty aggressive timeline given the amount of fairly large issues that remain to be resolved, especially exactly how the 'choose-your-own- partitioning' workflow is going to run (considering the stuff we discussed about constraints around partition size and boot partition requirements and disk label type requirements and so on). I think we need to be really ready, in advance, to pull the contingency lever for this one if it seems necessary. It should be fairly safe to do, since we'll still be testing the existing UI on other images, including the KDE live. First, thanks you and your team for all the help. I won't lie, we are on tight deadline, however, we decided that we would like to try to get the web UI in, so we have more feedback from the real users, thus we know what to focus on. Also, the benefit is that the fallback is pretty simple (just use the current GTK UI), so if we found any blocker, we can easily just post-pone this change to next Fedora. Another fallback is to also to add the current UI to the image next to the web UI. If we release the ISO and users will miss something it won't be blocking issue to anyone. We are trying to embrace quick releases and fast development cycle, by getting valuable feedback on real usage from our community, while ensuring that we provide a safe fallback solutions at any point. Best Regards, Jirka Naming nitpicks: I'm pretty sure the existing non-custom partitioning flow is formally called "guided partitioning", so calling a new slightly-more-customizable-one "guided partitioning" and retroactively renaming the existing one "automatic partitioning" might be a bit confusing, at least to old-timers. Also, I still think of the existing UI as 'newUI', so I'm gonna keep calling this one 'webUI'. :D ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
Dne 26. 06. 23 v 20:39 Hans de Goede napsal(a): Hi, On 6/26/23 18:00, Aoife Moloney wrote: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only. This all sounds great, thank you for working on this. === Additional information === * We are not planning to add support for spins with this change, they will use the existing GTK UI. * We don’t support remote connections to the WebUI yet. Hmm, this really is going to be a problem for low memory machines. I regularly install Fedora Workstation on 2G (not an issue atm) and 1G (requires some trickery) RAM systems. I know this is not a lot of RAM but generally speaking these systems work fine for non demanding work after the install. I'm pretty sure that not only the 1G but also the 2G RAM installs, which currently barely fit in RAM will become a problem with the new web installers. I was actually hoping the web-installer would help here since one can then just setup networking in the live environment and then have the browser showing the UI run somewhere else, hopefully reducing memory consumption compared to the gtk installer. Is there any chance this (remote installs) can at least be enabled with a commandline option for advanced users? I realize that making something for remote installs which works well for average users (and is also somehow using an authenticated connection) is quite a bit of work. But in the interim a cmdline option to start listening on other interfaces then the loopback device (and to not start the local browser) would be nice to have for power users. Note related to this ATM: https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/ "Minimum System Configuration" Says 2G is the supported minimum. It would be good to see if that can actually be made to / kept working. Has anyone already tested the new installer on a system with its RAM limited to 2G ? As said I have some tricks to help with this which currently allow me to go down to 1G. We should probably look into making some of those the default on the livecd. E.g. changing a few things to not run evolution-data-services on the livecd (no calendering will be configured anyways) is an easy win of at least 50 MB of RAM. Regards, Hans If you need low memory footprint you probably don't want to use Live image for installation. It's the biggest one because it needs to have whole Gnome environment in memory. For that, I would suggest you to use Fedora Server network installation ISO. It has much smaller memory footprint for installation and still can install workstation system in the Software Selection. The Fedora Server ISO is not part of this change so still GTK UI. If you want even smaller memory footprint then you can run the Server ISO in the text mode by setting 'inst.text' kernel boot parameter in the grub menu. We did some testing for the memory footprint of the web UI but it was some time ago and I don't remember the results. We can definitely verify it. To answer your question, remote installations work (probably not great on Live environment). We have 'inst.webui.remote' kernel boot parameter to enable that, however, we decided to not officially support it from a few reasons: - we don't have support for HTTPS connections yet (we are looking on the security aspects of this) - it will not work on Live out of the box because Anaconda is not autostarted there (something needs to start the Anaconda backend). This is the same reason why we don't support VNC installations on Live. About the improvements on the Live ISO, that should be a question on Fedora Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO. Best Regards, Jirka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
Dne 26. 06. 23 v 22:22 Adam Williamson napsal(a): On Mon, 2023-06-26 at 12:19 -0500, Chris Adams wrote: Once upon a time, Aoife Moloney said: == Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only. One thing not mentioned: what does this do to the install image size, especially for network booting? It won't do anything to the network install image size for the present, because it won't be used for it - only for the Workstation live. AIUI it shouldn't make the Workstation live any larger, because it's being run through Firefox, which is on the Workstation live already. When this does get applied to the network install image it will likely have to make it a bit bigger, though it is a bit complicated. The current images actually already have a web engine in them - webkitgtk, as backing for yelp, to display anaconda's current help pages. Since the new UI also comes with a new help system which is not yelp-based, I think we'll actually end up effectively trading out webkitgtk and trading in firefox, hopefully, unless something else drags in webkitgtk somehow. So it's *possible* the change won't be huge, unless I'm missing something. Yes, that is correct. We did some simple testing (might be inaccurate) and the size increase was around +40MB size. However, as said this is not true for Live image which should be almost the same size. Jirka ___ 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
Anaconda is slowing a boot by 5 secs
Hi everyone, I want to announce that Anaconda is slowing down a boot time by 5 seconds. It will be introduce in the next Anaconda release (version 39.10) on Rawhide. https://github.com/rhinstaller/anaconda/pull/4586 The reason is to improve the Anaconda OEMDRV functionality. This functionality is used to automatically load driverdisks or kickstart from device labeled "OEMDRV". It has unfortunate issue that some devices are visible later during the boot process. To mitigate this issue, we decided to wait during the boot 5 seconds, so the installation is able to take more of these devices (most notable it will enable to use USB devices). You can disable this functionality `inst.wait_for_disks=0`. Best Regards, Jirka ___ 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
Anaconda new Web UI is looking for your feedback!
Hello everyone, Anaconda team would like to ask you for your feedback. We are trying to design the storage partitioning for the new Web UI correctly and for that we would like to find out how you use your storage. Please help us by filling in this questionnaire so we can make correct decisions! The link to the questionnaire is in the blog post here: https://fedoramagazine.org/anaconda-web-ui-storage-feedback-requested/#comment-544800 Best Regards, Jirka ___ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
Similar situation happens if you have spec file in upstream. The problem is that mass rebuilds are adding entries to dowstream spec file only, so you have to manually merge the upstream and downstream or ideally do a backport upstream before realese. This is nice and easy solution for the issue. Even though, we solved that by using Packit for releasing. Jirka Dne 01. 01. 23 v 20:51 Fabio Valentini napsal(a): On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen wrote: My main questions are what is this supposed to fix long term? I have guessed that it has to do with automation, the shrinking number of active packagers in operating systems, and the exploding number of packages in requested languages (Rust, Go, jq, etc). However, that is just a guess and it doesn't really say "HOW" this gets to dealing with this long term. It also isn't clear what the underlying remaining active packagers want to be part of. Speaking for myself: Using rpmautospec has massively reduced the maintenance burden for the Rust stack, and also for other packages that I maintain. Due to the way optional dependencies / features are mapped to RPM subpackages (this works like with "extra" dependencies in Python packages, so this is not unique to Rust), you really should regenerate the entire spec file with rust2rpm for every new version (and every time when touching a patch that modifies features / optional dependencies in Rust crate metadata). Previously, this meant arduously copying the old changelog contents somewhere, regenerating the spec file with rust2rpm, copying the old changelog back, set the Release count to "0", run "rpmdev-bumpspec" for the latest change, and commit the changes (usually with a useless duplicate of the changelog entry as commit message). With rpmautospec, all steps except "regenerate the spec file with rust2rpm" and "git commit -c 'changelog contents'" are eliminated, which makes updating packages *much* easier, faster, and less error-prone. Additionally, not having Release counter and changelog in the .spec file means that you can usually freely cherry-pick or merge bug-fix commits across different dist-git branches. This wasn't possible without rpmautospec due to merge conflicts caused by different Release counter or changelog contents. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
Hi all, Dne 20. 12. 22 v 16:22 Ben Cotton napsal(a): https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Add support for unified kernels images to Fedora. == Feedback == == Benefit to Fedora == * Better secure boot support (specifically the initrd is covered by the signature). * Better confidential computing support (measurements are much more useful if we know what hashes to expect for the initrd). * More robust boot process (generating the initrd on the installed system is fragile, root cause for kernel bugs reported is simply a broken initrd sometimes). Just want to add Anaconda installation environment is also fighting with the second point. Thanks to the PXE boot it's maybe even more fragile environment. It could be pretty hard to find the root cause because it could fine on basically anything (mostly XFS modules). Best Regards, Jirka ___ 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: [Anaconda-devel] Anaconda Web UI
Hi, I'm sorry you feel it this way. Just want to point you to mount-point assignment feature which is in Anaconda for some time already (only text UI) where you are able to do your partitioning as you want and just assign that a mount points in Anaconda. I hope that helps. Best Regards, Jirka Dne 30. 11. 22 v 6:37 gius db napsal(a): Hi. Without controversy, developers and maintainers have every right to do things their own way and refuse requests. I my case, the installer's first problem isn't the interface, it's the lack of functionality, functions that have been blocked, the inability to bypass limits. In my case, it lacks the ability to upgrade/install over an existing installation, install over already existing empty partitions, use gparted, etc. . My feeling when using the installer is that I am a prisoner of a closed system without having enough advantages. gdb ___ Anaconda-devel mailing list -- anaconda-de...@lists.fedoraproject.org To unsubscribe send an email to anaconda-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/anaconda-de...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Anaconda-devel] Feedback on Webui Anaconda ISO
Hi Phil, Thanks for your feedback. It's really valuable. Dne 23. 11. 22 v 20:54 Phil Reese napsal(a): Hi, I've tried out your ISO on two systems. One was a USB install while the other was using the Cockpit tool. The USB install went well but seems too dumbed down. No real option for disk configuration. On a 2560x1440 screen there were ACRES of white space and I literally had to turn my head to read from one end to the other of the line. While not ideal for your theme, it might make sense to box the install screen to a modest size and center it in black space. The install was successful and I was able to create an account in the little forced step through process (Note this 'Tour' was boxed in, surrounded by other window space and was much easier to read and interact with.) Yes, we know about this issue and we are right now discussing improvement of the experience. Probably the window will be smaller in the center of the screen as it's popular with also other system installers but we are not yet decided. The second install using Cockpit was a bust. As has been with other F36 ISO installs in Cockpit. The major issue is that the many changed window sizes that the Anaconda process uses didn't work out well with the VNC viewer. The initial Language suggestion screen couldn't be used as the 'Next' box couldn't be clicked on, nor was it obvious that TAB stepped through all the options available (though I could be wrong, as I could only see the smallest top sliver of the blue box.) Not sure what exactly you mean by "using Cockpit". Could you please explain this in bigger detail. Do you mean remote installations? Nice look but it seems to give up too many configuration option that the current Anaconda offers and doesn't work well (or at all) with Cockpit. Please take into account that this is just a first public preview image, definitely not a final one. More configuration will be added but we are not yet there. The image will be updated when there will be something new to show and get feedback on. Best Regards, Jirka Phil Reese ___ Anaconda-devel mailing list -- anaconda-de...@lists.fedoraproject.org To unsubscribe send an email to anaconda-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/anaconda-de...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
New Anaconda Web UI preview image is public -- looking for feedback!
Hi everyone, We are excited to announce that Anaconda Web UI preview image mentioned by Fedora change[0] is now public for testing and providing feedback. You can find more information here: https://fedoramagazine.org/anaconda-web-ui-preview-image-now-public Feel free to download the ISO, test it and please provide us feedback as written in the article. Please note, we are now fixing size of the ISO (it has 7 GB because of the problem with a build of ISO), hopefully it should be resolved soon. Best Regards, Jirka on behalf of the Anaconda team [0]: https://fedoraproject.org/wiki/Changes/Anaconda_Web_UI_preview_image ___ 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: F37 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)
Hi everyone, I'm getting questions where people could get the ISO image with the Anaconda Web UI. If you also have this question I tried to answer it here: https://discussion.fedoraproject.org/t/isos-with-the-new-installer-are-they-available-yet/42448/2?u=jkonecny TL;DR Don't worry, we are planning to release it about a week after the F37 GA. The exact date could change. Best Regards, Jirka Dne 15. 07. 22 v 23:30 Ben Cotton napsal(a): https://fedoraproject.org/wiki/Changes/Anaconda_Web_UI_preview_image This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The work on Web UI for the Anaconda installer has advanced enough so that it is possible to create and publish self contained preview images. == Owner == * Name: [[User:m4rtink| Martin Kolman]] * Email: mkol...@redhat.com == Detailed Description == Even though still very simple the new Anaconda Web UI is now far enough to support a simple installation workflow from a self-contained image while demonstrating all the main aspects of the new UI, such as: * flexible Wizard layout * responsive PatternFly components * new style built-in help * local and remote access to the Web UI For this we will create a self-contained boot.iso style image with a built-in tar-payload (so that the image can work even without network access) based on the latest Anaconda upstream code. We aim to have the image available for download just after the F37 release (so that the tar-payload can contain final F37 release content) and then updated automatically in regular intervals. That way the rather active Web UI development of the Web UI will be reflected in the up-to-date installation image, as well as any feedback and community PRs. == Benefit to Fedora == The Anaconda Web UI will provide modern responsive user interface based on a well known and widely used toolkit (PatternFly) and backed by proven Cockpit tooling. The screen layout is based on latest UX design guidelines as well as usability testing of the new interface and extensive mockup work. There are improvements in developer experience as well due to the more modern & more mainstream UI technology chosen and powerful Cockpit test tooling (rich unit-test as well as pixel-test framework). The stateless property of the Web UI allows almost live-coding style of UI development. This should make it easier to work on the Anaconda Web UI for not only the Anaconda team, addon developer but also for any interested contributors. Remote Web UI access should also provide a much better experience than the slow and inefficient VNC based remote GUI installation support Anaconda has today. Due to no need for local rendering remotely driven GUI installations on a constrained hardware with minimal installation images should become possible. == Scope == * Proposal owners: The Anaconda team will setup and maintain an automated Web UI preview image creation pipeline, with the image being available via a web server on the Fedora infrastructure. It will be a '''preview image only''', not an official Fedora deliverable and it will not influence Fedora release criteria in any way. * Other developers: Other developers and Fedora users are welcome to try the image once it is released and to provide feedback. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == (not supplied) == How To Test == Download the Anaconda Web UI preview image and boot it on VM or hardware that contains no important data. Install using the Web UI locally, alternatively try using the Web UI remotely. The installed OS should be functional but its testing or any issues with it are currently out of scope for the Anaconda Web UI preview image. To provide feedback use one of the Anaconda team communication channels: * IRC: [https://web.libera.chat/#anaconda #anaconda] on libera.chat * mailing list: anaconda-de...@lists.fedoraproject.org - https://lists.fedoraproject.org/archives/list/anaconda-de...@lists.fedoraproject.org/ * Github Discussion: https://github.com/rhinstaller/anaconda/discussions == User Experience == Should be improved compared to the current GTK interface. == Dependencies == (not supplied) == Contingency Plan == * Contingency mechanism: If we hit some blocking technical issues, the image will be published later. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System Wide Change) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
Re: F37 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)
Hi Kevin, Dne 16. 07. 22 v 21:35 Kevin Fenzi napsal(a): ...snip... For this we will create a self-contained boot.iso style image with a built-in tar-payload (so that the image can work even without network access) based on the latest Anaconda upstream code. What packages will be in this tar-payload? We are planning to use payload from F37 Workstation GA. So it will install fully functional Fedora 37. The side benefit will be that the payload is already tested. And can you use the boot.iso to do netinstalls against the network respositories, or are you restricted to the tar-payload contents? Not yet, we are missing Software selection and Source management. This version is really a first usable image which enables to select disks and start the installation. However, it's a good base for us for future improvements so the ISO can be updated with new features and we can get feedback soon. ...snip... == Scope == * Proposal owners: The Anaconda team will setup and maintain an automated Web UI preview image creation pipeline, with the image being available via a web server on the Fedora infrastructure. So, you will need space to place these images in Fedora Infrastructure and nothing else right now from Infra? Yes, we just need a publicly accessible storage, where we can upload the ISO. Right now, we are thinking about https://fedorapeople.org/groups/anaconda/. Do you think it's a good idea Kevin or would you recommend us something else? Looking forward to playing with it! Great to hear that! :) Best Regards, Jirka kevin ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)
Hi, Dne 16. 07. 22 v 14:34 Dan Čermák napsal(a): Hi, On July 15, 2022 9:30:48 PM UTC, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Anaconda_Web_UI_preview_image This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The work on Web UI for the Anaconda installer has advanced enough so that it is possible to create and publish self contained preview images. == Owner == * Name: [[User:m4rtink| Martin Kolman]] * Email: mkol...@redhat.com == Detailed Description == Even though still very simple the new Anaconda Web UI is now far enough to support a simple installation workflow from a self-contained image while demonstrating all the main aspects of the new UI, such as: * flexible Wizard layout * responsive PatternFly components * new style built-in help * local and remote access to the Web UI For this we will create a self-contained boot.iso style image with a built-in tar-payload (so that the image can work even without network access) based on the latest Anaconda upstream code. We aim to have the image available for download just after the F37 release (so that the tar-payload can contain final F37 release content) and then updated automatically in regular intervals. That way the rather active Web UI development of the Web UI will be reflected in the up-to-date installation image, as well as any feedback and community PRs. == Benefit to Fedora == The Anaconda Web UI will provide modern responsive user interface based on a well known and widely used toolkit (PatternFly) and backed by proven Cockpit tooling. The screen layout is based on latest UX design guidelines as well as usability testing of the new interface and extensive mockup work. There are improvements in developer experience as well due to the more modern & more mainstream UI technology chosen and powerful Cockpit test tooling (rich unit-test as well as pixel-test framework). The stateless property of the Web UI allows almost live-coding style of UI development. This should make it easier to work on the Anaconda Web UI for not only the Anaconda team, addon developer but also for any interested contributors. Remote Web UI access should also provide a much better experience than the slow and inefficient VNC based remote GUI installation support Anaconda has today. Due to no need for local rendering remotely driven GUI installations on a constrained hardware with minimal installation images should become possible. == Scope == * Proposal owners: The Anaconda team will setup and maintain an automated Web UI preview image creation pipeline, with the image being available via a web server on the Fedora infrastructure. It will be a '''preview image only''', not an official Fedora deliverable and it will not influence Fedora release criteria in any way. * Other developers: Other developers and Fedora users are welcome to try the image once it is released and to provide feedback. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == (not supplied) == How To Test == Download the Anaconda Web UI preview image and boot it on VM or hardware that contains no important data. Install using the Web UI locally, alternatively try using the Web UI remotely. The installed OS should be functional but its testing or any issues with it are currently out of scope for the Anaconda Web UI preview image. Do you have any plans to integrate this with the Fedora openQA tests? That would automatically give you some basic coverage for the functionality of the installed system. That would be definitely valuable but I don't think it's feasible right now. The current progress is pretty rapid and we are constantly changing things. Having the OpenQA to reflect that could be too heavy from the maintenance PoV. Instead of that, we have pixel tests[0] in our upstream repository to avoid breaking UI, that is much easier to keep updated by us. When the UI will be more stable than we definitely want to have OpenQA support. [0]: https://cockpit-project.org/blog/pixel-testing.html Best Regards, Jirka To provide feedback use one of the Anaconda team communication channels: * IRC: [https://web.libera.chat/#anaconda #anaconda] on libera.chat * mailing list: anaconda-de...@lists.fedoraproject.org - https://lists.fedoraproject.org/archives/list/anaconda-de...@lists.fedoraproject.org/ * Github Discussion: https://github.com/rhinstaller/anaconda/discussions == User Experience == Should be improved compared to the current GTK interface. == Dependencies == (not supplied) == Contingency Plan == * Contingency mechanism: If we hit some blocking technical issues, the image will be published later. *
Re: F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
Thanks a lot for creating this. It wasn't nice experience after running `restorecon -Rv /` -- yeah, now I know you shouldn't do that on SB. Jirka Dne 16. 02. 22 v 18:12 Ben Cotton napsal(a): https://fedoraproject.org/wiki/Changes/Silverblue_Kinoite_readonly_sysroot == Summary == This change is about enabling an opt-in ostree feature that re-mounts `/sysroot` as read only to avoid accidental changes. Users and administrators are not expected to directly interact with the content available there and should instead use the interface offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to manage their system. == Owner == * Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš Popela]], [[User:jkonecny| Jiří Konečný]] * Email: si...@fedoraproject.org, tpop...@fedoraproject.org, jkone...@redhat.com * FESCo shepherd: [[User:Ngompa| Neal Gompa]] ngo...@fedoraproject.org == Detailed Description == On rpm-ostree based systems, the real root (the root directory of the root partition on the disk) is mounted under the `/sysroot` path. By default it contains the state of the system (the content of `var` and `etc`) as well as the system versions themselves (each versioned copy of `/usr`) in the ostree repository (`/ostree/repo`). This change is about enabling an opt-in ostree feature that re-mounts `/sysroot` as read only to avoid accidental changes. Users and administrators are not expected to directly interact with the content available there and should instead use the interface offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to manage their system. Example of issue: https://github.com/fedora-silverblue/issue-tracker/issues/232 This change replicates for Fedora Silverblue/Kinoite what has been done in Fedora CoreOS in a previous release. == Feedback == None so far. == Benefit to Fedora == This will make Fedora Silverblue/Kinoite more robust to accidental damage from users. == Scope == * Proposal owners: ** Work on the changes requires for new installations (potentially Anaconda configuration changes) and support for in place updates for existing installations (requires a two step process). * Other developers: ** Potential Anaconda changes required. * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == We will create a systemd unit that perform the updates in place for existing systems. This will require a two step process (changing the existing kernel arguments, and then enabling the ostree feature). Once the feature is enabled, user won't be able to rollback to previous deployments where the kernel argument is not set. We will have to clearly document that in the documentation for easier troubleshooting. == How To Test == Only try the following if you are confortable debugging an un-bootable system and have made backups! `$ sudo rpm-ostree kargs --append-if-missing=rw` `$ sudo ostree config --repo=/sysroot/ostree/repo set "sysroot.readonly" "true"` `$ sudo systemctl reboot` Note that you can not "rollback" to the previous deployment to undo this change. You will have to boot into a Live ISO and edit the config file in the ostree repo to remove this config option. == User Experience == There should be no visible change in user experience. == Dependencies == Requires changes in Anaconda (maybe just config?) to set default kargs and property on ostree repo for new installations. == Contingency Plan == Revert the change before the release. == Documentation == N/A (not a System Wide Change) == Release Notes == TODO ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Does anybody still use `starship'?
Hi, I'm using it too. I guess expected from the creator of the other thread you are mentioning :D. And I would definitely love to have it updated because new version support right_format on fish, which would be great to have. Because of that I'm using COPR now. Jirka On led 9 2022, at 5:31 pm, Stefano Figura via devel wrote: > I used to until two days ago, when I switched to this COPR repo with a most > recent version: > > > https://copr.fedorainfracloud.org/coprs/atim/starship/ > > On Sun, 9 Jan 2022, at 12:24, Igor Raits wrote: > > Hello, > > > > > > I saw some recent discussions (yet another time) how packaging Rust / > > Go / Node.js is horrible, we should simply bundle everything and such. > > > > Let's not discuss this here, though. > > > > > > I'm interested to hear if there are any users of the `starship' > > application here in Fedora that consume it from the repositories. > > > > Please speak up if you do! > > > > > > As pointed out in the other places, I don't think we are able to > > update things like that as fast as releases popping out with just as > > > > few people working on the packaging Rust stack these days (I'm pretty > > > > much not contributing for last couple years due to the other work). > > > > And the question, if we want to keep packaging it (with some slower > > > > update cycle, as the time permits) or we want to retire it completely. > > > > > > Personally, I'd love to have more people working on packaging (and > > most importantly keeping up-to-date) Rust crates / apps but I think > > > > this is not so realistic :) > > > > -- > > > > — Igor Raits. > > > > ___ > > > > devel mailing list -- devel@lists.fedoraproject.org > > (mailto:devel@lists.fedoraproject.org) > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > (mailto:devel-le...@lists.fedoraproject.org) > > > > Fedora Code of Conduct: > > https://docs.fedoraproject.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 on the list, report it: > > https://pagure.io/fedora-infrastructure > > > > > > ___ > 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 on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Discussion] Future of the CLI APP packaging
Dne 08. 01. 22 v 15:28 Fabio Valentini napsal(a): On Sat, Jan 8, 2022 at 3:08 PM Jiri Konecny wrote: (snip) I really can't blame the people. Not everyone has the week of time to package all the dependencies one by one. But COPR is a nice shortcut to that so I can have what the upstream is producing without spending so much time and just re-using binaries produced upstream. The same works for pinging people to update their packages. On the other hand ... if you don't have the time to properly maintain a package, maybe you shouldn't push it to the official Fedora repositories at all? This only results in the worst outcome: Frustration for the packager (don't have time to properly update) *and* users (package in Fedora is out of date). Pushing things in a not-entirely-packaging-guidelines-compliant-but-maintainable-with-limited-time form to COPR would be a way better solution here from the start. I understand your point but this kind of packaging is starting to be so demanding that I fear that only a few people will be able to have packages in the Fedora in the future. And those will be pretty overloaded. Best Regards, Jirka ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Discussion] Future of the CLI APP packaging
Dne 08. 01. 22 v 1:08 Fabio Valentini napsal(a): On Fri, Jan 7, 2022 at 9:48 PM Jiri Konecny wrote: Hi everyone, I would like to do here a bit of brainstorming and ask if there is an existing solution to this problem. To explain my problem, recently I found more and more apps likes terminals, prompt and command line tooling, which are great to use but not packaged or are outdated in our repositories. The reason for this is simple. These apps are written in languages like Rust or Go which works the way that there are plenty of smaller libraries and these are really a hell to package or maintain in Fedora. On the other hand it's pretty simple to build it from the source (most of the time) but hard to split it into packages. Hello! (I'd argue that most popular Rust libraries really are not small at all. Some are, but some are large. Most are medium-sized, as Rust does not have the same incentives as, for example, NodeJS, to publish single-function-modules.) I did not programmed much in Rust so I can't tell. :) Great example of this is Startship command line prompt, we have outdated version but when you look to dependencies[1] you have to completely understand. There is a slight problem with picking starship as an example here. Because it is almost certainly the Rust application with the largest number of (direct) dependencies. The starship project also frequently adds new dependencies with new versions, and aggressively uses new major versions of dependencies, both of which make updating it very painful (which is also why the package maintainer seemingly gave up on the Fedora package and now only updates it in COPR). Another example is chezmoi: https://github.com/twpayne/chezmoi/blob/master/go.mod#L5 Not packaged in Fedora at all. However, a great tool for solving your dotfiles. Upstream recommended way how to install this -> curl install script to bash... :( However, they also have RPM files (without repository). I don't want to start here a discussion if that is insecure or a good idea. That is something which has to be solved by people creating the ecosystem around these languages. What I would like to discuss here is how Fedora could improve the situation. Where you see a technological problem, I see a deeper problem with the way we do package maintenance. Many packagers came to the Rust ecosystem because they wanted to add "that one cool new application" to Fedora. But they usually don't have the time to care about their dependencies too, other than maybe doing the initial packaging and then throwing them over the rust-sig wall. On the other hand, there's people like me, who try to keep the lower-level libraries up-to-date, monitor security advisories, etc., but obviously I can't care about updating shiny application X or the-new-hotness Y as well - because I just don't have the time. And I don't think making sure somebody else can update their package is my responsibility. That disconnect between "application maintainers" and "library maintainers" is often frustrating. Application maintainers grumble about having to file new package review tickets, and that their dependencies are out of date. Library maintainers often update libraries to new major versions only "as needed", because those major changes often involve creating compat packages or pushing coordinated updates of all dependents of a library. But often the "I can't update my shiny application X to the new version! The libraries are out of date, you lazy library maintainers!" (I'm exaggarating, but you get the point) is the result of missing "major" updates that just weren't needed (or possible!) before shiny application X needed the new version. Additionally, some application maintainers are now no longer actively maintaining their Fedora packages, but instead push updates only to COPR, where they don't need to follow Packaging Guidelines. starship is an example here [1]. While the COPR is up-to-date (with using bundled dependencies), the Fedora package could be described as unmaintained. I really can't blame the people. Not everyone has the week of time to package all the dependencies one by one. But COPR is a nice shortcut to that so I can have what the upstream is producing without spending so much time and just re-using binaries produced upstream. The same works for pinging people to update their packages. [1]: https://copr.fedorainfracloud.org/coprs/atim/starship/ I would say, that for GUI apps we already done that. We have Flatpak which is doing great job to get these apps there and motivate people to do that because it's then consumable on plenty of places. However, this is not really usable if you need app which is core part of the system (like prompt) or emacs/vim which needs a lot of dependencies from the system based on user configuration. My question is, what we can do to avoid situations as in Windows? I mean that first
Re: [Discussion] Future of the CLI APP packaging
Dne 07. 01. 22 v 21:54 Major Hayden napsal(a): On 1/7/22 14:46, Jiri Konecny wrote: I would like to do here a bit of brainstorming and ask if there is an existing solution to this problem. To explain my problem, recently I found more and more apps likes terminals, prompt and command line tooling, which are great to use but not packaged or are outdated in our repositories. The reason for this is simple. These apps are written in languages like Rust or Go which works the way that there are plenty of smaller libraries and these are really a hell to package or maintain in Fedora. On the other hand it's pretty simple to build it from the source (most of the time) but hard to split it into packages. Oh gosh, yes, this has been a problem for me for a while. I maintain azure-cli, which has a few subpackages. It depends on about 95 other Azure Python SDK components which depend on various Python libraries. Each of these must be carefully updated when the main azure-cli package is updated. 掠 I would say, that for GUI apps we already done that. We have Flatpak which is doing great job to get these apps there and motivate people to do that because it's then consumable on plenty of places. However, this is not really usable if you need app which is core part of the system (like prompt) or emacs/vim which needs a lot of dependencies from the system based on user configuration. I do like Flatpaks for GUI applications. For CLIs, I've seen people use container images since it's a single item that is easily updated. However, it's not always easy to determine how a container was built and the home of its sources. The cloud vendors seem to be moving towards bundling everything up into a zip file that you download and run. AWS now has their own crypto/hashing components and bundled Python in a zip. Google has a large zip with plenty of third party vendored content. Bundling to ZIP is again the same issue. You have to download it from somewhere and from my PoV that is a bigger problem than not being able to validate the content. In general I'm thinking if we shouldn't "shift" our current packager is responsible for safe content to author is responsible for safe content. That is basically happening for Flatpak. It's much easier to package because you can "just take the binary" from author and don't care. Partial solution to that is COPR. Which I'm taking as AUR (Archlinux). That is great but maybe there is something not specific for RPM but working out of the RPM world? That would be much better marketing for the authors to do the packaging. I'm very interested to hear additional use cases and ideas. ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.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 on the list, report it:https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Discussion] Future of the CLI APP packaging
Sorry adding missing link: [0]: https://github.com/starship/starship/blob/master/Cargo.toml#L32 Dne 07. 01. 22 v 21:46 Jiri Konecny napsal(a): Hi everyone, I would like to do here a bit of brainstorming and ask if there is an existing solution to this problem. To explain my problem, recently I found more and more apps likes terminals, prompt and command line tooling, which are great to use but not packaged or are outdated in our repositories. The reason for this is simple. These apps are written in languages like Rust or Go which works the way that there are plenty of smaller libraries and these are really a hell to package or maintain in Fedora. On the other hand it's pretty simple to build it from the source (most of the time) but hard to split it into packages. Great example of this is Startship command line prompt, we have outdated version but when you look to dependencies[1] you have to completely understand. I don't want to start here a discussion if that is insecure or a good idea. That is something which has to be solved by people creating the ecosystem around these languages. What I would like to discuss here is how Fedora could improve the situation. I would say, that for GUI apps we already done that. We have Flatpak which is doing great job to get these apps there and motivate people to do that because it's then consumable on plenty of places. However, this is not really usable if you need app which is core part of the system (like prompt) or emacs/vim which needs a lot of dependencies from the system based on user configuration. My question is, what we can do to avoid situations as in Windows? I mean that first thing what Win users are doing is to look on internet and start to download random binaries. Do we have something like Flatpaks for core parts of the system now? Is there something we could adopt? Am I completely wrong with my assumptions :D? Also want to mention that I don't have much experience with this. It's more that I'm worried and maybe this discussion could lead to something in the future. Best Regards, Jirka Konecny ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Discussion] Future of the CLI APP packaging
Hi everyone, I would like to do here a bit of brainstorming and ask if there is an existing solution to this problem. To explain my problem, recently I found more and more apps likes terminals, prompt and command line tooling, which are great to use but not packaged or are outdated in our repositories. The reason for this is simple. These apps are written in languages like Rust or Go which works the way that there are plenty of smaller libraries and these are really a hell to package or maintain in Fedora. On the other hand it's pretty simple to build it from the source (most of the time) but hard to split it into packages. Great example of this is Startship command line prompt, we have outdated version but when you look to dependencies[1] you have to completely understand. I don't want to start here a discussion if that is insecure or a good idea. That is something which has to be solved by people creating the ecosystem around these languages. What I would like to discuss here is how Fedora could improve the situation. I would say, that for GUI apps we already done that. We have Flatpak which is doing great job to get these apps there and motivate people to do that because it's then consumable on plenty of places. However, this is not really usable if you need app which is core part of the system (like prompt) or emacs/vim which needs a lot of dependencies from the system based on user configuration. My question is, what we can do to avoid situations as in Windows? I mean that first thing what Win users are doing is to look on internet and start to download random binaries. Do we have something like Flatpaks for core parts of the system now? Is there something we could adopt? Am I completely wrong with my assumptions :D? Also want to mention that I don't have much experience with this. It's more that I'm worried and maybe this discussion could lead to something in the future. Best Regards, Jirka Konecny ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Anaconda new community mailing list available
Dne 02. 12. 21 v 17:04 Ben Cotton napsal(a): On Thu, Dec 2, 2021 at 11:02 AM Jiri Konecny wrote: we (Anaconda team) have decided to migrate our old anaconda-devel-l...@redhat.com mailing list under Fedora. This decision was made to be closer to community and more discoverable in the Fedora world. This is great, thank you! If you are interested about what is happening with your loved installer, please subscribe here to the new mailing list: https://lists.fedoraproject.org/admin/lists/anaconda-devel.lists.fedoraproject.org/ Will existing subscribers be migrated or will people need to re-subscribe if they want to continue participating on the list? Hi, unfortunately, I wasn't able to find a way to do the automatic re-subscribe. I did send mail to the old list that people need to re-subscribe, can't do much more. Best Regards, Jirka ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Anaconda new community mailing list available
Good day everyone, we (Anaconda team) have decided to migrate our old anaconda-devel-l...@redhat.com mailing list under Fedora. This decision was made to be closer to community and more discoverable in the Fedora world. The new mailing list will work the same way as the old one. If you have any idea, feedback, question to the Anaconda team, feel free to use this mailing list to reach us. We or someone else from the community will try to help to resolve your issue. The old mailing list will be changed to alias to this new one and will stop working from start of the next week (the exact date is not known). History of the old mailing list will stay publicly available. If you are interested about what is happening with your loved installer, please subscribe here to the new mailing list: https://lists.fedoraproject.org/admin/lists/anaconda-devel.lists.fedoraproject.org/ Best Regards, Jirka and the Anaconda team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)
Dne 01. 12. 21 v 16:16 Jonathan Wakely napsal(a): On Mon, 29 Nov 2021 at 19:36, Ben Cotton wrote: == Release Notes == In the User spoke, the "Make this user administrator" checkbox is now checked by default. This improves installation experience for users who do not know and need to rely on the default values to guide them. What's the context of this text? Is it in a section that is specifically about anaconda? Because "the User spoke" isn't very meaningful on its own. Arguably talking about spokes at all isn't very meaningful for end users who are reading the release notes. I did a double-take when reading it, until remembered that's the anaconda terminology, and I've been using anaconda for years and years. Yes, you are correct it's the Anaconda context. Good point, maybe it would be good to change the proposal a bit to clarify that? Jirka ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)
Dne 01. 12. 21 v 1:10 Michel Alexandre Salim napsal(a): On Tue, Nov 30, 2021 at 10:08:19AM -0600, Michael Catanzaro wrote: On Tue, Nov 30 2021 at 10:57:37 AM -0500, Colin Walters wrote: https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b453902315539e4f327481162c4f8 Should we be using this on other Fedora variants too...? At least for Workstation, where root is always locked? That seems sensible, can it be part of this Change or should it be worked on separately? I don't think it should be part of this change. It seems unrelated to the change proposal. Jirka It's probably also a good idea to prompt to set the root password, /iff/ the user unchecks the administrator box, but understandable if the Change authors feel that's out of scope. Best regards, ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.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 on the list, report it:https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Sub: make US keyboard layout easier to find in Anaconda
Hi Sundeep, First of all I want to say thanks a lot for your contribution to sort the languages in Anaconda. Especially for me as Anaconda developer this is really handy feature. I really like to see that you are thinking about the next improvement. I love to see that, however, please wait with these changes after F36 is released. Right now, it seems that we have to fundamentally change the code and logic for the keyboard switching because of https://bugzilla.redhat.com/show_bug.cgi?id=2016613 and https://bugzilla.redhat.com/show_bug.cgi?id=1955025#c6 So please wait with this change for F37. Sorry for slowing you down. On the other hand it's definitely fine to do the research now :). Best Regards, Jirka Dne 27. 10. 21 v 8:05 Sundeep Anand napsal(a): Hi, Even in native language anaconda majority of users prefer and choose US keyboard layout. This proposal[1] is to pull US layout at the top of the list. User story: As a US keyboard layout user, I would like to be able to find the US keyboard layout in my own language quickly and easily in the Anaconda installer. thoughts? regards, sundeep [1] https://github.com/rhinstaller/anaconda/pull/3667 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Replace the Anaconda product configuration files with profiles (Self-Contained Change proposal)
Hi Matthew, The goal here is to use `ID` and `VARIANT_ID` instead of what we are doing now. So yes, we want to replace the current solution. We would like to make the detection consistent across all the installations so ideally even stop using /.buildstamp if possible. Best Regards, Jirka On 6/4/21 9:59 PM, Matthew Miller wrote: On Fri, Jun 04, 2021 at 03:37:57PM -0400, Ben Cotton wrote: * The detection based on the os-release files will no longer work because of [https://fedoraproject.org/wiki/Changes/Fedora_Linux_in_os-release a Fedora 35 change]. I'm not arguing against the proposed change here, but this shouldn't be a reason. In fact, I'm generally _for_ the change. But: The detection¹ seems to be looking at human-readable NAME and designed for machine parsing VERSION_ID instead of both machine-parseable ID and VERSION_ID as it should be. Unless the plan is to just remove this code, that was always a bug and should be fixed regardless of this feature. [1] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/storage/devicetree/root.py, right? ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
