Anaconda-devel July 2012

anaconda-devel@lists.stg.fedoraproject.org

30 participants
33 discussions

Ability to install to loopmounted filesystem - mentor wanted
by Tirtha Chatterjee 02 Dec '12

02 Dec '12

Hello. I am trying to implement something like Wubi on Fedora. For this, I first need to make it possible to install to loopmounted filesystems through anaconda. I don't think a lot of modification to the existing source code is required. I tried going through the source code, but it seemed quite big to manage without some guidance. I would be extremely happy if someone guided me on this. Hoping for an affirmative reply :-) -- Regards Tirtha Chatterjee KDE developer http://wyuka.co.cc/

2 3

Bill's patch for software selection + comps metadata
by Máirín Duffy 17 Aug '12

17 Aug '12

For those of us not on anaconda-patches list (like myself and the other designers I know are monitoring this list :) ): https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-July/000165.… Here is the screencast Bill Nottingham made of the UI changes in the patch: http://notting.fedorapeople.org/installer.webm Some things Chris, Bill, and I discussed about the patch: - Overall a great idea. - 'Installation Type' is maybe an odd term to use. We talked about using the term 'Environment' instead - that term is inclusive of all the desktop options and (no-desktop) minimal install that are in that selection box. - We use the term 'install class' a lot, so it might be better to pick a different term. Bill has used install class here to mean a desktop + the comps groups that are compatible with it = a base package set. Some alternatives Bill proposed (with some thesaurus help): selection collection combination compilation assembly mix My suggestion is to use "environment collection" (even though it's long) because I think collection is the most appropriate term (a group of sets, think Flickr 'collections' vs 'sets') but it's also important to use the term 'environment' in it so that someone looking at the comps knows that it relates to the 'environment' widget in the UI. Thoughts? ~m

4 7

[PATCH] libudev now has a version of .1
by Mark Hamzy 15 Aug '12

15 Aug '12

libudev bumped the version number up to /usr/lib64/libudev.so.1 Also, change the error message from None. --- pyanaconda/pyudev.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/pyanaconda/pyudev.py b/pyanaconda/pyudev.py index 4b5d586..705b93d 100644 --- a/pyanaconda/pyudev.py +++ b/pyanaconda/pyudev.py @@ -31,10 +31,12 @@ def find_library(name, somajor=0): return None # find the udev library -libudev = find_library(name="udev", somajor=0) +name = "udev" +somajor = 1 +libudev = find_library(name=name, somajor=somajor) if not libudev or not os.path.exists(libudev): - raise ImportError, "No library named %s" % libudev + raise ImportError, "No library named %s.%d" % (name, somajor) # load the udev library libudev = CDLL(libudev) -- 1.7.10.1

4 3

[newui] Remove scdate usage and have timezone only in ksdata
by Vratislav Podzimek 07 Aug '12

07 Aug '12

PATCH 1/2 removes the last piece of live code that uses the system-config-date (note that there still is the old GUI code using the scdate's timezone map). However, I didn't find scdate as a dependency in anaconda.spec.in nor in lorax templates for the installation runtime environment. How it gets to the install image? PATCH 2/2 does basically two things: 1) It removes the Timezone class used in the anaconda object for timezone data replacing it with the code using ksdata as the only sctructure storing data and execute method of the Timezone pykicstart command. 2) It moves some pieces of code from the localization module to the separate timezone module adding a function for writing timezone configuration. This function is based on the old one from the Timezone class. I have just replaced copying timezone file to the /etc/localtime with creating a symlink because this way it is easy to find out which timezone the system is using. -- Vratislav Podzimek

4 10

[PATCH] Some accessibility improvements
by Joanmarie Diggs 06 Aug '12

06 Aug '12

Hey all. As some of you know, I have been threatening to do this work for a while now, but other things keep bubbling to the top of my priority list. :-/ I'm really sorry about that. Rather than wait until I have everything done, I'm attaching some changes which greatly improve the accessibility of Anaconda for users who are blind and are, insofar as the code goes, pretty trivial. What the patches do is: 1. Set accessible relations between labels and the things being labeled. As a result, instead of Orca saying things like "text" and leaving the user to guess what text he/she should type, Orca now says "foo: text" and the user knows to type a value for foo. This was also done for labels associated with a group of widgets so that the user has some context when navigating. Note that there are a couple of ways you can tackle this: Add accessibility-specific code to set the relations or just set the mnemonic widget property and let Gtk do it for you automatically. I wound up doing the latter based on the suggestion of Benjamin Otte (Gtk+ developer). 2. Change initial focus for each* installer step to the likely widget of interest. As a result, instead of Orca merely saying "Next" and leaving the user to wonder what step he/she is on and what is required in order to proceed, Orca now automatically presents the widget and associated context for each new screen/step that appears ("Step foobar, you must enter a foo and a bar, foo text"). * Well, most steps. More work is needed here. 3. Because the change in step 2 in some cases broke the "Just press Return for the 'Next' button" functionality, make the 'Next' button the default. That brings back the "Just press Return" functionality so the end user experience for everyone else should still be the same as it currently is. If you have any questions, please let me know. Thanks, take care, and again my apologies for the delay. --joanie (Orca project lead)

3 3

Key installer functionality for F18: rescue mode, text/serial console mode
by Adam Williamson 02 Aug '12

02 Aug '12

Hey, folks. Since there's been some discussion on test@ about possibly-missing features with the f18 newUI transition, I wanted to make sure we're all on the same page about what needs to be in for f18. the two features QA was worried about missing are text mode installation, and the rescue mode that's present on the DVD/netinst images. on text install: apparently it's now the plan that a basic text mode will be included in f18 and may even make Alpha. As long as that's a commitment then that should work out fine and is no longer a worry. on rescue mode: we would like to see a roughly functional equivalent replacement for rescue mode present in f18, with considerable flexibility as to the exact form. as far as I can tell, these are the major features of rescue mode: 1) bring up network 2) mount installed system partitions 3) provide rescue shell with binaries from installed system in $PATH it also has a 'diagnostics' thing, but that seems somewhat obscure - it gives you a screen full of cryptic output when you run it, but that output almost all appears to come from some sort of mdraid analysis thingy. It doesn't seem to do much beyond that. Anyone have more details on the 'diagnostics' feature and how it's supposed to work? Anyway, diagnostics aside, it shouldn't be too much effort to implement something that does 1, 2 and 3. One idea has been to make it as a module for dracut. wwoods suggested "personally what I'd want to do is use lorax and make a rescue runtime, or just add stuff to a rescue target in the normal anaconda runtime". I'm not making any suggestion for what method would be best - anything works so long as there's something =) If anaconda team can commit to a rescue mode replacement for f18 final at least, that'd be great. thanks. Also, if anyone's aware of any other major functionality that might go away with newUI - besides what's already been discussed or called out on the feature page - please let us know. thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

9 23

Bug in newui and python-meh problem
by Vratislav Podzimek 01 Aug '12

01 Aug '12

When trying to make python-meh exception handling work, I've hit a traceback [1]. It happens every time, but since it is in separate thread, without python-meh everything else goes on. I've used the updates.img to use up to date code. Another problem is, that if unhandled exception appears in a separate thread, python-meh displays the mainExceptionWindow, but then immediately whole Gtk crashes with many error messages on tty1. I guess the problem is that python-meh runs another Gtk main loop from a different thread. Any ideas how to resolve that? Appart from that, I added some patches that make python-meh work (posted on our patches list). [1] http://fpaste.org/Fbiu/ -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

4 4

Text based UI - framework core, example hub&spokes and input related questions
by Martin Sivak 31 Jul '12

31 Jul '12

Hi, Lets move this to devel list so others can comment too. > That's fair. I really don't know how many of those spokes we can > actually do in text mode given the constraints though. So the current info I got from David is that we are required to have full featured text mode. We can do spokes which consist of more linear screens though to make up for the lack of screen space. > > > > Your examples used the Hub & Spoke model and you need a way of > > returning back to the Hub when the Spoke is done. We also need > > linear > > progression (to move between hubs or inside Spoke screens) and two > > "dialogs" (showError and showYesNoQuestion as required by > > UserInterface base class). > > This is true. My example was just about showing the UI, not about > how > to actually code it. As far as navigation is concerned, we certainly > want to re-use as much of the existing ui code that's already in > ui/gui/. I agree and we should be able to separate the UI agnostic parts to some kind of common/ abstract classes and then inherit from those for GUI and TUI cases. > I agree that columns are a bad idea. Particularly when you start > throwing translated strings into those. Well not really, this might still work, try the example code I did yesterday (I am attaching it again, since you probably missed it on devel list). I do not plan on adding much more widgets now, but what is there can actually do columns pretty easily and it will work even on dot matrix printer with translations in place :) > I don't necessarily have something different in mind. I am > struggling > with how to make use of this code with a real spoke. Right now I'm > looking at what it takes to re-use much of the code existing in > ui/gui > to setup a single text hub and single text spoke and somehow get it > displayed. Your code may in fact become handy there, something in > place > of Gtk.main(). That is the idea behind App and UIScreen classes. I am reading input using raw_input so no single keypresses at the moment, but that might be easily changed. There is one more issue coming up, how do handle textual/numeric input? Can we use readline on s390? Or maybe use readline only where it is supported? Does anybody know how does that work on those dumb terminals? Martin

2 14

Feature request: ipmi
by Jeffrey_L_Mendoza＠Dell.com 31 Jul '12

31 Jul '12

Hi List, I have a feature request for https://fedoraproject.org/wiki/Anaconda/Features : ipmi functionality. An immediate feature would be the ability to include freeipmi-bmc-watchdog. This would allow administrators to use the service processor/bmc to detect/report a stuck install. Future use would be to have anaconda run ipmi commands to log install status: start, step completed, success, failure. Therefore having the service processor aware of the install status. I assume this is accomplished by including the ipmi driver and ipmitool/freeipmi packages in the stage 2 image. I am in the process of familiarizing myself with the wiki: http://fedoraproject.org/wiki/Anaconda/SourceOverview http://fedoraproject.org/wiki/Anaconda/Stage2DevelopmentGuide Thanks, Jeff Mendoza Software Engineer Dell | Linux OS Engineering

3 2

Use systemd-localed?
by Vratislav Podzimek 31 Jul '12

31 Jul '12

As it was suggested in the discussion here on the devel list, we could use the systemd-localed DBus service [1] to set keyboard layouts. I've looked at it and tried some tests and here are the results: 1.) The main problem is, that this service allows to set only one keyboard layout and is therefore not usable for us for setting multiple X11 keyboard layouts. 2.) While it has a method for setting the virtual console keyboard layout too, it provides us the same functionality as loadkeys command. I see no reason for replacing loadkeys calling with DBus method invocations. Once rhbz#837292 [2] gets resolved it would allow us to use more keyboard layouts in the console, but for now I don't see any reason to use it. Comments are, of course, welcome. [1] http://www.freedesktop.org/wiki/Software/systemd/localed [2] https://bugzilla.redhat.com/show_bug.cgi?id=837292 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel July 2012