Occasionally, updating dom0 can take literally hours, and if you’re updating via the GUI instead of qubes-dom0-update, then all you get is “updating dom0” for those few hours and nothing more. We really should have some sort of stdout passed to the GUI to at least let users know what’s going on.
I mentioned this in another thread at least a year ago when the CLI command became “unrecommended”, but I’m making this it’s own post since no progress has been made.
This is true, actually for other qubes as well. You watch it spin, then eventually it’s done but you have no idea how soon that will be.
I think it’s being worked on.
Hopefully I won’t have to bump this thread another year down the road
There are many users and few who make any contribution.
That’s common in free software.
If more users stepped up and contributed, then such issues would be
resolved more quickly.
One time I went looking for the source code for a specific “piece” of Qubes (I don’t remember the name any more, but it’s the popup that lets you choose a VM to send files to on a qvm-copy–after following a bunch of scripts I found something that was binary).
I found the Github system totally unnavigable and never did find which one of several dozen possible places that code was hiding. (Search was useless, it would either pull things in from the entire universe or fixate only on the place I already had a listing of in front of my face.)
If a person cannot find the code he wants to look at how can he contribute?
@SteveC If that happens again and you need help locating the source code for any Qubes OS feature, if you ask about it in this forum by indicating precisely what you’re looking for, I’ve no doubt you’ll get an equally precise answer.
GitHub isn’t always easy to navigate, and the search tool in simple form
is aimed at finding repositories.
It is possible to use Advanced options in the search.
There are some other route to take.
To start, a reasonable approach is to identify the package that
is involved, and find the repo that is used to build that package…
dnf provides and dpkg -S will show you the package on Fedora and
Debian systems.
Armed with that it’s straightforward to find the repository that holds
the code. (If you have a choice, check out the spec file or
debian/control file, which will show the packages built from the
source code in that repository).
Alternatively, you can take a guess based on the subject matter - many
repositories provide specific tools, like app-linux-pdf-converter , or
are named in obvious way.
Say you want to investigate the popup @SteveC refers to. You should know
that this is part of the qrexec framework - there’s a repository
named core-qrexec. Take a look in there, and you find a directory
named glade - the standard application for generating GUIs. So that’s
where you find the code for that pop-up.
Another approach could be to run make get-sources to pull down all the
repositories. A simple grep will help you to focus on the repo you need
that provides a specific feature.
These are simple ways that you can use to find specific repositories
that provide features.
And, of course, you can always come here - ask, and it shall be given you;
seek, and ye shall find.