gnome-shell high cpu consumption during install?
Is anyone else seeing 100% CPU consumption in top for gnome-shell for the entire installation process? This seems excessive for something that isn't doing anything, or being interacted with. https://dl.dropbox.com/u/3253801/Screen%20Shot%202012-10-24%20at%2010.48.58%20PM.png Does it make sense to use strace to find out what gnome-shell is doing and file a bug on this sort of behavior? And if so what strace options would I use? Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On Wed, 2012-10-24 at 20:10 -0600, Vincent Danen wrote: > >What's your opinion on "moderate bugs that can't be fixed by > >updates" (i.e. persistent flaws) as a Final blocker? Is that going too > >far? > > I don't think that's going too far, but again it should be evaluated on > a case-by-case basis. Some moderates are more serious than others. We > often fix moderate flaws in errata, but there are plenty that we defer. > They are, by classification, moderate but just aren't worth the effort > to do a fix for it "right now". I think the same could be done here. > Important+: no question. Moderate: maybe it needs to get some acks > before it is considered a blocker? What we're trying to do with the criteria is reduce the occurrence of 'case-by-case evaluation' as much as we can. It's inevitably the case that we can't entirely eliminate it, but we want to make things as objective as we can. > For instance, a moderate flaw that only would affect a small subset of > users probably shouldn't be a release blocker if it's found a week > before GA. One that affects 90% of users probably should. > > Again, I don't know the process here, but maybe it would make sense to > have moderate flaws block the alpha (and maybe the beta?) but not later. > This gives you an out -- two weeks to release and someone finds a > moderate flaw, you don't have to necessarily delay the release. But if > it's found a month before GA and can be fixed prior to the alpha > release, maybe that should be considered just so that it gets done. (My > fear otherwise is that if you have critical-only as blocking alpha, you > _have_ to leave it to a later stage that might be more inconvenient). Ah, the old RHEL attitude again ;) Funny how things come in twos. This seems to be a RHEL strategy - throw everything but the kitchen sink on the 'blocker' list early in the process, and get tighter closer to release. That's not how we do things in Fedora, we do things the other way around, really. Note that in Fedora the blocker list is not a todo list or a 'let's not forget about these bugs' list. It is a _list of bugs that block the release_. That's all it is. No bug is ever intended to be on the list of blockers for a given release unless it's really and truly blocking that release. We don't use the blocker list for 'just so that it gets done' purposes. We decided a few years back that that way of doing things kind of sucked, and designed a more rigorous way of doing things :) If you think it wouldn't realistic to say 'we'll take any persistent moderate flaw as a blocker' that's valuable feedback...then the question becomes do we only bother about important+ bugs, do we try and come up with some kind of solid definition for what 'moderate' bugs we'll consider blockers and which ones we won't, or do we just say 'we'll evaluate 'moderate' bugs on a case-by-case basis'. > >Yeah, that would be too ambitious. The other difference in Fedora is we > >don't consider 0-day updates part of a release. We ship a bunch of > >0-days, but they're just not considered in the 'release process', except > >in very special circumstances. Blocker bugs have to be fixed *in the > >release package set* (what gets frozen). > > That makes sense. I didn't think that Fedora had "0-day errata" like we > do with RHEL releases. They just get pumped out on or after release > date, regardless of security-relevance (at least that's what it seems to > me, but as far as Fedora is concerned, I'm just an end-user). The way you say it it does sound like there's a difference, because for Fedora, a 0-day update is just any update that happens to have been pushed stable by the official release date. There's no special handling of such updates, they just happen. What actually happens is that we lift freeze after the go/no-go meeting but before release; any update that accumulates sufficient karma and gets pushed 'stable' in the period between the freeze being lifted and the release going out becomes a 0-day update, i.e., it's available on release day. There's no special shepherding of such updates, usually. > Absolutely. I didn't mean to imply you shouldn't make it a policy > because it's more often than not a non-issue. Rather, I meant it should > be easy enough to get into place as a policy because it's been easily > achieved (so far), so can't really be seen as a major undertaking or > "too much to ask for" kind of thing. Yup, that's useful feedback indeed, and thanks. > Conversations for another day. > > I would be happy with this as a first start, honestly. A cornerstone to > start building a more comprehensive policy on is nothing to be taken > lightly. =) > > Thanks for bringing this up, Adam. Thanks a lot for the input! -- 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
Re: Criterion proposal: security
On Wed, 2012-10-24 at 19:38 -0600, Vincent Danen wrote: > So if you're looking at alpha's as having all criticals fixed, I think > you can say that is quite well understood and I don't think it's a > problem. > > Important-impact issues in beta and release is totally doable. It's the > lower-impact stuff I'd like to see resolved properly. For this thread I want to keep it to what goes in the release criteria, if we can. If we spread the discussion too wide we'll never get done. Note that, if I'm understanding your mail correct, what you call 'persistent flaws' is what I'm referring to when I talk about 'cannot be fully resolved by a package update' - we're talking about stuff in the install process or live boot or first boot, which we can't resolve just by shipping an update. That's why I made that distinction and gave those bugs, in general, more importance. What's your opinion on "moderate bugs that can't be fixed by updates" (i.e. persistent flaws) as a Final blocker? Is that going too far? Note the blocker process is pretty much orthogonal to priority/severity. A blocker issue for Fedora is a blocker. We don't ship the release without fixing it. It's a very simple binary state. It doesn't matter what priority/severity a blocker bug happens to get assigned, it must be fixed for the release to go out. > Our rule for RHEL is no known important+ security flaws. This may lead > to a bunch of 0-day errata to get things squared away at GA (if we find > out about something post-freeze, etc.). This is for "dot" releases, > like 6.2 or 6.3. For a new "dot-0" release the rules are different. > For those releases, we absolutely strive for no known security flaws of > _any_ impact. We don't want to release a product with known security > issues. > > How does that equate to Fedora? I don't know. Do we look at Fedora's > quick release cycle as a series of ".X" releases? Or are they all ".0" > releases? I'd love to see them as ".0" with no known security issues, > but I suspect that won't happen anytime soon. =) Yeah, that would be too ambitious. The other difference in Fedora is we don't consider 0-day updates part of a release. We ship a bunch of 0-days, but they're just not considered in the 'release process', except in very special circumstances. Blocker bugs have to be fixed *in the release package set* (what gets frozen). > To me, no known important+ flaws at a Fedora GA is a doable goal, and > I'm pretty sure that more often than not we achieve that without really > aiming for it. Making this into some sort of policy makes sure it's > followed, but I think the real benefactor to this policy would be > Anaconda. Really it's just about getting things into the policy. 'Achieving the goal without really aiming for it' is fine and all, but it's not bulletproof :) There've been a few cases where we've kinda wanted to take security bugs as blockers but simply haven't had a framework for it. We're very strict on the blocker process these days: we don't just throw the 'blocker' status around arbitrarily. There _has_ to be a justification for it in the criteria. > I'd like to see some kind of improved policy for dealing with security > bugs in Fedora in general, but I think that is a resource problem and > the fact that the Fedora Security Response Team really doesn't do > anything. Most of the duties that it would have, Red Hat Security > Response handles. The real "hole" in our process is we don't > followup/badger/whatever once these tracking bugs are filed. We tend to > fire and forget, which may be the wrong approach, but is really the only > one that works for us due to time/resource constraints. > > Perhaps the Fedora Security Response Team could be more formalized and > chase those things? Maybe that's a good first step to aim for? > > That might be outside the scope of what you're bringing up here, Adam. > Sorry if you feel like maybe you opened a can of worms. You just gave > me a soap-box I've been eyeing for a few years. =) Yes, I think we're somewhat out of scope here. If you want to start up that discussion then go for it, but I'd _really_ like to keep criterion proposal threads on track, because they're not talking shops. Criteria revisions are important actions in QA, this isn't just a trial balloon, the intent is to put something in place in a fairly short term here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On Wed, Oct 24, 2012 at 05:06:41PM -0700, Adam Williamson wrote: > What do folks think of this? Anyone want to tweak what severity issues +1 > we block for when, or think the approach is bad? Thanks! We might not > want to start at Alpha, on the basis that Alpha is supposed to be for > testing *only* and should never have sensitive data committed to it, for > instance: we could combine the proposed Alpha criterion into the Beta > one. "critical" is pretty serious on the Red Hat scale. I think the way you have it is reasonable. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Criterion proposal: security
So, IIRC, we've vaguely considered this before, but never really come up with a criterion proposal. But I think we need one or two, to explicitly allow security issues to be blockers. I *really* don't want to get into the business of defining what constitutes a security issue, and what the severity of various types of issue is, in the criteria. It's a complex and specialized area, and there are already authorities for doing this. I just had a look at the major ones - notably CVSS - and it's crazy complex and we're not likely to be doing those calculations ourselves, so I'm thinking it may be best to take advantage of the relatively simple Red Hat security classifications: https://access.redhat.com/security/updates/classification/ That would allow us to say something like this: Alpha: "The release must contain no known security issues of 'critical' impact according to the Red Hat severity classification scale" Beta: "The release must contain no known security issues of 'important' impact according to the Red Hat severity classification scale which cannot be fully resolved by a package update (e.g. issues during installation)" Final: "The release must contain no known security issues of 'important' impact according to the Red Hat severity classification scale, or issues of 'moderate' impact which cannot be fully resolved by a package update (e.g. issues during installation)" (remember that criteria are additive, the Alpha criterion would apply to Beta and Final) Something like that - the precise boundaries we could tweak, but I think the basic idea flies. We use the severities from the RH classification and we draw a line between issues that could be fixed with an update (most will fall in this category) and ones we can't fix with an update - like issues in anaconda. What do folks think of this? Anyone want to tweak what severity issues we block for when, or think the approach is bad? Thanks! We might not want to start at Alpha, on the basis that Alpha is supposed to be for testing *only* and should never have sensitive data committed to it, for instance: we could combine the proposed Alpha criterion into the Beta one. CCing vdanen (from the security team) for a security expert perspective. Vincent, your input would be appreciated, remember we can't set bars *too* high for Fedora due to the release cycle and available development resources - it'd be interesting to know what rules RHEL uses here, but we can't necessarily do the same for Fedora. -- 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
Fedora 17 updates-testing report
The following Fedora 17 Security updates need testing: Age URL 6 https://admin.fedoraproject.org/updates/FEDORA-2012-16442/drupal7-7.16-1.fc17 108 https://admin.fedoraproject.org/updates/FEDORA-2012-10391/bcfg2-1.2.3-1.fc17 6 https://admin.fedoraproject.org/updates/FEDORA-2012-16440/Django-1.4.2-1.fc17 5 https://admin.fedoraproject.org/updates/FEDORA-2012-16485/xlockmore-5.40-3.fc17 13 https://admin.fedoraproject.org/updates/FEDORA-2012-15874/drupal7-feeds-2.0-0.5.alpha6.fc17 2 https://admin.fedoraproject.org/updates/FEDORA-2012-16614/dokuwiki-0-0.14.20121013.fc17 31 https://admin.fedoraproject.org/updates/FEDORA-2012-14650/tor-0.2.2.39-1700.fc17 11 https://admin.fedoraproject.org/updates/FEDORA-2012-16048/cobbler-2.4.0-beta2.fc17 29 https://admin.fedoraproject.org/updates/FEDORA-2012-14717/openjpeg-1.4-14.fc17 1 https://admin.fedoraproject.org/updates/FEDORA-2012-16662/net-snmp-5.7.1-5.fc17 1 https://admin.fedoraproject.org/updates/FEDORA-2012-16680/optipng-0.7.4-1.fc17 1 https://admin.fedoraproject.org/updates/FEDORA-2012-16669/kernel-3.6.3-1.fc17 0 https://admin.fedoraproject.org/updates/FEDORA-2012-16753/claws-mail-3.8.1-3.fc17 9 https://admin.fedoraproject.org/updates/FEDORA-2012-16163/ssmtp-2.61-19.fc17 35 https://admin.fedoraproject.org/updates/FEDORA-2012-14347/pcp-3.6.8-1.fc17 111 https://admin.fedoraproject.org/updates/FEDORA-2012-10269/revelation-0.4.14-1.fc17 The following Fedora 17 Critical Path updates have yet to be approved: Age URL 0 https://admin.fedoraproject.org/updates/FEDORA-2012-16851/plymouth-0.8.5-0.2012.04.27.4.fc17 0 https://admin.fedoraproject.org/updates/FEDORA-2012-16846/abrt-2.0.17-1.fc17,libreport-2.0.17-1.fc17,btparser-0.21-1.fc17 0 https://admin.fedoraproject.org/updates/FEDORA-2012-16826/cryptsetup-1.5.1-1.fc17 0 https://admin.fedoraproject.org/updates/FEDORA-2012-16848/policycoreutils-2.1.12-4.fc17 The following builds have been pushed to Fedora 17 updates-testing abrt-2.0.17-1.fc17 ams-2.0.1-5.fc17 btparser-0.21-1.fc17 cryptsetup-1.5.1-1.fc17 dmlite-0.4.2-2.fc17 dmlite-plugins-librarian-0.4.0-1.fc17 dmlite-plugins-memcache-0.4.0-1.fc17 dmlite-plugins-mysql-0.4.1-1.fc17 fping-3.4-1.fc17 gambas3-3.3.3-1.fc17 gobi_loader-0.7-6.fc17 jemalloc-3.1.0-1.fc17 kdevelop-4.4.0-2.fc17 kdevelop-php-1.4.0-1.fc17 kdevplatform-1.4.0-1.fc17 latexmk-4.34-1.fc17 ldns-1.6.14-1.fc17 libmatecomponent-1.4.0-14.fc17 libreport-2.0.17-1.fc17 man-db-2.6.0.2-9.fc17 maven-3.0.4-14.fc17 mimepull-1.8-3.fc17 muffin-1.1.2-1.fc17 openlmi-networking-0.0.5-1.fc17 openlmi-providers-0.0.10-1.fc17 openlmi-storage-0.4.0-2.fc17 php-pear-PEAR-Command-Packaging-0.3.0-4.fc17.1 php-phpunit-PHPUnit-3.6.12-2.fc17 php-voms-admin-0.6.5-1.fc17 plymouth-0.8.5-0.2012.04.27.4.fc17 policycoreutils-2.1.12-4.fc17 python-hghooks-0.5.4-3.fc17 python-virtinst-0.600.3-2.fc17 rsync-3.0.9-4.fc17 tzdata-2012g-1.fc17 unicode-ucd-6.2.0-3.fc17 virt-manager-0.9.4-2.fc17 Details about builds: abrt-2.0.17-1.fc17 (FEDORA-2012-16846) Automatic bug detection and reporting tool Update Information: This update fixes rpm and libsmi symbols collision caused by python hook, wrong product string if anaconda is installed and few bugs in bugzilla plugin and reort GUI. ChangeLog: * Wed Oct 24 2012 Jakub Filak 2.0.17-1 - provide a problem item containing versions of binaries listed in Xorg backtrace Adresses #867694 comment 1 - import rpm lazily - Resolves: #864324 References: [ 1 ] Bug #741647 - python report uses product from anaconda even on installed machine https://bugzilla.redhat.com/show_bug.cgi?id=741647 [ 2 ] Bug #849833 - new bug (or forced re-open) needed when dup crosses releases https://bugzilla.redhat.com/show_bug.cgi?id=849833 [ 3 ] Bug #867118 - limit bugzilla summary to 255 chars https://bugzilla.redhat.com/show_bug.cgi?id=867118 [ 4 ] Bug #869032 - report-gtk can't open bugzilla link https://bugzilla.redhat.com/show_bug.cgi?id=869032 ams-2.0.1-5.fc17 (FEDORA-2012-16822) Alsa Modular Synth, a realtime modular synthesizer Update Information: AlsaModularSynth is a realtime modular synthesizer and effect processor. It features * MIDI controlled modular software synthesis * Realtime
Fedora 16 updates-testing report
The following Fedora 16 Security updates need testing: Age URL 6 https://admin.fedoraproject.org/updates/FEDORA-2012-16421/drupal7-7.16-1.fc16 108 https://admin.fedoraproject.org/updates/FEDORA-2012-10402/bcfg2-1.2.3-1.fc16 32 https://admin.fedoraproject.org/updates/FEDORA-2012-14452/bacula-5.0.3-33.fc16 5 https://admin.fedoraproject.org/updates/FEDORA-2012-16490/xlockmore-5.40-3.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-16415/389-ds-base-1.2.10.16-1.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-16417/Django-1.3.4-1.fc16 35 https://admin.fedoraproject.org/updates/FEDORA-2012-14322/pcp-3.6.8-1.fc16 13 https://admin.fedoraproject.org/updates/FEDORA-2012-15844/drupal7-feeds-2.0-0.5.alpha6.fc16 2 https://admin.fedoraproject.org/updates/FEDORA-2012-16605/dokuwiki-0-0.14.20121013.fc16 111 https://admin.fedoraproject.org/updates/FEDORA-2012-10314/revelation-0.4.14-1.fc16 31 https://admin.fedoraproject.org/updates/FEDORA-2012-14654/tor-0.2.2.39-1600.fc16 37 https://admin.fedoraproject.org/updates/FEDORA-2012-14126/dbus-1.4.10-4.fc16 1 https://admin.fedoraproject.org/updates/FEDORA-2012-16659/net-snmp-5.7.1-3.fc16 11 https://admin.fedoraproject.org/updates/FEDORA-2012-16028/mapserver-6.0.3-4.fc16 11 https://admin.fedoraproject.org/updates/FEDORA-2012-16032/cobbler-2.4.0-beta2.fc16 0 https://admin.fedoraproject.org/updates/FEDORA-2012-16772/claws-mail-3.8.1-3.fc16 11 https://admin.fedoraproject.org/updates/FEDORA-2012-16055/thunderbird-16.0.1-1.fc16 The following Fedora 16 Critical Path updates have yet to be approved: Age URL 0 https://admin.fedoraproject.org/updates/FEDORA-2012-16832/plymouth-0.8.4-0.20110822.7.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-16249/thunderbird-lightning-1.8-1.fc16,thunderbird-16.0.1-2.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-16243/xulrunner-16.0.1-2.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-16252/curl-7.21.7-8.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-16251/perl-5.14.3-202.fc16 10 https://admin.fedoraproject.org/updates/FEDORA-2012-16099/kde-settings-4.7-15.fc16 11 https://admin.fedoraproject.org/updates/FEDORA-2012-16055/thunderbird-16.0.1-1.fc16 The following builds have been pushed to Fedora 16 updates-testing ReviewBoard-1.6.13-1.fc16 ams-2.0.1-5.fc16 fping-3.4-1.fc16 gambas3-3.3.3-1.fc16 jemalloc-3.1.0-1.fc16 latexmk-4.34-1.fc16 php-voms-admin-0.6.5-1.fc16 plymouth-0.8.4-0.20110822.7.fc16 python-djblets-0.6.24-1.fc16 tzdata-2012g-1.fc16 unicode-ucd-6.2.0-3.fc16 Details about builds: ReviewBoard-1.6.13-1.fc16 (FEDORA-2012-16845) Web-based code review tool Update Information: * Wed Oct 24 2012 Stephen Gallagher - 1.6.13-1 - New upstream release 1.6.13 - http://www.reviewboard.org/docs/releasenotes/dev/reviewboard/1.6.13/ - http://www.reviewboard.org/docs/releasenotes/dev/reviewboard/1.6.12/ - New Features: * Added support for incremental diff expansion * Replaced our old Report Bug and Bugs links in the top-right with Support * Added support for Clear Case snapshot views - Performance Improvements: * We no longer perform syntax highlighting for very large files - Hosting Service Changes * Fedora Hosted has been switched to use cgit instead of GitWeb - Web API Changes: * The FileDiffComment resource was showing all comments for all files in a diffset. Now it’s taking into account the requested FileDiff * Passing ?shipit=0 to the ReviewRequests resource now returns all review requests that do not have a Ship It - Bug Fixes: * General: * Fixed a regression where users could see other users' unpublished replies * Diff upload API errors now serialize the revision correctly * Fixed linking to bug numbers when they contain a # * The headers shown on the diffs in e-mails are no longer broken * The diff viewer no longer allows expansion to a function/class unless that function/class is defined within the collapsed region * Fixed validation of bug tracker URLs * Linked URLs with parenthesis in the URL no longer generate broken links * Fixed problems with collapsing SVN keywords * Changes to new files in parent diffs are no longer styled wrong * Fix JavaScript errors when publishing reviews with screenshot comments * The alt text for images in the dashboard now show the expected text and not Python representations of objects * Clear Case: * Filenames on Clear Case are now displayed in a more readable format * Fixed so
Re: 2012-10-08, 2012-10-15, 2012-10-22 - Fedora QA Meeting - recap
On Wed, 2012-10-24 at 19:02 +, "Jóhann B. Guðmundsson" wrote: > On 10/24/2012 06:15 PM, Adam Williamson wrote: > > Right. I do wish you wouldn't exaggerate things, Johann. The criteria > > are a part of Fedora as a whole, they define what the project considers > > minimum acceptable functionality for each release point. They are not > > solely a QA issue, other teams clearly have input into the question. > > we are the one who create the criteria > we are the ones that follow it > we are the ones that test if the relevant stuff meets the criteria > > Yes developers and packagers might do mistakes but in the end it's we ( > QA/Releng ) the ones that are ultimately responsible for the overall > quality of the release > we are the last line of defense for the end user and we are the ones > that should handle this ( from my pov. ) > > Asking the relevant developer group in this case Anaconda if they think > we are setting *our* distribution criteria to high to meet their *own* > software or even the group of individuals that approved the newUI > feature accepted it and allowed it with no better contingency plan than > what was given. I just don't agree with your principles here. 'We', as in QA, are not the only ones who create the criteria, no. The initial major revision of the criteria was done with significant input from the development teams. Changes since have often involved the development teams. Fundamentally I don't think it's correct to say that it is QA's job and QA's job alone to define what the requirements are for a Fedora release to be made. It's QA's job to *check* those requirements. I don't see how we can say that the best way to *define* the requirements is for QA to decide what they are and everyone else to butt out. Defining the requirements involves issues beyond those that are QA specific. It is more along the lines of the 'what Fedora is supposed to be' question. You can't draw up criteria without an answer to the questions 'what is a Fedora Alpha release for?' 'what is a Fedora Beta release for?' 'what is a Fedora Final release for?', which are questions that go far wider than QA alone. > An group of people that seem to be incapable of > answering one simply question I have asked on numerous occasion when it > became clear that the newUI installer is no way ready to be released to > the general public. Why the rush? why not push it back a release to > allow it to stabilize a bit more? > > And so I quote yourself to FESCO... > > "Additionally, RH has asked its staff on the anaconda team to prioritize > work on a pending RHEL release over work on Fedora 18, and that is > happening, which may further delay work on the upgrade tool and the > current blocker list." > > Yet another alarm bell ringing and where does this leave us ( the > project ) with the installer? > > So excuse me for being skeptical about FESCO decision making and an > development group that no longer has the time to develop the > distributions installer for showing concerns and "exaggerate things. Now you're just muddying the waters. None of the above really has any relation to the question of discussing release criteria revisions. -- 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: 2012-10-08, 2012-10-15, 2012-10-22 - Fedora QA Meeting - recap
On 10/24/2012 06:15 PM, Adam Williamson wrote: Right. I do wish you wouldn't exaggerate things, Johann. The criteria are a part of Fedora as a whole, they define what the project considers minimum acceptable functionality for each release point. They are not solely a QA issue, other teams clearly have input into the question. we are the one who create the criteria we are the ones that follow it we are the ones that test if the relevant stuff meets the criteria Yes developers and packagers might do mistakes but in the end it's we ( QA/Releng ) the ones that are ultimately responsible for the overall quality of the release we are the last line of defense for the end user and we are the ones that should handle this ( from my pov. ) Asking the relevant developer group in this case Anaconda if they think we are setting *our* distribution criteria to high to meet their *own* software or even the group of individuals that approved the newUI feature accepted it and allowed it with no better contingency plan than what was given. An group of people that seem to be incapable of answering one simply question I have asked on numerous occasion when it became clear that the newUI installer is no way ready to be released to the general public. Why the rush? why not push it back a release to allow it to stabilize a bit more? And so I quote yourself to FESCO... "Additionally, RH has asked its staff on the anaconda team to prioritize work on a pending RHEL release over work on Fedora 18, and that is happening, which may further delay work on the upgrade tool and the current blocker list." Yet another alarm bell ringing and where does this leave us ( the project ) with the installer? So excuse me for being skeptical about FESCO decision making and an development group that no longer has the time to develop the distributions installer for showing concerns and "exaggerate things. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F18 NM IPv6 not working with address auto configuration
This is one of those "it used to work, I think" things. Fedora 18. NetworkManager-0.9.7.0-6.git20121004.fc18.x86_64 On subnet with IPv6 address auto configuration enabled. NetworkManager brings up interface, link-local (fe80) address is configured, however no global address is configured. Link is an ethernet (hard) link, and it is configured to use IPv6 automatically. There are many other systems on this network segment that are all working with address auto configuration, so I believe it is endemic to NetworkManager. Anyone else seeing this? Any ideas? -Erinn signature.asc Description: OpenPGP digital signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F18 Beta Blocker Bug Review #5 Minutes
#fedora-qa: f18beta-blocker-review-5 Minutes: http://meetbot.fedoraproject.org/fedora-qa/2012-10-24/f18beta-blocker-review-5.2012-10-24-16.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-qa/2012-10-24/f18beta-blocker-review-5.2012-10-24-16.01.txt Log: http://meetbot.fedoraproject.org/fedora-qa/2012-10-24/f18beta-blocker-review-5.2012-10-24-16.01.log.html Meeting summary --- * Roll Call (tflink, 16:01:09) * Introduction (tflink, 16:06:14) * Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. (tflink, 16:06:22) * We'll be following the process outlined at: (tflink, 16:06:32) * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (tflink, 16:06:32) * The bugs up for review today are available at: (tflink, 16:06:39) * LINK: http://qa.fedoraproject.org/blockerbugs/current (tflink, 16:06:39) * The criteria for release blocking bugs can be found at: (tflink, 16:06:49) * LINK: https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria (tflink, 16:06:49) * LINK: https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria (tflink, 16:06:49) * LINK: https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria (tflink, 16:06:49) * 7 Proposed Blockers (tflink, 16:07:06) * 8 Accepted Blockers (tflink, 16:07:06) * 0 Proposed NTH (tflink, 16:07:06) * 12 Accepted NTH (tflink, 16:07:06) * (868519) LUKS passphrase exposed in /root/anaconda-ks.cfg (tflink, 16:07:59) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=868519 (tflink, 16:07:59) * Proposed Blocker, anaconda, ASSIGNED (tflink, 16:07:59) * AGREED: it's agreed in principle that security issues above a certain severity level (to be decided) not fixable by an update must be resolved before final release (adamw, 16:32:58) * AGREED: 868519 - RejectedBlocker (beta), AcceptedNTH (beta), AcceptedBlocker (final) - This does not violate any F18 beta release criteria and is thus rejected as a blocker for F18. Following the agreement above, this is provisionally accepted as a blocker for F18 final and NTH for F18 beta. (tflink, 16:34:27) * (848764) default mediacheck on 18 Alpha RC2 discs does not work (tflink, 16:34:39) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=848764 (tflink, 16:34:40) * Proposed Blocker, anaconda, POST (tflink, 16:34:40) * AGREED: 848764 - RejectedBlocker(beta), AcceptedNTH(beta), AcceptedBlocker(Final) - This doesn't violate any criteria for F18 beta and is rejected as a blocker. However, it does violate the following F18 final criterion and thus is accepted as beta NTH and final blocker: "If there is an embedded checksum in the image, it must match. If there is a related UI element displayed after booting the image, it must work and display the correct result" (tflink, 16:41:47) * (858801) [zh_TW] Please add Chinese (Taiwan) language to language selection menu in anaconda (tflink, 16:41:54) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=858801 (tflink, 16:41:57) * Proposed Blocker, anaconda, POST (tflink, 16:41:59) * AGREED: 858801 - RejectedBlocker (beta), AcceptedNTH (beta) - There are no translation requirements for beta and this is rejected as a blocker for beta. However, a tested patch would be accepted after beta freeze to add traditional chinese. Please re-propose as a final blocker for later review (tflink, 16:53:52) * (862784) newUI custom partitioning does not allow formatting of an existing partition for use in the installed system (tflink, 16:54:30) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=862784 (tflink, 16:54:33) * Proposed Blocker, anaconda, MODIFIED (tflink, 16:54:35) * AGREED: 862784 - RejectedBlocker (beta) - This doesn't violate any of the F18 beta release requirements, seems unlikely to hit any proposed revisions and has several reasonable workarounds. (tflink, 17:02:13) * (868777) fail to install the system use vnc (tflink, 17:02:22) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=868777 (tflink, 17:02:22) * Proposed Blocker, anaconda, NEW (tflink, 17:02:22) * AGREED: 868777 - RejectedBlocker (beta) - Since this seems to only affect VNC installs with media and dhcp, there are several workable workarounds and it was decided that this is not a blocker for f18 beta. (tflink, 17:08:08) * (869091) Gnome fails to install in TC6 Beta netinstall (tflink, 17:08:14) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=869091 (tflink, 17:08:14) * Proposed Blocker, distribution, NEW (tflink, 17:08:14) * AGREED: 869091 does not seem to be reproducible by anyone else
Re: 2012-10-08, 2012-10-15, 2012-10-22 - Fedora QA Meeting - recap
On Wed, 2012-10-24 at 07:18 -0600, Tim Flink wrote: > On Wed, 24 Oct 2012 09:48:47 + > "Jóhann B. Guðmundsson" wrote: > > > On 10/24/2012 03:33 AM, Adam Williamson wrote: > > > criterion" - not done yet > > > * "tflink to ask other interested parties (anaconda team, > > > fesco...) to look over the beta criteria and see if > > > there's anything they feel should be dialled down" - not done yet > > > > Since you guys seem to be not confident enough in our own criteria > > writing perhaps we should just stop writing them and have FESCO > > writing those for us? > > I think there is a difference between confidence and realizing that > we (and by we, I mean Fedora QA) are not omniscient - we can't > possibly know everything about what's reasonable and what makes up > a set of acceptably comprehensive criteria to describe an acceptable > release. > > There is wisdom in getting input from other groups - QA is a part of > Fedora as a whole, not some completely isolated group which dictates > the definition of a quality release. There is also wisdom in not setting > the bar too high - that's a great path to irrelevance and having the > criteria ignored. Right. I do wish you wouldn't exaggerate things, Johann. The criteria are a part of Fedora as a whole, they define what the project considers minimum acceptable functionality for each release point. They are not solely a QA issue, other teams clearly have input into the question. -- 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: 2012-10-08, 2012-10-15, 2012-10-22 - Fedora QA Meeting - recap
On Wed, 24 Oct 2012 09:48:47 + "Jóhann B. Guðmundsson" wrote: > On 10/24/2012 03:33 AM, Adam Williamson wrote: > > criterion" - not done yet > > * "tflink to ask other interested parties (anaconda team, > > fesco...) to look over the beta criteria and see if > > there's anything they feel should be dialled down" - not done yet > > Since you guys seem to be not confident enough in our own criteria > writing perhaps we should just stop writing them and have FESCO > writing those for us? I think there is a difference between confidence and realizing that we (and by we, I mean Fedora QA) are not omniscient - we can't possibly know everything about what's reasonable and what makes up a set of acceptably comprehensive criteria to describe an acceptable release. There is wisdom in getting input from other groups - QA is a part of Fedora as a whole, not some completely isolated group which dictates the definition of a quality release. There is also wisdom in not setting the bar too high - that's a great path to irrelevance and having the criteria ignored. Tim signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-18 Branched report: 20121024 changes
Compose started at Wed Oct 24 09:15:33 UTC 2012 Broken deps for x86_64 -- [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dnf] dnf-0.2.14-2.git4831982.fc18.noarch requires python-hawkey >= 0:0.3.0 [dustmite] dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires libphobos-ldc.so.59()(64bit) [evolution-exchange] evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-cal-1.2.so.17()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-book-1.2.so.14()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libecal-1.2.so.12()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebackend-1.2.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libcamel-1.2.so.36()(64bit) [flush] flush-0.9.10-7.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_signals-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [func] func-0.28-1.fc17.noarch requires smolt [gcc-python-plugin] gcc-python2-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python2-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-10.fc18.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.4.0.0 [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserver-1.2.so.16()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libebook-1.2.so.13()(64bit) [gnome-shell-theme-selene] gnome-shell-theme-selene-3.4.0-5.fc18.noarch requires gnome-shell-extensions-user-theme [ip-sentinel] ip-sentinel-upstart-0.12-1303.fc18.noarch requires /sbin/initctl [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [mapserver] mapserver-perl-6.0.1-5.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [milter-greylist] milter-greylist-upstart-4.2.7-1701.fc18.noarch requires /sbin/initctl [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [openvrml] libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-xembed-
Re: 2012-10-08, 2012-10-15, 2012-10-22 - Fedora QA Meeting - recap
On 10/24/2012 03:33 AM, Adam Williamson wrote: criterion" - not done yet * "tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down" - not done yet Since you guys seem to be not confident enough in our own criteria writing perhaps we should just stop writing them and have FESCO writing those for us? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2012-10-24 @ 16:00 UTC - F18 Beta Blocker Bug Review #5
> # F18 Beta Blocker Review meeting #5 > # Date: 2012-10-24 > # Time: 16:00 UTC [1] (12:00 EDT, 09:00 PDT) > # Location: #fedora-qa on irc.freenode.net Can't attend today, sorry, I'll be presenting Fedora at a university in Ostrava. Hopefully someone else from Brno comes by. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Upgrade path to F18 Beta-Final\Gold or other precious item?
On 23/10/12 22:35, Adam Williamson wrote: On Tue, 2012-10-23 at 22:20 +0100, Frank Murphy wrote: Seeing all the "obsolete" upgrade tests for Fedora 17 to 18 and having looked at https://fedorahosted.org/fesco/ticket/946 Will Fedora 17 be fedup with F18? Will beta be yummy? I'm still hoping we can hold the Beta until fedup is working acceptably, but some people are getting itchy feet since we've delayed the freeze twice already. FESCo is still discussing it in that very ticket. No problem with delays, just that there will be a viable upgrade path, is good news. -- Regards, Frank "Jack of all, fubars" -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
