-
-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Graphical interface to manage testing repository updates #4550
Comments
Good idea. I'd look for a tool for Fedora (or other dnf/yum based distro) first. If that exists, the task would be simple - just include it. |
I looked last night and didn't find anything new. That Ubuntu tool is only for APT, and the only other package I can think of for Fedora is GNOME Software. I wanted to see if it even includes this functionality but rejected it before I even installed it because it pulls in all sorts of wacky stuff - WebKit, ModemManager, Flatpak, ostree... the list goes on. I don't think we want all that stuff in dom0. |
Actually, I looked again and found two interfaces we could use - yumex-dnf and dnfdragora. But neither seem optimal because the repository management stuff is integrated in a larger graphical interface. And the package management stuff, at least for installs, won't work because it's dom0. Here are screenshots of both. |
https://github.com/timlau/yumex-dnf seems to be dead. As for dnfdragora, it should be possible to either request a feature upstream (and probably implement it...) to open just that dialog, or create a wrapper script to do it. This all will work if the application will run in dom0. But for separate GUI VM case, it will need some different handling (probably qrexec services for listing, enabling and disabling repositories). Yet another reason for creating separate application instead of using dnfdragora. |
@marmarek I'll start working on some qrexec services to start with, so we don't have to rewrite this later. |
So, I started tinkering with qrexec (which I've never used before) but I can't figure out a good way to test a dom0 to dom0 call.
and then prints usage. Any idea on how to get around this? Or am I going about it wrong? |
Since nowhere else dom0 calls to dom0 right now (besides Admin API, but in that case it talks to qubesd over local socket, not generic qrexec), the For now you can call |
This is a prerequisite for QubesOS/qubes-issues#4550.
This is a prerequisite for QubesOS/qubes-issues#4550.
This is a prerequisite for QubesOS/qubes-issues#4550.
This is a prerequisite for QubesOS/qubes-issues#4550.
This is a prerequisite for QubesOS/qubes-issues#4550.
Since we have new enough dnf version, native write_raw_configfile() can be used, instead of external iniparse module. QubesOS/qubes-issues#4550
* origin/pr/172: Say which repository caused the error in warnings Only make qrexec calls when necessary Squash more PyLint warnings Decode stderr in repo qrexec calls Fix error handling Fix `self` being undefined when showing warnings Only apply repo preferences when "OK" is clicked Don't use asserts for error handling Check that repo management succeeded Remove unnecessary assert Squash some PyLint warnings Add UI for managing Qubes update repositories Fix typo Fixes QubesOS/qubes-issues#4550
Automated announcement from builder-github The package
|
Qubes OS version:
R4.0
Affected component(s):
Qubes Global Settings
Steps to reproduce the behavior:
Look for a way in Qubes Global Settings to enable the testing repositories.
Expected behavior:
There are checkboxes for them.
Actual behavior:
There's only a checkbox for overall dom0 updates.
General notes:
Overall I'm thinking about something that looks vaguely like https://help.ubuntu.com/community/Repositories/Ubuntu#Updates_Tab. I'm interested in contributing patches for this but I wanted to file an issue first to double-check that it'd be accepted.
Related issues:
The text was updated successfully, but these errors were encountered: