Re: F19 Installer a little better, but...
On 2013-06-14 12:53 (GMT-0700) Adam Williamson composed: On Fri, 2013-06-14 at 15:40 -0400, Felix Miata wrote: Mount point among the input fields appears above everything except (the inexplicably present input field:) device name (duplicating the larger bolder device name above it to left). One should be able to fill it in at any time, including (logically top to bottom) first. Well, no, because it's not a legitimate operation to assign a mount point to a partition that is set to contain no filesystem. It can't be mounted. Why should the configuration be allowed? If anaconda let you do this, you could then complete custom part with a partition given a mount point, but not containing a filesystem: what are you expecting anaconda to do in this case? Write a nonsensical fstab? Implement an error condition on trying to complete custom partitioning in this situation? It's already running a sanity check by not allowing some fields to be completed prior to the secret prerequsite field. Why shouldn't the check be run when the user tries to exit the screen, with another of those little ! icons to indicate something's missing? Apparently, I'm not the only one who thinks at the done-exit point is when it makes good sense to do the check: http://fm.no-ip.com/SS/Suse/yast2-04-expertPartChooseEdit0768.png http://fm.no-ip.com/SS/Suse/yast2-04-expertPart18Select0768.png http://fm.no-ip.com/SS/Suse/yast2-04-expertPart18Config0768.png http://fm.no-ip.com/SS/Suse/yast2-04-expertPart18Options0768.png Why is that better than just not allowing a mount point to be set in the first place until a filesystem is set? Easier to avoid user being frustrated. Whatever is prerequisite to other should be above other. I'm not a UI expert, so I don't know if this is an accepted principle of UI design. Might be good to ask Mo about. In USA and elsewhere Latin alphabets are normal, people read left to right and top to bottom. Top to bottom is how forms are most commonly laid out. Forms usually also allow field completion in no particular order as long as all required receive valid entries. When a prerequisite exists, typically whatever it is prerequisite to is not presented or available before it's appropriate to complete. Anaconda has this latter, but the prerequsite is a secret. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
consider people with poor vision, was Re: F19 Installer a little better, but...[consider people with poor vision
On 15/06/13 16:22, Felix Miata wrote: On 2013-06-14 12:53 (GMT-0700) Adam Williamson composed: [...] Among the many other complaints other people have raised about the installer, I don't recall one other person complaining about text being too small. Do you think people in the business of developing software or otherwise using a PC for most of any given work day are people whose vision is below average? I don't. I think quite the opposite, that those with poorer than average vision gravitate away from using a PC screen any more than they must, that many won't do it at all, and that few such people pursue occupations that require doing more than a little that requires using a PC. Net result is most in the puter business, including FOSS software testers, have both better than average vision, and more importantly, little or no understanding of or appreciation for the difficulties encountered by those who see less well. People aren't complaining because the people doing are almost entirely made up of a class of people with good vision, people who do it because they don't have undue visual obstacles to doing it. [...] For several years, I often had very misty vision because the layer of cells above my cornea could not handle moisture properly. Sometimes it was so bad that I could hardly read the keyboard at 300mm, and glancing around the screen meant I could eassily miss things. I remember concentrating hard to resolve whether a character was a comma ',' or a full stop '.' (similarly 'a' 'e') - not good for a software developer. I have had cataract surgery, and surgery to replace those layer of cells from grafts. So now I can see the screen quite fine with glasses - even from a metre away, whereas previously I needed to be at 600mm or closer depending on how misty my eyes were. Well I am 62 and still doing software development - so please do not put important things in small print and avoid dark grey text on a light grey background etc. (I can read it if I notice it, but I might miss its significant if I just glance at the screen). When my eyes were misty, I often recognised things by their overall shape even when individual characters where fuzzy. I am lucky (I know people who were a lot younger than I am, with much worse vision), I now can reduce fonts to less than their default sizes and see quite well, though I notice I tend to make browser text bigger. For me, what helped most (prior to my eye surgeries) was getting a 30 monitor. Now the biggest nuisance is swapping glasses: one for my laptop, one for my monitor, and no glasses required for walking around driving. In conclusion, there is a whole continuum between perfect vision being blind. So for really important things, especially if considered unexpected (either by new people - or people familiar with that screen, but something important has changed) be carefully how the text is presented. Cheers, Gavin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
yum question Is this ok [y/d/N]:
Hi all, can anybody explain the meaning of d in the yum prompt Is this ok [y/d/N]:? Googling this, I found this question too, but no answer. Kind regards Joachim Backes -- Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.6-300.fc19.x86_64 Joachim Backes joachim.bac...@rhrk.uni-kl.de https://www-user.rhrk.uni-kl.de/~backes -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum question Is this ok [y/d/N]:
Le 15/06/2013 10:43, Joachim Backes a écrit : Hi all, can anybody explain the meaning of d in the yum prompt Is this ok [y/d/N]:? Googling this, I found this question too, but no answer. download Kind regards Joachim Backes -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum question Is this ok [y/d/N]:
On Sat, 15 Jun 2013 10:43:21 +0200 Joachim Backes joachim.bac...@rhrk.uni-kl.de wrote: Hi all, can anybody explain the meaning of d in the yum prompt Is this ok [y/d/N]:? Googling this, I found this question too, but no answer. The same as putting yum --downloadonly -- Regards, Frank - I check for new mail app. 20min www.frankly3d.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum question Is this ok [y/d/N]:
On Sat, 15 Jun 2013 14:22:24 +0530 Someone Somewhere somewheresomeon...@gmail.com wrote: I think it should stand for yes/default/no.+ Default action may be different depending on the scrnario. Eg while installing it may be yes but qhile erasing it may be a no. Can someone confirm if my interpretation is correct? You are incorrect. -- Regards, Frank - I check for new mail app. 20min www.frankly3d.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum question Is this ok [y/d/N]:
Le 15/06/2013 10:52, Someone Somewhere a écrit : I think it should stand for yes/default/no. Default action may be different depending on the scrnario. Eg while installing it may be yes but qhile erasing it may be a no. Can someone confirm if my interpretation is correct? Default action is the one in uppercase Remi. -Kunal On Jun 15, 2013 2:17 PM, Remi Collet fed...@famillecollet.com mailto:fed...@famillecollet.com wrote: Le 15/06/2013 10:43, Joachim Backes a écrit : Hi all, can anybody explain the meaning of d in the yum prompt Is this ok [y/d/N]:? Googling this, I found this question too, but no answer. download Kind regards Joachim Backes -- test mailing list test@lists.fedoraproject.org mailto:test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20130615 changes
Compose started at Sat Jun 15 08:15:02 UTC 2013 Broken deps for x86_64 -- [0ad] 0ad-0.0.13-2.fc20.x86_64 requires libenet-1.3.7.so()(64bit) [aries-blueprint] aries-blueprint-0.3.1-5.fc19.noarch requires asm2 [aries-proxy] aries-proxy-0.3-4.fc19.noarch requires asm2 [cxf] 1:cxf-rt-2.6.6-1.fc19.noarch requires asm2 [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.12-6.fc20.x86_64 requires gcc = 0:4.8.1-1.fc20 gcc-python2-plugin-0.12-6.fc20.x86_64 requires gcc = 0:4.8.1-1.fc20 gcc-python3-debug-plugin-0.12-6.fc20.x86_64 requires gcc = 0:4.8.1-1.fc20 gcc-python3-plugin-0.12-6.fc20.x86_64 requires gcc = 0:4.8.1-1.fc20 [gdb-heap] gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17 [gnuplot] gnuplot-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit) gnuplot-minimal-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit) kyua-cli-tests-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit) [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [nodejs-better-assert] nodejs-better-assert-1.0.0-1.fc20.noarch requires npm(callsite) = 0:1.0.0 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [openlierox] openlierox-0.59-0.11.beta10.fc20.x86_64 requires libgd.so.2()(64bit) [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [oyranos] oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5 oyranos-libs-0.4.0-7.fc19.x86_64 requires libraw.so.5()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [perl-PDL] perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-flask-admin] python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee [qpid-cpp] qpid-qmf-0.22-1.1.fc20.i686 requires python-qpid = 0:0.22 qpid-qmf-0.22-1.1.fc20.x86_64 requires python-qpid = 0:0.22 [redeclipse] redeclipse-1.4-3.fc20.x86_64 requires libenet-1.3.7.so()(64bit) redeclipse-server-1.4-3.fc20.x86_64 requires libenet-1.3.7.so()(64bit) [ruby-RMagick] ruby-RMagick-2.13.1-11.fc20.1.x86_64 requires ImageMagick = 0:6.8.3.9 [rubygem-openshift-origin-common] rubygem-openshift-origin-common-1.8.10-1.fc20.noarch requires rubygem(safe_yaml) [rubygem-openshift-origin-node] rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires rubygem(safe_yaml) rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires openshift-origin-node-proxy [rubygem-qpid] rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidtypes.so.1()(64bit) rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidmessaging.so.3()(64bit) rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidcommon.so.5()(64bit) rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidclient.so.5()(64bit) [rubygem-qpid_messaging] rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidtypes.so.1()(64bit) rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidmessaging.so.3()(64bit) rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidcommon.so.5()(64bit) rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidclient.so.5()(64bit) [sagemath] sagemath-core-5.9-5.fc20.i686 requires libgd.so.2 sagemath-core-5.9-5.fc20.x86_64 requires libgd.so.2()(64bit) [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [shim-signed] shim-0.2-4.4.fc20.x86_64 requires shim-unsigned = 0:0.3-2.fc20 [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [speed-dreams] speed-dreams-2.1.0-13.trunk_r4810.fc20.2.i686 requires libenet-1.3.7.so speed-dreams-2.1.0-13.trunk_r4810.fc20.2.x86_64 requires libenet-1.3.7.so()(64bit) [spring] spring-94.1-1.fc20.x86_64 requires libassimp.so.2()(64bit) [sumwars] sumwars-0.5.6-12.fc20.x86_64 requires
F-19 Branched report: 20130615 changes
Compose started at Sat Jun 15 09:15:02 UTC 2013 Broken deps for x86_64 -- [avgtime] avgtime-0-0.5.git20120724.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [dsqlite] dsqlite-1.0-4.fc19.i686 requires libphobos-ldc.so.60 dsqlite-1.0-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [dustmite] dustmite-1-8.20121031git1fb3ac4.fc18.x86_64 requires libphobos-ldc.so.60()(64bit) [freeipa] freeipa-server-strict-3.2.1-1.fc19.x86_64 requires pki-ca = 0:10.0.2 [gl3n] gl3n-0.20120813-4.fc19.i686 requires libphobos-ldc.so.60 gl3n-0.20120813-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [nodejs-tilelive] nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) 0:0.4 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [stoken] stoken-devel-0.2-4.fc19.i686 requires pkgconfig(libtomcrypt) stoken-devel-0.2-4.fc19.x86_64 requires pkgconfig(libtomcrypt) [tango] tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60 tango-2-12.20120821git7b92443.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [avgtime] avgtime-0-0.5.git20120724.fc19.i686 requires libphobos-ldc.so.60 [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq
Re: consider people with poor vision, was Re: F19 Installer a little better, but...[consider people with poor vision
On Sat, 2013-06-15 at 12:07 +0300, moshe nahmias wrote: I agree with Gavin, I have a poor vision because of Keratoconus and on most cases it's not easy or comfortable for me to read things when installing fedora. More important is that we should consider poor eyesight since we want any one to be able to install and use fedora. I would want (for F20 if possible) to be able to change the font size easily. It's really not technically possible to do that with how anaconda's written. The UI is to an extent written around the text. You can't just change all the text to be 20pt in size and still have the UI work; stuff just doesn't _fit_ any more. I'm going to look up some a11y guidelines from respectable institutions and file a few bugs on things it might be plausible to fix, but it's not any kind of simple 'implement ctrl+' fix, I'm afraid. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Problem with xorg-x11 or mesa or radeon.
I have Fedora 19 installed in virtualbox running on Win 7 host and I have Fedora 19 running on bare metal on the same machine --not at the same time of course. Anyway, blender works perfect running in VBox but on bare metal it crashes. The difference between the systems are mesa and radeon driver which is what makes me think the problem is there but I really don't know how to debug it. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On 2013-06-15 08:08 (GMT-0700) Adam Williamson composed: I would want (for F20 if possible) to be able to change the font size easily. It's really not technically possible to do that with how anaconda's written. I suspect the solution is both possible, and easier than you think. Likely it's constructed in similar fashion to web pages that size in pixels instead of characters (em/rem/ex) or fractions thereof. Dispensing with pixel values of more than a single digit for sizing anything other than bitmap images unleashes the natural adaptability of a display screen that doesn't apply to designing for paper. The UI is to an extent written around the text. You can't just change all the text to be 20pt in size and still have the UI work; stuff just doesn't _fit_ any more. I'm going to look up some a11y guidelines from respectable institutions and file a few bugs on things it might be plausible to fix, but it's not any kind of simple 'implement ctrl+' fix, I'm afraid. I've filed the first one for you: X forced DPI = 96 on displays natively 96 DPI causes a11y issues https://bugzilla.redhat.com/show_bug.cgi?id=974780 -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Sat, 15 Jun 2013 14:57:18 -0400 Felix Miata wrote: X forced DPI = 96 on displays natively 96 DPI causes a11y issues https://bugzilla.redhat.com/show_bug.cgi?id=974780 But you gotta be really careful :-). My Samsung TV I use as a display reports itself as 7 inches (it is really 46). If it actually believes the EDID info, you get fonts so gigantic nothing actually fits on the screen :-). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Sat, 2013-06-15 at 14:57 -0400, Felix Miata wrote: On 2013-06-15 08:08 (GMT-0700) Adam Williamson composed: I would want (for F20 if possible) to be able to change the font size easily. It's really not technically possible to do that with how anaconda's written. I suspect the solution is both possible, and easier than you think. Likely it's constructed in similar fashion to web pages that size in pixels instead of characters (em/rem/ex) or fractions thereof. Dispensing with pixel values of more than a single digit for sizing anything other than bitmap images unleashes the natural adaptability of a display screen that doesn't apply to designing for paper. No, that's not the point at all. The point is that there is only so much space for text in the UI. Have you tried running anaconda in Japanese or German at 800x600? When there's too much text on a spoke (those are both languages which use a lot of characters to say the same thing compared to English), the display of the spoke becomes entirely corrupted. The UI is to an extent written around the text. You can't just change all the text to be 20pt in size and still have the UI work; stuff just doesn't _fit_ any more. I'm going to look up some a11y guidelines from respectable institutions and file a few bugs on things it might be plausible to fix, but it's not any kind of simple 'implement ctrl+' fix, I'm afraid. I've filed the first one for you: X forced DPI = 96 on displays natively 96 DPI causes a11y issues https://bugzilla.redhat.com/show_bug.cgi?id=974780 Well, no, that's absolutely useless and just reviving a decade old bikeshed. That is not what I was planning to do at all. Fixed 96dpi is a ship that's sailed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Sat, 2013-06-15 at 12:12 -0700, Adam Williamson wrote: On Sat, 2013-06-15 at 14:57 -0400, Felix Miata wrote: On 2013-06-15 08:08 (GMT-0700) Adam Williamson composed: I would want (for F20 if possible) to be able to change the font size easily. It's really not technically possible to do that with how anaconda's written. I suspect the solution is both possible, and easier than you think. Likely it's constructed in similar fashion to web pages that size in pixels instead of characters (em/rem/ex) or fractions thereof. Dispensing with pixel values of more than a single digit for sizing anything other than bitmap images unleashes the natural adaptability of a display screen that doesn't apply to designing for paper. No, that's not the point at all. The point is that there is only so much space for text in the UI. Have you tried running anaconda in Japanese or German at 800x600? When there's too much text on a spoke (those are both languages which use a lot of characters to say the same thing compared to English), the display of the spoke becomes entirely corrupted. Oh, and trying to size an entire UI in relative units in a GTK+/glade project is a giant PITA, so far as I understand. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On 2013-06-15 15:04 (GMT-0400) Tom Horsley composed: On Sat, 15 Jun 2013 14:57:18 -0400 Felix Miata wrote: X forced DPI = 96 on displays natively 96 DPI causes a11y issues https://bugzilla.redhat.com/show_bug.cgi?id=974780 But you gotta be really careful :-). My Samsung TV I use as a display reports itself as 7 inches (it is really 46). If it actually believes the EDID info, you get fonts so gigantic nothing actually fits on the screen :-). Obviously competent provision for working around bad EDID is necessary. The bug is explicitly about working with valid EDID. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Validation tests not yet run against Final
Here are the installation test cases which have not yet been run against any of the Final TCs for any arch: https://fedoraproject.org/wiki/QA:Testcase_install_to_PATA_device I installed Fedora-19-Final-TC3-i386-DVD.iso MATE desktop to bare metal i686 having no SATA channels and two PATA channels: one with two EIDE harddrives (IDE0 master and slave) and one with two DVD drives (IDE1 master and slave). Everything worked; all tests on that page above passed. I couldn't find the summary page to update the test coverage matrix. -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: installing TC3 on EFI
On Sat, 2013-06-15 at 21:09 +0300, moshe nahmias wrote: Hi, I tried to install F19-TC3 on my laptop and it didn't work, while trying to file a bug anaconda stopped responding and just hang there, I wanted to try and copy the info that was on the retrace right below the question if I want to file a bug but couldn't. The bug was reported according to ABRT as bug number 947142 for fedora 18. When installing with bios it worked perfectly and now I update the system without rsyslog as adam suggested. If there is more info you need/want just ask away and I will do my best to answer it. Unfortunately if you couldn't get the backtrace, it's pretty much impossible to know what the problem was :( Can you re-try the install on that laptop, or is it a system you need to use? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Validation tests not yet run against Final
On Sat, 2013-06-15 at 12:20 -0700, John Reiser wrote:
Here are the installation test cases which have not yet been run against
any of the Final TCs for any arch:
https://fedoraproject.org/wiki/QA:Testcase_install_to_PATA_device
I installed Fedora-19-Final-TC3-i386-DVD.iso MATE desktop to bare metal i686
having no SATA channels and two PATA channels: one with two EIDE harddrives
(IDE0 master and slave) and one with two DVD drives (IDE1 master and slave).
Everything worked; all tests on that page above passed.
I couldn't find the summary page to update the test coverage matrix.
D'oh, of course, I should have linked it.
https://fedoraproject.org/wiki/Test_Results:Fedora_19_Final_TC3_Install
you'd just want to insert a {{result|pass|jreiser}} (or whatever your
FAS name is) in the appropriate spot. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: installing TC3 on EFI
On Sat, 2013-06-15 at 22:37 +0300, moshe nahmias wrote: I can re-try but would prefer to know what I need to do before hand, so I won't need to do it again afterwards or at least lower the chances of doing so again. what should I do when the bug hit again? I don't care to try multiple times as long as it's done one after the other to find something and not for every question here. I do need this computer but can do it for now, hopefully the debugging will be short enough so we will be able to find the culprit before I will have to stop. All we really need to do is get the backtrace out. You could try the reporting tool again, or when it crashes, you can hit ctrl-alt-f2 which should get you a console, and you should find an anaconda-tb-(something) file in /tmp - you can fpaste it out if you have a network connection, or plug in a USB stick, mount it and copy to that. Oh, and also get /tmp/program.log. Thanks! BTW, if it's possible to do dual boot, one install with bios and the other with EFI That's very unlikely to work on a single disk. It might work in theory with two+ disks if you only have one type of install per disk, but it's entirely possible that some firmwares would be buggy with this setup. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rsyslog
On Sat, 2013-06-15 at 15:40 -0400, Frank McCormick wrote: Update wants to replace rsyslog on my system- I have downgraded rsyslog to handle the spamming log problem. [root@franksfedora19 frank]# yum update Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package rsyslog.i686 0:7.2.6-1.fc19 will be updated --- Package rsyslog.i686 0:7.4.0-1.fc19 will be an update -- Finished Dependency Resolution Is it safe now to allow it to be upgraded ? if you have updated to systemd 204-8, it ought to be safe. If you have inflated logs from the SELinux accounts-daemon bug, then rsyslog will still run the CPU to 100% for some time after the upgrade, because it'll be writing the entire journal out to /var/log/messages; but it will eventually complete and quiet down. Personally I recommend pruning the journal first if you have a huge journal full of those SELinux messages - if your system logs aren't that important to you, you can safely just blow away the larger (over 10MB) files in /var/log/journal and that should trim the journal down to a reasonable size. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On 2013-06-15 12:12 (GMT-0700) Adam Williamson composed: The point is that there is only so much space for text in the UI. Have you tried running anaconda in Japanese or German at 800x600? When there's too much text on a spoke (those are both languages which use a lot of characters to say the same thing compared to English), the display of the spoke becomes entirely corrupted. Who's forcing anyone to run a native display mode during installation? The Mandriva/Mageia approach seems rather sensible: announce a limited choice of display resolutions at initialization and in the docs, then use the highest of the limited choices even when the device's native mode is much higher. It/they default to 800x600, offering text and 1024x768 as alternatives, and plant windows sized to 1024x768 in the middle of a larger background for any who figure out how to (unnecessarily) get X into any mode higher than 1024x768 during the OS installation process. Well, no, that's absolutely useless and just reviving a decade old bikeshed. That is not what I was planning to do at all. Fixed 96dpi is a ship that's sailed. It can't be denied that forcing is doing what it's doing. Whether to do anything about it directly is a different matter. If there's an easier way to keep text from shrinking as display size increases, fine; but don't continue to penalize people who follow a logical course of action when they need or want bigger. Text that shrinks as available space for it increases is idiotic. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On 2013-06-15 12:14 (GMT-0700) Adam Williamson composed: Oh, and trying to size an entire UI in relative units in a GTK+/glade project is a giant PITA, so far as I understand. Maybe with the increasing disparity among environments the time has come to retire it. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Sat, 2013-06-15 at 15:46 -0400, Felix Miata wrote: On 2013-06-15 12:12 (GMT-0700) Adam Williamson composed: The point is that there is only so much space for text in the UI. Have you tried running anaconda in Japanese or German at 800x600? When there's too much text on a spoke (those are both languages which use a lot of characters to say the same thing compared to English), the display of the spoke becomes entirely corrupted. Who's forcing anyone to run a native display mode during installation? The Mandriva/Mageia approach seems rather sensible: announce a limited choice of display resolutions at initialization and in the docs, then use the highest of the limited choices even when the device's native mode is much higher. It/they default to 800x600, offering text and 1024x768 as alternatives, and plant windows sized to 1024x768 in the middle of a larger background for any who figure out how to (unnecessarily) get X into any mode higher than 1024x768 during the OS installation process. What? I didn't say anything about native resolutions. The point is that anaconda's layout gets completely corrupted if text takes up too much space. If you make the text bigger, which is what you're proposing, people are inevitably going to start running into that problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Sat, 2013-06-15 at 15:46 -0400, Felix Miata wrote: Well, no, that's absolutely useless and just reviving a decade old bikeshed. That is not what I was planning to do at all. Fixed 96dpi is a ship that's sailed. It can't be denied that forcing is doing what it's doing. Whether to do anything about it directly is a different matter. If there's an easier way to keep text from shrinking as display size increases, fine; but don't continue to penalize people who follow a logical course of action when they need or want bigger. Text that shrinks as available space for it increases is idiotic. You're drawing an erroneous conclusion from a sample of two displays. It is not always the case that larger displays have a higher native DPI than smaller displays. In fact, desktop PC displays almost all have DPIs in the narrow range of 95-110 - varying within that range in a fashion that is not predictably related to screen size - precisely because Windows locks its DPI to 96 by default, and with a 'logical' DPI of 96, a display with a 'physical' DPI of about 100-105 is what looks 'right' to most people. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Sat, 15 Jun 2013 12:51:09 -0700 Adam Williamson wrote: You're drawing an erroneous conclusion from a sample of two displays. It is not always the case that larger displays have a higher native DPI than smaller displays. So we just need to all chip in and buy the anaconda developers one of these, and suddenly font sizes and readability would become a high priority :-). http://www.sharp-world.com/products/professional-monitors/products/pn-k321/index.html -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rsyslog
On 06/15/2013 03:43 PM, Adam Williamson wrote: On Sat, 2013-06-15 at 15:40 -0400, Frank McCormick wrote: Update wants to replace rsyslog on my system- I have downgraded rsyslog to handle the spamming log problem. [root@franksfedora19 frank]# yum update Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package rsyslog.i686 0:7.2.6-1.fc19 will be updated --- Package rsyslog.i686 0:7.4.0-1.fc19 will be an update -- Finished Dependency Resolution Is it safe now to allow it to be upgraded ? if you have updated to systemd 204-8, it ought to be safe. I have. If you have inflated logs from the SELinux accounts-daemon bug, then rsyslog will still run the CPU to 100% for some time after the upgrade, because it'll be writing the entire journal out to /var/log/messages; but it will eventually complete and quiet down. Personally I recommend pruning the journal first if you have a huge journal full of those SELinux messages - if your system logs aren't that important to you, you can safely just blow away the larger (over 10MB) files in /var/log/journal and that should trim the journal down to a reasonable size. I chose to deleteseems to be running fine...but I'll keep an eye on it for a while. Thanks -- --Cheers-- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Sat, 2013-06-15 at 16:03 -0400, Tom Horsley wrote: On Sat, 15 Jun 2013 12:51:09 -0700 Adam Williamson wrote: You're drawing an erroneous conclusion from a sample of two displays. It is not always the case that larger displays have a higher native DPI than smaller displays. So we just need to all chip in and buy the anaconda developers one of these, and suddenly font sizes and readability would become a high priority :-). http://www.sharp-world.com/products/professional-monitors/products/pn-k321/index.html Oh, you can get a high DPI display much cheaper: just buy a MBP Retina or a Pixel (or a Kirabook, now). But they kinda prove the point that (as you say) dpi-fundamentalism is misguided. My laptop is 1920x1080 at 13, which is about 170dpi, but if I set it to 170 dpi the fonts look *huge*. If I set it to 170dpi and put the laptop 1.5 feet away from my eyes, where my desktop displays are, it looks fine...and then I can't type on it any more. In practice, I set my laptop's dpi to about 130 to get it to 'look right'. I rather suspect the world is going to go with the dumb-but-practical Apple solution: have a few DPI Buckets and just support those. So maybe you'll be able to use 96, 144 or 192 and things will be made to 'look right'... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Unable to graphically EFI boot Fedora in vbox
On Jun 14, 2013, at 12:35 AM, Andre Robatino robat...@fedoraproject.org wrote: Chris Murphy lists at colorremedies.com writes: I just tried it with Fedora-19-TC2-x86_64-DVD.iso in Oracle VirtualBox 4.2.12 and it worked for me. Still not working with Fedora-Live-Desktop-x86_64-19-TC3-1.iso and VirtualBox 4.2.12 on OS X. What are your VirtualBox video settings? Do you have either 3D or 2D acceleration enabled? How much video memory? And how many CPUs? Guest additions and Extension Pack installed, 3D enabled, 2D disabled (it only works for Windows guests anyway), 12 MB of video memory, 1024 MB of RAM, 1 CPU. OK well I can't build guest additions for Live media, since on reboot it's gone anyway. The issue is that booting Live media doesn't bring up X and therefore no gdm, no gnome shell, and no anaconda. So is the prescribed procedure to use text install in this case? Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rsyslog
On Sat, Jun 15, 2013 at 12:43:53PM -0700, Adam Williamson wrote: but it will eventually complete and quiet down. Personally I recommend pruning the journal first if you have a huge journal full of those SELinux messages - if your system logs aren't that important to you, you can safely just blow away the larger (over 10MB) files in /var/log/journal and that should trim the journal down to a reasonable size. It would be handy if there were a journalctl command to force discard logs from before a certain time or down to a certain size. I tried to look for an existing RFE for this but couldn't find one, so I filed this: https://bugzilla.redhat.com/show_bug.cgi?id=974787 -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: installing TC3 on EFI
On Sat, 2013-06-15 at 16:28 -0400, Chris Murphy wrote: On Jun 15, 2013, at 3:37 PM, moshe nahmias mosheg...@gmail.com wrote: BTW, if it's possible to do dual boot, one install with bios and the other with EFI then I can do it and then I will be able to do it for much longer since I have a bios installation now that works. It's not advised to run CSM (BIOS) because in many (all?) implementations AHCI isn't fully supported so you get SATA devices in a fallback IDE mode and therefore poor performance. My Asus motherboard does AHCI on CSM just fine. Also ACPI is limited so battery life of the laptop isn't so great. Do you have a source for this? I did a CSM install on my new laptop because doing a native UEFI install was a pain, and I haven't noticed any particular issues with drive performance or battery life. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rsyslog
On Sat, 2013-06-15 at 16:33 -0400, Matthew Miller wrote: On Sat, Jun 15, 2013 at 12:43:53PM -0700, Adam Williamson wrote: but it will eventually complete and quiet down. Personally I recommend pruning the journal first if you have a huge journal full of those SELinux messages - if your system logs aren't that important to you, you can safely just blow away the larger (over 10MB) files in /var/log/journal and that should trim the journal down to a reasonable size. It would be handy if there were a journalctl command to force discard logs from before a certain time or down to a certain size. I tried to look for an existing RFE for this but couldn't find one, so I filed this: There are settings for rotating / pruning the logs in /etc/systemd/journald.conf , but they don't seem to work terribly well when you have huge single files. A manual discard command might be nice, but what I was thinking of RFE'ing was some kind of rate limiting, especially for identical messages. I'm not sure anyone really _needs_ the same AVC printed into their logs every three seconds; just a note that a given AVC had occurred 1000 times in the last hour or whatever would be sufficient. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rsyslog
On Sat, Jun 15, 2013 at 01:36:54PM -0700, Adam Williamson wrote: There are settings for rotating / pruning the logs in /etc/systemd/journald.conf , but they don't seem to work terribly well when you have huge single files. A manual discard command might be nice, but what I was thinking of RFE'ing was some kind of rate limiting, especially for identical messages. I'm not sure anyone really _needs_ the same AVC printed into their logs every three seconds; just a note that a given AVC had occurred 1000 times in the last hour or whatever would be sufficient. There *is* rate limiting, but maybe it needs more fine-tuning. RateLimitInterval=, RateLimitBurst= Configures the rate limiting that is applied to all messages generated on the system. If in the time interval defined by RateLimitInterval= more messages than specified in RateLimitBurst= are logged by a service all further messages within the interval are dropped, until the interval is over. A message about the number of dropped messages is generated. This rate limiting is applied per-service, so that two services which log do not interfere with each other's limits. Defaults to 200 messages in 10s. The time specification for RateLimitInterval= may be specified in the following units: s, min, h, ms, us. To turn off any kind of rate limiting, set either value to 0. I've often had the _opposite_ problem, where some program spitting out tracebacks or other verbose information gets cut off. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Unable to keep Input Method running
What does this mean? This is F19 from TC3 running on omen.com. -- Chuck Forsberg WA7KGX c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Unable to graphically EFI boot Fedora in vbox
I downloaded and tested Fedora-Live-Desktop-x86_64-19-TC3-1.iso and it does not come up graphically for me either - see https://bugzilla.redhat.com/show_bug.cgi?id=742695#c19 . Can you verify that that is what you see as well? And could you try it with an install image? (Fedora-19-TC3-x86_64-netinst.iso works for me.) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
