Re: F19 Final criteria revamp
On Sun, 2013-06-09 at 23:34 -0400, Chris Murphy wrote: On Jun 5, 2013, at 12:55 AM, Adam Williamson awill...@redhat.com wrote: * We were covering bootloaders in a half-assed way in the Windows dual boot criterion, but that seemed kinda dumb, so I figured it would make sense to break out an explicit bootloader criterion: The installer must allow the user to choose which disk the system bootloader will be installed to, and to choose not to install one at all. In practice that's basically what we required to work for F18. I'd like to point out a problem with the existing #9 final criterion, which reads: • The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working. It seems the single-partition requirement has been unreasonable for a long time, since Windows 7/8 OEM installations are multi-partition, and if the disk partition is erased and Windows 7/8 is re-installed on an unpartitioned disk, it creates multiple partition installations. Oh, yes - I forgot to mention it in my write-up, but I actually recalled you raising that issue before, and adjusted the text of the rewritten criterion somewhat. Could you take a look and see if it's better now, or still needs improving? Thanks. In particular, what's the default 'multi-partition' layout of Win7/8? I don't think I've seen a stock install of either (I still use an old copy of XP for Windows testing, here.) -- 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
[Test-Announce] CANCELLED: 2013-06-10 Fedora QA Meeting (blocker meeting still on)
It's been a while, but it looks like we can skip the QA meeting this week: I'm not aware of any topics that particularly need discussion outside of 19 Final work, and I don't see that anyone else has proposed any. Note that we will still aim to do a blocker review meeting at 16:00 - I'll send out a separate announcement for that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] 2013-06-10 @ 16:00 UTC - F19 Final Blocker Bug Review #4
# F19 Final Blocker Review meeting #4 # Date: 2013-06-10 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net We're cancelling the QA meeting for 2013-06-10, but we should still get together and do some blocker review at 16:00 - we have all the blockers and anaconda FEs proposed since Wednesday to go through! Please, folks - including non-regulars, and people who aren't necessarily 'QA people' but are interested in helping make sure the 19 release goes ahead smoothly - come out and contribute! Blocker meeting attendance has been kind of thin lately and it'd be nice to avoid it turning into too much of a cabal, it's good to have a range of opinions and expertise. Note that blocker reviews are a joint exercise of QA, release engineering and development, they're not just a 'QA thing'. We'll be running through the final blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria For guidance on Blocker and FreezeException bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 07:51 AM, Adam Williamson wrote: On Sun, 2013-06-09 at 23:34 -0400, Chris Murphy wrote: On Jun 5, 2013, at 12:55 AM, Adam Williamson awill...@redhat.com wrote: * We were covering bootloaders in a half-assed way in the Windows dual boot criterion, but that seemed kinda dumb, so I figured it would make sense to break out an explicit bootloader criterion: The installer must allow the user to choose which disk the system bootloader will be installed to, and to choose not to install one at all. In practice that's basically what we required to work for F18. I'd like to point out a problem with the existing #9 final criterion, which reads: • The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working. It seems the single-partition requirement has been unreasonable for a long time, since Windows 7/8 OEM installations are multi-partition, and if the disk partition is erased and Windows 7/8 is re-installed on an unpartitioned disk, it creates multiple partition installations. Oh, yes - I forgot to mention it in my write-up, but I actually recalled you raising that issue before, and adjusted the text of the rewritten criterion somewhat. Could you take a look and see if it's better now, or still needs improving? Thanks. In particular, what's the default 'multi-partition' layout of Win7/8? I don't think I've seen a stock install of either (I still use an old copy of XP for Windows testing, here.) We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Red Hat can just keep this criteria for RHEL if that's the reason for it to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) They don't depend on Windows, they depend on our tools that detect Windows. nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. We don't have to have this tested. If there are no bug reports, there's probably nothing to fix. OTOH, sure, it's better when it gets tested. If we have the means. Red Hat can just keep this criteria for RHEL if that's the reason for it The reason is that Windows dual-boot is very important for our users and we are usually capable of making sure it works. If you want to have no user base, sure, dump Windows support. to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. Microsoft provides Windows 8 evaluation copies that you can use legally and for free. Of course, IANAL. And we don't seem to lack for community testers that have a Windows installation present. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
RAT mouse clicking problem
Hi! I've installed TC2 and everything seems to run fine so far. I am however running into an issue I had randomly under F18 (when the mouse was new) where the (left) clicking seems to lock the mouse into the application into which it clicks. The issue seems to be more systematic now but maybe it's just the same. I did an extensive web search a few month back and came up with an added /etc/X11/xorg.conf.d/03-rat.conf file which read this: Section InputClass Identifier Mouse Remap MatchProduct Saitek Cyborg R.A.T.7 Mouse MatchDevicePath /dev/input/event* Option Buttons 17 Option ButtonMapping 1 2 3 4 5 0 0 8 9 7 6 12 13 13 13 16 17 18 19 20 21 Option AutoReleaseButtons 13 14 15 Option ZAxisMapping 4 5 6 7 EndSection On my first login the problem systematically appears, I then go to any application that has a setting window that will come over the main window, adjust the click to work properly (by clicking on the mode button) and then log out and back in. I often use the Settings/Displays app, disable a monitor, apply and then cancel the changes. Canceling the changes doesn't initially work until switching modes (by clicking on the mode/preset button 1/2 or 3 times). This fixes this issue. What would be the best way to get rid of this problem? Thanks. Fred -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 10:08 AM, Kamil Paral wrote: We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) They don't depend on Windows, they depend on our tools that detect Windows. nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. We don't have to have this tested. If there are no bug reports, there's probably nothing to fix. OTOH, sure, it's better when it gets tested. If we have the means. Red Hat can just keep this criteria for RHEL if that's the reason for it The reason is that Windows dual-boot is very important for our users and we are usually capable of making sure it works. If you want to have no user base, sure, dump Windows support. Our user base is Fedora users not Windows users or dual booting users and more or less every shipped hardware in the past five years has supported virtualization ( even more so HW requirements for running windows Vista/7/8 not sure if XP is still supported by Microsoft ) which is the area we should be focusing on supporting well as in running Fedora in other OS supported/provided virtualization or running other OS in the virtualization we provide ( there is no such thing as support in Fedora ). Quite frankly dual booting is a thing of the past and it should be dropped from the criteria. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: os-prober and fd0?
On Sun, 09 Jun 2013 18:55:49 -0700 Adam Williamson wrote: The way to achieve this, though, is to file a bug report. Could you do that? Thanks. Done: https://bugzilla.redhat.com/show_bug.cgi?id=972670 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Unicode and console font problem?
I just installed f19 beta, picking minimal install, which does not install X - I just get a console login. The apostrophe-like thing in Schrödinger's cat (which prints in the login prompt) shows up as a white block (I do get the 'o' with the two little dots above it though). I also copied some files from one partition to another and the message it prints asking about overwriting a file also has square blocks instead of quotes around the filename it prints in the message. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 10:49 (GMT) Jóhann B. Guðmundsson composed: Quite frankly dual booting is a thing of the past and it should be dropped from the criteria. Yet another Fedora way to alienate users. While dual booting is indeed a thing of the '80's, multibooting isn't going away just because virtualization exists. Virtually all my 30+ usable systems are multiboot, regardless whether their hardware supports virtualization. Most of them don't. Virtualization is emulation, faking. Some testing requires using real hardware. Some environments require using real hardware. Some users require real hardware. Even if I personally embraced the concept of virtualization as a replacement for multiboot, I wouldn't want to use a host OS with a mere 18 month support life. -- 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: F19 Final criteria revamp
On 06/10/2013 11:56 AM, Felix Miata wrote: Yet another Fedora way to alienate users. While dual booting is indeed a thing of the '80's, multibooting isn't going away just because virtualization exists. Virtually all my 30+ usable systems are multiboot, regardless whether their hardware supports virtualization. Most of them don't. And in what are you using those 30+ usable system and why aren't you running Fedora only on them? Virtualization is emulation, faking. Some testing requires using real hardware. Some environments require using real hardware. Some users require real hardware. Even if I personally embraced the concept of virtualization as a replacement for multiboot, I wouldn't want to use a host OS with a mere 18 month support life. Then perhaps Fedora is not the distribution for you to use since it has such an short life cycle ( 13 months ) + we are just talking about removing this from the release critera not stop supporting this. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20130610 changes
Compose started at Mon Jun 10 08:15:03 UTC 2013 Broken deps for x86_64 -- [bind10] bind10-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-1.0.0-3.fc20.x86_64 requires liblog4cplus-1.1.so.5()(64bit) bind10-dhcp-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-dhcp-1.0.0-3.fc20.x86_64 requires liblog4cplus-1.1.so.5()(64bit) bind10-dns-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-dns-1.0.0-3.fc20.x86_64 requires liblog4cplus-1.1.so.5()(64bit) [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) [gdb-heap] gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17 [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 [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [lutok] lutok-devel-0.2-4.fc19.i686 requires lua-devel 0:5.2 lutok-devel-0.2-4.fc19.x86_64 requires lua-devel 0:5.2 [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) [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) [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-cpp-server-xml-0.20-6.fc20.x86_64 requires libxqilla.so.5()(64bit) [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) [spring] spring-94.1-1.fc20.x86_64 requires libassimp.so.2()(64bit) [tex-simplecv] tex-simplecv-doc-1.6-12.fc19.noarch requires texlive-texmf-doc [tuna] tuna-0.11-1.fc20.noarch requires python-linux-procfs = 0:0.4.6 [zarafa] libmapi-7.0.13-1.fc19.i686 requires libicalss.so.0 libmapi-7.0.13-1.fc19.i686 requires libical.so.0 libmapi-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit) libmapi-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit) 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 zarafa-ical-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit) zarafa-ical-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit) Broken deps for i386 -- [bind10] bind10-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-dhcp-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 bind10-dns-1.0.0-3.fc20.i686 requires liblog4cplus-1.1.so.5 [ekiga] ekiga-4.0.1-1.fc19.i686 requires libedata-book-1.2.so.17 [gdb-heap] gdb-heap-0.5-12.fc19.i686 requires glibc(x86-32) = 0:2.17 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [lutok] lutok-devel-0.2-4.fc19.i686 requires lua-devel 0:5.2 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.i686 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.i686 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.i686 requires libgdmsimplegreeter.so.1 [oyranos] oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5 [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.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) [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
Re: Unable to graphically EFI boot Fedora in vbox
https://bugzilla.redhat.com/show_bug.cgi?id=742695#c13 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Jun 10, 2013, at 4:46 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: We should just drop that entirely. That's unrealistic. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Well it's a matter of some recruitment and volunteering of interested parties to do some testing before the product goes final, isn't it? I don't think any of the hard core testers should be required to buy it. Some impetus is on users with a vested interest in it working to do the testing, and presumably they have it. On Jun 10, 2013, at 6:49 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Our user base is Fedora users not Windows users or dual booting users and more or less every shipped hardware in the past five years has supported virtualization Quite frankly dual booting is a thing of the past and it should be dropped from the criteria. This is specious. Fedora users depend on dual boot more than RHEL users, not the other way around. Fedora users largely depend on another OS as their primary OS. Of those perhaps most are virtualizing Fedora in a non-KVM environment, and the second is baremetal dual boot. Dual boot capability is important because it creates the condition to improve linux's ability to run on a variety of hardware, video card drivers and so forth. If linux runs well to excellent, then running Windows (or OS X) in qemu/kvm is then realistic. On a whole lot of hardware that's just not the case. Chris Murphy -- 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 10, 2013, at 8:42 AM, Andre Robatino robat...@fedoraproject.org wrote: https://bugzilla.redhat.com/show_bug.cgi?id=742695#c13 add inst.usefbx and video=efifb to the linuxefi kernel line in grub2 So in the case of baremetal EFI, X detects something adequately enough that it works. But somehow on vbox it isn't. It'd be nice if this worked better. This is an old bug. Chris Murphy -- 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 10, 2013, at 9:07 AM, Chris Murphy li...@colorremedies.com wrote: On Jun 10, 2013, at 8:42 AM, Andre Robatino robat...@fedoraproject.org wrote: https://bugzilla.redhat.com/show_bug.cgi?id=742695#c13 add inst.usefbx and video=efifb to the linuxefi kernel line in grub2 This doesn't work for me. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 12:57 PM, Chris Murphy wrote: On Jun 10, 2013, at 4:46 AM, Jóhann B. Guðmundssonjohan...@gmail.com wrote: We should just drop that entirely. That's unrealistic. There is nothing unrealistic removing it from the criteria but still retain the test case(s) like we do for other things that people want to have tested without having it blocking the release... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-19 Branched report: 20130610 changes
Compose started at Mon Jun 10 09:15:03 UTC 2013 Broken deps for x86_64 -- [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [freeipa] freeipa-server-strict-3.2.0-2.fc19.x86_64 requires krb5-server = 0:1.11.2 [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 [llvm] clang-3.3-0.4.rc2.fc19.i686 requires libstdc++-devel = 0:4.8.0 clang-3.3-0.4.rc2.fc19.i686 requires gcc = 0:4.8.0 clang-3.3-0.4.rc2.fc19.x86_64 requires libstdc++-devel = 0:4.8.0 clang-3.3-0.4.rc2.fc19.x86_64 requires gcc = 0:4.8.0 [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) [postgresql-plparrot] postgresql-plparrot-0.05-4.fc19.x86_64 requires libparrot.so.5.0.0()(64bit) [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) [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 -- [deltacloud-core] deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) = 0:0.0.18 [dragonegg] dragonegg-3.1-19.fc19.i686 requires gcc = 0:4.7.2-9.fc19 [freeipa] freeipa-server-strict-3.2.0-2.fc19.i686 requires krb5-server = 0:1.11.2 [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-1.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.i686 requires php(zend-abi) = 0:20100525-x86-32 php-kolab-0.4.1-3.fc19.i686 requires php(api) = 0:20100412-x86-32 [llvm] clang-3.3-0.4.rc2.fc19.i686 requires libstdc++-devel = 0:4.8.0 clang-3.3-0.4.rc2.fc19.i686 requires gcc = 0:4.8.0 [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.i686 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.i686 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.i686 requires libgdmsimplegreeter.so.1 [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.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) [postgresql-plparrot] postgresql-plparrot-0.05-4.fc19.i686 requires libparrot.so.5.0.0 [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) [zarafa] php-mapi-7.0.13-1.fc19.i686 requires php(zend-abi) = 0:20100525-x86-32 php-mapi-7.0.13-1.fc19.i686 requires php(api) = 0:20100412-x86-32 Updated Packages: dosfstools-3.0.17-1.fc19 * Tue Jun 04 2013 Jaroslav Škarvada jskar...@redhat.com - 3.0.17-1 - New version Resolves: rhbz#968400 - Dropped fix-label patch (upstreamed) Size change: 520 bytes gnome-nettool-3.8.1-1.fc19 -- * Sun Jun 02 2013 Kalev Lember kalevlem...@gmail.com - 3.8.1-1 - Update to 3.8.1 Size change: -78 bytes hercules-3.08.2-1.fc19
Re: Unable to graphically EFI boot Fedora in vbox
Chris Murphy lists at colorremedies.com writes: add inst.usefbx and video=efifb to the linuxefi kernel line in grub2 This doesn't work for me. I just tried it with Fedora-19-TC2-x86_64-DVD.iso in Oracle VirtualBox 4.2.12 and it worked for me. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: windows7/8 in a gnome box
On Sun, Jun 09, 2013 at 09:55:54PM -0300, Germán A. Racca wrote: On 06/09/2013 01:56 PM, Alexander Volovics wrote: I wanted to test gnome-boxes on a fully updated fed19 beta. Both Win7 and Win8 install without problems but I am unable to enable 16:9 fullscreen (or any 16:9 screen). For example 1600x900 does not appear in the Windows screen resolution settings menu. (gnome-boxes 3.8.3) In fed19 beta I also checked with kvm/qemu but the problem remains. I'm also able to use fullscreen in my F19beta vm. What do you mean by 'fullscreen'. My laptop has a 1600:900 screen. When I install Win7 in kvm-qemu (or in a gnome-box) I can run the VM in fullscreen but NOT Win7. You have to adjust the screen resolution in Win7 and as Win7 only sees a 'standard vga graphics adapter' you cannot get a 1600:900 resolution. The best you can do is 1680x1050 but this does not fill up the 1600:900 screen. At the left and the right of the win7 desktop there remain black stripes. If I install Ubuntu-13.04 in kvm-qemu or in a gnome-box Ubuntu has the 'qxl' driver and I can run Ubuntu fullscreen with 1600:900 resolution. I thought when looking up info with regard to Spice that there was better graphics support for Windows but the documentation is not clear and 'old'. AV -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Mon, 2013-06-10 at 08:38 -0400, Chris Murphy wrote: On Jun 10, 2013, at 3:51 AM, Adam Williamson awill...@redhat.com wrote: Could you take a look and see if it's better now, or still needs improving? Criterion reads: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora. There was a debate regarding dual boot (here is explained how to install the bootloader into the first sector of the partition) https://lists.fedoraproject.org/pipermail/users/2013-January/429440.html After all, why to get rid of this way of dual boot capability for non UEFI systems, for non encrypted dual boot? What is the big advantage to not have that? Cristian Sava -- 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
Running on what OS? In on Mac OS, maybe this is part of the problem. Can you post your vbox.log for successful bout to that forum thread? Chris Murphy (Sorry for top post, stupid Android mail client seems to have to other option.) Andre Robatino robat...@fedoraproject.org wrote: Chris Murphy lists at colorremedies.com writes: add inst.usefbx and video=efifb to the linuxefi kernel line in grub2 This doesn't work for me. I just tried it with Fedora-19-TC2-x86_64-DVD.iso in Oracle VirtualBox 4.2.12 and it worked for me. -- test mailing list 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
Re: os-prober and fd0?
On 06/09/2013 10:50 PM, Joerg Lechner wrote: I have made a new installation via Final TC2 DVD iso (4.2GB). First checked my BIOS settings. Found Boot Up Floppy Seek enabled, but I also don't have a Floppy. Setting to disabled shows now the time for bootloader installieren (German Language) of about 15 min instead of about half an hour. In the BIOS, look for Onboard peripherals (or something similar) where several BIOS on my machines allow me to Disable the Parallel port, Serial Port, Floppy, Ethernet port, Audio, PATA, SATA. -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
How does grub2 know what to boot?
I just installed f19 beta, and it overwrote my MBR with grub2ness (as expected). But now I'm wondering - the actual installation of f19 is entirely on /dev/sda2 (including the /boot directory which is just a subdirectory of /, not a separate partition). My old f18 /dev/sda3 partition is the only one marked as boot. So how the heck is grub2 locating and booting the /dev/sda2 /boot stuff? Is there a pointer stashed in the MBR telling it where to look? Just curious :-). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 12:04 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 11:56 AM, Felix Miata wrote: Yet another Fedora way to alienate users. While dual booting is indeed a thing of the '80's, multibooting isn't going away just because virtualization exists. Virtually all my 30+ usable systems are multiboot, regardless whether their hardware supports virtualization. Most of them don't. And in what are you using those 30+ usable system They are all in the same building. and why aren't you running Fedora only on them? This is a test list, so I subscribe because I'm a tester. My role is discovering and reporting reproducible problems in software. Fedora is both testing tool and test subject. None of the testing I do requires a complete PC be constrained to a single operating system. -- 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
Fedora 19 updates-testing report
The following Fedora 19 Security updates need testing: Age URL 54 https://admin.fedoraproject.org/updates/FEDORA-2013-5801/mantis-1.2.15-1.fc19 27 https://admin.fedoraproject.org/updates/FEDORA-2013-8116/clamav-0.97.8-1.fc19 16 https://admin.fedoraproject.org/updates/FEDORA-2013-9102/libXvMC-1.0.7-5.20130524gite9415ddef.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2013-9715/heat-jeos-9-1.fc19 8 https://admin.fedoraproject.org/updates/FEDORA-2013-9827/livecd-tools-19.4-1.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2013-9918/perl-Dancer-1.3111-3.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-9981/subversion-1.7.10-1.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-9976/libFS-1.0.5-1.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-9986/xen-4.2.2-6.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-10020/community-mysql-5.5.31-7.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-10032/gallery3-3.0.8-1.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-10029/libguestfs-1.22.2-1.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2013-9984/bind-9.9.3-3.P1.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2013-10206/php-5.5.0-0.8.RC3.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2013-10288/rrdtool-1.4.8-2.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2013-10354/perl-Module-Signature-0.73-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2013-10381/owncloud-4.5.12-1.fc19 The following builds have been pushed to Fedora 19 updates-testing beakerlib-1.8-1.fc19 cinnamon-1.9.1-9.fc19 evolution-3.8.3-1.fc19 evolution-data-server-3.8.3-1.fc19 evolution-ews-3.8.3-1.fc19 evolution-mapi-3.8.3-1.fc19 ghc-geniplate-0.6.0.3-1.fc19 glib2-2.36.3-1.fc19 gnome-documents-3.8.3-1.fc19 gnome-rdp-0.3.1.0-4.fc19 google-noto-fonts-20130411-4.fc19 ibus-kkc-1.5.14-1.fc19 lfcbase-1.5.5-1.fc19 libappindicator-12.10.0-1.fc19 libkkc-0.2.4-1.fc19 mtpaint-3.40-12.fc19 ninja-build-1.3.4-1.fc19 openstack-keystone-2013.1.2-1.fc19 python-amqpclt-0.5-1.fc19 sdparm-1.08-1.fc19 vlgothic-fonts-20130607-1.fc19 xautolock-2.2-13.fc19 xchat-2.8.8-19.fc19 yad-0.21.0-1.fc19 yash-2.35-1.fc19 Details about builds: beakerlib-1.8-1.fc19 (FEDORA-2013-10465) A shell-level integration testing library Update Information: This update brings the updated upstream version (1.8), fixing the UTF-8 in distro name processing bug (Hello, Herr Schroedinger) and advanced rlRun parameter-related bugs. ChangeLog: * Mon Jun 10 2013 Petr Muller mul...@redhat.com - 1.8-1 - Update to new upstream version (1.8) * Thu May 9 2013 Petr Muller mul...@redhat.com - 1.7-2 - Robustify journal to accept umlaut in distro release name - Fix internal documentation References: [ 1 ] Bug #905005 - [RFE]: rlRun should print non-zero return value, even if it is expected https://bugzilla.redhat.com/show_bug.cgi?id=905005 [ 2 ] Bug #908325 - rlService* functions should provide more debugging information https://bugzilla.redhat.com/show_bug.cgi?id=908325 [ 3 ] Bug #959138 - [RFE] Make PURPOSE file optional https://bugzilla.redhat.com/show_bug.cgi?id=959138 [ 4 ] Bug #961121 - Beakerlib 1.7 failing in Fedora 19 https://bugzilla.redhat.com/show_bug.cgi?id=961121 [ 5 ] Bug #966479 - Wrong path in man page https://bugzilla.redhat.com/show_bug.cgi?id=966479 [ 6 ] Bug #950042 - rlLogDebug return nonzero return code while DEBUG mode is not active https://bugzilla.redhat.com/show_bug.cgi?id=950042 [ 7 ] Bug #956111 - rlBundleLogs tries to pack also its first argument (package name) https://bugzilla.redhat.com/show_bug.cgi?id=956111 [ 8 ] Bug #963621 - rlAssertGrep / rlAssertNotGrep do not separate options and other parameters properly https://bugzilla.redhat.com/show_bug.cgi?id=963621 [ 9 ] Bug #971783 - rlRun -c deletes /dev/null on RHEL-5 https://bugzilla.redhat.com/show_bug.cgi?id=971783 [ 10 ] Bug #968381 - rlRun -s design leads to /dev/null removal https://bugzilla.redhat.com/show_bug.cgi?id=968381 cinnamon-1.9.1-9.fc19 (FEDORA-2013-10477) Window management and application launching for GNOME Update Information: - add requires gnome-screensaver
Re: How does grub2 know what to boot?
On Mon, 2013-06-10 at 10:25 -0400, Tom Horsley wrote: I just installed f19 beta, and it overwrote my MBR with grub2ness (as expected). But now I'm wondering - the actual installation of f19 is entirely on /dev/sda2 (including the /boot directory which is just a subdirectory of /, not a separate partition). My old f18 /dev/sda3 partition is the only one marked as boot. So how the heck is grub2 locating and booting the /dev/sda2 /boot stuff? Is there a pointer stashed in the MBR telling it where to look? Just curious :-). Sometime back I had a similar problem and I discovered that my old grub install (other partition) was used. Do you mind to check? Cristian Sava -- 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
Chris Murphy lists at colorremedies.com writes: Running on what OS? In on Mac OS, maybe this is part of the problem. Can you post your vbox.log for successful bout to that forum thread? My host is F18 x86_64. Noticed that you're running F19 so I can't vouch for that. Attached my VBox.log to https://forums.virtualbox.org/viewtopic.php?f=3t=55937 . -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How does grub2 know what to boot?
Yes. The code in the MBR jumps to a specific LBA in the MBR gap where core.img is installed. Once that's loaded, grub understands the /boot filesystem, and can locate and load normal.mod, grub.cfg, and the modules the grub.cfg specifies for loading. The prefix for where core.img looks is baked into core.img. This works differently on UEFI. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Unicode and console font problem?
I just installed f19 beta, picking minimal install, which does not install X - I just get a console login. The apostrophe-like thing in Schrödinger's cat (which prints in the login prompt) shows up as a white block (I do get the 'o' with the two little dots above it though). I also copied some files from one partition to another and the message it prints asking about overwriting a file also has square blocks instead of quotes around the filename it prints in the message. https://bugzilla.redhat.com/show_bug.cgi?id=889710 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How does grub2 know what to boot?
On Mon, 10 Jun 2013 17:46:21 +0300 Cristian Sava wrote: Sometime back I had a similar problem and I discovered that my old grub install (other partition) was used. Do you mind to check? I don't have an actual problem. It is definitely using the new install to boot from because it offers the new f19 install as a boot option, I'm just curious how it works :-). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 02:38 PM, Felix Miata wrote: On 2013-06-10 12:04 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 11:56 AM, Felix Miata wrote: Yet another Fedora way to alienate users. While dual booting is indeed a thing of the '80's, multibooting isn't going away just because virtualization exists. Virtually all my 30+ usable systems are multiboot, regardless whether their hardware supports virtualization. Most of them don't. And in what are you using those 30+ usable system They are all in the same building. So being in the same building is why you are multi booting them? and why aren't you running Fedora only on them? This is a test list, so I subscribe because I'm a tester. My role is discovering and reporting reproducible problems in software. Fedora is both testing tool and test subject. None of the testing I do requires a complete PC be constrained to a single operating system. You could just as well wipe those machine clean and perform a fresh OS test on a fresh install ( along with what ever hw driver development you are into ) of what ever OS you have running each time you are performing test. JBG -- 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'm using F19 beta Live media on VBox on OS X. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
It absolutely should block the release as there's no way to fix it after the fact. Dropping the requirement for sane multiboot behavior isn't a good idea. (Sane being, it's possible and does no harm to the existing system.) Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
Cristian Sava wrote: After all, why to get rid of this way of dual boot capability for non UEFI systems, for non encrypted dual boot? What is the big advantage to not have that? Because anaconda devs don't want to support what grub devs recommend against. I think the former is reasonable. Some ext devs think grub devs are being overly cautious. But the reality is, grub does support embedding to a partition without force for filesystems with a large enough boot loader pad, such as Btrfs which has a 64kb pad. Ext's is 1024k, not nearly big enough for grub's core.img. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 14:57 (GMT) Jóhann B. Guðmundsson composed: And in what are you using those 30+ usable system They are all in the same building. So being in the same building is why you are multi booting them? No. I really don't understand the question or why you are asking it. and why aren't you running Fedora only on them? This is a test list, so I subscribe because I'm a tester. My role is discovering and reporting reproducible problems in software. Fedora is both testing tool and test subject. None of the testing I do requires a complete PC be constrained to a single operating system. You could just as well wipe those machine clean and perform a fresh OS test on a fresh install ( along with what ever hw driver development you are into ) of what ever OS you have running each time you are performing test. I test diverse kinds of software. Operating systems are just one software class among them. OS installation is among the most time consuming and lowest priority tests I perform. I often clone and upgrade the clone in order to avoid the OS installation process. Due to my experience with the pre-release F18 installer, all my F19 installations have been made via partition clone and Yum upgrade. I repeat: Fedora here is both testing tool and test subject. Interference between the two functions needs to be limited. Wiping is antithetical to my limitation methodology and primary goals. -- 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: F19 Final criteria revamp
On 06/10/2013 03:46 PM, Felix Miata wrote: On 2013-06-10 14:57 (GMT) Jóhann B. Guðmundsson composed: And in what are you using those 30+ usable system They are all in the same building. So being in the same building is why you are multi booting them? No. I really don't understand the question or why you are asking it. To see if there is an actual reason for you to be using multiboot in the first place. What exactly are you developing or test being developed? and why aren't you running Fedora only on them? This is a test list, so I subscribe because I'm a tester. My role is discovering and reporting reproducible problems in software. Fedora is both testing tool and test subject. None of the testing I do requires a complete PC be constrained to a single operating system. You could just as well wipe those machine clean and perform a fresh OS test on a fresh install ( along with what ever hw driver development you are into ) of what ever OS you have running each time you are performing test. I test diverse kinds of software. Operating systems are just one software class among them. OS installation is among the most time consuming and lowest priority tests I perform. I often clone and upgrade the clone in order to avoid the OS installation process. Due to my experience with the pre-release F18 installer, all my F19 installations have been made via partition clone and Yum upgrade. So you are using unsupported method of upgrading Fedora to test your application on Fedora and your company supports running application on a upgraded host which is a) upgraded b) via the unofficial method of the distribution? I repeat: Fedora here is both testing tool and test subject. Interference between the two functions needs to be limited. Wiping is antithetical to my limitation methodology and primary goals. And what I'm saying we should not blocking the release for that. We are first and foremost shipping our distribution to be used as primary OS on our users HW just like any other OS does. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: vlan doesn't work?
On Sat, 2013-06-08 at 10:39 -0400, Tom Horsley wrote: I disabled NetworkManager, I enabled network, I copied in all my /etc/sysconfig/network-scripts/ifcfg-* files, but I don't get any networking on my fedora 19 install. I've got this box connected to a dd-wrt router doing tagged packets for vlan support, so the network setup is a tad complex :-). You can see the scripts here: http://home.comcast.net/~tomhorsley/game/isolate.html An ifconfig -a command doesn't show anything but lo and p6p1, none of my bridges or p6p1.1 and p6p1.3 vlans. Anyone know what might be missing that prevents this stuff from working? VLAN=yes is missing in your ifcfg scripts I am not sure whether you need it in both the main and vlan ifcfg files. You may have to try to add it in both, but at least the vlan files need it /Louis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Mon, 2013-06-10 at 15:58 +, Jóhann B. Guðmundsson wrote: And what I'm saying we should not blocking the release for that. We are first and foremost shipping our distribution to be used as primary OS on our users HW just like any other OS does. NO, you have not valid reasons to avoid the requirement for sane multiboot behavior (sane being, it's possible and does no harm to the existing system) as Chris Murphy stated. Fedora have to just install, work and do not harm. And NO, IT IS NOT A GOOD IDEA. The user have to be able to choose what and how to install on his PC. Cristian Sava -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: vlan doesn't work?
On Mon, 2013-06-10 at 18:04 +0200, Louis Lagendijk wrote: On Sat, 2013-06-08 at 10:39 -0400, Tom Horsley wrote: I disabled NetworkManager, I enabled network, I copied in all my /etc/sysconfig/network-scripts/ifcfg-* files, but I don't get any networking on my fedora 19 install. I've got this box connected to a dd-wrt router doing tagged packets for vlan support, so the network setup is a tad complex :-). You can see the scripts here: http://home.comcast.net/~tomhorsley/game/isolate.html An ifconfig -a command doesn't show anything but lo and p6p1, none of my bridges or p6p1.1 and p6p1.3 vlans. Anyone know what might be missing that prevents this stuff from working? VLAN=yes is missing in your ifcfg scripts I am not sure whether you need it in both the main and vlan ifcfg files. You may have to try to add it in both, but at least the vlan files need it There are some related bugs already reported (https://bugzilla.redhat.com/show_bug.cgi?id=964139) Cristian Sava -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Mon, 2013-06-10 at 08:38 -0400, Chris Murphy wrote: On Jun 10, 2013, at 3:51 AM, Adam Williamson awill...@redhat.com wrote: Could you take a look and see if it's better now, or still needs improving? Criterion reads: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora. a. Since free space is atypical, this phrasing implies the installer doesn't need to be able to resize or resize correctly. Since it's an offered scenario in the installer, I think at this point it should be required to work and thus incorporated into the criterion. That is indeed the implication, it's intentional, and I wouldn't want to change it without input from the anaconda team. Their position is that resizing is inherently a risky and unpredictable operation that we cannot guarantee the functionality of, but we should be able to guarantee what's written in the criterion. I suppose we could try and come up with a tightly-worded criterion that the resize mechanism in the installer must not be broken - so it should 'do what it's supposed to do', but if ntfsresize fails for some reason, that wouldn't be a blocker. b. For BIOS installs, the requirement for the bootloader to boot both Windows and Fedora is reasonable. It's probably not reasonable, still, for UEFI. GRUB2+os-prober really isn't acting as a suitable replacement Boot Manager, so the user either needs to use the firmware boot manager to choose a bootloader (bootmgr.efi for Windows, grubx64.efi for Fedora), or some other boot manager (rEFInd or gummiboot). Well, I see the point, but at the same time, we are finding out that in the Real World, it's a really bad idea to depend on the EFI boot manager because it just isn't being presented to the user in a sane way in enough of the real UEFI implementations. So we might actually want to keep that requirement, and fix up os-prober (which we're currently working on). We'll have to see what pjones' take on that is. Clean Windows installation reveal reads in part: The expected scenario is a cleanly installed or OEM-deployed Windows installation into a single partition. Issues caused by recovery or 'system' partitions may not be considered to violate this criterion, depending on the specific circumstances. I think those two sentences are unworkable. OEM deployed Windows is multi-partition. In particular, what's the default 'multi-partition' layout of Win7/8? I've only recently BIOS installed Windows 7, and it's two partitions to an unpartitioned disk. I think for EFI installing Windows 7, it's three partitions. For Windows 8 EFI, it's four partitions, so I'll guess it's one less for BIOS. What are the partitions? -- 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: F19 Final criteria revamp
On Mon, 2013-06-10 at 08:46 +, Jóhann B. Guðmundsson wrote: We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Red Hat can just keep this criteria for RHEL if that's the reason for it to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. No, the criterion has nothing to do with RHEL. I don't know if multi-boot is even a supported deployment method for RHEL (I suspect not, but I have absolutely no idea). It was created as part of the original criteria effort at F13 because this is something people generally expect Linux distributions to be able to do, and they get angry if they can't. Each time this has been brought up since, it's seemed fairly clear that the majority of people still believe this should be the case, even though you think it's now a 'legacy' thing. -- 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: F19 Final criteria revamp
On 2013-06-10 15:58 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 03:46 PM, Felix Miata wrote: On 2013-06-10 14:57 (GMT) Jóhann B. Guðmundsson composed: And in what are you using those 30+ usable system They are all in the same building. So being in the same building is why you are multi booting them? No. I really don't understand the question or why you are asking it. To see if there is an actual reason for you to be using multiboot in the first place. What exactly are you developing or test being developed? Diverse things. Among them, that developers are developing to meet convenience, needs and wishes of users rather than those of developers, and not just users whose eyesight is 50th percentile or better. Developers of all types too often forget not everyone's eyesight is not as good as their own. Another: whether a reported problem is reproducible or not, with or without matching the reporter's environment. Another: whether any particular OS installation can be made without disrupting prior multiboot installations. So you are using unsupported method of upgrading Fedora to test your application on Fedora and your company supports running application on a upgraded host which is a) upgraded b) via the unofficial method of the distribution? I test to see what works or not, and how well, not necessarily whether a particular procedure meets some definition of supported or official. I repeat: Fedora here is both testing tool and test subject. Interference between the two functions needs to be limited. Wiping is antithetical to my limitation methodology and primary goals. And what I'm saying we should not blocking the release for that. We are first and foremost shipping our distribution to be used as primary OS on our users HW just like any other OS does. So what you're saying is whether Fedora is satisfactory as a testing tool or secondary OS needn't be determined prior to release; that it only matters that it works for those who use it as a sole OS. Myopic is thinking few or unimportant those that would want bleeding edge as sole or secondary to something with maximum stability and broadest support, a good way to alienate both common users and community contributors. -- 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: F19 Final criteria revamp
On 06/10/2013 04:33 PM, Adam Williamson wrote: On Mon, 2013-06-10 at 08:46 +, Jóhann B. Guðmundsson wrote: We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Red Hat can just keep this criteria for RHEL if that's the reason for it to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. No, the criterion has nothing to do with RHEL. I don't know if multi-boot is even a supported deployment method for RHEL (I suspect not, but I have absolutely no idea). It was created as part of the original criteria effort at F13 because this is something people generally expect Linux distributions to be able to do, and they get angry if they can't. Each time this has been brought up since, it's seemed fairly clear that the majority of people still believe this should be the case, even though you think it's now a 'legacy' thing. You mean few users here on the test list think it's a must thing afaik there has not been a system wide community survey regarding this ( and usually is not regarding things we deprecate ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 04:48 PM, Stephen John Smoogen wrote: Johann. DROP IT. Seriously. You are picking a fight just for the sake of a fight. I am sick and tired of you doing this every couple of months. If you can not express yourself in a better less You are an idiot because you disagree with me. point of view, take a break and come back when you can. Seriously stay out of my way and find someone else to pick on in this community I cannot express myself without you butting in. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: os-prober and fd0?
On 06/10/2013 08:37 AM, Joerg Lechner wrote: I have now disabled, all what there is to disable (including parallel and serial port, second and third boot device), enabled USB, PS2, first boot device - cdrom, network etc.. This bootloader process took now approximately 1 minute. What do You think causes this wasted installation time? Is the only chance to test try and error? Error recovery on a device with moving parts is *SLOW*. For example, recovering from a read error on a physical DVD can take a whole minute or more. Just recovering an ATA bus error can take 30 seconds or more. I've seen these: one of the SATA channels on the I/O bridge chip on one of my boxes is flaky. At first I thought it was the DVD drive, but a new drive which worked in another box also experienced the same problem. So now there's a piece of tape over that SATA connector. -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 04:53 PM, Felix Miata wrote: So what you're saying is whether Fedora is satisfactory as a testing tool or secondary OS needn't be determined prior to release; that it only matters that it works for those who use it as a sole OS. Yes that our primary focus should be the only OS ( which is afaik what other OS like Microsoft Windows or Apple does ) running and as secondary OS as a virtual guest ( or guest container for that matter ). Resize and refitting another OS along with already installed one on the same hardware ( disks ) is not something I see as we should or could be officially supporting hence we should not be blocking our release for that. Windows or Apple or some other OS changes it partition filesystem etc. and we need to delay our release until we have played catchup to those changes. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 17:51 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 04:53 PM, Felix Miata wrote: So what you're saying is whether Fedora is satisfactory as a testing tool or secondary OS needn't be determined prior to release; that it only matters that it works for those who use it as a sole OS. Yes that our primary focus should be the only OS Primary focus? Or sole focus? The two are not the same. ( which is afaik what other OS like Microsoft Windows or Apple does ) It's not what other top 10 distros do. running and as secondary OS as a virtual guest ( or guest container for that matter ). Resize and refitting another OS along with already installed one on the same hardware ( disks ) is not something I see as we should or could be officially supporting hence we should not be blocking our release for that. Newbie: Which Linux distro should I try? Puter geek: It makes little difference, as long as you don't pick Fedora. Fedora will screw your system so you can no longer use what you have on it now. -- 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: F19 Final criteria revamp
On 06/10/2013 06:09 PM, Felix Miata wrote: On 2013-06-10 17:51 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 04:53 PM, Felix Miata wrote: So what you're saying is whether Fedora is satisfactory as a testing tool or secondary OS needn't be determined prior to release; that it only matters that it works for those who use it as a sole OS. Yes that our primary focus should be the only OS Primary focus? Or sole focus? The two are not the same. Primary as in we should test this but not block the release for it not working ( which is afaik what other OS like Microsoft Windows or Apple does ) It's not what other top 10 distros do. First in our foundation indicates we should be leading not following ;) running and as secondary OS as a virtual guest ( or guest container for that matter ). Resize and refitting another OS along with already installed one on the same hardware ( disks ) is not something I see as we should or could be officially supporting hence we should not be blocking our release for that. Newbie: Which Linux distro should I try? And the opposide part of the coin Fedora just try the live cd/dvd and see if it works out for you if it does you can install it from the live... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 12:51 AM, Adam Williamson wrote: still needs improving? Thanks. In particular, what's the default 'multi-partition' layout of Win7/8? I don't think I've seen a stock install of either (I still use an old copy of XP for Windows testing, here.) I recently had the fun of installing Fedora beside Windows 7 on more than 10 different laptops. (This was for a class where the students were required to provide their own laptops.) The number of Windows partitions varied from 2 to 4. The 4 partition case required me to delete one of them because they were all primary partitions! Sorry, I don't remember what the contents were on the partitions. My guess of the options was boot, main OS, user data, system (BIOS config?), recovery. There was one Windows 8 laptop which was easier because it used GPT so I didn't have to mess with the partitions other than resizing them. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Mon, 2013-06-10 at 17:33 +, Jóhann B. Guðmundsson wrote: On 06/10/2013 04:33 PM, Adam Williamson wrote: On Mon, 2013-06-10 at 08:46 +, Jóhann B. Guðmundsson wrote: We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Red Hat can just keep this criteria for RHEL if that's the reason for it to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. No, the criterion has nothing to do with RHEL. I don't know if multi-boot is even a supported deployment method for RHEL (I suspect not, but I have absolutely no idea). It was created as part of the original criteria effort at F13 because this is something people generally expect Linux distributions to be able to do, and they get angry if they can't. Each time this has been brought up since, it's seemed fairly clear that the majority of people still believe this should be the case, even though you think it's now a 'legacy' thing. You mean few users here on the test list think it's a must thing afaik there has not been a system wide community survey regarding this ( and usually is not regarding things we deprecate ) Well, let me put it more baldly: up till now I can't recall a single person agreeing with you that we should stop blocking on basic multiboot-alongside-a-simple-Windows-install. Not a single person. I agree we have a very small sample size on this list, but still, that seems pretty indicative. I can run a forum poll if you like, though... -- 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: F19 Final criteria revamp
On 06/10/2013 07:09 PM, Adam Williamson wrote: Well, let me put it more baldly: up till now I can't recall a single person agreeing with you that we should stop blocking on basic multiboot-alongside-a-simple-Windows-install. Not a single person. I agree we have a very small sample size on this list, but still, that seems pretty indicative. I can run a forum poll if you like, though... More appropriate place then a forum poll or this mailing list would be in the survey the boards working on. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 18:16 (GMT) Jóhann B. Guðmundsson composed: Primary as in we should test this but not block the release for it not working The dangerous not working mode is screwing up the target so what was functional there is no longer. Do you remember as well as I Disk Druid's capacity for destruction? Early on it lead me from RedHat to Mandrake and away from partitioners included on installation media. First do no harm needs testing. First in our foundation indicates we should be leading not following ;) Fine, as long as those ultimately responsible for the choice of path and those implementing it aren't myopic, and the path chosen is one real users are interested to take. It is no success to excel at something none care about. Newbie: Which Linux distro should I try? And the opposide part of the coin Fedora just try the live cd/dvd and see if it works out for you if it does you can install it from the live... Works from live media does not equate to successfully install from live media. -- 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
what could screw up login credentials?
I had a working minimal install of f19. I booted f18 on the same machine to get work done, and in background installed a gazillion packages while chrooted into the f19 partition. Now when I try to boot f19, it tells me I have an invalid password for every user I try to login as :-(. I tried chrooting in again and running passwd to update the passwords, but it still says invalid. Anyone know how the devil to fix this? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
RE: F19 Final criteria revamp
Date: Mon, 10 Jun 2013 19:10:19 + From: johan...@gmail.com To: test@lists.fedoraproject.org Subject: Re: F19 Final criteria revamp On 06/10/2013 07:09 PM, Adam Williamson wrote: Well, let me put it more baldly: up till now I can't recall a single person agreeing with you that we should stop blocking on basic multiboot-alongside-a-simple-Windows-install. Not a single person. I agree we have a very small sample size on this list, but still, that seems pretty indicative. I can run a forum poll if you like, though... More appropriate place then a forum poll or this mailing list would be in the survey the boards working on. JBG -- Dude, I think it is pretty well known that I think Microsoft could take a flying at a donut. However, I know that there are plenty of people that aren't quite willing to totally commit to Linux. Therefore, this is a totally valid, and even needed criteria. As far as RHEL, I rather doubt that RHEL's target audiance would be dual-booting servers ... John. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: what could screw up login credentials?
On 06/10/2013 12:43 PM, Tom Horsley wrote: Now when I try to boot f19, it tells me I have an invalid password for every user I try to login as :-(. I tried chrooting in again and running passwd to update the passwords, but it still says invalid. Check the logs for selinux errors or boot with selinux in permissive mode. You may need to relabel the filesystem. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: what could screw up login credentials?
On 06/10/2013 07:43 PM, Tom Horsley wrote: I had a working minimal install of f19. I booted f18 on the same machine to get work done, and in background installed a gazillion packages while chrooted into the f19 partition. Now when I try to boot f19, it tells me I have an invalid password for every user I try to login as :-(. I tried chrooting in again and running passwd to update the passwords, but it still says invalid. Anyone know how the devil to fix this? Try comment out the pam_loginuid line in /etc/pam.d/login to see if that works around this... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: what could screw up login credentials?
On Mon, 10 Jun 2013 14:59:51 -0700 Samuel Sieb wrote: Check the logs for selinux errors or boot with selinux in permissive mode. You may need to relabel the filesystem. Good idea. I'll check that when I get back to work tomorrow. I usually turn off selinux, but I don't think I did that yet. Thanks. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F19 Installer a little better, but...
...I'm still filled with trepidation when the only choice I appear to have is to click Done after selecting a disk to install on. I'm not Done :-). I want to pick partitions to install on, etc, but there is absolutely no indication you will have that chance unless you actually work up the nerve to click Done then see that you are provided additional options. (So apparently even anaconda doesn't think you are Done). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Installer a little better, but...
On Mon, 2013-06-10 at 21:23 -0400, Tom Horsley wrote: ...I'm still filled with trepidation when the only choice I appear to have is to click Done after selecting a disk to install on. I'm not Done :-). I want to pick partitions to install on, etc, but there is absolutely no indication you will have that chance unless you actually work up the nerve to click Done then see that you are provided additional options. (So apparently even anaconda doesn't think you are Done). You are 'Done' picking disks, though, and there's a big chunk of text on the screen saying They will be left untouched until you click on the main menu's Begin Installation button. So I'm not sure it's really that scary now. Quite a lot of people have said they find the current layout a bit confusing, but then, we tried two other layouts before this one and people found both of those confusing too. At this point we are running out of possibilities, but perhaps we could label the button 'Unicorn' and have it orbit the screen randomly. That would at least be different. =) -- 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
sound
Hi gang: It may be my ignorance - I probably know this but am unaware of it at the moment; since upgrading to tc2 (and perhaps tc1), I lost my sound. Any hints on how to get it back? Thanks, Richard -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Installer a little better, but...
On 06/10/2013 07:09 PM, Adam Williamson wrote: On Mon, 2013-06-10 at 21:23 -0400, Tom Horsley wrote: ...I'm still filled with trepidation when the only choice I appear to have is to click Done after selecting a disk to install on. I'm not Done :-). I want to pick partitions to install on, etc, but there is absolutely no indication you will have that chance unless you actually work up the nerve to click Done then see that you are provided additional options. (So apparently even anaconda doesn't think you are Done). You are 'Done' picking disks, though, and there's a big chunk of text on the screen saying They will be left untouched until you click on the main menu's Begin Installation button. So I'm not sure it's really that scary now. Quite a lot of people have said they find the current layout a bit confusing, but then, we tried two other layouts before this one and people found both of those confusing too. At this point we are running out of possibilities, but perhaps we could label the button 'Unicorn' and have it orbit the screen randomly. That would at least be different. =) Relabel the DONE button to SELECTION COMPLETED or something else that is not ambiguous. -- 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: F19 Final criteria revamp
On Jun 10, 2013, at 1:51 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Resize and refitting another OS along with already installed one on the same hardware ( disks ) is not something I see as we should or could be officially supporting hence we should not be blocking our release for that. Certainly installing to free space should be uncontroversial. I don't care to understand the idea that user choice should only apply to FOSS. You either believe in user choice or you don't, it is a fairly binary position regardless of the software's license. The installer supports it, and considering the damage that could be done is in the category of data loss, yes it needs to have a suitable release blocking criterion. Windows or Apple or some other OS changes it partition filesystem etc. and we need to delay our release until we have played catchup to those changes. Please, Microsoft and Apple have file systems from the Pleistocene. And it's already the case that HFS+ isn't resized by anaconda (or any linux tools at all insofar as I'm aware). If the file system changes, it'll indicate a version change in a way identifiable to the installer's support utilities, or it won't be an identifiable system at all. In either case the installer should refuse to resize. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: sound
On Mon, 2013-06-10 at 19:22 -0700, Richard Vickery wrote: Hi gang: It may be my ignorance - I probably know this but am unaware of it at the moment; since upgrading to tc2 (and perhaps tc1), I lost my sound. Any hints on how to get it back? the 'TC' numbers are only really relevant for the media, for an issue like this it doesn't mean a lot. So, um - what did you 'upgrade' from, exactly? Are you talking about going from F18 to F19, here? Or just regular updates on F19? -- 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
