| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
|
|
|
|
| |
It may happen that _current_action is None even when self._actions is
not None and not empty.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
No sense having it hang around in the kickstart object in plain text.
Also add my name to the authors as now I've got a bunch of lines in this
file too.
|
|
|
|
|
| |
libxklavier now returns lists of ordinal numbers of chars instead of
null-byte terminated strings.
|
|
|
|
|
| |
There is no showError method in python-meh's interfaces, they have
messageWindow instead.
|
|
|
|
|
| |
If the screen successfully processes the input and doesn't schedule
another screen, it should be redrawn, so that the new state is shown.
|
|
|
|
|
|
|
|
|
|
|
|
| |
(1) Letting _first_refresh be the first time we reference payload.groups and
payload.environments means we are potentially downloading lots of big data in
the main thread, which means the UI cannot update.
(2) Referencing anything in software.py's _initialize grabs the yum lock,
possibly for a long time. When we later check the source spoke's status, we
reference ready which checks baseRepo, which also attempts to grab the same
lock. This isn't a deadlock because it will eventually get released, but it
does make the UI unresponsive for a while.
|
|
|
|
|
|
|
|
| |
We've got a temporary locking issue somewhere that causes the UI to become
unresponsive for a bit (see #886680, perhaps other bugs). Examining the code
indicates this isn't necessarily due to running things in the main loop
that shouldn't be. There's something waiting for the _yum_lock. This patch
adds logging to help debug.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This involves couple of places:
- TUI is blocking and waiting for user input
- Progress HUB is in charge and is reading the progress queue
- any other part wanting to react to a message like READY, ..
This patch directly fixes the first two and adds a mechanism
to register callbacks that will react to the third one.
We (me and vpodzime) expect python-meh integration to use
this to file exception reports from text mode installation.
|
|
|
|
|
|
| |
Fixes IOError: Could not load UI file 'advanced_user.glade' for object
Signed-off-by: Martin Sivak <msivak@redhat.com>
|
| |
|
|
|
|
|
| |
Otherwise there is no other way to find out what happened other
than rebooting and using pdb.
|
|
|
|
| |
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
|
|
|
|
|
|
|
|
| |
The only thing here was one completely unused function that tried to
eject the media at the end of the install.
We've got better ways to handle eject now, so this code is useless.
Remove it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous versions of anaconda ejected the media by default for
interactive installs.
After commit a724f80 (May 2007), kickstart installs needed to pass
"reboot --eject" to make the drive eject. (See bug #238711, #239002)
Commit 2f601d2 (Sep 2010) added the "noeject" boot argument, which
overrides both the default and the kickstart command. (See bug #477887)
This patch should restore this behavior:
a) Eject is enabled by default, but
b) disabled for automatedInstall unless "reboot --eject" is used, and
c) disabled if "noeject" is passed as a boot argument.
|
|
|
|
|
| |
These files may or may not exist; check to see if they exist before
copying them!
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
TODO:
- sync dracut and NM naming convention for slaves?
perhaps better: don't write any ifcfg files for kickstart case
- test with new NM (dhcp on slaves)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This should help a little bit with the confusion people have where it looks
like filesystems are vanishing, when instead they are just moving to under
a different root. However, note that anything calling _do_refresh will cause
everything to be closed except the current page.
I do not yet see a way around that.
|
|
|
|
|
|
| |
When multiple pages can be expanded at the same time, the currentPage method
doesn't make a lot of sense. Instead, make it a property of the custom
spoke and have it depend on the current selector.
|
|
|
|
|
|
| |
We're using it all over the place anyway, so there's no point keeping the
underscore on it. Also I gave CreateNewPage a members attr as well, so there's
no need to test for it anymore.
|
| |
|
|
|
|
| |
You could do this in the old UI, so let's bring it forward to the new UI.
|
| |
|
|
|
|
|
|
|
|
| |
Going back to the options dialogs is arguably not really a bug (the user may
want to go to custom partitioning), but they have other ways of doing those
things. Also, watching people test this out showed it to be very confusing
and led to people going down paths they didn't need to. Also, it's the way
it worked in F17.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This dialog now serves two different purposes: (1) You do not have enough
free space, and need to make some before you can continue to install. (2) You
do have enough free space but want to free up additional space.
Because the button is labeled "Reclaim space", we only want to allow clicking
on it if you have chosen some destructive action. Buttons should be labeled
with what they do, after all. However, we also want to take into account any
free space that may already exist on disk when considering whether you have
enough to continue.
|
|
|
|
|
|
| |
This is to help communicate how much total free space there is, in the case
where you've got enough but choose to go into the reclaim dialog to do some
other things anyway.
|
|
|
|
|
| |
If you go into the reclaim dialog already with enough space, it's a very
confusing thing to be told you do not have enough free space.
|
|
|
|
|
| |
This was caused by 1821378de1aecbbf5806edcad34ee928f0892296, which changed what
was being stored in the DiskOverviews.
|
|
|
|
|
|
|
|
|
|
|
|
| |
screen." (#905899).
This reverts commit f4ec3d682ffd93dfc7105eaa09acdd7fd672a3e8.
This patch also removes the button entirely. All I've ever seen it do is reduce
the installable package set to something like 30 packages and result in really
cryptic bugs about commands that should be there failing to run. It doesn't
seem to help in just removing the one or two packages that have a problem,
since it looks like it's frequently a core package with the problem.
|