| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
| |
Account for space gained through clearpart and use actual payload
space requirement.
|
| | |
|
| |
|
|
|
|
| |
This way, the user knows why they can't yet go into the source or software
spokes. When the spokes become ready, their status message will be changed
automatically.
|
| |
|
|
|
|
|
|
|
|
| |
Using a queue worked so well elsewhere that I should use it for spoke-to-hub
communications as well. This has several advantages:
* No passing around a callback.
* Allows for marking a spoke as not ready later after it's become ready.
* Allows for changing the status of a not ready spoke to let the user know why.
* Uses the same abstraction as is in use elsewhere.
|
| | |
|
| |
|
|
|
|
|
|
| |
Start a thread to download repo metadata in the source spoke's apply
method. Wait for that thread to finish before refreshing the software
spoke.
This also adds locking around access to YumPayload's YumBase instance.
|
| |
|
|
|
|
|
|
|
|
| |
Switching from a configured base repo to using the closest mirror
needs to disable the previously-configured base repo.
Any change of base repo requires a call to updateBaseRepo.
Never fully reset ksdata.method. Instead, unset method.method to
disable it while retaining the details in method's url, &c attrs.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It will automatically cycle the image every 60 seconds. Similarly to how
it all used to work, we will check for images in directories both containing
a language-specific component and not.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
With the previous code, I could never get the UI to be redrawn to reflect the
changes, even though the changes appeared to have taken effect.
This new code instead uses a message queue for communication between the thread
doing all the hard work and the main thread that handles GTK stuff. The storage
code will shove messages into that queue when it does something like create a
filesystem, and the main thread watches in the idle loop for messages.
I've also provided yet another context manager to make all this code simpler.
|
| |
|
|
|
| |
Otherwise, there's a brief moment where "Installing %s" is visible before
the real work starts.
|
| |
|
|
|
| |
Even after manual modification by the user we want to keep the displayed
date and time updated to the newly set system date and time.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
First, it means we can move the special run behavior into the run method
directly instead of the roundabout way it was being done. Second, it
provides a place to make sure the thread gets removed from the threadMgr's
list when it terminates.
|
| | |
|
| | |
|
| |
|
|
|
| |
Otherwise, small int/bigger int = 0, which means the progress bar will always
be stuck.
|
| |
|
|
|
|
|
| |
There's nothing particularly clever about this. It just calls the ksdata
execute methods linearly, makes partitions, and installs packages. Error
handling is not yet in good shape and neither is progress reporting.
However, an autopart setup will actually make partitions.
|
| |
|
|
|
|
|
| |
We need to be able to update the progress bar and the message independently.
The message should be updated when an action begins so you know what's
taking so long, and the progress bar should be updated when an action ends
so you know how far you are through now.
|
| |
|
|
|
|
| |
For now, we're just going to support installing to the MBR on the first disk
in the list. That's the expected autopart behavior anyway, and autopart is
all we can do for now.
|
| | |
|
| |
|
|
| |
This way, it's possible for you to continue on to the second hub.
|
| |
|
|
|
|
| |
For a long time, it was just being displayed as a big black square on the hub.
Whatever was wrong has fixed itself, so we can use the icon I always wanted us
to be using.
|
| |
|
|
|
|
|
|
|
|
| |
In the custom partitioning UI, we want to present the user with everything as
it is now so they can then change it to what they want it to be. Thus, we need
to not look at the requests.
Note that this currently only works for things like swap or biosboot, not real
filesystems as storage.mountpoints is not yet set up. That's another pile of
work.
|
| |
|
|
|
|
| |
If you don't have enough free space but have the ability to make enough,
you can click the "I don't need help" checkbox and the "Reclaim space"
button. That should send you straight to custom partitioning.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
and days
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This spoke is indirect, meaning you can only get to it through the initial
storage configuration spoke. It doesn't appear anywhere on the hub.
It doesn't yet do very much useful. I should be grabbing the devices to display
in the right hand side instead of the list of partitioning requests, and you
can't do any editing anyway. But, it's something and allows for checking out
how everything looks.
|
| |
|
|
|
| |
This is going to be handy for the custom partitioning spoke which we do not
want to dispaly on the hub.
|
| | |
|
| | |
|
| |
|
|
| |
This only affects the base method, not any extra addon repos.
|
| | |
|
| | |
|
