Re: xfce does not remember saved sessions on Fedora 20
On 12/16/2013 11:38 PM, Kevin Fenzi wrote: I'm still scratching my head over the other applications not saving/restoring correctly, but xfce4-terminal at least is fixed in an update I just pushed. Thanks for taking care about this issue. Testing and karma welcome: https://admin.fedoraproject.org/updates/xfce4-terminal-0.6.2-3.fc19 So far, I've only given the x86_64.fc19 version a try. - xfce4-terminals now seem to be saved and restored correctly. - Same issues with gnome as before. E.g. ghex, gedit get restored on last active workspace before log-out (The workspace the log-out was performed), instead of the workspace they were placed on before log-out. - No issues with firefox and thunderbird. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposed validation test case: root on LVM thinp
On Dec 16, 2013, at 6:33 PM, Adam Williamson wrote: > Actually - it'd basically just be the 'guided installation' table from > https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix#Guided_installationwithout > all the other bits, basically. I basically get this. I expect there'll be separate matrices or pages for the archs? Question for EFI as an arch, we haven't been testing every layout presumably because of overlap with x86_64. But I'd guess the QA:Testcase_dualboot_with_windows tests for existing GPT, and EFI System partition, rather than actually creating them (correctly). I'll bet the code that does that is called once for all of the guided partition schemes. So it seems like if we check the Windows case to make sure it doesn't break Windows, we also get a "use existing GPT and ESP" test of code; but still need one that "creates new GPT and ESP" layout test of the code. Yes? I did that on Mac EFI, but it's got slightly different code. > Do we think it's worth taking that bit out of the larger storage rework > proposal and sticking it in the current matrix, replacing the > appropriate existing test cases? It would be an hour or two's work for > me, I guess. Eh, I guess I'll just draft it up and send it out and see > what you all think. Why not just delete the appropriate existing test cases rather than merging them? Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Dec 16, 2013 1:23 PM, "Adam Williamson" wrote: > > Hi, folks. So this one keeps popping up for individual people, and we > keep doing a quick band-aid when anyone needs group membership...but we > may as well just bite the bullet and do it properly. > > Fedora QA has always been pretty informally organized, we've generally > not wanted to build a big heavy organizational structure with > hierarchies and bits of paper to sign and stuff. One facet of this is > that we don't really have an 'official' Fedora QA FAS group. There is a > 'qa' group in FAS, but it has very few members, and we haven't ever > worked on the assumption that the people in it are the 'real' QA people > or anything. > > For our purposes we don't really have any incredible need for a QA group > in FAS, but there are some things in Fedora which require you to be a > member of a FAS group besides cla_signed - voting in some elections, for > instance, and getting a fedorapeople.org space. It seems unfortunate > that QA contributors don't get these things unless they get themselves > added to another group. > > So I'm proposing we do something simple: let's just go ahead and stick > everyone who can reasonably be considered a 'QA team member' in the FAS > 'qa' group. This wouldn't be hard to do, I can make sure sufficient > people within and outside RH have moderator status in the qa group, and > then those of us who are mods can just add people appropriately. Anyone > who files karma regularly, or validation test results, or posts to > test@, or attends QA team meetings, anything like that - let's just > stick 'em in QA group, and then for the future we can just say > 'moderators can give anyone who's obviously a QA person membership in > the QA group at any time, and when someone sends a self-introduction > mail and doesn't completely disappear, the QA group mods should stick > that person in the group'. > > How does that sound? Seems like something we can just get done already. > > Right now me, James Laska, Will Woods and Jesse Keating are the admins > of the QA group. This is obviously a bit silly. I'll drop jlaska's, > wwoods' and jesses' admin roles, and make some more appropriate people > admins and moderators instead. I'll do that right now, since it's > clearly the right thing to do... > -- > Adam Williamson > Hi, random outside-ish perspective here: I semi-regularly do something like "/msg zodbot fasinfo johannbg", to locate an email address, check time zone, pair with a name and face, whatever. I appreciate that FAS groups give me an idea of someone's area of contribution, even if I don't know the degree or the privileges allowed to members of a given group. These things help the communicate effectively, and I was surprised when I learned from this mail that the 'QA' group was disused. --Pete -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
> So I'm proposing we do something simple: let's just go ahead and stick > everyone who can reasonably be considered a 'QA team member' in the > > FAS > 'qa' group. This wouldn't be hard to do, I can make sure sufficient > people within and outside RH have moderator status in the qa group, and > then those of us who are mods can just add people appropriately. Anyone > who files karma regularly, or validation test results, or posts to > test@, or attends QA team meetings, anything like that - let's just > stick 'em in QA group, and then for the future we can just say > 'moderators can give anyone who's obviously a QA person membership in > the QA group at any time, and when someone sends a self-introduction > mail and doesn't completely disappear, the QA group mods should stick > that person in the group'. If we can do every QA stuff without being a part of QA group then what's the use of creating a QA group -- Akshay vyas (http://www.gofedora.in) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
RE: Proposal: let's just use the FAS group already
Ahoy, So, I am with Adam on this one (I'm not a mod?). I've been +1 for this idea for quite some time now. Johann, I've been around for a long time, even longer than Adam, and I don't remember the original purpose for the QA group; I do vaguely recall James Laska telling me it had some purpose or other when I asked him about it (oddly enough so I could be in more than the CLA group). John -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
Thank you for the summary Bob. I was necessary.
On Mon, 2013-12-16 at 20:12 -0500, Bob Lightfoot wrote:
> Let me make sure I have this correct. {I had to read 20+ emails to
> condense it, I may have missed something}
>
> PROBLEM STATEMENT: There exists and will continue to exist persons who
> participate in and assist the QA process in quantifiable ways. These
> persons would like access to the fedorapeople space to assist them in
> assisting QA. Presently access to fedorapeople space requires
> membership in an FAS Group other than CLA signed.
The entire project, including infra uses FAS groups to grant volunteers
access to various resources. I see no reason why QA shouldn't use this
too.
>
> ADAM'S SOLUTION: Open up the presently mostly idle QA-FAS Group and
> add these people granting them fedorapeople access.
+1 for this.
>
> JOHANN'S OBJECTION: The group was idled eons past for valid reasons
> {not elaborated, but still valid} and ressurecting the group is not
> advisable.
I haven't found the reasons. Unfortunately, I really don't have the time
to go through the archives and hunt them down. A one sentence summary
would be helpful :)
If the issue is to do with inactive members, it's something all
volunteer projects need to tackle. As long as the number of active
members is more than inactive ones, or even sufficient to handle QA
tasks properly, the inactive ones can just be left alone. Mods can prune
them out when they have nothing else to do.
If the issue is some shortcoming in the design of FAS or how the project
is structured, I'd be most interested in listening to it at the right
channels: infra probably?
>
> JOHANN'S SOLUTION: None given yet, that I can determine, just doesn't
> like Adam's.
>
> OTHER SOLUTIONS PROPOSED: Haven't read any other solutions proposed.
>
> If that wraps things up, lets either propose an alternative to Adam's
> idea or move forward with Adams. Reading 20 emails on this problem is
> enough.
+1 to Adam's proposal. I see no "game" here. Let's not turn Adam into
Moriarty ;)
--
Thanks,
Warm regards,
Ankur (FranciscoD)
http://fedoraproject.org/wiki/User:Ankursinha
Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG
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: Proposed validation test case: root on LVM thinp
On Fri, 2013-12-13 at 14:13 -0800, Adam Williamson wrote: > I meant to write this test case anyhow, but today's brown paper bag bug > - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1040669 - gives > it a certain sense of importance, so I thought I'd best get it done now. > > I wrote > https://fedoraproject.org/wiki/QA:Testcase_anaconda_lvmthinp_rootfs , > and I propose we add it to the installation validation matrix for F21 > and later, with release level Beta, as it matches this criterion: > > https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Guided_partitioning > > "When using the guided partitioning flow, the installer must be able > to: ... Complete an installation using any combination of disk > configuration options it allows the user to select" > > LVM thinp is now one of the options on the 'filesystem type' dropdown on > the Installation Options screen, which is what 'disk configuration > options' in that criterion is talking about. > > Anyone have feedback on the test case, or the proposed inclusion in the > matrices? I based the test case on the ext4 rootfs one but tidied it up > somewhat, and placed stronger restrictions on changing other > configuration during the test; I will probably go through all the > filesystem-y test cases and propose similar changes, if we think that's > a good idea. We should try to make the whole set consistent. I went ahead and stuck the thinp test case in the F21 template, for now, since no-one raised any issues with it. Beyond that, though, even a *small* rework of the existing partitioning test cases exposes a bit of a problem. The partitioning test cases we do have are basically still oldUI holdovers, they were written explicitly to the old anaconda UI. There wasn't so much filesystem selection in autopart in oldUI, so the test cases are split between just exercising the different autopart algorithms oldUI had (use all space, use free space, wipe Linux partitions only) and a few desultory tests of different filesystems in custom partitioning. oldUI did let you pick whether to use LVM or not, but the old test cases just sort of conveniently ignored that distinction. newUI has filesystem options in guided partitioning, which makes things a bit more complex. right now we just have the old autopart test cases slightly tweaked for newUI's guided partitioning, and the old filesystem test cases not really accounting for the fact that you can do filesystem selection in guided partitioning. My off-the-top-of-my-head idea for revising it would be to do the kind of 'matrix judo' I've been fond of recently, with small matrices with different column headings according to what's being exercised: further modify the 'autopart' tests to properly cover the various possibilities in 'guided partitioning' for newUI, then have a matrix with those tests as the rows and the column headings being 'LVM, standard partition, btrfs, lvm thinp'. Actually - it'd basically just be the 'guided installation' table from https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix#Guided_installation without all the other bits, basically. Do we think it's worth taking that bit out of the larger storage rework proposal and sticking it in the current matrix, replacing the appropriate existing test cases? It would be an hour or two's work for me, I guess. Eh, I guess I'll just draft it up and send it out and see what you all think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/16/2013 04:38 PM, Kevin Fenzi wrote: I'm still scratching my head over the other applications not saving/restoring correctly, but xfce4-terminal at least is fixed in an update I just pushed. Testing and karma welcome: https://admin.fedoraproject.org/updates/xfce4-terminal-0.6.2-3.fc19 https://admin.fedoraproject.org/updates/xfce4-terminal-0.6.2-3.fc20 kevin Terminal issue definitely solved here! Super! I will add karma shortly. Other applications - nope! Firefox - not predictable. Thunderbird - definitely not. Thunar - not sure yet. But, it seems to mostly start. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 20:12 -0500, Bob Lightfoot wrote:
> Let me make sure I have this correct. {I had to read 20+ emails to
> condense it, I may have missed something}
>
> PROBLEM STATEMENT: There exists and will continue to exist persons who
> participate in and assist the QA process in quantifiable ways. These
> persons would like access to the fedorapeople space to assist them in
> assisting QA. Presently access to fedorapeople space requires
> membership in an FAS Group other than CLA signed.
fedorapeople.org space is just an example - there are others, the one
that leapt to mind was elections, but I think there are yet others
beyond that. And the FAS group would also let us grant all QA folks
'editbugs' privileges too, which can come in handy.
Other than that, good summary :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Let me make sure I have this correct. {I had to read 20+ emails to
condense it, I may have missed something}
PROBLEM STATEMENT: There exists and will continue to exist persons who
participate in and assist the QA process in quantifiable ways. These
persons would like access to the fedorapeople space to assist them in
assisting QA. Presently access to fedorapeople space requires
membership in an FAS Group other than CLA signed.
ADAM'S SOLUTION: Open up the presently mostly idle QA-FAS Group and
add these people granting them fedorapeople access.
JOHANN'S OBJECTION: The group was idled eons past for valid reasons
{not elaborated, but still valid} and ressurecting the group is not
advisable.
JOHANN'S SOLUTION: None given yet, that I can determine, just doesn't
like Adam's.
OTHER SOLUTIONS PROPOSED: Haven't read any other solutions proposed.
If that wraps things up, lets either propose an alternative to Adam's
idea or move forward with Adams. Reading 20 emails on this problem is
enough.
Sincerely,
Bob Lightfoot
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSr6TrAAoJEKqgpLIhfz3XiOUH/RHJTLnmWXc/lwwdrMeuNJc5
LGFw7RrlowDsc1YWTKj7m0Ae8cK5bRKYz1KCBvHSDgnGou6otaP09NqEipTxw5Fd
cQTpulOOWd0lhpyzKx9VLlN4Flro7ZRrMBIcXUa8chGLPd/fff40sqt/+mZBd5RT
cBUajd/9QKo3JpCb1AV6UstEVe7djFRXpbKZMKAjCx7x9HRxpn33ja1x8O/jhMUW
k11t/JpD2djGBjWjduJEwTW3q/gj7aZdn6qXWkyxtlmHBUdyh5DQPx8dAQUPyxaM
dMURM+OQHwmkg1uXNQqwl9ZxpScOCQXMlnODO4c0vECZSwc5p94dLD10sbXhK1s=
=kl7J
-END PGP SIGNATURE-
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft combined checksums test case and sanity matrix
On Sun, 2013-12-15 at 20:18 -0800, Adam Williamson wrote: > Hi, folks. So I've had this on my todo list for the last three weeks > (oops...): > > "adamw to draft a new test case and matrix row for validating cloud > image checksums" > > So I finally got around to doing it. Looking at how to integrate a test > into the matrices, it seemed to me like we could combine all the 'image > sanity' tests together into a single matrix; over time, they've all got > separated and moved around into sort of random positions in the tables, > and we don't really need three different checksum test cases. > > So, I've drafted a 'generic' checksum test case, which is really just > the ISO checksum test case - > https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums - > slightly modified to make the 'checkisomd5' step optional (to cover the > case of the non-ISO images to which it doesn't apply). > > Then I drafted a new matrix, with just the image sanity tests in it: > > https://fedoraproject.org/wiki/User:Adamwill/Draft_sanity_matrix > > we could make this its own page, or we could simply make it a section of > the Installation matrix page, it doesn't really matter. Obviously, the > tests would be moved out of their current locations. > > Oh, I've just noticed, we would also have to slightly extend > https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size to list > target sizes for ARM and Cloud images. This would be a trivial change. I > think we can assume their max sizes are CD size (same as netinst) for > all except the ARM KDE image, which probably can be taken to have the > same size target as the x86 Live. As all the feedback in the meeting this morning was positive, and viking-ice didn't raise any objections when I asked him about it, I've gone ahead and just done this - created the f21 installation results template: https://fedoraproject.org/wiki/QA:Fedora_21_Install_Results_Template and put the new image sanity matrix in at the top, taking the image sanity tests out from everywhere else they existed. I put my draft checksum test case into production as https://fedoraproject.org/wiki/QA:Testcase_Mediakit_Checksums - Andre, if you see anything wrong, yell, or just go ahead and fix it! - and threw some ARM and cloud target sizes into https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size . I also tweaked the colors of the section headings while I was in there, so none of them are duplicated and USB isn't grey any more :) Yell if anyone sees anything wrong - this stuff won't be used in anger until we hit F21 Alpha testing, and may need more revision for the fedora.next stuff, so it's not very urgent. I just wanted to make sure I didn't forget about it and wind up never pushing it out. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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 79 https://admin.fedoraproject.org/updates/FEDORA-2013-17836/davfs2-1.4.7-3.fc19 59 https://admin.fedoraproject.org/updates/FEDORA-2013-19262/quassel-0.9.1-1.fc19 51 https://admin.fedoraproject.org/updates/FEDORA-2013-19963/openstack-glance-2013.1.4-1.fc19 9 https://admin.fedoraproject.org/updates/FEDORA-2013-22919/net-snmp-5.7.2-13.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2013-23062/rubygem-i18n-0.6.1-4.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23141/python-setuptools-0.6.49-1.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23206/ack-2.12-1.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23315/libreswan-3.7-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23432/openttd-1.3.3-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23437/v8-3.14.5.10-3.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23457/xen-4.2.3-12.fc19 The following Fedora 19 Critical Path updates have yet to be approved: Age URL 25 https://admin.fedoraproject.org/updates/FEDORA-2013-21772/unzip-6.0-11.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23155/langtable-0.0.23-1.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23141/python-setuptools-0.6.49-1.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23219/iscsi-initiator-utils-6.2.0.873-17.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23305/libfm-1.1.4-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23419/gcc-4.8.2-7.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23412/xorg-x11-drv-synaptics-1.7.1-6.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23454/yum-3.4.3-122.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23467/gupnp-0.20.9-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2013-22326/fedora-bookmarks-15-5.fc19 The following builds have been pushed to Fedora 19 updates-testing CuraEngine-13.11.2-1.fc19 armadillo-3.930.1-1.fc19 bcfg2-1.3.3-3.fc19 chmsee-2.0.2-5.git86d101c9.fc19 cura-13.11.2-1.fc19 dmlite-0.6.1-2.fc19 ez-ipupdate-3.0.11-0.29.b8.fc19 fedora-bookmarks-15-5.fc19 fedpkg-1.15-1.fc19 gupnp-0.20.9-1.fc19 libvirt-1.0.5.8-1.fc19 netpbm-10.61.02-7.fc19 php-symfony-2.3.7-4.fc19 qterminal-0.4.0-5.fc19 speedcrunch-0.11-0.8.alpha.fc19 thunderbird-lightning-2.6.4-7.fc19 ultimaker2-marlin-firmware-13.11-2.1.fc19 vcsh-1.20131214-1.fc19 xen-4.2.3-12.fc19 yum-3.4.3-122.fc19 Details about builds: CuraEngine-13.11.2-1.fc19 (FEDORA-2013-23458) Engine for processing 3D models into G-code instructions for 3D printers Update Information: cura update 13.11.2 * Adjusted the gantry height to 55mm for the Ultimaker, as 60mm was 3mm to high for the default setup with an V2 hotend. * Added disallowed zones for UM2 * Added ooze-shield for dual-color printing * Added wipe tower for dual-extrusion * Added no-go zones for UM2 glass clips * Added imageToMesh tool to load images as 3D height maps * Fixed Z support distance when using "everywhere" support. * Updated to new version of clipper to fix rare slicing bugs that resulted in odd paths. * Fixed "Reset profile" so it no longer resets the machine settings. * Updated support material so support is smoother and has less small sections which are hard to remove. * Fixed start-gcode when using dual-support material * Change how the fan is handled on lower layer to improve UM2 printing. * Fix that retraction is enabled when selecting UM2 or RepRap. * Scale down very large models, or scale up very tiny models automagicly. * Fixed skirt and brim to go around the support instead of under it. * Added spiralize mode Ultimaker2 - Firmware update - 13.11-2 * Fixed UM2 build volume offset so that you do not print off the glass plate. * Slightly tweaked the filament change procedure so there is less chance of a blob staying behind. * Slightly tweaked the SD-Card error problems. * Added LED settings to Tune menu * Start heating the nozzles when the bed is nearing its final temperature, so the nozzles do not sit hot. * Make sure all commands are finished before starting a print or changing material. This could cause issues when you where too fast. * Fixed SD-Card read error * Added feature to store your own material presets * Fixed the 280C ABS problem, causing a temperature sensor error ChangeLog: * Sat Dec 14 2013 Miro Hrončok - 13.11.2-1 - New version 13.11.2 - Makefile seding changed to reflect changes - Clipper usage no longer need patching * Fri Aug 2 2013 Fedora Release Engineering
Fedora 18 updates-testing report
The following Fedora 18 Security updates need testing: Age URL 240 https://admin.fedoraproject.org/updates/FEDORA-2013-6117/eucalyptus-3.2.2-1.fc18 87 https://admin.fedoraproject.org/updates/FEDORA-2013-17195/spice-gtk-0.18-3.fc18 81 https://admin.fedoraproject.org/updates/FEDORA-2013-17635/wireshark-1.10.2-4.fc18 79 https://admin.fedoraproject.org/updates/FEDORA-2013-17853/davfs2-1.4.7-3.fc18 23 https://admin.fedoraproject.org/updates/FEDORA-2013-21875/389-ds-base-1.3.0.9-1.fc18 9 https://admin.fedoraproject.org/updates/FEDORA-2013-22949/net-snmp-5.7.2-7.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-23068/rubygem-i18n-0.6.0-2.fc18 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23122/firefox-26.0-2.fc18,xulrunner-26.0-1.fc18 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23140/python-setuptools-0.6.49-1.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23215/php-5.4.23-1.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23291/thunderbird-24.2.0-2.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23299/libreswan-3.7-1.fc18 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23378/openttd-1.3.3-1.fc18 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23401/v8-3.14.5.10-3.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23479/nss-util-3.15.3-1.fc18,nss-3.15.3-1.fc18,nss-softokn-3.15.3-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23466/xen-4.2.3-12.fc18 The following Fedora 18 Critical Path updates have yet to be approved: Age URL 310 https://admin.fedoraproject.org/updates/FEDORA-2013-2192/nautilus-3.6.3-5.fc18 9 https://admin.fedoraproject.org/updates/FEDORA-2013-22918/opus-1.1-1.fc18 9 https://admin.fedoraproject.org/updates/FEDORA-2013-22917/colord-1.0.5-1.fc18 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23122/firefox-26.0-2.fc18,xulrunner-26.0-1.fc18 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23140/python-setuptools-0.6.49-1.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23224/openssh-6.1p1-11.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23291/thunderbird-24.2.0-2.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23312/dracut-029-1.fc18.3 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23306/abrt-2.1.10-1.fc18,libreport-2.1.10-1.fc18,satyr-0.12-1.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-23297/libfm-1.1.4-1.fc18 1 https://admin.fedoraproject.org/updates/FEDORA-2013-23381/cryptsetup-1.6.3-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23479/nss-util-3.15.3-1.fc18,nss-3.15.3-1.fc18,nss-softokn-3.15.3-1.fc18 The following builds have been pushed to Fedora 18 updates-testing armadillo-3.930.1-1.fc18 bcfg2-1.3.3-3.fc18 chmsee-2.0.2-5.git86d101c9.fc18 eclipse-4.2.2-8.fc18 ez-ipupdate-3.0.11-0.29.b8.fc18 nss-3.15.3-1.fc18 nss-softokn-3.15.3-1.fc18 nss-util-3.15.3-1.fc18 qterminal-0.4.0-5.fc18 thunderbird-lightning-2.6.4-7.fc18 vcsh-1.20131214-1.fc18 xen-4.2.3-12.fc18 Details about builds: armadillo-3.930.1-1.fc18 (FEDORA-2013-23455) Fast C++ matrix library with interfaces to LAPACK and ATLAS Update Information: Latest stable release, the main changes are: * added divide-and-conquer variant of svd_econ(), for faster SVD * added divide-and-conquer variant of pinv(), for faster pseudo-inverse * added element-wise variants of min() and max() * added size() based specifications of submatrix view sizes * added randi() for generating matrices with random integer values * added inplace_trans() for memory efficient in-place transposes (contributed by Alexandre Drouin) * added more intuitive specification of sort direction in sort() and sort_index() * added more intuitive specification of method in det(), .i(), inv() and solve() * added more precise timer for the wall_clock class when using C++11 ChangeLog: * Tue Dec 10 2013 José Matos - 3.930.1-1 - update to 3.930.1 - update the name of the documentation paper from 2013 to 2014 bcfg2-1.3.3-3.fc18 (FEDORA-2013-23473) A configuration management system Update Information: Fixes bz #1043229 This update includes the new upstream 1.3.3 release and the work to reconcile the upstream specfile with the Fedora specfile. The new specfile includes the 'settings.py' module bugfix (commit 7895f095 from July). This update includes
Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 22:33 +, "Jóhann B. Guðmundsson" wrote: > On mán 16.des 2013 22:12, Adam Williamson wrote: > > What, in your estimation, would be the right place? Instead of just > > saying 'no', can you provide an alternative solution to the problem? > > Solution to fix this lies not within in us ( QA ) the alternative > solution requires a real change in the project not dressing the emperor > in new clothes which the WG proposal does. Well, I mean, I agree there are potentially other approaches to granting things like fedorapeople access and so on, but any change like that would be a big one which would likely involve lots of proposing and arguing and take a lot of time. I personally am not interested in driving such a change. The mechanics of FAS group membership and so on are not, in and of themselves, interesting to me, so this isn't something I want to work on. All I'm trying to do is remove a speedbump for new QA group members that we keep encountering, in the most simple and obvious way: currently the way the Fedora project is set up, it expects members of Fedora groups/projects like QA to be in a FAS group, so let's just do that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 22:26 +, "Jóhann B. Guðmundsson" wrote: > On mán 16.des 2013 22:22, Adam Williamson wrote: > > If you mean "Then limit that group entirely with providing him and > > others with that." - well, that's already what we'd be doing. The > > proposal isn't to make the QA group required for anything at all in > > relation to QA. The proposal is just to add all the QA people we can to > > the group, and in the future, when new people join, add them too. And > > make it inherit fedorabugs (or make fedorabugs inherit it, whichever way > > around it goes) so QA people get editbugs privileges. And > > then...nothing. That's it. We don't actually use the group for anything > > in QA, or anything. That's not what I'm suggesting. > > I thought you meant to ( or worried that it gradually will ) revoke it > to it's previous status I don't even know what its previous status was, but no, I certainly wasn't planning on suggesting we 'gate' anything on qa group membership. > but why dont you just add everybody to the > fedorabugs group and keep this one dead and buried? People aren't really meant to be directly added to the fedorabugs group, the design is that you get added to another group that inherits fedorabugs: the design is for fedorabugs to be simply a tool we use to grant editbugs status to members of various other groups. And this way just seems more clear - you're a QA person, you're in the QA group. It means we don't have to keep explaining and remembering all the background. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 16 Dec 2013, Bruno Wolff III wrote: > The game is to treat QA volunteers like other contributors. > That way they don't have to also become packagers (or > something else) in order to participate in Fedora Elections > or make use of resources limited to people who are in more > than just the Fedora CLA group. ... fwiw, this list is about the only Fedora list I actively read anymore in near real time. I am not directly interested in the various other roads into gaining 'elector' capacity because of the time commitments implied If there is a 'game afoot' by Adam, it is one of which approve if the end result is as Bruno outlines -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 16 Dec 2013 22:33:05 + "Jóhann B. Guðmundsson" wrote: > > On mán 16.des 2013 22:12, Adam Williamson wrote: > > What, in your estimation, would be the right place? Instead of just > > saying 'no', can you provide an alternative solution to the problem? > > Solution to fix this lies not within in us ( QA ) the alternative > solution requires a real change in the project not dressing the > emperor in new clothes which the WG proposal does. > > JBG How does the WG tie into getting people like danofsatx access to Fedorapeople and the other access they could use? // Roshi signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 16 Dec 2013 22:26:08 + "Jóhann B. Guðmundsson" wrote: > > On mán 16.des 2013 22:22, Adam Williamson wrote: > > If you mean "Then limit that group entirely with providing him and > > others with that." - well, that's already what we'd be doing. The > > proposal isn't to make the QA group required for anything at all in > > relation to QA. The proposal is just to add all the QA people we > > can to the group, and in the future, when new people join, add them > > too. And make it inherit fedorabugs (or make fedorabugs inherit it, > > whichever way around it goes) so QA people get editbugs privileges. > > And then...nothing. That's it. We don't actually use the group for > > anything in QA, or anything. That's not what I'm suggesting. > > I thought you meant to ( or worried that it gradually will ) revoke > it to it's previous status but why dont you just add everybody to the > fedorabugs group and keep this one dead and buried? > > JBG I think for the sake of sanity, having the group with a name that's clearly tied to it's purpose would be easier from an administration standpoint. Also wouldn't just appropriating the fedorabugs group have a negative impact on that group? Just a thought. // Roshi signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On 12/16/2013 04:06 PM, Bruno Wolff III wrote: On Mon, Dec 16, 2013 at 21:57:41 +, The game is to treat QA volunteers like other contributors. That way they don't have to also become packagers (or something else) in order to participate in Fedora Elections or make use of resources limited to people who are in more than just the Fedora CLA group. Even though there may not be QA specific resources restricted by groups, it is still nice for QA contributors to have access to generic resources normally available to active Fedora contributors. I am very new to linux and Fedora community in general but, as I understand it, I like this idea of QA group very much Just another opinion, I guess. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
I'm still scratching my head over the other applications not saving/restoring correctly, but xfce4-terminal at least is fixed in an update I just pushed. Testing and karma welcome: https://admin.fedoraproject.org/updates/xfce4-terminal-0.6.2-3.fc19 https://admin.fedoraproject.org/updates/xfce4-terminal-0.6.2-3.fc20 kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On mán 16.des 2013 22:12, Adam Williamson wrote: What, in your estimation, would be the right place? Instead of just saying 'no', can you provide an alternative solution to the problem? Solution to fix this lies not within in us ( QA ) the alternative solution requires a real change in the project not dressing the emperor in new clothes which the WG proposal does. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On mán 16.des 2013 22:22, Adam Williamson wrote: If you mean "Then limit that group entirely with providing him and others with that." - well, that's already what we'd be doing. The proposal isn't to make the QA group required for anything at all in relation to QA. The proposal is just to add all the QA people we can to the group, and in the future, when new people join, add them too. And make it inherit fedorabugs (or make fedorabugs inherit it, whichever way around it goes) so QA people get editbugs privileges. And then...nothing. That's it. We don't actually use the group for anything in QA, or anything. That's not what I'm suggesting. I thought you meant to ( or worried that it gradually will ) revoke it to it's previous status but why dont you just add everybody to the fedorabugs group and keep this one dead and buried? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 22:16 +, "Jóhann B. Guðmundsson" wrote: > On mán 16.des 2013 22:10, Adam Williamson wrote: > > I'm not playing any game...in fact, the thing that prompted me to > > finally write this email was Dan asking on #fedora-qa if there was a FAS > > group we could put him in so he'd have fedorapeople space! > > The limit that group entirely with providing him and others with that. Sorry? I can't parse that. If you mean "Then limit that group entirely with providing him and others with that." - well, that's already what we'd be doing. The proposal isn't to make the QA group required for anything at all in relation to QA. The proposal is just to add all the QA people we can to the group, and in the future, when new people join, add them too. And make it inherit fedorabugs (or make fedorabugs inherit it, whichever way around it goes) so QA people get editbugs privileges. And then...nothing. That's it. We don't actually use the group for anything in QA, or anything. That's not what I'm suggesting. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On mán 16.des 2013 22:10, Adam Williamson wrote: I'm not playing any game...in fact, the thing that prompted me to finally write this email was Dan asking on #fedora-qa if there was a FAS group we could put him in so he'd have fedorapeople space! The limit that group entirely with providing him and others with that. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On mán 16.des 2013 22:08, Bruno Wolff III wrote: On Mon, Dec 16, 2013 at 22:06:44 +, "\"Jóhann B. Guðmundsson\"" wrote: Adam is right about what's wrong but as so often he's trying to fix it in the wrong place... Access to those reources are controlled by group membership. So we either add people to a group or get the people responsible for the resources to drop the requirement on group access. I think the former makes more sense than the latter in this case. Still approaching and trying to solve the underlying cause the wrong way... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 22:06 +, "Jóhann B. Guðmundsson" wrote: > On mán 16.des 2013 21:45, Mike Ruckman wrote: > > For those of us who haven't been with QA for even a year yet, can you > > give a brief "too long; didn't read" synopsis of your reasoning and > > where it stems from? Without some form of background it's hard to infer > > what your reasoning is. > > You can look at the archive why we initially dropped the QA group and Do you have specific links for that? "the archive" is several years big, it's probably easier to find if you were there at the time and remember the approximate date or the thread title or something. > the reasoning why we should not revive the QA group is related to the > future and I ain't talking about the future WG's "providing" us with but > an actual future and direction for the project be heading into. > > Adam is right about what's wrong but as so often he's trying to fix it > in the wrong place... What, in your estimation, would be the right place? Instead of just saying 'no', can you provide an alternative solution to the problem? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Dec 16, 2013, at 3:06 PM, "Jóhann B. Guðmundsson" wrote: > > On mán 16.des 2013 21:45, Mike Ruckman wrote: >> For those of us who haven't been with QA for even a year yet, can you >> give a brief "too long; didn't read" synopsis of your reasoning and >> where it stems from? Without some form of background it's hard to infer >> what your reasoning is. > > You can look at the archive why we initially dropped the QA group and the > reasoning why we should not revive the QA group is related to the future and > I ain't talking about the future WG's "providing" us with but an actual > future and direction for the project be heading into. > > Adam is right about what's wrong but as so often he's trying to fix it in the > wrong place… Seems to me it'll either be sorta useful, or it'll be completely utterly useless yet still benign. *shrug* Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 21:57 +, "Jóhann B. Guðmundsson" wrote: > On mán 16.des 2013 21:48, Dan Mossor wrote: > > I may be misinterpreting, but what do you have against volunteers? > > Especially since Fedora is a volunteer-driven project? > > Dont fall into whatever game Adam is playing by reviving this group. I'm not playing any game...in fact, the thing that prompted me to finally write this email was Dan asking on #fedora-qa if there was a FAS group we could put him in so he'd have fedorapeople space! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, Dec 16, 2013 at 22:06:44 +, "\"Jóhann B. Guðmundsson\"" wrote: Adam is right about what's wrong but as so often he's trying to fix it in the wrong place... Access to those reources are controlled by group membership. So we either add people to a group or get the people responsible for the resources to drop the requirement on group access. I think the former makes more sense than the latter in this case. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On mán 16.des 2013 21:45, Mike Ruckman wrote: For those of us who haven't been with QA for even a year yet, can you give a brief "too long; didn't read" synopsis of your reasoning and where it stems from? Without some form of background it's hard to infer what your reasoning is. You can look at the archive why we initially dropped the QA group and the reasoning why we should not revive the QA group is related to the future and I ain't talking about the future WG's "providing" us with but an actual future and direction for the project be heading into. Adam is right about what's wrong but as so often he's trying to fix it in the wrong place... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, Dec 16, 2013 at 21:57:41 +, "\"Jóhann B. Guðmundsson\"" wrote: On mán 16.des 2013 21:48, Dan Mossor wrote: I may be misinterpreting, but what do you have against volunteers? Especially since Fedora is a volunteer-driven project? Dont fall into whatever game Adam is playing by reviving this group. The game is to treat QA volunteers like other contributors. That way they don't have to also become packagers (or something else) in order to participate in Fedora Elections or make use of resources limited to people who are in more than just the Fedora CLA group. Even though there may not be QA specific resources restricted by groups, it is still nice for QA contributors to have access to generic resources normally available to active Fedora contributors. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F20: System doesn't resume correctly from suspend any more
On Dec 16, 2013, at 2:50 PM, Adam Williamson wrote: > On Mon, 2013-12-16 at 14:09 -0700, Chris Murphy wrote: >> On Dec 16, 2013, at 1:47 PM, nonamedotc wrote: >> >>> On 12/11/2013 06:57 PM, Chris Murphy wrote: On Dec 11, 2013, at 5:41 PM, Ankur Sinha wrote: > On Wed, 2013-12-11 at 17:25 -0600, nonamedotc wrote: >> >> Is anyone still seeing this? Just curious as I have also been seeing >> this ... > > I am. I can't reproduce it reliably though. It happens randomly here. Maybe need to go to more aggressive kernel parameters to get more information. debug loglevel=7 udev_log="debug" Chris Murphy >>> >>> I might be **misunderstanding** - but with the kernel-3.12.5-301, the >>> suspend issue seems to be gone (in my tests - 3 repetitions). >>> >>> Suspend *seems to work* without issues - Is this the case across the board >>> or is this a one off occurance. >> >> >> I'm not sure. On 3.13.rc2 my laptop does suspend with pulsing power button >> as expected. On resume, I have a black screen and I can't ssh into it. So >> it's dead. When I reboot the logs show that it suspended OK and nothing but >> the reboot after that. So I have no information. This is with systemd >> debugging enabled. > > I'm consistently getting the case where I can see the bootsplash but > Shell is running and "alt-f2, r" recovers, FWIW. I use nomodeset/basic graphics, so it's possible there's an issue with it and not nouveau. But I'd still expect ssh to work if services are actually up and running. Is this a use case for netconsole? Or is there something better/more recent? Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On mán 16.des 2013 21:48, Dan Mossor wrote: I may be misinterpreting, but what do you have against volunteers? Especially since Fedora is a volunteer-driven project? Dont fall into whatever game Adam is playing by reviving this group. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F20: System doesn't resume correctly from suspend any more
On Mon, 2013-12-16 at 14:09 -0700, Chris Murphy wrote: > On Dec 16, 2013, at 1:47 PM, nonamedotc wrote: > > > On 12/11/2013 06:57 PM, Chris Murphy wrote: > >> > >> On Dec 11, 2013, at 5:41 PM, Ankur Sinha wrote: > >> > >>> On Wed, 2013-12-11 at 17:25 -0600, nonamedotc wrote: > > Is anyone still seeing this? Just curious as I have also been seeing > this ... > >>> > >>> I am. I can't reproduce it reliably though. It happens randomly here. > >> > >> Maybe need to go to more aggressive kernel parameters to get more > >> information. > >> > >> debug loglevel=7 udev_log="debug" > >> > >> Chris Murphy > >> > > > > I might be **misunderstanding** - but with the kernel-3.12.5-301, the > > suspend issue seems to be gone (in my tests - 3 repetitions). > > > > Suspend *seems to work* without issues - Is this the case across the board > > or is this a one off occurance. > > > I'm not sure. On 3.13.rc2 my laptop does suspend with pulsing power button as > expected. On resume, I have a black screen and I can't ssh into it. So it's > dead. When I reboot the logs show that it suspended OK and nothing but the > reboot after that. So I have no information. This is with systemd debugging > enabled. I'm consistently getting the case where I can see the bootsplash but Shell is running and "alt-f2, r" recovers, FWIW. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On 12/16/2013 03:35 PM, "Jóhann B. Guðmundsson" wrote: > > On mán 16.des 2013 21:00, Adam Williamson wrote: >> Even though we don't really have a lot of use for the FAS group, > > None what so ever. > >> Fedora >> as a whole is set up such that 'being a member of a FAS group' is a bar >> to entry for some things, > > Not with us and never should be. > >> so it seems like we're putting ourselves at a >> disadvantage by not putting our members in our FAS group. > > No we are not and we are putting ourselves in advantage by not doing so. > > JBG I may be misinterpreting, but what do you have against volunteers? Especially since Fedora is a volunteer-driven project? -- Dan Mossor Systems Engineer at Large Fedora QA Team Volunteer FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 16 Dec 2013 21:35:56 + "Jóhann B. Guðmundsson" wrote: > > On mán 16.des 2013 21:00, Adam Williamson wrote: > > Even though we don't really have a lot of use for the FAS group, > > None what so ever. > > > Fedora > > as a whole is set up such that 'being a member of a FAS group' is a > > bar to entry for some things, > > Not with us and never should be. > > > so it seems like we're putting ourselves at a > > disadvantage by not putting our members in our FAS group. > > No we are not and we are putting ourselves in advantage by not doing > so. > > JBG For those of us who haven't been with QA for even a year yet, can you give a brief "too long; didn't read" synopsis of your reasoning and where it stems from? Without some form of background it's hard to infer what your reasoning is. Thanks! // Roshi signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 21:35 +, "Jóhann B. Guðmundsson" wrote: > On mán 16.des 2013 21:00, Adam Williamson wrote: > > Even though we don't really have a lot of use for the FAS group, > > None what so ever. Actually, there is one, I forgot to mention it: we can have 'qa' inherit 'fedorabugs', which would give all QA members 'editbugs' privileges. > > Fedora > > as a whole is set up such that 'being a member of a FAS group' is a bar > > to entry for some things, > > Not with us and never should be. We're part of Fedora, not some kind of independent entity. Having fedorapeople space is a useful thing for QA members. Being able to vote in elections is a useful thing for QA members. Currently, you have to find some other way to get yourself added to a group in order to get those things, which means you have to apply to some other group or find someone with moderator privileges for a group and persuade them to add you, just so you can 'game the system'. Why is it a bad thing if we just put QA people in the QA group so they can have access to those things? > > so it seems like we're putting ourselves at a > > disadvantage by not putting our members in our FAS group. > > No we are not and we are putting ourselves in advantage by not doing so. Could you please explain what advantage we're giving ourselves by not putting people in a FAS group? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On mán 16.des 2013 21:00, Adam Williamson wrote: Even though we don't really have a lot of use for the FAS group, None what so ever. Fedora as a whole is set up such that 'being a member of a FAS group' is a bar to entry for some things, Not with us and never should be. so it seems like we're putting ourselves at a disadvantage by not putting our members in our FAS group. No we are not and we are putting ourselves in advantage by not doing so. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 16 Dec 2013 12:23:32 -0800 Adam Williamson wrote: > So I'm proposing we do something simple: let's just go ahead and stick > everyone who can reasonably be considered a 'QA team member' in the > FAS 'qa' group. This wouldn't be hard to do, I can make sure > sufficient people within and outside RH have moderator status in the > qa group, and then those of us who are mods can just add people > appropriately. Anyone who files karma regularly, or validation test > results, or posts to test@, or attends QA team meetings, anything > like that - let's just stick 'em in QA group, and then for the future > we can just say 'moderators can give anyone who's obviously a QA > person membership in the QA group at any time, and when someone sends > a self-introduction mail and doesn't completely disappear, the QA > group mods should stick that person in the group'. I think this makes sense for getting people FedoraPeople space. As long as there is a decent spread of admins so people can get added when they need, and we prune the list as it needs pruned - then I think this makes sense. // Roshi signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F20: System doesn't resume correctly from suspend any more
On 12/16/2013 03:09 PM, Chris Murphy wrote: On Dec 16, 2013, at 1:47 PM, nonamedotc wrote: I might be **misunderstanding** - but with the kernel-3.12.5-301, the suspend issue seems to be gone (in my tests - 3 repetitions). Suspend *seems to work* without issues - Is this the case across the board or is this a one off occurance. I'm not sure. On 3.13.rc2 my laptop does suspend with pulsing power button as expected. On resume, I have a black screen and I can't ssh into it. So it's dead. When I reboot the logs show that it suspended OK and nothing but the reboot after that. So I have no information. This is with systemd debugging enabled. Chris Murphy Thanks. Let me keep looking at this more carefully to understand what is going on. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F20: System doesn't resume correctly from suspend any more
On Dec 16, 2013, at 1:47 PM, nonamedotc wrote: > On 12/11/2013 06:57 PM, Chris Murphy wrote: >> >> On Dec 11, 2013, at 5:41 PM, Ankur Sinha wrote: >> >>> On Wed, 2013-12-11 at 17:25 -0600, nonamedotc wrote: Is anyone still seeing this? Just curious as I have also been seeing this ... >>> >>> I am. I can't reproduce it reliably though. It happens randomly here. >> >> Maybe need to go to more aggressive kernel parameters to get more >> information. >> >> debug loglevel=7 udev_log="debug" >> >> Chris Murphy >> > > I might be **misunderstanding** - but with the kernel-3.12.5-301, the suspend > issue seems to be gone (in my tests - 3 repetitions). > > Suspend *seems to work* without issues - Is this the case across the board or > is this a one off occurance. I'm not sure. On 3.13.rc2 my laptop does suspend with pulsing power button as expected. On resume, I have a black screen and I can't ssh into it. So it's dead. When I reboot the logs show that it suspended OK and nothing but the reboot after that. So I have no information. This is with systemd debugging enabled. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 20:40 +, "Jóhann B. Guðmundsson" wrote: > On mán 16.des 2013 20:23, Adam Williamson wrote: > > > > How does that sound? Seems like something we can just get done already. > > > > It sounds like a bad plan revoke the QA group previously occupied and > manage by RH staff only and I'm strongly against that. > > So why are you planning to revert what we already had decide we did not > need. > > What's your end game with this move? "Let QA people have fedorapeople.org space", basically. danofsatx is the latest, but there've been three or four people recently who started contributing to QA and then found they wanted one of the things in Fedora you can get by being a member of a FAS group. Even though we don't really have a lot of use for the FAS group, Fedora as a whole is set up such that 'being a member of a FAS group' is a bar to entry for some things, so it seems like we're putting ourselves at a disadvantage by not putting our members in our FAS group. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On mán 16.des 2013 20:32, Adam Williamson wrote: On Mon, 2013-12-16 at 12:23 -0800, Adam Williamson wrote: >Right now me, James Laska, Will Woods and Jesse Keating are the admins >of the QA group. This is obviously a bit silly. I'll drop jlaska's, >wwoods' and jesses' admin roles, and make some more appropriate people >admins and moderators instead. I'll do that right now, since it's >clearly the right thing to do... For now I've made me, tflink, kparal and viking-ice administrators and cmurf a moderator, just as raptor-proofing. Which is entirely irrelevant since this group should not be revived so stop with this nonsense already. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F20: System doesn't resume correctly from suspend any more
On 12/11/2013 06:57 PM, Chris Murphy wrote: On Dec 11, 2013, at 5:41 PM, Ankur Sinha wrote: On Wed, 2013-12-11 at 17:25 -0600, nonamedotc wrote: Is anyone still seeing this? Just curious as I have also been seeing this ... I am. I can't reproduce it reliably though. It happens randomly here. Maybe need to go to more aggressive kernel parameters to get more information. debug loglevel=7 udev_log="debug" Chris Murphy I might be **misunderstanding** - but with the kernel-3.12.5-301, the suspend issue seems to be gone (in my tests - 3 repetitions). Suspend *seems to work* without issues - Is this the case across the board or is this a one off occurance. Best wishes. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On mán 16.des 2013 20:23, Adam Williamson wrote: How does that sound? Seems like something we can just get done already. It sounds like a bad plan revoke the QA group previously occupied and manage by RH staff only and I'm strongly against that. So why are you planning to revert what we already had decide we did not need. What's your end game with this move? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 12:23 -0800, Adam Williamson wrote: > Right now me, James Laska, Will Woods and Jesse Keating are the admins > of the QA group. This is obviously a bit silly. I'll drop jlaska's, > wwoods' and jesses' admin roles, and make some more appropriate people > admins and moderators instead. I'll do that right now, since it's > clearly the right thing to do... For now I've made me, tflink, kparal and viking-ice administrators and cmurf a moderator, just as raptor-proofing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Proposal: let's just use the FAS group already
Hi, folks. So this one keeps popping up for individual people, and we keep doing a quick band-aid when anyone needs group membership...but we may as well just bite the bullet and do it properly. Fedora QA has always been pretty informally organized, we've generally not wanted to build a big heavy organizational structure with hierarchies and bits of paper to sign and stuff. One facet of this is that we don't really have an 'official' Fedora QA FAS group. There is a 'qa' group in FAS, but it has very few members, and we haven't ever worked on the assumption that the people in it are the 'real' QA people or anything. For our purposes we don't really have any incredible need for a QA group in FAS, but there are some things in Fedora which require you to be a member of a FAS group besides cla_signed - voting in some elections, for instance, and getting a fedorapeople.org space. It seems unfortunate that QA contributors don't get these things unless they get themselves added to another group. So I'm proposing we do something simple: let's just go ahead and stick everyone who can reasonably be considered a 'QA team member' in the FAS 'qa' group. This wouldn't be hard to do, I can make sure sufficient people within and outside RH have moderator status in the qa group, and then those of us who are mods can just add people appropriately. Anyone who files karma regularly, or validation test results, or posts to test@, or attends QA team meetings, anything like that - let's just stick 'em in QA group, and then for the future we can just say 'moderators can give anyone who's obviously a QA person membership in the QA group at any time, and when someone sends a self-introduction mail and doesn't completely disappear, the QA group mods should stick that person in the group'. How does that sound? Seems like something we can just get done already. Right now me, James Laska, Will Woods and Jesse Keating are the admins of the QA group. This is obviously a bit silly. I'll drop jlaska's, wwoods' and jesses' admin roles, and make some more appropriate people admins and moderators instead. I'll do that right now, since it's clearly the right thing to do... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Introduction to QA - or, howto become a tester
On Mon, 2013-12-16 at 11:42 -0600, Dan Mossor wrote: > I submitted myself for torture as a QA tester just last month, as I have > years of experience in both Linux and testing (for reference, do some > research on the USAF 346th Testing Squadron). > > I jumped in with a lot of enthusiasm for the project, after having > carefully evaluated all (most) of the major distros and their > philosophies. I dislike Debian architecture in general, and abhor > Canonical, so that branch never had a chance. Arch is, well, Arch. > openSUSE is almost as restrictive as *buntu. Red Hat more or less made > Linux the product it is today, and most of my "real-world" experience > was with RHEL or CentOS systems anyhow. > > ButI jumped into a very deep pool, barely knowing how to tread these > waters, and with a very short rope at > https://fedoraproject.org/wiki/QA/Join - that page, unless you already > understand the Fedora/RH hierarchy, is confusing at best. It doesn't > really give a whole lot of info for the newbies like myself that, > although new to the project, know what we're doing and want to help. I'm sorry you feel that way! If it's any consolation, I actually think you've been doing great so far, so you had me fooled ;) From the outside it looks like you have things pretty much figured out already. (If you're worried that you missed something with all the fedora.next stuff...you really are not alone. No-one seems to be sure where that's going. At least, I'm not.) > In the KDE criterion revision thread, Mr. Ryniker proposed something > that I thought had some good ideas ( > https://lists.fedoraproject.org/pipermail/test/2013-December/119494.html > ). His "proposal" involved setting up a test organizational structure, > complete with test directors and test managers. This was soundly shot > down, and for good reason (structure doesn't fit into the F/OSS vision). Y'know, me saying I don't like something isn't the same as it being 'roundly shot down' =) I'm just one monkey with an opinion. If everyone else thought the idea was great, we should do it. > However, there are some points he made that I think are great ideas - > one of which was the "test mentor", someone to lead a new recruit > through the steps of becoming a Fedora tester. Since we're clamoring > about the size of the workload for QA, and needing more people on the > team, why don't we try to make it easier for people to join the team? I think mentoring is a great system, and we've tried to use it in a few efforts before. Bugzappers tried to use it when that project was at its most active, and proven testers tried to use it when that project was active too. Now I'm not going to draw any conclusions from the fact that all the projects where we try to use mentoring seem to die, but...;) Nah, seriously. It sounds like a good idea to me and I certainly don't think we'd lose anything if we did try to do more active mentoring, rather than the 'just say hi then ask questions if you're unsure about anything!' approach. It is a pretty time-intensive thing, but if existing experienced QA folks are willing to commit to it, I'm sure it could help us bring new people on board. > I'm sticking with this because I am, as my wife would say, stubborn. But > how many have thought that they would like to help, then see the wiki > pages and change their mind because there's not enough info there? I'm > willing to take on the work of fixing it, but I need to learn it myself, > first. This is where I'm at right now - I'm still learning, and by > bugging the usual suspects in #fedora-qa, I'm slowly but surely getting > there. I really hope that's not happening, and if it is we should certainly fix it. It does make me sad to know that the existing documentation wasn't sufficient to give you confidence that you were doing the right thing, though like I said, so far at least to me you seem to be doing great - you were a huge help in getting that KDE blocker bug fixed, for instance. I did quite a bit of work on the current front page and Join pages back when I first joined RH, but in the last few years haven't really sat down to see if they can be brought up to date, improved, expanded etc. That's certainly something we could look at doing in the down time before all this F21 stuff gets sorted out, though - is it possible for you to say in greater detail what some of the things you feel need to be explained better are? > I feel the first thing that needs "improved" is either the base QA wiki > page, or the Join QA page. I'll plug away at it, but I would really > appreciate any help from the more "senior" members of the QA team. As I said, I've worked on those pages before and would certainly be interested in helping out if you want to take a look and see if we can make them better again! Thanks for all your efforts so far. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
RC1.1 at Caddyshack
Last evening I performed a fresh net install on omen.com. The machine uses an i5-3550 CPU @ 3.30GHz with 32GB RAM. For the installation I chose Xfce desktop, no Gnome or KDE. I was able to install the stuff I use without a groupinstall. The machine uses the on chip Intel display. Switching between X and console terminals and back works as expected without Noveau. So far the obvious anomaly observed is the disruption of some desktop icons. I cannot find the proper icon for the Xfce4 app-finder. -- 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
Introduction to QA - or, howto become a tester
I submitted myself for torture as a QA tester just last month, as I have years of experience in both Linux and testing (for reference, do some research on the USAF 346th Testing Squadron). I jumped in with a lot of enthusiasm for the project, after having carefully evaluated all (most) of the major distros and their philosophies. I dislike Debian architecture in general, and abhor Canonical, so that branch never had a chance. Arch is, well, Arch. openSUSE is almost as restrictive as *buntu. Red Hat more or less made Linux the product it is today, and most of my "real-world" experience was with RHEL or CentOS systems anyhow. ButI jumped into a very deep pool, barely knowing how to tread these waters, and with a very short rope at https://fedoraproject.org/wiki/QA/Join - that page, unless you already understand the Fedora/RH hierarchy, is confusing at best. It doesn't really give a whole lot of info for the newbies like myself that, although new to the project, know what we're doing and want to help. In the KDE criterion revision thread, Mr. Ryniker proposed something that I thought had some good ideas ( https://lists.fedoraproject.org/pipermail/test/2013-December/119494.html ). His "proposal" involved setting up a test organizational structure, complete with test directors and test managers. This was soundly shot down, and for good reason (structure doesn't fit into the F/OSS vision). However, there are some points he made that I think are great ideas - one of which was the "test mentor", someone to lead a new recruit through the steps of becoming a Fedora tester. Since we're clamoring about the size of the workload for QA, and needing more people on the team, why don't we try to make it easier for people to join the team? I'm sticking with this because I am, as my wife would say, stubborn. But how many have thought that they would like to help, then see the wiki pages and change their mind because there's not enough info there? I'm willing to take on the work of fixing it, but I need to learn it myself, first. This is where I'm at right now - I'm still learning, and by bugging the usual suspects in #fedora-qa, I'm slowly but surely getting there. I feel the first thing that needs "improved" is either the base QA wiki page, or the Join QA page. I'll plug away at it, but I would really appreciate any help from the more "senior" members of the QA team. -- Dan Mossor Systems Engineer at Large Fedora QA Team Volunteer FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20131216 changes
Compose started at Mon Dec 16 05:15:06 UTC 2013 Broken deps for i386 -- [LuxRender] LuxRender-1.0-16.fc21.i686 requires libImath-2_0.so.10 LuxRender-1.0-16.fc21.i686 requires libIlmThread-2_0.so.10 LuxRender-1.0-16.fc21.i686 requires libIlmImf-Imf_2_0.so.20 LuxRender-1.0-16.fc21.i686 requires libIex-2_0.so.10 LuxRender-1.0-16.fc21.i686 requires libHalf.so.10 LuxRender-core-1.0-16.fc21.i686 requires libImath-2_0.so.10 LuxRender-core-1.0-16.fc21.i686 requires libIlmThread-2_0.so.10 LuxRender-core-1.0-16.fc21.i686 requires libIlmImf-Imf_2_0.so.20 LuxRender-core-1.0-16.fc21.i686 requires libIex-2_0.so.10 LuxRender-core-1.0-16.fc21.i686 requires libHalf.so.10 LuxRender-lib-1.0-16.fc21.i686 requires libImath-2_0.so.10 LuxRender-lib-1.0-16.fc21.i686 requires libIlmThread-2_0.so.10 LuxRender-lib-1.0-16.fc21.i686 requires libIlmImf-Imf_2_0.so.20 LuxRender-lib-1.0-16.fc21.i686 requires libIex-2_0.so.10 LuxRender-lib-1.0-16.fc21.i686 requires libHalf.so.10 [OpenEXR_CTL] OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIexMath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIex.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libHalf.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIex.so.6 [OpenEXR_Viewers] OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libImath-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmThread-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmImf-Imf_2_0.so.20 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIexMath-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIex-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libHalf.so.10 [calligra] calligra-krita-2.7.90-1.fc21.i686 requires libkritasketchlib.so [converseen] converseen-0.6.2-2.fc20.i686 requires libMagick++-6.Q16.so.1 [derelict] derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod [dmapd] dmapd-0.0.55-5.fc21.i686 requires libImath-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libIlmThread-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libIlmImf-Imf_2_0.so.20 dmapd-0.0.55-5.fc21.i686 requires libIexMath-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libIex-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libHalf.so.10 [dragonegg] dragonegg-3.3-11.fc21.i686 requires gcc = 0:4.8.2-1.fc21 [drawtiming] drawtiming-0.7.1-11.fc20.i686 requires libMagick++-6.Q16.so.1 [enblend] enblend-4.1.2-3.fc21.i686 requires libvigraimpex.so.4 [evolution-rss] 1:evolution-rss-0.3.94-2.fc21.i686 requires libcamel-1.2.so.46 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-16.fc21.i686 requires gcc = 0:4.8.2-4.fc21 gcc-python2-plugin-0.12-16.fc21.i686 requires gcc = 0:4.8.2-4.fc21 gcc-python3-debug-plugin-0.12-16.fc21.i686 requires gcc = 0:4.8.2-4.fc21 gcc-python3-plugin-0.12-16.fc21.i686 requires gcc = 0:4.8.2-4.fc21 [gpsdrive] gpsdrive-2.11-20.fc20.i686 requires libgps.so.20 [gtkd] gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60 [httpdtap] httpdtap-0.2-2.fc21.noarch requires kernel-debuginfo httpdtap-0.2-2.fc21.noarch requires httpd-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-util-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-debuginfo [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [kmymoney] kmymoney-4.6.4-1.fc21.i686 requires libcalligrakdchart.so.12 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [licq] licq-1.8.1-1.fc21.i686 requires libgloox.so.8 [mpqc] mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3 mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3 [netdisco] netdisco-1.1-6.fc20.noarch requires perl(SNMP::Info::Layer2::Bay) [nifti2dicom] nifti2dicom-0.4.6-3.fc20.i686 requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkTextAn
Re: Proposed validation test case: root on LVM thinp
On 12/14/2013 01:49 AM, Adam Williamson wrote: > On Fri, 2013-12-13 at 15:49 -0700, Chris Murphy wrote: >> On Dec 13, 2013, at 3:13 PM, Adam Williamson wrote: >> >>> I meant to write this test case anyhow, but today's brown paper bag bug >>> - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1040669 - gives >>> it a certain sense of importance, so I thought I'd best get it done now. >>> >>> I wrote >>> https://fedoraproject.org/wiki/QA:Testcase_anaconda_lvmthinp_rootfs , >>> and I propose we add it to the installation validation matrix for F21 >>> and later, with release level Beta, as it matches this criterion: >>> >>> https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Guided_partitioning >>> >>> "When using the guided partitioning flow, the installer must be able >>> to: ... Complete an installation using any combination of disk >>> configuration options it allows the user to select" >>> >>> LVM thinp is now one of the options on the 'filesystem type' dropdown on >>> the Installation Options screen, which is what 'disk configuration >>> options' in that criterion is talking about. >>> >>> Anyone have feedback on the test case, or the proposed inclusion in the >>> matrices? I based the test case on the ext4 rootfs one but tidied it up >>> somewhat, and placed stronger restrictions on changing other >>> configuration during the test; I will probably go through all the >>> filesystem-y test cases and propose similar changes, if we think that's >>> a good idea. We should try to make the whole set consistent. >> >> Yeah I'm holding off on a major f bomb email until I understand what >> happened and exactly when this broke. If you have some insight on that >> to save me regression testing, that would be helpful. > > Already looked into it. it was broken by > dracut-034-64.git20131205.fc20.x86_64 , which landed in either TC5 or > RC1, I don't recall which, but either way, very late. We needed it to > fix https://bugzilla.redhat.com/show_bug.cgi?id=881624 and > https://bugzilla.redhat.com/show_bug.cgi?id=1038838 . However, dracut > team pulled their usual trick of sending us a new git snapshot with a > bunch of other unrelated changes. I told them on IRC that we weren't > happy about that but they really wanted the other changes and promised > they were all safe. I sat down with them and eyeballed the list of > changes in the RPM changelog and Bodhi ticket, and made sure none of > them looked like they affected real sensitive areas. > > It turns out, though, that the new git snapshot also included at least > one other change which was not communicated in the package changelog or > to me while we were talking about it, and that change was very badly > broken - it contains at least two errors and one major logic fail in > seven lines of shell script, which is kind of impressive, in an odd way. > It tried to make 'hostonly' dracut builds only install the thinp tools > if a thinp was actually present on the system...but the check did not > work, so it just wound up never installing them. And it neglected to set > up the conditional so that 'generic' builds always included the tools, > instead they *never* get the tools. > > Ultimately, the effect of the patch was that no initramfs dracut > generated could possibly have the thinp tools in it. If they'd only > managed to break _either_ hostonly _or_ generic mode then installs would > at least have _one_ kernel which would boot, but since they managed to > break both modes with one patch, neither kernel you have after a fresh > install works. > > The change was utterly unnecessary and should never have been sent near > a release in a final freeze in the first place, and on top of that, it > appears to have been committed to upstream git on the _same day_ they > sent the build downstream for F20 final, 12-05: > > https://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=c21c4dc2b469107ac35d8c1157f245965fd55292 > > so it seems very likely it had no upstream review or testing at the time > it was sent down to Fedora. Needless to say, I'm not exactly happy with > this, especially since one of the blocker bugs we pulled the new dracut > to fix in the _first_ place - > https://bugzilla.redhat.com/show_bug.cgi?id=881624 - was caused by a > very similar logic error in upstream dracut. > > I'd suggest to the dracut developers that they strengthen their > development practices and checks. Right now they seem to be developing > with the mindset "things should only be in the initramfs if we're > absolutely sure they should be": they should precisely reverse that > mindset, and make it "we should only include code that introduces the > possibility that something will be left out of an initramfs if we are > VERY sure that code is correct, and every single change of this kind > should be specifically vetted to ensure that generic builds are not > being incorrectly conditionalized or broken." > Yes. Brown paper bag for me :-( Will add a LVM thin test case
