This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 725219 - anaconda should run in clone not span mode
anaconda should run in clone not span mode
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: xorg-x11-server-utils (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
[cat:rendering] QuitSlackingOffAjax
: FutureFeature, Triaged
: 729790 730032 740755 741204 741966 745096 746794 746879 748283 750559 752800 754176 756509 783094 804461 808901 815014 (view as bug list)
Depends On:
Blocks: F17-accepted/F17FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2011-07-24 07:12 EDT by Pasi Karkkainen
Modified: 2015-03-05 18:57 EST (History)
34 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Pasi Karkkainen 2011-07-24 07:12:45 EDT
Description of problem:
Currently (as of Fedora 15) anaconda installer and fedora live media uses span mode as a default, ie. all displays are activated and desktop spans all displays, and the primary gnome desktop with menus etc is only on one of the displays. On many laptops the primary desktop ends up being on the internal LVDS panel, which could be under a closed lid (because ACPI lid status is not trusted and checked), and thus users don't see the primary desktop at all! (until they open the closed lid).

It's better to use 'clone' mode as a default, so all displays have the same content, so the main display (gnome menus and/or installer) is visible on all outputs (lvds panel, external monitors, etc).

Version-Release number of selected component (if applicable):
F15 anaconda and live media.

How reproducible:
Always.

Steps to Reproduce:
1. Boot fedora live cd or installer dvd on a system with multiple displays.
2. Notice spanned desktop is used.

  
Actual results:
spanned desktop mode is used.

Expected results:
clone mode should be used instead.

Additional info:

using 'span' mode as a default causes bugs like this:

"ACPI LID state ignored on laptop, wrong display used for desktop/installer":
https://bugzilla.redhat.com/show_bug.cgi?id=712706

Based on discussion on fedora-devel mailinglist with Adam Williamson, using clone mode as a default might require some patches to Xorg or xorg default config, since currently X does not provide very easy mechanism to override the default of span mode.

Clone mode should be used as a default on both the Fedora live CD and on installer DVD.
Comment 1 Adam Williamson 2011-07-26 12:42:43 EDT
For now I'd like to restrict the scope to anaconda; live mode is an even harder problem because it's difficult to differentiate a live boot from a post-live install state, and we do want to respect upstream defaults in the latter. 'use clone mode for traditional install boots' is a more simple scope to deal with first.
Comment 2 Pasi Karkkainen 2011-07-26 12:57:18 EDT
Sounds reasonable. One step at a time :)
Comment 3 Adam Williamson 2011-07-26 13:26:39 EDT
picking a couple of anaconda folks to CC, anaconda team, my memory is that we discussed this in IRC or something and the problem was we couldn't find a simple way for anaconda to override the X default (span mode), like a command-line parameter - is that right?
Comment 4 Chris Lumens 2011-07-27 10:45:34 EDT
Hm, I don't see anything in my irc logs that indicate we talked about this but on the other hand, "span" is pretty hard to search for.  I also see nothing in the Xorg man page that would allow for us to override this default.
Comment 5 Adam Williamson 2011-07-27 12:28:59 EDT
It might have been somewhere else, it's just one of those vague 'hum, I'm sure this came up before' thoughts.

I believe the current way to override this would be to use an xorg.conf fragment in /etc/X11/xorg.conf.d . That would require it to be possible for that fragment to be there for anaconda purposes, but not be present on the installed system, so the installed system used span mode. Is that possible with how anaconda works?
Comment 6 Adam Jackson 2011-08-02 17:40:41 EDT
There's not any obvious way to set span/clone policy from xorg.conf right now, actually.
Comment 7 Pasi Karkkainen 2011-08-02 17:48:51 EDT
So it's just not exposed as xorg.conf option? At least the gnome "Monitor Preferences" has "Same image in all monitors" button.. which I guess just uses xrandr to configure the monitors.
Comment 8 Adam Williamson 2011-08-03 00:12:36 EDT
ajax: well, xrandr has a --same-as option which I assume is the way you set clone mode using xrandr, and xorg.conf seems to use more or less the same syntax turned into xorg.conf-y camel case, so something like:

Section "Monitor"
Identifier "Foo"
Option "SameAs" "Bar"
EndSection

should do the trick - but then of course you have to identify the outputs. ergh. it would be nice to have some kind of master switch somewhere in X, or else we're kinda stuck on the anaconda end of this. shall we re-assign to X server for now?
Comment 9 Chris Lumens 2011-08-04 15:30:44 EDT
anaconda already runs xrandr to set resolution on occassion, so it's possible for us to add extra arguments.  The biggest problem would be identifying the other output devices to construct the command line.  Doing the same thing as the rest of the system (and as the automatic defaults) would be my first choice, though.
Comment 10 Adam Williamson 2011-08-04 19:54:26 EDT
I think clone is pretty clearly the 'best' behaviour for anaconda, as it takes precisely no benefit from span mode, so the only possible effect of span mode is a negative one (if you're looking at the wrong screen, you see nothing). but it looks like it may not be simple to achieve...
Comment 11 Chris Lumens 2011-08-09 14:53:12 EDT
14:49 < clumens> ajax: so, there's not really any simple way for me to set up the cloned displays, huh?  it looks like i could do it with xrandr, but i'd have to figure out what all the displays are and then which is the primary and blah blah blah.
14:51 < ajax> clumens: not easily, no. feel free to throw the bug at me though, i'll happily write the xrandr goo
14:52 < ajax> it's pretty reasonable for it to have a --clone-all flag
Comment 12 Adam Jackson 2011-08-09 14:54:32 EDT
Add F16Blocker so I don't slack off.
Comment 13 Chris Lumens 2011-08-10 16:50:38 EDT
*** Bug 729790 has been marked as a duplicate of this bug. ***
Comment 14 Ian Pilcher 2011-08-10 16:55:43 EDT
Just a note that as of Fedora 16 Alpha RC3, anaconda is now actually
spanning its display across two screens.  Depending on the resolutions
of the respective displays, this could potentially put important buttons,
etc., in completely invisible places.

(See picture in bug 729790.)

So things have actually gotten a bit worse ...
Comment 15 Chris Lumens 2011-08-11 12:00:22 EDT
*** Bug 730032 has been marked as a duplicate of this bug. ***
Comment 16 Pasi Karkkainen 2011-08-28 13:30:37 EDT
Any updates?
Comment 17 Chris Lumens 2011-09-23 11:08:12 EDT
*** Bug 740755 has been marked as a duplicate of this bug. ***
Comment 18 Chris Lumens 2011-09-26 09:15:21 EDT
*** Bug 741204 has been marked as a duplicate of this bug. ***
Comment 19 Chris Lumens 2011-09-28 12:41:02 EDT
*** Bug 741966 has been marked as a duplicate of this bug. ***
Comment 20 Adam Williamson 2011-09-28 12:48:28 EDT
while testing the EFI stuff I noticed a somewhat annoying consequence of this - on my desktop, which has 2x 1920x1080 displays, if I leave both connected, anaconda is borderline unusable, as the left hand display has most of the UI elements but not the forward/next buttons, and the right hand display is blank. not quite sure what's going on there. the only way to move between steps is to use the tab key and try to guess / remember exactly how many buttons there are in the bottom right, and what order they're in, in order to successfully hit Next.
Comment 21 Šimon Lukašík 2011-09-28 14:56:32 EDT
Beside the final *R*eboot button, Ctrl-N sequence (like *N*ext) worked for me.
Comment 22 Adam Williamson 2011-09-30 15:46:48 EDT
Discussed at 2011-09-30 blocker review meeting. Agreed this isn't a blocker as it's pretty easy to work around: disconnect the extra display.  We would also like to note that we were deeply unconvinced by the cited reason for blocker status, Adam ;). Rejected as a blocker, but accepted as NTH as this is a visible installer issue that can't be fixed by an update.
Comment 23 Adam Williamson 2011-09-30 15:47:22 EDT
quit slacking off, ajax.
Comment 24 Ian Pilcher 2011-10-01 10:06:26 EDT
(In reply to comment #20)
> while testing the EFI stuff I noticed a somewhat annoying consequence of this -
> on my desktop, which has 2x 1920x1080 displays, if I leave both connected,
> anaconda is borderline unusable, as the left hand display has most of the UI
> elements but not the forward/next buttons, and the right hand display is blank.
> not quite sure what's going on there. the only way to move between steps is to
> use the tab key and try to guess / remember exactly how many buttons there are
> in the bottom right, and what order they're in, in order to successfully hit
> Next.

I've seen this as well.  I think this happened on my laptop with 2 external displays connected.  I'd say that "borderline unusable" is a very kind
description.
Comment 25 Ian Pilcher 2011-10-01 10:08:33 EDT
(In reply to comment #22)
> Discussed at 2011-09-30 blocker review meeting. Agreed this isn't a blocker as
> it's pretty easy to work around: disconnect the extra display.  We would also
> like to note that we were deeply unconvinced by the cited reason for blocker
> status, Adam ;). Rejected as a blocker, but accepted as NTH as this is a
> visible installer issue that can't be fixed by an update.

Note that disconnecting displays is not always a realistic option, depending on one's physical setup.  (Some of us *really* like zip-ties.)  VNC and "basic
video driver" are probably better workarounds most of the time.
Comment 26 Adam Williamson 2011-10-03 23:49:58 EDT
only problem with that is that 'basic video driver' has post-install consequences - it sets vesa as the driver after install as well as using it during install.
Comment 27 Martin Gracik 2011-10-12 04:00:01 EDT
*** Bug 745096 has been marked as a duplicate of this bug. ***
Comment 28 Ales Kozumplik 2011-10-18 04:12:35 EDT
*** Bug 746879 has been marked as a duplicate of this bug. ***
Comment 29 Chris Lumens 2011-10-25 10:24:01 EDT
*** Bug 748283 has been marked as a duplicate of this bug. ***
Comment 30 Chris Lumens 2011-10-25 10:24:20 EDT
*** Bug 746794 has been marked as a duplicate of this bug. ***
Comment 31 Chris Lumens 2011-11-01 12:48:36 EDT
*** Bug 750559 has been marked as a duplicate of this bug. ***
Comment 32 John Chivall 2011-11-06 14:10:14 EST
(In reply to comment #20)
> while testing the EFI stuff I noticed a somewhat annoying consequence of this -
> on my desktop, which has 2x 1920x1080 displays, if I leave both connected,
> anaconda is borderline unusable, as the left hand display has most of the UI
> elements but not the forward/next buttons, and the right hand display is blank.
> not quite sure what's going on there. the only way to move between steps is to
> use the tab key and try to guess / remember exactly how many buttons there are
> in the bottom right, and what order they're in, in order to successfully hit
> Next.

A similar thing happens if your right-hand monitor has a lower native resolution than the left. eg. LH Monitor 1280x1024, RH monitor 1024x768

The anaconda window is spanned across both, but the buttons are then below the visible part of the RH display and thus not visible. I had to do a lot of pressing Tab and guessing to get through an upgrade. I forgot to file this bug at the time as I was having other issues with the upgrade due to #748119
Comment 33 Nathan G. Grennan 2011-11-08 16:03:50 EST
I see this with Fedora 16 Final. In my case I had a Dell 24" 1900x1200 and a Acer 20" 1680x1050. Physically the 20" was on the right, but display layout wise it was made to be left of the 24".

Another user told me he saw this with two monitors of the same model.
Comment 34 Dr. Tilmann Bubeck 2011-11-09 02:47:35 EST
I see two workaround for this bug:

1. Move the mouse to the left screen _immediately_ after the mouse occurs.
2. Disconnect the right display.

This is only a workaround. This bug should be fixed soon, because two-head display is unusable in anaconda. This would probably stop many users from installing F16.
Comment 35 Chris Lumens 2011-11-10 09:50:48 EST
*** Bug 752800 has been marked as a duplicate of this bug. ***
Comment 36 Adam Williamson 2011-11-10 16:56:13 EST
"This is only a workaround. This bug should be fixed soon, because two-head
display is unusable in anaconda. This would probably stop many users from
installing F16."

That seems like a stretch. I don't think there's too many configurations where it is impossible to disconnect one monitor temporarily.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 37 Ian Pilcher 2011-11-10 17:12:39 EST
(In reply to comment #36)
> That seems like a stretch. I don't think there's too many configurations where
> it is impossible to disconnect one monitor temporarily.

Maybe not impossible, but it can be pretty darned inconvenient (inconvenient
enough to seriously discourage testing of the installer, for example).

And honestly, this gives a *terrible* first impression of Fedora, regardless
of how easy or difficult the workaround is.  The really disheartening thing
is that it seems like this will only be fixed if it's accepted as a release
blocker ... and it won't be accepted as a release blocker.  :-(
Comment 38 Adam Williamson 2011-11-10 18:05:56 EST
"The really disheartening thing is that it seems like this will only be fixed if it's accepted as a release blocker"

That's not at all true.

It cannot be fixed for F16, now, as F16 is released. And blocker status has nothing to do with whether it gets fixed for F17.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 39 Nathan G. Grennan 2011-11-10 18:16:59 EST
The key question is will there be a respin to address this issue, and I hope so. 

I have heard of a related(maybe the same) bug where bugs are off the screen on computers with one 16:9 monitor.
Comment 40 Adam Williamson 2011-11-14 19:41:34 EST
No. We don't do release respins. We might theoretically do one in the case of some incredibly vicious bug where we were actively bricking hardware, or something, but this isn't even in my Top Ten list of unfortunate bugs we've shipped in releases. It's just a bit of a niggle.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 41 Tom Trebisky 2011-11-14 20:07:26 EST
Well I just spent a bunch of time tripping over this issue installing on Fedora 16
x86_64 from the install DVD.  I have a dual head Nvidia GeForce 6800 XT card with dual DVI connectors.  The root of the problem is that the Back and Next buttons are off in invisible space somewhere, one monitor is black, and the other monitor looks "almost right", but I found myself unable to proceed in the install process at certain points by "typing blind via the keyboard".  Just turning off the other monitor did not help things, neither did switching the two monitor cables.  The only thing that got me going was to physically unplug the monitor that was coming up with a black screen, then the installer would restrict itself to the visible universe.  Then I want on and stumbled across the "you have not created a bootloader stage1 target device" and had had enough for one day.  Stay tuned to this same channel tomorrow though!  Please do fix this for F17!!

The title of this bug is hardly informative to people who are suffering from it, maybe it makes sense to the folks who have been stroking their beards and thinking about fixing it since back in July.  I only made it here via other bugs marked as duplicates of this one which had descriptions that resembled the problem as actually experienced by a naive end user.
Comment 42 Chris Lumens 2011-11-15 10:57:21 EST
*** Bug 754176 has been marked as a duplicate of this bug. ***
Comment 43 Adam Williamson 2011-11-15 17:09:37 EST
tom: the description is exactly accurate for the purposes of actually *fixing the bug*, though. yes, turning the monitor off will not help, because the graphics card has no way of knowing whether a monitor is turned on or not, only whether it's connected.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 44 Nathan G. Grennan 2011-11-16 16:12:01 EST
Lack of respins is very lame, especially in light of this bug. I strong suggest bringing up rethinking that strategy, or at least lowering your standard on what is a blocker bug. That you on one hand knew about this bug before release, and ignored it, and then on the other hand are just going to do nothing about it seems pretty unacceptable.
Comment 45 Adam Williamson 2011-11-16 16:37:18 EST
Doing respins sucks up considerable QA and releng time which could be used doing other things. It's just not a productive investment of time to fix anything but incredibly serious bugs. This is not an incredibly serious bug: all you have to do to avoid it is unplug a monitor.

We didn't ignore the bug. It's reported, and discussed. There is considerable discussion up top between anaconda and X teams on how to fix it, which makes it clear that fixing it is not a trivial thing. Both anaconda and X teams had substantially more significant bugs to work on during the cycle. Not accepting a bug as a blocker is not the same thing as ignoring it.

We're trying to release a fast-moving product on a six month release cycle, here; inherent in that is that we are not going to be able to do perfect releases. It's just a fact. We have to set a reasonably stringent bar on what constitutes a blocker, or else we'll just never get a release done. This isn't Debian, we don't have six month freezes to polish stuff. We get, like, two weeks frozen, and then it's on to the next one. Sorry, but it's just something that's intrinsic to how Fedora operates at present. We do our best to ensure quality within the inherent limitations of the release schedule, but there *are* limitations, and we can't achieve the impossible. The entire QA team already just about killed itself getting F16 released; we had unpaid volunteers working 18 hour days on validation. It's all very well to say 'you should do this', but we can't do what we just don't have the person hours to do.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 46 Chris Lumens 2011-11-23 16:27:47 EST
*** Bug 756509 has been marked as a duplicate of this bug. ***
Comment 47 Chris Lumens 2012-01-19 13:25:22 EST
*** Bug 783094 has been marked as a duplicate of this bug. ***
Comment 48 Adam Williamson 2012-01-23 14:52:01 EST
Can we please have this thing fixed for F17, anaconda team / ajax? Especially given that during F16 it seems to have gotten to the state where you can't actually install without blind keyboard interaction, if your second screen isn't visible: when spanning, parts of anaconda wind up on both screens. At the minimum that should be fixed so that, even when spanning, the whole UI winds up on a single display.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 49 Tim Flink 2012-01-27 10:22:15 EST
Removing F16 blocker related info from the whiteboard
Comment 50 Adam Williamson 2012-01-27 13:03:56 EST
Discussed at 2012-01-27 blocker review meeting. Agreed this is not a blocker per the criteria, though it is very annoying. Accepted as NTH as it's a highly visible and inconvenient bug. Please fix it!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 51 Jóhann B. Guðmundsson 2012-02-15 16:07:40 EST
+1 to NTH got bitten by this when I install F16 on the dual monitor workstation at my previous work. Cursed so loud that I probably killed kittens when I unplugged one of the monitors.
Comment 52 Chris Lumens 2012-03-19 11:16:06 EDT
*** Bug 804461 has been marked as a duplicate of this bug. ***
Comment 53 Chris Lumens 2012-04-01 23:18:08 EDT
*** Bug 808901 has been marked as a duplicate of this bug. ***
Comment 54 Kamil Páral 2012-04-12 08:06:30 EDT
Alpha is out, re-proposing as F17 Final NTH
Comment 55 Chris Lumens 2012-04-23 10:14:47 EDT
*** Bug 815014 has been marked as a duplicate of this bug. ***
Comment 56 Adam Williamson 2012-05-04 14:07:50 EDT
We believe this may actually be fixed by the fix for https://bugzilla.redhat.com/show_bug.cgi?id=800609 - anaconda now picks the smallest big-enough mode, not the biggest available. Can people confirm with final TC2 that this is fixed? Thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 57 Adam Williamson 2012-05-04 18:04:31 EDT
Insofar as NTH status goes: discussed at 2012-05-04 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-04/f17-final-blocker-review-4.2012-05-04-17.00.log.html . We agreed to table the bug for a week in the hopes it'll turn out to be fixed and we don't have to make a decision.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 58 Dr. Tilmann Bubeck 2012-05-05 03:06:42 EDT
It is still running in span mode (and not in clone mode). And therefore it might still be running on the wrong display. 

However, together with the fix of bug #800609 anaconda should at least show all buttons and not crop them off because of different resolutions. Also everything is now running on one display and the other display is black (but you can reach it with the mouse).

Anaconda is usable without any limitations. No need to turn a monitor off or move the mouse to another window (as suggested bz duplicate comment #34).

The only problem remaining is that by using span mode, you might use the wrong display at all. This can only by fixed by using clone mode. Regarding the subject you can not close the issue (because we do not run clone mode). On the other hand, all important things should now work, therefore you can close.
Comment 59 Dr. Tilmann Bubeck 2012-05-05 03:08:13 EDT
Sorry. Forgot to mention, that my above comment #58 is based upon Fedora-17-TC2-x86_64-DVD.iso
Comment 60 Pasi Karkkainen 2012-05-06 12:41:54 EDT
I just tested F17 Final TC3 x86_64 Desktop LiveCD. Unfortunately it's still broken :(

I get span mode, NOT clone mode, and the monitor in use shows only the Fedora background picture, nothing else.

Equipment used for testing:
- HP Elitebook 8530p laptop.
- laptop is on a docking station, with the laptop LID closed, so NO internal LVDS panel in use.
- External DVI monitor connected to the dock and the only display in use.

So when I boot F17 Final TC3 Desktop LiveCD I see the normal Fedora boot messages, and when the LiveCD desktop should show up, I just get the Fedora background picture, and nothing else. Also the mouse cursor is on the "other display".

When I open the closed laptop LID, I can see the Fedora desktop on the internal LVDS.

So clearly Fedora desktop shows up on the *wrong* display. Btw ACPI lid state works properly on this laptop.. I wish it was used.. Or then clone-mode was used instead so we didn't have this problem in the first place.
Comment 61 Kamil Páral 2012-05-09 07:54:36 EDT
I tried TC3 on laptop (1400x1050) with external monitor attached over VGA (1680x1050). Anaconda is displayed on the external monitor, laptop monitor is black (but active). When I move the mouse cursor onto the laptop screen, it is clearly distorted (cursor shape wrong). When I switch to tty1, the text on laptop screen is distorted and cut from the right side (but it is mirrored, which might be the reason).
Comment 62 Pasi Karkkainen 2012-05-09 10:02:46 EDT
Kamil: Did you have both displays active? (=laptop lid open)?

Because when I tested I got the opposite results; anaconda was NOT displayed on the external monitor.. instead anaconda showed up under the closed lid.
Comment 63 Kamil Páral 2012-05-09 10:27:58 EDT
AFAIK we can't reliably detect turned off monitors/closed lids. Therefore yes, I had both monitors active.
Comment 64 Pasi Karkkainen 2012-05-09 10:44:24 EDT
Kamil: Well, people keep saying that. At least on my laptop it is possible to reliably detect if the LID is open or closed. "/proc/acpi/button/lid/LID/state" seems to work fine. I've heard other people saying the same, it works for them. 

I'm sure there are some (old?) laptops where it doesn't work, but that's not the case with every laptop.

So to resolve this bug.. two options. 

1) Make anaconda/X use clone-mode instead of span-mode.

2) Introduce boot-time option/flag "trust acpi lid state" and enable/disable displays based on the lid state information. So then people could enable it when they know it works on their hardware.. Or try if it works on their laptop. I think having an option like this is better than nothing.

Those are the options I can think of.
Comment 65 Bruno Wolff III 2012-05-13 09:26:59 EDT
+1 NTH as this affects installs from media.
Comment 66 Kamil Páral 2012-05-14 12:44:55 EDT
+1 NTH, dual displays often cause trouble. Clone mode would help.
Comment 67 Nathan G. Grennan 2012-05-16 14:27:35 EDT
I am seeing lack of back/next buttons on Fedora 17 TC5 with VMware Workstation 8.0.3. I am running it on a host with two displays, but did tell VMware Workstation to only create one for the guest instead of auto detect.
Comment 68 Petr Schindler 2012-05-21 04:48:21 EDT
+1 NTH. Is there any better idea what to put on the second monitor than clone of the first one?
Comment 69 jeff 2013-01-19 14:12:33 EST
This is still a problem with fedora 18.
Comment 70 Fedora End Of Life 2013-04-03 16:21:47 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 71 Fedora End Of Life 2015-01-09 17:29:35 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 72 Kamil Páral 2015-01-15 10:12:12 EST
(In reply to Adam Williamson (Red Hat) from comment #23)
> quit slacking off, ajax.

Didn't help.

Note You need to log in before you can comment on or make changes to this bug.