Fwd: [Bug 727814] F16 Alpha TC1 installer crash | LUKSError: luks device not configured
> https://bugzilla.redhat.com/show_bug.cgi?id=727814 > > --- Comment #8 from Tim Flink 2011-09-01 13:18:54 EDT --- > Discussed in the 2011-08-26 blocker review meeting. Rejected as a Fedora 16 > beta blocker because it doesn't violate any of the beta release criteria [1]. > > Accepted as NTH because it's annoying and a fix is ready. > > [1] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria I don't think we should mark any installer crashes as non-blockers when there is a good chance users would hit it. I believe this particular bug should have been an Alpha blocker: "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption or LVM enabled" https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria Whether I do or don't provide the password to my existing encrypted partitions doesn't really matter, both ways are very probable, both ways should work. At least in my opinion. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 14 updates-testing report
The following Fedora 14 Security updates need testing: https://admin.fedoraproject.org/updates/avahi-0.6.27-8.fc14 https://admin.fedoraproject.org/updates/phpMyAdmin-3.4.4-1.fc14 https://admin.fedoraproject.org/updates/cups-1.4.8-2.fc14 https://admin.fedoraproject.org/updates/mongoose-3.0-2.fc14 https://admin.fedoraproject.org/updates/perl-Data-FormValidator-4.66-6.fc14 https://admin.fedoraproject.org/updates/pl-5.7.11-7.fc14 https://admin.fedoraproject.org/updates/squid-3.1.15-1.fc14 https://admin.fedoraproject.org/updates/system-config-firewall-1.2.27-2.fc14 https://admin.fedoraproject.org/updates/libsndfile-1.0.25-1.fc14 https://admin.fedoraproject.org/updates/libcap-2.22-1.fc14 https://admin.fedoraproject.org/updates/libvpx-0.9.7.1-1.fc14 https://admin.fedoraproject.org/updates/ecryptfs-utils-90-2.fc14 https://admin.fedoraproject.org/updates/rubygem-actionpack-2.3.8-4.fc14 https://admin.fedoraproject.org/updates/dhcp-4.2.0-23.P2.fc14 https://admin.fedoraproject.org/updates/php-5.3.8-1.fc14,maniadrive-1.2-32.fc14,php-eaccelerator-0.9.6.1-9.fc14 https://admin.fedoraproject.org/updates/libsoup-2.32.2-2.fc14 https://admin.fedoraproject.org/updates/rubygem-activesupport-2.3.8-4.fc14 https://admin.fedoraproject.org/updates/pidgin-2.10.0-1.fc14 https://admin.fedoraproject.org/updates/ca-certificates-2011.78-1.fc14 https://admin.fedoraproject.org/updates/foomatic-4.0.8-3.fc14 https://admin.fedoraproject.org/updates/hplip-3.11.7-2.fc14 https://admin.fedoraproject.org/updates/tomcat6-6.0.26-21.fc14 https://admin.fedoraproject.org/updates/openldap-2.4.23-10.fc14 The following Fedora 14 Critical Path updates have yet to be approved: https://admin.fedoraproject.org/updates/kernel-2.6.35.14-96.fc14 https://admin.fedoraproject.org/updates/ca-certificates-2011.78-1.fc14 https://admin.fedoraproject.org/updates/livecd-tools-14.3-1.fc14 https://admin.fedoraproject.org/updates/tzdata-2011i-1.fc14 https://admin.fedoraproject.org/updates/udev-161-10.fc14 https://admin.fedoraproject.org/updates/avahi-0.6.27-8.fc14 https://admin.fedoraproject.org/updates/setup-2.8.28-2.fc14 https://admin.fedoraproject.org/updates/curl-7.21.0-10.fc14 https://admin.fedoraproject.org/updates/audit-2.1.3-1.fc14 https://admin.fedoraproject.org/updates/system-config-users-1.2.110-1.fc14 https://admin.fedoraproject.org/updates/libcap-2.22-1.fc14 https://admin.fedoraproject.org/updates/ModemManager-0.4.998-1.git20110706.fc14 https://admin.fedoraproject.org/updates/unique-1.1.6-3.fc14 https://admin.fedoraproject.org/updates/xorg-x11-drv-savage-2.3.2-3.fc14 https://admin.fedoraproject.org/updates/mash-0.5.22-1.fc14 https://admin.fedoraproject.org/updates/perl-5.12.4-146.fc14 https://admin.fedoraproject.org/updates/policycoreutils-2.0.85-30.2.fc14 https://admin.fedoraproject.org/updates/xorg-x11-drv-openchrome-0.2.904-8.fc14.2 https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.0.21-3.fc14 https://admin.fedoraproject.org/updates/xorg-x11-drv-nouveau-0.0.16-14.20101010git8c8f15c.fc14 https://admin.fedoraproject.org/updates/libconcord-0.23-5.fc14,udev-161-9.fc14,concordance-0.23-2.fc14 https://admin.fedoraproject.org/updates/openldap-2.4.23-10.fc14 The following builds have been pushed to Fedora 14 updates-testing 389-ds-base-1.2.9.8-1.fc14 389-ds-base-1.2.9.9-1.fc14 airrac-0.1.2-1.fc14 bitfrost-1.0.15-1.fc14 ca-certificates-2011.78-1.fc14 cclive-0.7.5.1-1.fc14 cgnslib-2.5-5.r2.fc14 dovecot-2.0.14-1.fc14 ecryptfs-utils-90-2.fc14 glue-schema-2.0.7-1.fc14 gnome-gmail-1.8.1-1.fc14 gtkpod-2.0.2-1.fc14 ibus-table-chinese-1.3.4-1.fc14 kernel-2.6.35.14-96.fc14 ktorrent-4.1.2-1.fc14 libktorrent-1.1.2-1.fc14 olpc-powerd-35-1.fc14 openttd-1.1.2-1.fc14 python-mtTkinter-0.4-3.fc14 qlandkartegt-1.2.3-1.fc14 thunderbird-3.1.12-2.fc14 xulrunner-1.9.2.20-2.fc14 zanata-python-client-1.3.1-1.fc14 zyGrib-5.0.4-2.fc14 Details about builds: 389-ds-base-1.2.9.8-1.fc14 (FEDORA-2011-11985) 389 Directory Server (base) Update Information: Couple of bug fixes a handful of bug fixes and a new feature to allow the server to start with an expired cert Fixes for update, winsync, ruv/counters Fix another coverity NULL deref in previous patch Fix coverity NULL deref defect in 1.2.9.3 A few bug fixes The 1.2.9.0 release - several bug fixes found during alpha testing 389-ds-base-1.2.9.a2 - several bug fixes - automember improvements look for separate openldap ldif library Split automember regex rules into separate entries writing Inf file shows SchemaFile = ARRAY(0xhexnum) add support for ldif files with changetype: add Auto Membershi
New BugZapper Introduction
Hi, I'm a long time RH & Fedora user, first installed ~1997, and thought it would be nice to try and contribute to the project. My day job has been working with Unix since 2000 and mostly Linux since 2004, performing fault analysis of kernel dumps or determining if bugs are in our code or somewhere else in Red Hat, and fixing bugs in our code. So I spend a fair amount of time with c code, and have spent too much time looking at stacks and disassembled code. I'm 39 and live in Phoenix, Arizona. I have a wife, a daughter who will soon be 2, and another child on the way. I look forward to working with everyone and helping out. regards, Gerard Snitselaar irc: snits -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: btrfs-progs signed with F-15 GPG key [was F-16 Branched report: 20110831 changes]
On Thu, 2011-09-01 at 23:09 -0400, Chuck Anderson wrote: > Somehow this got built as a F-15 package but ended up in the F-16 > Branched repo, signed by the F-15 GPG key which makes yum not happy > since it can't find the F-15 key. Is there some reason why F-16 > packages aren't being built for this package, and instead you are only > building F-15 and F-17 packages? I think F-16 is inheriting the F-15 > build and breaking the F-16 repo. This is already known; Dennis has resigned the package and is disabling F15->F16 inheritance. But yes, it seems wrong to build the package for f15 and f17 but not f16. -- 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
btrfs-progs signed with F-15 GPG key [was F-16 Branched report: 20110831 changes]
On Wed, Aug 31, 2011 at 04:23:32PM +, Branched Report wrote: > btrfs-progs-0.19-16.fc15 > > * Fri Aug 05 2011 Josef Bacik 0.19-16 > - fix a typo > > * Fri Aug 05 2011 Josef Bacik 0.19-15 > - actually build btrfs-zero-log > > * Thu Aug 04 2011 Josef Bacik 0.19-14 > - bring btrfs-progs uptodate with upstream Somehow this got built as a F-15 package but ended up in the F-16 Branched repo, signed by the F-15 GPG key which makes yum not happy since it can't find the F-15 key. Is there some reason why F-16 packages aren't being built for this package, and instead you are only building F-15 and F-17 packages? I think F-16 is inheriting the F-15 build and breaking the F-16 repo. Downloading Packages: warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 069c8460: NOKEY Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 The GPG keys listed for the "Fedora 16 - x86_64" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository. Name: btrfs-progs Version : 0.19 Release : 16.fc15 Architecture: x86_64 Install Date: (not installed) Group : System Environment/Base Size: 1655725 License : GPLv2 Signature : RSA/SHA256, Fri 05 Aug 2011 10:14:55 AM EDT, Key ID b4ebf579069c8460 Source RPM : btrfs-progs-0.19-16.fc15.src.rpm Build Date : Fri 05 Aug 2011 02:12:59 PM EDT Build Host : x86-05.phx2.fedoraproject.org Relocations : (not relocatable) Packager: Fedora Project Vendor : Fedora Project URL : http://btrfs.wiki.kernel.org/index.php/Main_Page Summary : Userspace programs for btrfs Description : The btrfs-progs package provides all the userpsace programs needed to create, check, modify and correct any inconsistencies in the btrfs filesystem. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Radeon 69xx (Norther Island) support in Fedora 16
Hi, what is the status of the open source drivers in Fedora 16 with regards to the Radeon 69xx Northern Island cards? I booted the alpha live cd on a system equipped with a 6950 card and got dumped into fallback mode and with the recent ABI change the Catalyst driver is not going to work either so I'm wondering what is needed to make Fedora 16 work on that card without the fallback mode? Regards, Dennis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft 'install alongside Windows' test case
On Thu, Sep 1, 2011 at 1:05 PM, Adam Williamson wrote: > On Thu, 2011-09-01 at 10:10 -0400, Tom H wrote: >> On Wed, Aug 31, 2011 at 8:08 PM, Adam Williamson wrote: >> > >> > Hey, folks. I just threw together a quick draft of an 'install alongside >> > Windows' test case - we have this as a final criterion, but no test case >> > for it as of yet. Here's the draft: >> > >> > https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_install_alongside_Windows >> > >> > any comments, questions, suggestions welcome! thanks. >> >> " Prepare a system with a Windows installation, and some free disk >> space on the same disk as the Windows installation " >> >> Isn't the most likely scenario one where the Windows partition has to >> be resized? > > We specifically don't support (in the sense of 'delay releases for') > resizing as it's known to be a very hairy area. For instance, I did a > test where I install a completely clean, single-partition Win7 system > taking up an entire 20GB virtual disk, immediately booted to the Fedora > installer and tried to resize the partition, and ntfsresize crapped out > because (AFAICT) Windows had actually created the partition wrong - the > NTFS filesystem was a sector larger than the actual underlying > partition. This is, apparently, not unusual behaviour for Windows, and > it's not something we can do much about because *ntfsresize itself* > intentionally does not try and handle this case, it just throws an error > and goes to bed. > > Basically, resizing is an inherently fragile operation and we made the > choice not to 'guarantee' it with the criteria. > > You could say the test represents the scenario where you do the resizing > with something specialized like gparted prior to starting Fedora > installation. Thanks for the explanation! -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Working multiboot configuration
On Wed, 2011-08-31 at 23:35 -0400, Marty Felkler wrote: > My first post as a new thread to this list. > > Using'grub2-mkconfig -o /boot/grub2/grub.cfg' which as I said on > the FedoraForums is the correct way to create a boot grub.cfg I read your post on the forums. The simplest solution to your original problem would be to install the os-prober package (yum install os-prober) and then re-run grub2-mkconfig as specified above by you. David -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GIMP vs. poppler licensing, was: So you want to test an unstable GIMP...
On Thu, 2011-09-01 at 21:24 +0100, Dr Andrew John Hughes wrote: > > > Legal question: is it better to put this in its own subpackage to be > > > able to specify this individual license, or would GIMP better have > > > "GPLv3+ and LGPLv3+ and (GPLv2 or GPLv3)" as its license? > > > > if you combine them in a single package then I guess you'll have to drop > > the '+' from the license, as the non '+' components prevents it. > > > > IANAL of course. > > > > IANAL either, but as I read this, the logic being suggested is to list all > applicable licenses, not one license for the combined whole (which would > have to be GPLv3 for executables and LGPLv3 for libraries). > > FWIW, a separate package would make the situation clearer. Also NAL, but I believe Dr. Hughes is right - it does depend on how 'separable' the binary elements of the resulting package are. Say some of the code is GPLv2 and some is GPLv2+, and they build into two separately-executable programs which happen to be in the same package, then 'GPLv2 and GPLv2+' would be an appropriate license tag. But if some code was GPLv2 and some was GPLv2+, and both bits of code built into a single binary, the effective license would be GPLv2, because the license tag on the RPM refers to the compiled code, and there's no way you can access the GPLv2+ bit separately from the GPLv2 bit. As I read this specific situation, since you can execute the file-pdf plugin independently of GIMP, if you were to keep them in a single package, then the "GPLv3+ and LGPLv3+ and (GPLv2 or GPLv3)" tag would be appropriate. As everyone else said, a subpackage would probably make things clearer, but I don't think either is legally 'more valid' or 'safer'. It's worth remembering the License: field in the RPM is *informational* in nature, it has no particular legal force or relevance. If you write incorrect information in there it doesn't really result in any legal issues, it's just...an error that should be corrected. But we should probably just wait for Spot to weigh in. =) -- 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: [Fedora-legal-list] GIMP vs. poppler licensing, was: So you want to test an unstable GIMP...
> "NP" == Nils Philippsen writes: NP> Legal question: is it better to put this in its own subpackage to be NP> able to specify this individual license, or would GIMP better have NP> "GPLv3+ and LGPLv3+ and (GPLv2 or GPLv3)" as its license? This is covered by http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Multiple_Licensing_Scenarios Basically, you are encouraged to separate differently licensed pieces of code into subpackages with different licensing. However, it is sufficient to simply indicate all of the licenses in the License: tag and include an explanation of which files in the binary package are under which license. (Various methods for doing this are given in the URL above.) - J< -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
GIMP vs. poppler licensing, was: So you want to test an unstable GIMP...
It seems one always forgets something... well, better this than leaving the stove on. On Thu, 2011-09-01 at 12:45 +0200, Nils Philippsen wrote: > Here's the gist (in no particular order): - GIMP 2.7 and later is licensed as "GPLv3+ and LGPLv3+" (executables, libraries) - This makes it incompatible with poppler's license (GPLv2 only, inherited from xpdf at the time). The xpdf license has since been amended to "GPLv2 or GPLv3" in version 3.03 and poppler will follow suit in version 0.20. In the meantime, I'll build GIMP without poppler, falling back to using the postscript plugin for importing PDF files. As soon as poppler packages with the new license are available, I'll revert to using it again. In this case the GIMP will have a file-pdf plugin again which will be licensed as "GPLv2 or GPLv3" (as it's an exe of its own). Legal question: is it better to put this in its own subpackage to be able to specify this individual license, or would GIMP better have "GPLv3+ and LGPLv3+ and (GPLv2 or GPLv3)" as its license? Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] 2011-09-02 @ 17:00 UTC - F16 Beta Blocker Bug Review #2
# F16 Beta Blocker Review meeting #2 # Date: 2011-09-02 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net The second action packed beta blocker review meeting will be this Friday at 17:00 UTC in #fedora-bugzappers. We'll be running through the beta blockers and nice-to-haves. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the Beta release criteria [2] and should stay on the list 2. Whether they are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting . Thanks, Tim [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria signature.asc Description: PGP signature ___ 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: Some days it just doesn't pay to update
On Thu, 2011-09-01 at 09:47 -0600, Jonathan Corbet wrote: > On Wed, 31 Aug 2011 16:21:13 -0700 > Adam Williamson wrote: > > > Obvious suspects there - gnome-bluetooth and udev for the BT keyboard > > issue, > > None of the above, as it turns out. These guys: > > bluez-libs-4.96-2.fc17.x86_64 > bluez-4.96-2.fc17.x86_64 > > break my keyboard. Downgrading to: > > bluez-libs-4.96-1.fc17.x86_64 > bluez-4.96-1.fc17.x86_64 > > makes me happy. Interesting changelog: http://koji.fedoraproject.org/koji/buildinfo?buildID=260991 I've pinged hans about it. -- 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: Draft 'install alongside Windows' test case
On Thu, 2011-09-01 at 05:49 -0400, Al Dunsmuir wrote: > On Wednesday, August 31, 2011, 10:27:27 PM, Adam Williamson wrote: > > On Wed, 2011-08-31 at 20:45 -0400, Al Dunsmuir wrote: > >> On Wednesday, August 31, 2011, 8:08:19 PM, Adam Williamson wrote: > >> > Hey, folks. I just threw together a quick draft of an 'install alongside > >> > Windows' test case - we have this as a final criterion, but no test case > >> > for it as of yet. Here's the draft: > >> > >> > https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_install_alongside_Windows > >> > >> > any comments, questions, suggestions welcome! thanks. > >> > >> I think that you need to be specific as to what you mean by "Windows" > >> - especially given the different behaviours with GPT and MBR. > > > Well, no version of Windows yet sets up a GPT disk label, and anaconda > > is supposed to leave existing MSDOS disk labels around. > > True, but anaconda does let one create additional empty partitions > that could be used to install Windows after Fedora (creating a dual > boot system in the opposite order). The release criterion explicitly doesn't support this; installing Windows after Linux is known to be Doing It Rong, or at least, making it harder than it needs to be. > Where a Windows variant does support GPT, it would be useful to know > if it tolerates installing in a partition created during the Fedora > install. Useful, sure. Not really part of our criteria or something I'm terribly worried about for release validation testing, though. I mean, if you want to write something up to be added to the matrix as an optional test or something, go for it...but I don't think it's something we need to cover in just a simple basic test case to validate the criterion. > >> There need to be tests (with release blocking on fails for): > >> * XP 32-bit (both FAT and NTFS) > >> * Vista (32 & 64-bit) > >> * Windows 7 (32 & 64-bit) > >> * Windows 8 preview (32 & 64-bit) > > > Remember, the tests go into a matrix which has both 32-bit and 64-bit > > columns, so there's no need to have different tests. > > I'm not talking Fedora 32-bit vs 64-bit, I'm talking Windows 32 vs 64. The results page doesn't say 'Fedora' either =) > Making sure one records the Windows variant separately minimizes > confusion, and allows tests by multiple reporters to be merged > together reasonably. Again, that's not really something that goes in the test case itself, more in the results table. I don't really want to make that any longer than it *needs* to be. If we do get lots of people testing, and confusing results, we can lengthen it appropriately. > > I'm not sure it's realistic to list separate test cases for every > > version of Windows known to man; I left it generic on purpose so that > > people can test with whatever Windows they happen to own. The version of > > Windows that's present shouldn't ever make an awful lot of difference, > > anyway, since Fedora doesn't have to *do* anything with it besides > > identify it. Ditto FAT vs. NTFS: we're intentionally *not* covering > > partition resizing here, as it's not supported. About the only issue > > would be ensuring os-prober can recognize all Windows variants. > > The grub utility that does probing needs to be tested against a > variety of Windows variants. Accurately recording which variant that > was tested against was the point of my post. Well, my take on that is that if someone actually hits a failure, they'll need to file a bug report, and that information can be included in the bug. > >> I would suggest that you also want to test against a DOS variant > >> (especially FreeDOS since it is FOS). > > > This isn't in the scope of the release criteria, and I don't think it > > really needs to be. We're concerned with the common case of 'I want to > > install Fedora alongside Windows'. Installing alongside DOS is pretty > > corner case-y these days. > > FreeDOS documents grub booting. Again, the grub _probing_ should do > the right thing, or at least do no harm. Should? Sure. But I'm concerned with release validation, here, and that's not part of it. I'm not trying to write test cases to cover every possible function of os-prober here, just a test case to give a basic procedure to validate the release criterion we have in place, which is specific to Windows. -- 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: Draft 'install alongside Windows' test case
On Thu, 2011-09-01 at 10:10 -0400, Tom H wrote: > On Wed, Aug 31, 2011 at 8:08 PM, Adam Williamson wrote: > > > > Hey, folks. I just threw together a quick draft of an 'install alongside > > Windows' test case - we have this as a final criterion, but no test case > > for it as of yet. Here's the draft: > > > > https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_install_alongside_Windows > > > > any comments, questions, suggestions welcome! thanks. > > " Prepare a system with a Windows installation, and some free disk > space on the same disk as the Windows installation " > > Isn't the most likely scenario one where the Windows partition has to > be resized? We specifically don't support (in the sense of 'delay releases for') resizing as it's known to be a very hairy area. For instance, I did a test where I install a completely clean, single-partition Win7 system taking up an entire 20GB virtual disk, immediately booted to the Fedora installer and tried to resize the partition, and ntfsresize crapped out because (AFAICT) Windows had actually created the partition wrong - the NTFS filesystem was a sector larger than the actual underlying partition. This is, apparently, not unusual behaviour for Windows, and it's not something we can do much about because *ntfsresize itself* intentionally does not try and handle this case, it just throws an error and goes to bed. Basically, resizing is an inherently fragile operation and we made the choice not to 'guarantee' it with the criteria. You could say the test represents the scenario where you do the resizing with something specialized like gparted prior to starting Fedora installation. -- 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: services and systemd in F16
On Thu, 2011-09-01 at 15:28 +0200, Lennart Poettering wrote: > On Thu, 01.09.11 15:13, Nils Philippsen (n...@redhat.com) wrote: > > > > > On Thu, 2011-09-01 at 13:57 +0200, Lennart Poettering wrote: > > > On Thu, 01.09.11 13:49, Nils Philippsen (n...@redhat.com) wrote: > > > > > > > > We actually support this for quite some time now in F16. You can get a > > > > > list of all unit files that are installed with their enablement > > > > > status, > > > > > and you get notifications if their state changes. You have bus calls > > > > > to > > > > > enable/disable/link/mask/unmask units files. So it should all be > > > > > there. > > > > > > > > > > The bus interfaces are not really documented very well, but it's quite > > > > > straight-forward I think and fully introspectable. If you have > > > > > questions, please ping me. > > > > > > > > Cool. I guess I'll use that if available and fall back to running > > > > systemctl is-enabled/enable/disable if not. > > > > > > Why the fallback? > > > > Fedora 15. > > I thoiught we had the official policy these days that released > distributions do not receive feature upgrades, but only bugfixes and > security fixes. I am not sure how adding support for this bus interface > would qualify as bugfix/security fix... That's why I don't ask you to implement on systemd's dbus interface but roll it in my own, allowing me to keep things consolidated between releases. From the POV of a s-c-services user not being able to enable/disable services is a deficiency in F-15 over F-14 and earlier that needs fixing. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-16 Branched report: 20110901 changes
Compose started at Thu Sep 1 13:15:23 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpagent.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) airrac-0.1.0-2.fc16.i686 requires libstdair.so.0.36 airrac-0.1.0-2.fc16.i686 requires libstdairuicl.so.0.36 airrac-0.1.0-2.fc16.x86_64 requires libstdairuicl.so.0.36()(64bit) airrac-0.1.0-2.fc16.x86_64 requires libstdair.so.0.36()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libecal-1.2.so.9()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libebook-1.2.so.11()(64bit) 1:anerley-0.3.0-1.fc16.i686 requires libedataserver-1.2.so.14 1:anerley-0.3.0-1.fc16.i686 requires libebook-1.2.so.11 1:anerley-0.3.0-1.fc16.x86_64 requires libebook-1.2.so.11()(64bit) 1:anerley-0.3.0-1.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires libgnome-menu.so.2()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libedataserver-1.2.so.14()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires libebook-1.2.so.11()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires libebook-1.2.so.11()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfl
Re: Some days it just doesn't pay to update
On Wed, 31 Aug 2011 16:21:13 -0700 Adam Williamson wrote: > Obvious suspects there - gnome-bluetooth and udev for the BT keyboard > issue, None of the above, as it turns out. These guys: bluez-libs-4.96-2.fc17.x86_64 bluez-4.96-2.fc17.x86_64 break my keyboard. Downgrading to: bluez-libs-4.96-1.fc17.x86_64 bluez-4.96-1.fc17.x86_64 makes me happy. Downgrading claws-mail fixes that problem, naturally; it also gets me rssyl back, which is nice. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some days it just doesn't pay to update
On Wed, 31 Aug 2011 16:21:13 -0700 Adam Williamson wrote: > Obvious suspects there - gnome-bluetooth and udev for the BT keyboard > issue, claws-mail itself for the claws update. I don't think Bluetooth itself should come into play at all; the device simply looks like a keyboard, even the BIOS can cope with it. I don't even have Bluetooth built into my kernel (but note, again, that the Fedora kernel behaves the same way). The system *seems* to recognize it properly: Aug 31 16:49:15 bike kernel: [ 648.761264] usb 2-4.2.2: new full speed USB device number 18 using ehci_hcd Aug 31 16:49:15 bike kernel: [ 648.853757] usb 2-4.2.2: New USB device found, idVendor=046d, idProduct=c713 Aug 31 16:49:15 bike kernel: [ 648.853763] usb 2-4.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Aug 31 16:49:15 bike kernel: [ 648.853767] usb 2-4.2.2: Product: Logitech BT Mini-Receiver Aug 31 16:49:15 bike kernel: [ 648.853770] usb 2-4.2.2: Manufacturer: Logitech Aug 31 16:49:15 bike kernel: [ 648.853773] usb 2-4.2.2: SerialNumber: 0007617AC3F9 Aug 31 16:49:15 bike kernel: [ 648.858614] input: Logitech Logitech BT Mini-Receiver as /devices/pci:00/:00:1d.7/usb2/2-4/2-4.2/2-4.2.2/2-4.2.2:1.0/input/input12 Aug 31 16:49:15 bike kernel: [ 648.858919] generic-usb 0003:046D:C713.000A: input,hidraw1: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-4.2.2/input0 (There is another set of stuff for the built-in mouse too; mouse doesn't work either). The syslog output is the same regardless of whether the device actually works or not. udev is an interesting idea, I may mess with that. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft 'install alongside Windows' test case
On Wed, Aug 31, 2011 at 8:08 PM, Adam Williamson wrote: > > Hey, folks. I just threw together a quick draft of an 'install alongside > Windows' test case - we have this as a final criterion, but no test case > for it as of yet. Here's the draft: > > https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_install_alongside_Windows > > any comments, questions, suggestions welcome! thanks. " Prepare a system with a Windows installation, and some free disk space on the same disk as the Windows installation " Isn't the most likely scenario one where the Windows partition has to be resized? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Grub2 not including windows
On Tue, Aug 30, 2011 at 10:07 AM, David Lehman wrote: > On Tue, 2011-08-30 at 07:39 +0530, Rahul Sundaram wrote: >> On 08/26/2011 10:01 PM, David Lehman wrote: >> > >> > We added code to automatically generate entries using os-prober, but >> > apparently os-prober is not available if you install from DVD without >> > enabling network repos. It's probably also unavailable if doing a live >> > install. We'll be working on rectifying this. >> >> Does this transparently detect other Linux distributions? If so, that >> needs testing and definitely worth highlighting in the documentation > > It should find other linux distributions. I expect there to be issues > with the kernel command line arguments which will probably require some > upstream grub2 work to get sorted out. I think that os-prober picks up grub.conf/menu.lst or grub.cfg entries, if they exist, on the partitions that it probes. I once landed through Google on a grub-devel post where one of the grub developers said that os-prober wasn't a grub program but a debian-boot one. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft 'install alongside Windows' test case
>Well, no version of Windows yet sets up a GPT disk label, and anaconda >is supposed to leave existing MSDOS disk labels around. I configured Windows Vista Ultimate 64-bit to use several disks in a software RAID arrangement a year or two past. A BIOS update to this HP system subsequently killed Windows (Fedora on the same machine was fine), but I suspect Windows used GPT labels (or something that looked like GPT disk labels) for the RAID disks. I encountered failures from fdisk, and complaints from parted about GPT labels, when I subsequently reused the RAID disks for single-volume file systems. This is not proof that Windows uses GPT disk labels, but suggests it may occur in some circumstances. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: services and systemd in F16
On Thu, 2011-09-01 at 13:57 +0200, Lennart Poettering wrote: > On Thu, 01.09.11 13:49, Nils Philippsen (n...@redhat.com) wrote: > > > > We actually support this for quite some time now in F16. You can get a > > > list of all unit files that are installed with their enablement status, > > > and you get notifications if their state changes. You have bus calls to > > > enable/disable/link/mask/unmask units files. So it should all be there. > > > > > > The bus interfaces are not really documented very well, but it's quite > > > straight-forward I think and fully introspectable. If you have > > > questions, please ping me. > > > > Cool. I guess I'll use that if available and fall back to running > > systemctl is-enabled/enable/disable if not. > > Why the fallback? Fedora 15. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20110901 changes
Compose started at Thu Sep 1 08:15:05 UTC 2011 Broken deps for x86_64 -- FlightGear-2.0.0-6.fc16.x86_64 requires libosgViewer.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgUtil.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgText.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgSim.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgGA.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgFX.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) SimGear-2.0.0-6.fc16.i686 requires libosgParticle.so.74 SimGear-2.0.0-6.fc16.i686 requires libosgDB.so.74 SimGear-2.0.0-6.fc16.i686 requires libosg.so.74 SimGear-2.0.0-6.fc16.i686 requires libOpenThreads.so.11 SimGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires libgnome-menu.so.2()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libedataserver-1.2.so.14()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet dh-make-0.55-3.fc15.noarch requires debhelper ekiga-3.3.1-3.fc17.x86_64 requires libpt.so.2.10.1()(64bit) ekiga-3.3.1-3.fc17.x86_64 requires libcamel-1.2.so.28()(64bit) emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_contrib.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_calib3d.so.2.2 fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_video.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_objdetect.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_ml.so.2.2()(64bit) fawk
Re: services and systemd in F16
On Wed, 2011-08-31 at 17:55 +0200, Lennart Poettering wrote: > On Wed, 31.08.11 17:01, Nils Philippsen (n...@redhat.com) wrote: > > > What's missing is a way to enable/disable/monitor enablement of a > > systemd/SysV service, partly because systemd doesn't expose this via its > > dbus interface (which the privileged s-c-services mechanism uses). I'll > > probably make it check this when a service is selected, but I'd really > > like something (dbus signals?) which I could monitor for instantaneous > > updates (Lennart, pretty please?). So much to do and so few round > > tuits :-). > > We actually support this for quite some time now in F16. You can get a > list of all unit files that are installed with their enablement status, > and you get notifications if their state changes. You have bus calls to > enable/disable/link/mask/unmask units files. So it should all be there. > > The bus interfaces are not really documented very well, but it's quite > straight-forward I think and fully introspectable. If you have > questions, please ping me. Cool. I guess I'll use that if available and fall back to running systemctl is-enabled/enable/disable if not. Thanks, Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some days it just doesn't pay to update
On 31 August 2011 23:57, Jonathan Corbet wrote: > So, I thought...LWN writing is almost done for the day, why not do an > update and see what happens? > I see the keyboard unpleasantness with both the > kernel-3.1.0-0.rc4.git0.0.fc17.x86_64 kernel I think 99% of the developers are now running and fixing F16. I don't think a lot of people care about F17 at the moment. Richard. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
So you want to test an unstable GIMP...
...or so I've heard[1]. Here we go: Herewith I announce the officially unofficial unstable GIMP for Fedora repository! I've held off making packages of the 2.7.x series for a long time, but thankfully Luya Tshimbalanga has offered his own versions of these on his fedorapeople repository, compensating for my slackness in that regard in the meantime. However, since I whined about testing on what will eventually become official packages (and because I'm a stickler for having signed packages in publicly available repos[2] -- I'm looking at you, spot), I've decided to bite the bullet and wrap up some packages by myself. Here's the gist (in no particular order): - Don't bother if you (or your spouse/kids/dog) are offended by having to look at a caged Wilber dominated by a goat in garters every single time you start the program. The rest of you may discuss the sheer brilliance of this metaphor. - Save early, save often and don't overwrite originals. - The packages are for Fedora 15, 16 and Rawhide (14 is missing dependencies all over the place -- gtk2, glib2, babl, gegl) and are signed with my GnuPG key[2]. Its fingerprint is in my email signature since a few years, I guess that'll have to do. - No patches anymore since everything is upstreamed. Woot! - External and third party plugins and scripts should work with this version. If GIMP warns you about these using deprecated interfaces, report this to the author(s) of the plugin in question. Crashes should be reported upstream to both GIMP and the plugin author(s). - These packages contain configuration which kicks ABRT in the shin so it won't generate reports for GIMP executables. If you run into bugs which are related to packaging, send me an email, otherwise report them to the upstream Bugzilla[3]. No tickets on bugzilla.redhat.com for these, please. - No delta RPMs (yet) as I'm too lazy to download the old versions for three distro versions and two architectures right now. - I'll probably throw in git snapshots when I feel like it. - The packages are called as they stable ones are (no "unstable" or "beta" in their names) and override the official Fedora packages. No way to install both stable and unstable packages at the same time. - Saving only saves to GIMP's native image format XCF. Nowadays you export to formats like JPEG, PNG, GIF. - If you want to use the new single window mode, you need to activate it in the "Windows" menu once. It's not the default. - GIMP will migrate settings from stable releases. If you want to start with a clean slate, move away or remove the ~/.gimp-2.6 folder (or that of any older stable GIMP version) before starting this GIMP version for the first time. Here's how you get this: - Download a release file for this repository (e.g. [4]) and install it. - Update your packages if you have gimp installed already, "yum install gimp gimp-help-browser" otherwise. Here's how you get rid of this and get the stable version back. - "rpm -e fedora-gimp-unstable-release" - "yum downgrade gimp\*" It's probably a good idea to not enable both Luya's and my repository at the same time. To switch between them, disable the repo configuration of the used repo, "yum downgrade gimp\*" to get back to the official versions, then enable the new one and "yum update". As soon as Fedora carries official packages, these will supersede the unstable versions. At that time you should uninstall the fedora-gimp-unstable-release package, or else installing/updating packages may fail when I remove the repository (as I'll probably forget to tell you about it then). Have fun and don't let it bite you. Nils [1]: http://lists.fedoraproject.org/pipermail/devel/2011-August/156160.html [2]: http://repos.fedorapeople.org/repos/nphilipp/gimp-unstable/RPM-GPG-KEY-nphilipp [3]: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP&version=2.7.3 [4]: http://repos.fedorapeople.org/repos/nphilipp/gimp-unstable/fedora-15/x86_64/fedora-gimp-unstable-release-2.7-1.fc15.noarch.rpm -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: August 31 Installs
2011/9/1 Chuck Forsberg WA7KGX N2469R: > I couldn't get a printer to configure, so had to boot something else > to get some work done. May be this issue: https://bugzilla.redhat.com/show_bug.cgi?id=734247 ? I haven't found a way yet to work around it. Using the CUPS web interface instead returns "bad request", thus no printer set up either. ~C -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft 'install alongside Windows' test case
On Wednesday, August 31, 2011, 10:27:27 PM, Adam Williamson wrote: > On Wed, 2011-08-31 at 20:45 -0400, Al Dunsmuir wrote: >> On Wednesday, August 31, 2011, 8:08:19 PM, Adam Williamson wrote: >> > Hey, folks. I just threw together a quick draft of an 'install alongside >> > Windows' test case - we have this as a final criterion, but no test case >> > for it as of yet. Here's the draft: >> >> > https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Testcase_install_alongside_Windows >> >> > any comments, questions, suggestions welcome! thanks. >> >> I think that you need to be specific as to what you mean by "Windows" >> - especially given the different behaviours with GPT and MBR. > Well, no version of Windows yet sets up a GPT disk label, and anaconda > is supposed to leave existing MSDOS disk labels around. True, but anaconda does let one create additional empty partitions that could be used to install Windows after Fedora (creating a dual boot system in the opposite order). Where a Windows variant does support GPT, it would be useful to know if it tolerates installing in a partition created during the Fedora install. >> There need to be tests (with release blocking on fails for): >> * XP 32-bit (both FAT and NTFS) >> * Vista (32 & 64-bit) >> * Windows 7 (32 & 64-bit) >> * Windows 8 preview (32 & 64-bit) > Remember, the tests go into a matrix which has both 32-bit and 64-bit > columns, so there's no need to have different tests. I'm not talking Fedora 32-bit vs 64-bit, I'm talking Windows 32 vs 64. Making sure one records the Windows variant separately minimizes confusion, and allows tests by multiple reporters to be merged together reasonably. > I'm not sure it's realistic to list separate test cases for every > version of Windows known to man; I left it generic on purpose so that > people can test with whatever Windows they happen to own. The version of > Windows that's present shouldn't ever make an awful lot of difference, > anyway, since Fedora doesn't have to *do* anything with it besides > identify it. Ditto FAT vs. NTFS: we're intentionally *not* covering > partition resizing here, as it's not supported. About the only issue > would be ensuring os-prober can recognize all Windows variants. The grub utility that does probing needs to be tested against a variety of Windows variants. Accurately recording which variant that was tested against was the point of my post. Otherwise your test might as well be comprised of tests against empty FAT and NTFS partitions. >> I would suggest that you also want to test against a DOS variant >> (especially FreeDOS since it is FOS). > This isn't in the scope of the release criteria, and I don't think it > really needs to be. We're concerned with the common case of 'I want to > install Fedora alongside Windows'. Installing alongside DOS is pretty > corner case-y these days. FreeDOS documents grub booting. Again, the grub _probing_ should do the right thing, or at least do no harm. As noted, very much a corner case but if it breaks there should be a note somewhere that Google could spider. I've got to install FreeDOS at some point to test zip/unzip built under Linux, but I'm not likely going to be ready in time to contribute to the F16 beta test results. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
August 31 Installs
The 64 bit netinst install panicked and locked up with default video or basic video. The Live desktop Gnome 3 install to disk installed with basic storage devices, which had flummoxed Verne in the past. Acceleration seems to work with an Nvidia gt460se. There might be some hope for Gnome 3 if remote admin is not a requirement. System admin needs to be brought to the level of quality last seen in Fedora 14. I couldn't get a printer to configure, so had to boot something else to get some work done. -- Chuck Forsberg WA7KGX N2469R 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
