Re: Rename anaconda to cryptoconda?
On Dec 3, 2012, at 1:51 PM, Adam Williamson awill...@redhat.com wrote: Yes, it's a bit messy, isn't it: the text is talking about the big +, but the big + is for creating *partitions*, not mount points. It's certainly a bit confusing to have text that talks about 'creating mount points', but the two actual viable operations are to 'set a mount point' or to 'create a partition and give it a mount point'. We could probably clean up the terminology there somehow. +/- is not a good symbol to use for a show-hide widget. After quite a bit of reading, I'm not finding in any of the anaconda newui mockups, only in anaconda itself. But in particular it's not a good idea to use +/- symbols in the same UI for two totally different functions, because it obviously makes it difficult for instructions to distinguish between the functions. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Rename anaconda to cryptoconda?
On Tue, 2012-12-04 at 01:10 -0700, Chris Murphy wrote: On Dec 3, 2012, at 1:51 PM, Adam Williamson awill...@redhat.com wrote: Yes, it's a bit messy, isn't it: the text is talking about the big +, but the big + is for creating *partitions*, not mount points. It's certainly a bit confusing to have text that talks about 'creating mount points', but the two actual viable operations are to 'set a mount point' or to 'create a partition and give it a mount point'. We could probably clean up the terminology there somehow. +/- is not a good symbol to use for a show-hide widget. After quite a bit of reading, I'm not finding in any of the anaconda newui mockups, only in anaconda itself. But in particular it's not a good idea to use +/- symbols in the same UI for two totally different functions, because it obviously makes it difficult for instructions to distinguish between the functions. I think it's used at present because it's the standard GTK+ widget. In general, anaconda is trying to use stock GTK+ stuff, again with the emphasis on maintainability - they want to minimize the use of custom widgets so they aren't a constant maintenance cost. -- 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
Bad setup by Network applet?
I recently upgraded the CPU/motherboard that runs omen.com. The gigabit local network that used to be p37p1 is now em1. After changing settings with the network applets the system would put the settings for the local network into the internet connection. When this happens the server is somewhat useless. Sometimes this would happen spontaneously. Looking at the network scripts, I noticed that only lo had a DEVICE= entry. I added appropriate DEVICE= entries to the other two scripts. Hopefully this should straighten things out. but shouldn't the setup app have done that? -- Chuck Forsberg WA7KGX N2469R c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Sound devices no longer accessible by audio group
Since the latest yum update I have to run audio programs as root in order to access an audio device. Previously being a member of audio group was sufficient. -- Chuck Forsberg WA7KGX N2469R c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Rename anaconda to cryptoconda?
Dne Po 3. prosince 2012 23:47:14, Adam Williamson napsal(a): This gets into a very general discussion, but there is a fairly solid case to be made that excessively aggressive behaviour on mailing lists doesn't just discourage those it's aimed at, I wish it had worked ... discouraging developers that do things that users do not like would be a good thing ;-) but sometimes I've got the opposite feeling - the more criticism, the more yes, I must be doing that right, they burnt Giordano Bruno on the stake for the truth, now they are trying to burn me but a substantial number of potential contributors who do not feel comfortable jumping into such an environment. hm, and would they feel comfortable jumping to an environment where they hear go away we don't want you? shouldn't the reaction be more like please keep your swearing at home than go away, don't test Fedora? K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp ka...@jabber.cz :: Never attribute to malice what can :: easily be explained by stupidity. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: community etiquette (Re: Rename anaconda to cryptoconda?)
On 2012-12-03 23:20 (GMT-0800) Adam Williamson composed: If you read the timestamps on the blog posts and design stuff we keep trying to persuade you to read, you will note that newUI has been under development for at least two years. The results I found have been two years in the making? Yikes!!! I don't recall you mentioning any blog in posts except http://blog.linuxgrrl.com/, where I had to hit Ctrl-+ 5 times to read it, at which point there was horizontal scroll with the browser fullscreen, and the text contained in its Anaconda images remained a mere 1/4 the size of my browser UI. The first date I found there was September 25, 2012, about 10 weeks ago. You do not appear to be making any effort at all to understand newUI My effort has proven all but fruitless. When you posted that list of 5 new bugs, I did formulate and begin a new plan. The obstacles to proceeding with that plan further exhausted me and available time. If someone who has been multibooting multiple machines with Linux since last century can't figure it out in less than a day, how's the average n00b going to fare, or even a non-n00b Fedora regular who is not also a regular testing participant? As noted upthread, this stuff is hard. All I need is what Mandriva/Mageia provide via cmdline option readonly=1 to select mount points among existing partitions, so maybe there's no reason for me to continue participating in Anaconda partitioning testing or discussion any time soon. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
OT: web size (was: Re: Rename anaconda to cryptoconda?)
Hi,
sorry to bother your circles, but one paragraph catched my eye ... it is
strongly offtopic here, but I couldn't resist to try to educate people - who
knows, maybe someday ... I'll live long enough until browser developers will
finally understand CSS ...
Dne Po 3. prosince 2012 14:35:15, Felix Miata napsal(a):
body {...font-size: 13px...}
What that rule says is that regardless how the viewer's browser is
configured, or the environment of the user, in particular the pixel density
of his display, 13px shall be used as a base instead. This rudely thwarts
the web's inherent adaptability.
this is not 100% true
please take a look at http://www.w3.org/TR/CSS21/syndata.html#value-def-length
- especially the image http://www.w3.org/TR/CSS21/syndata.html#img-pixel1
For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96
inch).
so, if pixel density of his display is very different from 96 DPI, the CSS px
unit should *not* be used 1:1 as display pixels
while you may consider setting base font size for reading at arms lenght to
3.38 mm rude in general, it surely does NOT rudely thwart the web's inherent
adaptability - it *should* adapt to the user's device, and it is just the
webbrowser developers' arrogance(*) if it doesn't adapt, go nag them
(*) I'd write laziness or something less offensive if I hadn't already tried
in vain with Gecko and KHTML
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp ka...@jabber.cz
:: Never attribute to malice what can
:: easily be explained by stupidity.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
fedora 18 spin for raspberry
Hello, I'm going to receive a raspberry in a few days and I would like to test upcoming Fedora 18 on it as there is already a F17 remix. Any repositories already in place or would it be a remix ready only post-final f18? Would be feasible to use it as a client to connect to oVirt infrastructure through spice? Anyone knows if the spice client related components are already in place in the current f17 remix ? Thanks, Gianluca -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedora 18 spin for raspberry
I think that there is no 18 available at the moment, why not install a 17 and try to help to debug it?? (i.e. it is not perfect, I have some problems) 2012/12/4 Gianluca Cecchi gianluca.cec...@gmail.com Hello, I'm going to receive a raspberry in a few days and I would like to test upcoming Fedora 18 on it as there is already a F17 remix. Any repositories already in place or would it be a remix ready only post-final f18? Would be feasible to use it as a client to connect to oVirt infrastructure through spice? Anyone knows if the spice client related components are already in place in the current f17 remix ? Thanks, Gianluca -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- Antonio Montagnani Skype : amontag52 Linux Fedora 17 Beefy Miracle -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedora 18 spin for raspberry
http://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedora_Remix_Installationthen download the image (that is a zip file to be unzipped directly from this link http://scotland.proximity.on.ca/raspberrypi/f17-releases/v5/latest/ Then you buy a SD card, ...dd to SD card , plug the card in the box, power on and you will see the usual first boot screens .. Basically I have the problem that I cannot use the poweroff/restart buttons that are greyed and after installation of yumex I cannot start it as after root password I get an error (but it is workinf fine if I start it in a terminal as su user!!) : I suppose that the two issues are connected 2012/12/4 Gianluca Cecchi gianluca.cec...@gmail.com On Tue Dec 4 10:57:09 UTC 2012 Antonio M wrote: I think that there is no 18 available at the moment, why not install a 17 and try to help to debug it?? (i.e. it is not perfect, I have some problems) For sure! I can also use more than flash card for my tests, no problem. Would I have to start with http://www.raspberrypi.org/archives/805 or any other link? Gianluca -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- Antonio Montagnani Skype : amontag52 Linux Fedora 17 Beefy Miracle -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Sound devices no longer accessible by audio group
On 12/04/2012 10:39 AM, Chuck Forsberg WA7KGX N2469R wrote: Since the latest yum update I have to run audio programs as root in order to access an audio device. Previously being a member of audio group was sufficient. Running audio programs as root should not be necessary and is almost never encouraged. Can you please file a bug outlining the steps you took to diagnose this problem? Perhaps pulseaudio was run as root at one time leaving a /tmp/.esd1000 file with root permissions lying around? Or perhaps it was a MIDI problem. Please file a bug. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedora 18 spin for raspberry
On Tue, 4 Dec 2012, Gianluca Cecchi wrote: Hello, I'm going to receive a raspberry in a few days and I would like to test upcoming Fedora 18 on it as there is already a F17 remix. Any repositories already in place or would it be a remix ready only post-final f18? Would be feasible to use it as a client to connect to oVirt infrastructure through spice? Anyone knows if the spice client related components are already in place in the current f17 remix ? Keep an eye on the Fedora ARM list https://admin.fedoraproject.org/mailman/listinfo/arm I believe an alpha image for F18 is in preparation but hasn't appeared yet. Michael Young -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: modify conflicts/dependencies criterion to cover all critical packaging errors
We agreed in principle at the meeting to amend the criterion to cover any critical packaging error. So I propose this wording: There must be no errors in any package on the DVD or release-blocking live desktop media which cause the package to fail to install. Such critical errors include, but are not limited to, undeclared conflicts (explicit Conflicts: tags are acceptable) and unresolved dependencies I'm in favor of this new one. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: modify conflicts/dependencies criterion to cover all critical packaging errors
On 12/04/2012 01:03 PM, Kamil Paral wrote: We agreed in principle at the meeting to amend the criterion to cover any critical packaging error. So I propose this wording: There must be no errors in any package on the DVD or release-blocking live desktop media which cause the package to fail to install. Such critical errors include, but are not limited to, undeclared conflicts (explicit Conflicts: tags are acceptable) and unresolved dependencies I'm in favor of this new one. As am I -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Blocker Bug Voting and Conversation
Affected Voters: - Do you vote on blocker status in bug comments? If necessary, but I don't like it much. In my experience the discussion in the meeting is often very helpful to understand the nature of the bug, and it can shift my opinion substantially. Also I don't like spamming bugzilla with irrelevant data. It makes the whole bug report less readable. - Would you vote on blocker status more often if you could easily vote outside of meetings? If we are not in a rush, I'd keep everything in the meeting. If we are in a rush (like now), I'd move some obvious (or controversial, those might be good candidates too) items outside of the meeting, but not into the bugzilla. An email thread on the test list is much better. It can contain long discussion without obfuscating bugzilla. Bugzilla can contain just a single comment with a hyperlink to the discussion, so that anyone interested can join. Once consensus is reached on the list, one of QA guys can update bugzilla status. There is one important drawback, and that is the necessity to be subscribed to the list. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda Accolades
On Tue, Dec 4, 2012 at 2:41 AM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-01 at 17:42 -0700, Peter Gueckel wrote: No need to comment. Just want to pass on experience to those up the ladder. 1. Stupid 20-minute pause (waiting for a timeout?) before the installation got underway. Thanks for the praise, but the 20 minute pause is somewhat worrying. Did you watch the console (probably too much to ask, but hey :) and see any messages that might relate to a timeout? Did you pick the media verification option or not? If you did, can you boot without it and see if it 'fixes' the delay? Thanks. I did not choose the media select (or at least I don't think I did) and also saw 20+ minute delays with no progress information while the DVD drive rapidly read data. Manually removing rd.live.check solved the issue. Looking at http://dl.fedoraproject.org/pub/alt/stage/18-Beta-RC1/Fedora/x86_64/os/isolinux/isolinux.cfgquickly it doesn't seem like that should happen, but perhaps there is confusion about if the media check option is selected or not (it is the default). I cannot get back to the computers I've been testing this on for at least a few hours though. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Blocker Bug Voting and Conversation
On 12/04/2012 01:22 PM, Kamil Paral wrote: Affected Voters: - Do you vote on blocker status in bug comments? If necessary, but I don't like it much. In my experience the discussion in the meeting is often very helpful to understand the nature of the bug, and it can shift my opinion substantially. Also I don't like spamming bugzilla with irrelevant data. It makes the whole bug report less readable. Same here - Would you vote on blocker status more often if you could easily vote outside of meetings? If we are not in a rush, I'd keep everything in the meeting. If we are in a rush (like now), I'd move some obvious (or controversial, those might be good candidates too) items outside of the meeting, but not into the bugzilla. An email thread on the test list is much better. It can contain long discussion without obfuscating bugzilla. Bugzilla can contain just a single comment with a hyperlink to the discussion, so that anyone interested can join. Once consensus is reached on the list, one of QA guys can update bugzilla status. Same here as well There is one important drawback, and that is the necessity to be subscribed to the list. I don't call that a draw back but rather the minimum requirement of being part of the QA community ( the other being fas/bugzilla account ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda Accolades
I did not choose the media select (or at least I don't think I did) and also saw 20+ minute delays with no progress information while the DVD drive rapidly read data. Manually removing rd.live.check solved the issue. It's very unfortunate the progress bar is not shown and information how to skip it is not displayed. Many people will then see it as being stuck or waiting for a timeout, and stupid. Should we make sure this problem is fixed in the final release? Currently it's proposed as NTH: https://bugzilla.redhat.com/show_bug.cgi?id=874486 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Blocker Bug Voting and Conversation
If we are not in a rush, I'd keep everything in the meeting. If we are in a rush (like now), I'd move some obvious (or controversial, those might be good candidates too) items outside of the meeting, but not into the bugzilla. An email thread on the test list is much better. It can contain long discussion without obfuscating bugzilla. Bugzilla can contain just a single comment with a hyperlink to the discussion, so that anyone interested can join. Once consensus is reached on the list, one of QA guys can update bugzilla status. Same here as well There is one important drawback, and that is the necessity to be subscribed to the list. I don't call that a draw back but rather the minimum requirement of being part of the QA community ( the other being fas/bugzilla account ) Yes, but don't forget the blocker bug process is a joint effort of developers, QA, release engineers and anyone else who is interested. It certainly presents some barrier. Some people might rather refrain from commenting because they would have to subscribe to yet another mailing list. I view it as very unfortunate (I am personally not fond of mailing lists at all), but I still see it as a better alternative to bugzilla voting and I don't see anything superior available. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-18 Branched report: 20121204 changes
Compose started at Tue Dec 4 09:15:31 UTC 2012 New package: brewtarget-1.2.5-4.fc18 An open source beer recipe creation tool Removed package: mod_auth_shadow-2.3-2.fc18 Removed package: uxlaunch-0.56-8.fc18 Updated Packages: RBTools-0.4.2-1.fc18 * Fri Nov 16 2012 - Stephen Gallagher sgall...@redhat.com - 0.4.2-1 - New upstream release 0.4.2 - http://www.reviewboard.org/docs/releasenotes/dev/rbtools/0.4.2/ - New Features: - * The .post-review-cookies.txt file is now made readable only by the calling user, improving security - * Improved debug output - * Updated our Plastic support for Plastic 4.0. This is no longer compatible with previous versions - * A revision to diff against can now be specified when using hgsubversion - Bug Fixes: - * General: -* Using UTF-8 in the summary or description no longer breaks -* The GNU diff error no longer mentions Subversion specifically -* Posting a diff to a submitted review request now displays an error instead of reopening the review request - * Clearcase: -* Fixed base path generation for Clear Case - * Git: -* Fix issues when running post-review within a git submodule with recent Git revisions -* Git diffs no longer include diffs from submodules, preventing useless diffs from being created -* post-review no longer breaks when run from a detached Git HEAD - * Mercurial: -* Fixed bailing on harmless warnings when running hg commands -* Fixed path calculation for hgsubversion when the path contains a username - * Subversion: -* Scanning for the right repository is much faster now when there are lots of Subversion repositories on the server -* Fix handling of revisions with deleted files for Subversion -* Handle modifications inside moved/copied directories for Subversion asymptote-2.21-3.fc18 - * Tue Oct 23 2012 Tom Callaway s...@fedoraproject.org - 2.21-3 - more missing BR, conditionalize texlive hacks * Sat Oct 20 2012 Jindrich Novy jn...@redhat.com - 2.21-2 - fix (Build)Requires * Wed Oct 10 2012 Tom Callaway s...@fedoraproject.org - 2.21-1 - update to 2.21 bsf-2.4.0-15.fc18 - * Thu Nov 22 2012 Tomas Radej tra...@redhat.com - 0:2.4.0-15 - Fixed URL of Source0 * Tue Nov 20 2012 Mikolaj Izdebski mizde...@redhat.com - 0:2.4.0-14 - Remove unneeded BR: jython cronie-1.4.10-1.fc18 * Tue Nov 27 2012 Marcela Mašláňová mmasl...@redhat.com - 1.4.10-1 - New release 1.4.10 * Fri Nov 23 2012 Marcela Mašláňová mmasl...@redhat.com - 1.4.9-2 - Re-add virtual provide on vixie-cron back because few packages still has incorrect requires on vixie-cron instead of dailyjobs. * Thu Nov 22 2012 Marcela Mašláňová mmasl...@redhat.com - 1.4.9-1 - New release 1.4.9 * Mon Oct 15 2012 Marcela Mašláňová mmasl...@redhat.com - 1.4.8-14 - remove BRs not needed anymore ctags-5.8-9.fc18 * Mon Nov 05 2012 Marcela Mašláňová mmasl...@redhat.com - 5.8-9 - fix license field again * Thu Oct 18 2012 Than Ngo t...@redhat.com - 5.8-8 - fix the crash in cssparse fonts-tweak-tool-0.1.2-1.fc18 - * Sat Nov 24 2012 Akira TAGOH ta...@redhat.com - 0.1.2-1 - New upstream release - Fix broken icons issue on non-GNOME desktops (#879140) * Wed Nov 21 2012 Akira TAGOH ta...@redhat.com - 0.1.1-3 - Fix a typo * Wed Nov 21 2012 Akira TAGOH ta...@redhat.com - 0.1.1-2 - clean up and improve the spec file. gdisk-0.8.5-1.fc18 -- * Sat Nov 17 2012 Terje Rosten terje.ros...@ntnu.no - 0.8.5-1 - 0.8.5 git-1.8.0.1-1.fc18 -- * Thu Nov 29 2012 Adam Tkac atkac redhat com - 1.8.0.1-1 - update to 1.8.0.1 - include git-subtree in git rpm (#864651) gnome-keyring-3.6.2-2.fc18 -- * Fri Nov 23 2012 Tomas Bzatek tbza...@redhat.com - 3.6.2-2 - Remove unused update-mime-database calls mc-4.8.6-2.fc18 --- * Wed Nov 28 2012 Jindrich Novy jn...@redhat.com 4.8.6-2 - sanitize of MC_EXT_SELECTED variable when viewing multiple files, CVE-2012-4463 (#862814) https://www.midnight-commander.org/ticket/2913 seamonkey-2.14-1.fc18 - * Thu Nov 22 2012 Dmitry Butskoy dmi...@butskoy.name 2.14-1 - update to 2.14 - fix elfhack compile ugene-1.11.3-2.fc18 --- * Tue Nov 27 2012 Rex Dieter rdie...@fedoraproject.org 1.11.3-2 - fix/update qt-related dependencies Summary: Added Packages: 1 Removed Packages: 2 Upgraded Packages: 12 Compose finished at Tue Dec 4 13:32:30 UTC 2012 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
safe install for fedora 18
I came up with a way to install fedora 18 on my main system without any worries that the cryptic partitioning interface might wind up wiping out my system. I liked it so much I may install fedora this way from now on. Here's my technique: 1. Install f18 in a brand new virtual machine. 2. Shutdown the VM 3. Mount the virtual filesystem with guestmount. 4. Format the real partition I want to install on. 5. rsync the guestmount to the new empty partition 6. edit the grub.cfg and fstab and wot-not in the new copy (to deal with UUID, root=, etc). 7. chroot into the new parition and run grub-install 8. Boot the new partition and see that it works. It works great. I can leave my system up and running while doing the install. I can feel pretty darn safe that anaconda inside the VM won't be clobbering anything outside the VM. A little tricky to find all the things that need to be edited, but I can record that info so it will be simpler in the future. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedora 18 spin for raspberry
On 12/04/2012 09:27 AM, Antonio M wrote: http://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedora_Remix_Installationthen download the image (that is a zip file to be unzipped directly from this link http://scotland.proximity.on.ca/raspberrypi/f17-releases/v5/latest/ Then you buy a SD card, ...dd to SD card , plug the card in the box, power on and you will see the usual first boot screens .. Basically I have the problem that I cannot use the poweroff/restart buttons that are greyed and after installation of yumex I cannot start it as after root password I get an error (but it is workinf fine if I start it in a terminal as su user!!) : I suppose that the two issues are connected yumex uses polkit. If you have the sudo/wheel thing set up then you use the user password. What DE does the spin use? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F-18 Branched report: 20121204 changes
On 12/04/2012 08:38 AM, Fedora Branched Report wrote: Compose started at Tue Dec 4 09:15:31 UTC 2012 VICTORY! NO BROKEN DEPS in Fedora 18! Now, I ask you all, please, please. Help me keep it that way! ~tom == Fedora Project -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F-18 Branched report: 20121204 changes
On Tue, Dec 4, 2012 at 9:07 AM, Tom Callaway tcall...@redhat.com wrote: On 12/04/2012 08:38 AM, Fedora Branched Report wrote: Compose started at Tue Dec 4 09:15:31 UTC 2012 VICTORY! NO BROKEN DEPS in Fedora 18! pops cork Now, I ask you all, please, please. Help me keep it that way! ~tom == Fedora Project -- devel mailing list de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F-18 Branched report: 20121204 changes
On Tue, Dec 04, 2012 at 10:07:15 -0500, Tom Callaway tcall...@redhat.com wrote: On 12/04/2012 08:38 AM, Fedora Branched Report wrote: Compose started at Tue Dec 4 09:15:31 UTC 2012 VICTORY! NO BROKEN DEPS in Fedora 18! Thanks for your work with this. You inspired me to try to fix up some of the broken deps in rawhide that looked easy to fix and had been sitting around for a while. Now I need to help Martin with getting stuff rebuilt for the latest Ogre. P.S. There is still some texlive brokenness in F18. If you have the latest texlive stuff installed and try to install db-latex it pulls in some old texlive stuff (that I think should be removed) that has file conflicts with the corresponding new texlive packages. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F-18 Branched report: 20121204 changes
On 12/04/2012 10:21 AM, Bruno Wolff III wrote: P.S. There is still some texlive brokenness in F18. If you have the latest texlive stuff installed and try to install db-latex it pulls in some old texlive stuff (that I think should be removed) that has file conflicts with the corresponding new texlive packages. If you can identify that, we'll go ahead and block those packages. Jindrich has been working hard to identify any remaining cases like you describe, and I'm happy to help. ~tom == Fedora Project -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F-18 Branched report: 20121204 changes
On Tue, Dec 04, 2012 at 10:44:11 -0500, Tom Callaway tcall...@redhat.com wrote: On 12/04/2012 10:21 AM, Bruno Wolff III wrote: P.S. There is still some texlive brokenness in F18. If you have the latest texlive stuff installed and try to install db-latex it pulls in some old texlive stuff (that I think should be removed) that has file conflicts with the corresponding new texlive packages. If you can identify that, we'll go ahead and block those packages. Jindrich has been working hard to identify any remaining cases like you describe, and I'm happy to help. I've been meaning to file bugs for the three affected packages. I'll get to it today. I don't think dblatex has a texlive varient yet, but maybe I can copy him on that one. For the two packages that appear to be obsolete, I'll file the bugs against the texlive variants so they are more likely to be seen by the right person. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Final criteria/Test cases interconnection
Final release criteria:
http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
I went through all criteria and connect them to test cases. I found
following problems:
We don't have TCs for:
* The release live images must properly support mounting and using a
persistent storage overlay for the entire system and/or one for
the /home partition, if such an overlay or overlays have been correctly
written to the medium from which the image is booted
* All critical path actions on release-blocking desktop environments
should correctly display all sufficiently complete translations
available for use - I don't think that this one is needed
* All known bugs that can cause corruption of user data must be fixed or
documented at Common F18 bugs - it doesn't make sence to have TC for
this one.
* No notices or alerts about pre-release status should be present -
there is no TC for anaconda
* The release must contain no known security bugs of 'important' or
higher impact according to the Red Hat severity classification scale
which cannot be satisfactorily resolved by a package update (e.g. issues
during installation) - I don't think we need TC for this.
* A Package-x-generic-16.pngspin-kickstarts package which contains the
exact kickstart files used to build the release must be present in the
release repository. The included kickstarts must define the correct set
of release repositories
* The final branded release notes from the Documentation team must be
present on ISO media and the appropriately versioned generic release
notes must be available in the online release repository
* A Package-x-generic-16.pngfedora-release package containing the
correct names, information and repository configuration for a final
Fedora release (as opposed to a pre-release) must be present on ISO
media while the appropriately versioned
Package-x-generic-16.pnggeneric-release package must be available in the
online release repository
Obsolete TCs:
* Hardware and BIOS RAID TCs - Do we support those now?
https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows
Other problems:
* I'm not sure which network-attached storage devices are supported. We
have only this
https://fedoraproject.org/wiki/QA:Testcase_EC2_AMI_Validation
Here is summary of all criteria/TC interconnections:
1. All Fedora 18 Beta Release Criteria must be met
2. All bugs blocking the F18Blocker tracker must be CLOSED
3. 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 -
https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums
4. The release live images must properly support mounting and using a
persistent storage overlay for the entire system and/or one for
the /home partition, if such an overlay or overlays have been correctly
written to the medium from which the image is booted - we don't have
test case for this
5. The installer must be able to use all supported local and remote
package source options - We have TC for: DVD, mirrorlist, http, ftp, nfs
and nfsiso
6. The installer must be able to complete an installation using any
network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel) -
Only TC we have now is
https://fedoraproject.org/wiki/QA:Testcase_EC2_AMI_Validation Are other
devices supported in F18?
7. The installer must be able to complete an installation using all
supported interfaces - We have TCs for: graphical, basic video driver,
text, vnc and serial console
8. The installer must be able to create and install to any workable
partition layout using any file system offered in a default installer
configuration, LVM, software, hardware or BIOS RAID, or combination of
the above - We have TCs for: custom partitioning, software, hardware and
BIOS RAID. Hardware and BIOS RAID TCs are obsolete.
9. The installer must be able to install into free space alongside an
existing clean single-partition Windows installation and either install
a bootloader which can boot into the Windows installation, or leave the
Windows bootloader untouched and working -
https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows it is
obsolete.
10. The installer must be able to use an installer update image
retrieved from removable media, remote installation source and HTTP
server - We have TCs for: URL, inst. source and local media
11. For each one of the release-blocking package sets ('minimal', and
the package sets for each one of the release-blocking desktops), it must
be possible to successfully complete an upgrade from a fully updated
installation of the previous stable Fedora release with that package set
installed, using all officially recommended upgrade mechanisms. The
upgraded system must meet all release criteria - The only TC we have is
https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop
12. The release must boot successfully as Xen DomU with releases
providing a functional, supported Xen
Re: fedora 18 spin for raspberry
On 12/04/2012 12:56 PM, Antonio M wrote: XFCE I do not understand the polkit thing, but I assume that a standard user should not have to open a rooted terminal to start Yumex or to issue a poweroff to stop the machine. Furthermore, it is not clear where and to whom to report any bug. You can solve the grayed out shutdown/reboot by installing consolekit. Yumex works just fine (although I'm in F18 now it did too in F17). I said that if the default user is administrator (wheel group) then the password to enter in the user's, not root's. 2012/12/4 Sergio sergiocmailbox-us...@yahoo.com.br On 12/04/2012 09:27 AM, Antonio M wrote: http://zenit.senecac.on.ca/**wiki/index.php/Raspberry_Pi_** Fedora_Remix_Installationthenhttp://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedora_Remix_Installationthen download the image (that is a zip file to be unzipped directly from this link http://scotland.proximity.on.**ca/raspberrypi/f17-releases/**v5/latest/http://scotland.proximity.on.ca/raspberrypi/f17-releases/v5/latest/ Then you buy a SD card, ...dd to SD card , plug the card in the box, power on and you will see the usual first boot screens .. Basically I have the problem that I cannot use the poweroff/restart buttons that are greyed and after installation of yumex I cannot start it as after root password I get an error (but it is workinf fine if I start it in a terminal as su user!!) : I suppose that the two issues are connected yumex uses polkit. If you have the sudo/wheel thing set up then you use the user password. What DE does the spin use? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Rename anaconda to cryptoconda?
On 04.12.2012 00:13, Eric Blake wrote: [I debated about starting a new thread, since no one else in this thread seems to have mentioned installing into a pre-existing LUKS volume group, but this bug summary proved too tempting to not add another bug to the list, not to mention that the term 'cryptoconda' seems somewhat apropos to my failed attempt to install to a pre-existing LUKS encrypted partition] I've successfully installed Fedora 18 beta from netinstall image on encrypted partition with LVM volumes for /, /home and swap. Surprisingly there was no single crash. Mateusz Marzantowicz -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Rename anaconda to cryptoconda?
On Tue, 2012-12-04 at 11:06 +0100, Karel Volný wrote: Dne Po 3. prosince 2012 23:47:14, Adam Williamson napsal(a): This gets into a very general discussion, but there is a fairly solid case to be made that excessively aggressive behaviour on mailing lists doesn't just discourage those it's aimed at, I wish it had worked ... discouraging developers that do things that users do not like would be a good thing ;-) but sometimes I've got the opposite feeling - the more criticism, the more yes, I must be doing that right, they burnt Giordano Bruno on the stake for the truth, now they are trying to burn me That's, er, a) completely unsubstantiated and b) not what I said. 'Doesn't just discourage X but Y' means 'it discourages both X and Y'. It doesn't mean 'it discourages Y but not X'. but a substantial number of potential contributors who do not feel comfortable jumping into such an environment. hm, and would they feel comfortable jumping to an environment where they hear go away we don't want you? shouldn't the reaction be more like please keep your swearing at home than go away, don't test Fedora? Ideally, for sure. But what if someone refuses to change their communication style? -- 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: community etiquette (Re: Rename anaconda to cryptoconda?)
On Tue, 2012-12-04 at 05:35 -0500, Felix Miata wrote: On 2012-12-03 23:20 (GMT-0800) Adam Williamson composed: If you read the timestamps on the blog posts and design stuff we keep trying to persuade you to read, you will note that newUI has been under development for at least two years. The results I found have been two years in the making? Yikes!!! Yes. I do keep saying this stuff is hard and encouraging you to read the design documentation and relevant blogs to understand how we got to where we are. I don't know why this is apparently so difficult. I don't recall you mentioning any blog in posts except http://blog.linuxgrrl.com/, where I had to hit Ctrl-+ 5 times to read it, at which point there was horizontal scroll with the browser fullscreen, and the text contained in its Anaconda images remained a mere 1/4 the size of my browser UI. The first date I found there was September 25, 2012, about 10 weeks ago. It's a blog. It has an archive. So strictly, newUI as a project really began at FUDCon Tempe, in January 2011 - just a month short of two years: http://blog.linuxgrrl.com/2011/06/16/making-fedora-easier-to-use-the-installer-ux-redesign/ But Mo had already been thinking about re-designing storage stuff as far back as August 2009: http://blog.linuxgrrl.com/2009/08/12/anaconda-advanced-storage-devices/ You do not appear to be making any effort at all to understand newUI My effort has proven all but fruitless. When you posted that list of 5 new bugs, I did formulate and begin a new plan. The obstacles to proceeding with that plan further exhausted me and available time. If someone who has been multibooting multiple machines with Linux since last century can't figure it out in less than a day, how's the average n00b going to fare, or even a non-n00b Fedora regular who is not also a regular testing participant? I don't know, and neither do you: that's why the team is planning in-person usability testing after the f18 release. We've had a range of reactions to the new design from existing experienced users; so far as I know, no 'n00b' has tried it at all yet, as n00bs don't run Fedora betas. Sometimes being a multibooting expert who refuses to read documentation or explanations makes things harder, not easier. :) As noted upthread, this stuff is hard. All I need is what Mandriva/Mageia provide via cmdline option readonly=1 to select mount points among existing partitions, so maybe there's no reason for me to continue participating in Anaconda partitioning testing or discussion any time soon. I don't see how the conclusion 'there's no reason for me to help test this new installer design' follows from the premise 'there's another installer whose design I am familiar with'. A Fedora Beta is not there for you to use it, it's there for you to test it. If you take the time to test it and provide constructive feedback, we definitely appreciate that. If you try it out and then yell at us and tell us it's garbage, we don't appreciate that so much, because it doesn't help us in any way. If you don't want to contribute your time to testing it, then that's perfectly fine: it is of course entirely up to you. But saying you'll only test something if it works really well appears to be putting the cart before the horse. -- 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: Release criterion proposal: modify conflicts/dependencies criterion to cover all critical packaging errors
On Tue, 2012-12-04 at 13:17 +, Jóhann B. Guðmundsson wrote: On 12/04/2012 01:03 PM, Kamil Paral wrote: We agreed in principle at the meeting to amend the criterion to cover any critical packaging error. So I propose this wording: There must be no errors in any package on the DVD or release-blocking live desktop media which cause the package to fail to install. Such critical errors include, but are not limited to, undeclared conflicts (explicit Conflicts: tags are acceptable) and unresolved dependencies I'm in favor of this new one. As am I Thanks. The inclusion of 'live desktop media' is slightly tricky, I should have unpacked that: it's basically impossible for a package to get onto the live media if it's not installable, as it has to be installed to build the media, but including the phrase gives us a criterion to use when a package is blocking the creation of the live media... -- 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: Anaconda Accolades
On Tue, 2012-12-04 at 08:26 -0500, Samuel Greenfeld wrote: I did not choose the media select (or at least I don't think I did) and also saw 20+ minute delays with no progress information while the DVD drive rapidly read data. Manually removing rd.live.check solved the issue. Looking at http://dl.fedoraproject.org/pub/alt/stage/18-Beta-RC1/Fedora/x86_64/os/isolinux/isolinux.cfg quickly it doesn't seem like that should happen, but perhaps there is confusion about if the media check option is selected or not (it is the default). I cannot get back to the computers I've been testing this on for at least a few hours though. Media verification is the default. If it's taking 20+ minutes on a physical DVD and we have no progress indicator, that's definitely something of a problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Final criteria/Test cases interconnection
On Tue, 2012-12-04 at 17:28 +0100, Petr Schindler wrote: Final release criteria: http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria I went through all criteria and connect them to test cases. I found following problems: We don't have TCs for: * The release live images must properly support mounting and using a persistent storage overlay for the entire system and/or one for the /home partition, if such an overlay or overlays have been correctly written to the medium from which the image is booted Should probably be added as a 'Base' test. * All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use - I don't think that this one is needed * All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs - it doesn't make sence to have TC for this one. Those two are basically 'on-demand' - it's hard to write a test case for the translations one, and if we were to expect one person to go through every translation it'd take forever. * No notices or alerts about pre-release status should be present - there is no TC for anaconda Sure it's not in any of the existing test cases? Though you might be right, since we've forgotten this in RCs in the past. * The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation) - I don't think we need TC for this. Yeah, another on-demand one. * A Package-x-generic-16.pngspin-kickstarts package which contains the exact kickstart files used to build the release must be present in the release repository. The included kickstarts must define the correct set of release repositories * The final branded release notes from the Documentation team must be present on ISO media and the appropriately versioned generic release notes must be available in the online release repository * A Package-x-generic-16.pngfedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned Package-x-generic-16.pnggeneric-release package must be available in the online release repository These could be combined as a single Base test. Obsolete TCs: * Hardware and BIOS RAID TCs - Do we support those now? Yes. Why would they be obsolete? https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows Ditto? Other problems: * I'm not sure which network-attached storage devices are supported. We have only this We probably ought to have at least an iSCSI test of some kind, we're kinda constrained by hardware here though. https://fedoraproject.org/wiki/QA:Testcase_EC2_AMI_Validation -- 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: Anaconda Accolades
On Tue, 2012-12-04 at 13:08 -0500, Scott Robbins wrote: On Tue, Dec 04, 2012 at 09:56:29AM -0800, Adam Williamson wrote: On Tue, 2012-12-04 at 08:26 -0500, Samuel Greenfeld wrote: Media verification is the default. If it's taking 20+ minutes on a physical DVD and we have no progress indicator, that's definitely something of a problem. As you've said before, it's always been the default. However in the past, it was very simple to skip--which I always have because frankly, in RH it's never been reliable. Well it was completely different before - it was an option in the loader UI, with buttons and a full progress screen and stuff. Right now it's part of dracut with very minimal UI. I don't recollect running into it in recent Beta test installs--is it something that is as easily skipped as it's always been? Not right now, no, that's kind of the problem - it runs right from the boot menu with zero UI, it just runs and you wait. It doesn't even tell you it's running. You should be able to bail out of it with Esc, but apparently that doesn't work. If you catch and read the boot menu it's easy enough to skip - you just pick 'Install Fedora 18' instead of 'Verify media and install Fedora 18'. But you do have to spot it. As long as it's easily turned off that's not a problem. As it's not something _I_ use, you can put put in a progress bar or not, but I won't see it. :) (Hrrm, the Archer episode, where he and Lana are going to become human prey, comes to mind. When the villain says to go, Archer pushes Lana to the ground to get a head start--she shouts, Archer, are you really that self-centered? He shouts back, Apparently.) MANY POINTS FOR ARCHER -- 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: Blocker Bug Voting and Conversation
On Tue, 2012-12-04 at 08:22 -0500, Kamil Paral wrote: Affected Voters: - Do you vote on blocker status in bug comments? If necessary, but I don't like it much. In my experience the discussion in the meeting is often very helpful to understand the nature of the bug, and it can shift my opinion substantially. Also I don't like spamming bugzilla with irrelevant data. It makes the whole bug report less readable. - Would you vote on blocker status more often if you could easily vote outside of meetings? If we are not in a rush, I'd keep everything in the meeting. If we are in a rush (like now), I'd move some obvious (or controversial, those might be good candidates too) items outside of the meeting, but not into the bugzilla. An email thread on the test list is much better. It can contain long discussion without obfuscating bugzilla. Bugzilla can contain just a single comment with a hyperlink to the discussion, so that anyone interested can join. Once consensus is reached on the list, one of QA guys can update bugzilla status. There is one important drawback, and that is the necessity to be subscribed to the list. I think this is an interesting idea, but aside from the drawbacks someone else noted (blocker voting is not QA-only), I see another: our current mailing list archive kinda sucks and is a pain to read a long thread on. If we get the shiny new one Mo is designing this might become a moot point, but right now I'd rather read even a messy bugzilla report than a long ML thread via our mail archives. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedora 18 spin for raspberry
Message: 8 Date: Tue, 4 Dec 2012 12:27:42 +0100 From: Antonio Mantonio.montagn...@gmail.com To: For testing and quality assurance of Fedora releases test@lists.fedoraproject.org Subject: Re: fedora 18 spin for raspberry Message-ID: capp99dcha-260egzsmxzkecyveqg5ndzds4dhdqlyzoyupf...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 http://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedora_Remix_Installationthen download the image (that is a zip file to be unzipped directly from this link http://scotland.proximity.on.ca/raspberrypi/f17-releases/v5/latest/ Then you buy a SD card, ...dd to SD card , plug the card in the box, power on and you will see the usual first boot screens .. Basically I have the problem that I cannot use the poweroff/restart buttons that are greyed and after installation of yumex I cannot start it as after root password I get an error (but it is workinf fine if I start it in a terminal as su user!!) : I suppose that the two issues are connected 2012/12/4 Gianluca Cecchigianluca.cec...@gmail.com On Tue Dec 4 10:57:09 UTC 2012 Antonio M wrote: I think that there is no 18 available at the moment, why not install a 17 and try to help to debug it?? (i.e. it is not perfect, I have some problems) For sure! I can also use more than flash card for my tests, no problem. Would I have to start with http://www.raspberrypi.org/archives/805 or any other link? Gianluca Look at this testing page: http://wiki.sugarlabs.org/go/Testing/Reports/ARM_RPi Tom Gilliard satellit on #sugar IRC freenode -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Blocker Bug Voting and Conversation
On Dec 3, 2012, at 3:19 PM, Tim Flink tfl...@redhat.com wrote: Affected Voters: - Do you vote on blocker status in bug comments? Rarely. I agree with Kamil's comment that it makes bug reports less readable. It may also encourage conversations, turning the bug report into a giant email thread, ick. - Would you vote on blocker status more often if you could easily vote outside of meetings? I don't think so. On the one hand the meetings, even shortened, are quite long which is a disincentive to participation; on the other hand a specifically scheduled time makes me more likely to participate if I have the time/interest. An email thread becomes yet another pile of emails I'm inclined to ignore even if it's easier to participate. Perhaps the solution to encourage participation by email is to limit it to controversial bugs, as suggested by Kamil. - Do you want to receive status updates on the bugs you vote on, even if those status updates don't deal directly with blocker status? No. Maybe 90+% of the bugs I vote on don't affect me, or minimally affect me. If I care about a bug I'm already on the bugzilla distribution for status/additional comments so I'll be notified if a change affects me. Anyhow, helpful thoughts would be appreciated. Hopefully we can improve the process so that it's less painful for everyone and maybe even more useful (at the very least, less difficult to understand). I think the release criteria needs to define which bugs can be determined entirely by QA to be blockers. A significant minority of bugs don't need to be voted on, when they obviously cause release criteria to not be met, for many users, and maybe another parameter or two go in there. If the bug is in that category, dink, it's a blocker and doesn't need to be voted on. I call this delegation to and trust in QA, and the process. So the process needs parameters to allow for this. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Blocker Bug Voting and Conversation
On Mon, 03 Dec 2012 19:34:12 -0800 Adam Williamson awill...@redhat.com wrote: snip Anyhow, helpful thoughts would be appreciated. Hopefully we can improve the process so that it's less painful for everyone and maybe even more useful (at the very least, less difficult to understand). I don't want to overplay how bad the current system is, to be honest. It's a duct tape job, sure, but it's survived as long as it has because it actually achieves its goals fairly efficiently. I think we can definitely build something more solid, but let's not throw out any babies... Hrm, I should have tried a bit harder to separate my thoughts. That was a little bit of the process is difficult to understand tacked on to the conversation bit that I was trying to discuss. I'm not trying to say that the process is completely broken but I do think that it's rather complicated and difficult to understand until you're familiar with it. I think the best evidence of this is the number of bugs which get proposed as blockers or NTH without any justification of why or citing of any release criterion that might be violated. I take that as the process isn't being communicated well and is complicated rather than contributors are ignoring stuff. I think that making the proposal process more straightforward and/or easy would go a long way towards addressing this particular issue but that's orthogonal to the where do we have blocker conversations question. Tim signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda Accolades
On Tue, Dec 04, 2012 at 10:14:59AM -0800, Adam Williamson wrote: On Tue, 2012-12-04 at 13:08 -0500, Scott Robbins wrote: Media verification is the default. If it's taking 20+ minutes on a physical DVD and we have no progress indicator, that's definitely something of a problem. As you've said before, it's always been the default. However in the past, it was very simple to skip--which I always have because frankly, in RH it's never been reliable. I don't recollect running into it in recent Beta test installs--is it something that is as easily skipped as it's always been? If you catch and read the boot menu it's easy enough to skip - you just pick 'Install Fedora 18' instead of 'Verify media and install Fedora 18'. But you do have to spot it. Ok, that works for me. :) I don't know if I've spotted it or not, but don't recollect noticing anything taking overly long--hrrm, installed mostly on VMs from iso images (netinstalls) and from USBs. (Hrrm, the Archer episode, where he and Lana are going to become human prey, comes to mind. When the villain says to go, Archer pushes Lana to the ground to get a head start--she shouts, Archer, are you really that self-centered? He shouts back, Apparently.) MANY POINTS FOR ARCHER Yes, quite popular here at work. Some of the things they came up with... such as that one. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Willow: You just don't like him 'cause of that time he beat you up every day for five years. Xander: Yeah, I'm irrational that way. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Blocker Bug Voting and Conversation
On Dec 4, 2012, at 11:51 AM, Tim Flink tfl...@redhat.com wrote: I think the best evidence of this is the number of bugs which get proposed as blockers or NTH without any justification of why or citing of any release criterion that might be violated. I take that as the process isn't being communicated well and is complicated rather than contributors are ignoring stuff. I think it's more of the latter and less of the former, but a combination of both. I remember it being communicated in the blocker submission documentation. But maybe other people are finding out how to submit blockers not via documentation but by mimicking blocker bugs, or from the email list. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda Accolades
On Tue, 2012-12-04 at 13:53 -0500, Scott Robbins wrote: On Tue, Dec 04, 2012 at 10:14:59AM -0800, Adam Williamson wrote: On Tue, 2012-12-04 at 13:08 -0500, Scott Robbins wrote: Media verification is the default. If it's taking 20+ minutes on a physical DVD and we have no progress indicator, that's definitely something of a problem. As you've said before, it's always been the default. However in the past, it was very simple to skip--which I always have because frankly, in RH it's never been reliable. I don't recollect running into it in recent Beta test installs--is it something that is as easily skipped as it's always been? If you catch and read the boot menu it's easy enough to skip - you just pick 'Install Fedora 18' instead of 'Verify media and install Fedora 18'. But you do have to spot it. Ok, that works for me. :) I don't know if I've spotted it or not, but don't recollect noticing anything taking overly long--hrrm, installed mostly on VMs from iso images (netinstalls) and from USBs. It runs *way* faster in those cases, yeah. Rotating media really is slow. -- 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: Blocker Bug Voting and Conversation
On Tue, 4 Dec 2012 08:22:12 -0500 (EST) Kamil Paral kpa...@redhat.com wrote: Affected Voters: - Do you vote on blocker status in bug comments? If necessary, but I don't like it much. In my experience the discussion in the meeting is often very helpful to understand the nature of the bug, and it can shift my opinion substantially. I'm not trying to do away with the meetings, per se but I would like to enable a bit more asynchronous action. One of the problems with doing blocker review meetings is that they happen at the time they're scheduled. Finding a time where enough people are able to attend is difficult and someone is always going to be unable to attend. I also think that pinging devs during the meeting is also sub-optimal. Assuming that someone is available during the meetings for whenever a bug assigned to them comes up, it's disruptive to be interrupted just because we happen to be discussing something right now. I'd like to find a solution where we weren't quite so dependent on simultaneous real-time interaction. Is it the meeting itself which you find helpful or the discussion and information during the review meetings? Could you see asynchronous conversation (exact method TBD) being as useful? Also I don't like spamming bugzilla with irrelevant data. It makes the whole bug report less readable. In my mind, the trick is finding a good balance. I think that keeping blocker status completely separate from the relevant bug is worse than polluting the bug with too much blocker conversation. - Would you vote on blocker status more often if you could easily vote outside of meetings? If we are not in a rush, I'd keep everything in the meeting. If we are in a rush (like now), I'd move some obvious (or controversial, those might be good candidates too) items outside of the meeting, but not into the bugzilla. I'm trying to keep on top of that for now as more of a manual process but I think that one person doing the sorting isn't great. It's a bit of a pain for the sorter, there are going to be mistakes and it doesn't get around the issue of where do we have the conversation?. An email thread on the test list is much better. It can contain long discussion without obfuscating bugzilla. Bugzilla can contain just a single comment with a hyperlink to the discussion, so that anyone interested can join. Once consensus is reached on the list, one of QA guys can update bugzilla status. Adam said something similar but I really don't want to use email alone for this. While it might technically work, I also find email threads like that to be rather difficult/painful to parse. It would also make any process automation (bug comments, status changes, vote counting etc.) much more difficult, adding to the amount of required human intervention. There is one important drawback, and that is the necessity to be subscribed to the list. Yeah, I think that's going to be a potential issue no matter what we end up with. Not necessarily list subscription but making sure that everyone who needs to be in the loop is in the loop while keeping the signal-to-noise ratio up and the annoyance factor down. Tim signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Blocker Bug Voting and Conversation
On Tue, 2012-12-04 at 11:42 -0700, Chris Murphy wrote: Anyhow, helpful thoughts would be appreciated. Hopefully we can improve the process so that it's less painful for everyone and maybe even more useful (at the very least, less difficult to understand). I think the release criteria needs to define which bugs can be determined entirely by QA to be blockers. A significant minority of bugs don't need to be voted on, when they obviously cause release criteria to not be met, for many users, and maybe another parameter or two go in there. If the bug is in that category, dink, it's a blocker and doesn't need to be voted on. I call this delegation to and trust in QA, and the process. So the process needs parameters to allow for this. I've thought about this too, it's clearly the case there's a bit of unnecessary bureaucracy overhead on certain bugs. The problem is that any time I sit down and try and find a way to fix it that won't lead to any problems, it gets tricky. On an 'ad hoc' basis the system we used this week - have someone go through the list and 'bin' the reports - isn't bad, but it's relying on there being a person to do that, and that's one more job that will probably inevitably fall to an RHian since we can be guaranteed to be around, which increases our workload and the perception that Fedora is just a cipher for RH, neither of which I'm super happy with encouraging...so it's a tricky problem. Ideas welcome, though. =) There are a few slam dunks like 'any failure of the repoclosure test on the DVD is a blocker', but we don't save _that_ much time with those, because we're already fairly accustomed to them and we pretty much just wave them through at meetings - or discuss how to fix them, which is valuable discussion that will have to happen even with auto-approval... -- 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: Blocker Bug Voting and Conversation
On Tue, 2012-12-04 at 12:10 -0700, Chris Murphy wrote: On Dec 4, 2012, at 11:51 AM, Tim Flink tfl...@redhat.com wrote: I think the best evidence of this is the number of bugs which get proposed as blockers or NTH without any justification of why or citing of any release criterion that might be violated. I take that as the process isn't being communicated well and is complicated rather than contributors are ignoring stuff. I think it's more of the latter and less of the former, but a combination of both. I remember it being communicated in the blocker submission documentation. But maybe other people are finding out how to submit blockers not via documentation but by mimicking blocker bugs, or from the email list. Right, and speaking personally, I actually err on the side of encouraging people to submit blockers even without all the i's dotted and the t's crossed rather than discouraging them from submission by being too hard about sticking precisely to the process. The thought that we might miss a blocker bug can certainly keep you awake at night, but the annoyance of having to figure out whether an unclear submission is a blocker or not is really just an annoyance... -- 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
php failed to run
Hello all, After installing both httpd and php and setting a UserDir to enable public_html, I encountered an issue with php which failed to run despite its presence. Here is the conf userdir.conf # # Control access to UserDir directories. The following is an example # for a site where these directories are restricted to read-only. # Directory /home/*/public_html AllowOverride FileInfo AuthConfig Limit Indexes Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec Require method GET POST OPTIONS /Directory php.conf # # Cause the PHP interpreter to handle files with a .php extension. # FilesMatch \.php$ SetHandler application/x-httpd-php /FilesMatch # # Add index.php to the list of files that will be served as directory # indexes. # DirectoryIndex index.php # # Uncomment the following lines to allow PHP to pretty-print .phps # files as PHP source code: # #FilesMatch \.phps$ #SetHandler application/x-httpd-php-source #/FilesMatch # # Apache specific PHP configuration options # those can be override in each configured vhost # php_value session.save_handler files php_value session.save_path/var/lib/php/session -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.thefinalzone.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Blocker Bug Voting and Conversation
On 12/04/2012 07:29 PM, Adam Williamson wrote: I've thought about this too, it's clearly the case there's a bit of unnecessary bureaucracy overhead on certain bugs. The problem is that any time I sit down and try and find a way to fix it that won't lead to any problems, it gets tricky. On an 'ad hoc' basis the system we used this week - have someone go through the list and 'bin' the reports - isn't bad, but it's relying on there being a person to do that, and that's one more job that will probably inevitably fall to an RHian since we can be guaranteed to be around, Not really which increases our workload and the perception that Fedora is just a cipher for RH, neither of which I'm super happy with encouraging...so it's a tricky problem. Ideas welcome, though. =) I would say one symptom is that our criteria is getting to complicated which leads to all the gray area that needs to be discussed. Eliminate that gray area like we just did with There must be no errors in any package on the DVD or release-blocking live desktop media which cause the package to fail to install. and the process will become more efficient. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: php failed to run
On Tue, 2012-12-04 at 11:38 -0800, Luya Tshimbalanga wrote: Hello all, After installing both httpd and php and setting a UserDir to enable public_html, I encountered an issue with php which failed to run despite its presence. Here is the conf What error message do you get? Did you check if it's SELinux? (Easy way to check - 'setenforce Permissive', try again, see if it works. If it does, the correct conclusion is not 'oh well, I'll just run in permissive mode forever' but 'ah, I need to fix up the SELinux contexts'.) -- 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
Puzzled
I have been trying to install F18 beta on real hardware and seem to have it a problem concerning disk allocation. I have successfully installed the beta into a virtual systems. My problem is that I have a test system with almost all of the disk space pre-allocated into various partitions. There are /boot partitions on the sda disk but the remainder are in lvm. I cannot seem to be able to get to the lvm configurations. What am I missing. Gene -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: php failed to run
On Tue 04 Dec 2012 11:45:39 AM PST, Adam Williamson wrote: What error message do you get? Did you check if it's SELinux? (Easy way to check - 'setenforce Permissive', try again, see if it works. If it does, the correct conclusion is not 'oh well, I'll just run in permissive mode forever' but 'ah, I need to fix up the SELinux contexts'.) One of errors was apparently related to SELinux which I sent a report : https://bugzilla.redhat.com/show_bug.cgi?id=883200 After creating a policy, testing a simple phpinfo() from a local server still display blank. Setting selinux to permissive has no effect on php behaviour, I always leave Enforcing on by default. All setting are done from /etc/httpd/conf.d/ with only edited userdir. -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.thefinalzone.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Sound devices no longer accessible by audio group
On 12/04/2012 04:07 AM, Brendan Jones wrote: On 12/04/2012 10:39 AM, Chuck Forsberg WA7KGX N2469R wrote: Since the latest yum update I have to run audio programs as root in order to access an audio device. Previously being a member of audio group was sufficient. Running audio programs as root should not be necessary and is almost never encouraged. Can you please file a bug outlining the steps you took to diagnose this problem? Perhaps pulseaudio was run as root at one time leaving a /tmp/.esd1000 file with root permissions lying around? Or perhaps it was a MIDI problem. Please file a bug. rm -R /tmp/.esd* seems to have fixed the problem, which may have been caused by the cpu/motherboard swap. -- Chuck Forsberg WA7KGX N2469R c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda Accolades
Adam Williamson awilliam at redhat.com writes: I don't recollect running into it in recent Beta test installs--is it something that is as easily skipped as it's always been? Not right now, no, that's kind of the problem - it runs right from the boot menu with zero UI, it just runs and you wait. It doesn't even tell you it's running. You should be able to bail out of it with Esc, but apparently that doesn't work. If you catch and read the boot menu it's easy enough to skip - you just pick 'Install Fedora 18' instead of 'Verify media and install Fedora 18'. But you do have to spot it. Rebooting works as well to opt out, once the check starts. With the old interactive mediacheck, that was apparently the ONLY way - see https://bugzilla.redhat.com/show_bug.cgi?id=874486#c10 . It should be easier now to opt out than it was before - with two one-keystroke options, one before the check starts and one after - but of course that depends on 874486 getting fixed. And mediacheck was the default before, with slower hardware and all. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Manual Partitioning and LVM, Re: Puzzled
On Dec 4, 2012, at 1:43 PM, Gene Czarcinski g...@czarc.net wrote: My problem is that I have a test system with almost all of the disk space pre-allocated into various partitions. There are /boot partitions on the sda disk but the remainder are in lvm. I cannot seem to be able to get to the lvm configurations. What am I missing. They are in Manual Partitioning, probably listed inside Unknown. You'll need to make sure you've manually created an LV because neither anaconda autopart or Manual Partitioning can create an LV from available VG free space. When I click on a VG that contains free space (no LVs) I get a message: This device cannot be edited directly. You can remove it or select a different device. If I have a VG with many LVs, but still has free space, I can't get anaconda to make new LVs. Chris Murphy-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: php failed to run
On Tue, 2012-12-04 at 12:49 -0800, Luya Tshimbalanga wrote: On Tue 04 Dec 2012 11:45:39 AM PST, Adam Williamson wrote: What error message do you get? Did you check if it's SELinux? (Easy way to check - 'setenforce Permissive', try again, see if it works. If it does, the correct conclusion is not 'oh well, I'll just run in permissive mode forever' but 'ah, I need to fix up the SELinux contexts'.) One of errors was apparently related to SELinux which I sent a report : https://bugzilla.redhat.com/show_bug.cgi?id=883200 After creating a policy, testing a simple phpinfo() from a local server still display blank. Setting selinux to permissive has no effect on php behaviour, I always leave Enforcing on by default. All setting are done from /etc/httpd/conf.d/ with only edited userdir. Is there something in the httpd logs which might indicate what the problem is now? That's where I'd look next. -- 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: Manual Partitioning and LVM, Re: Puzzled
On Tue, 2012-12-04 at 15:13 -0700, Chris Murphy wrote: On Dec 4, 2012, at 1:43 PM, Gene Czarcinski g...@czarc.net wrote: My problem is that I have a test system with almost all of the disk space pre-allocated into various partitions. There are /boot partitions on the sda disk but the remainder are in lvm. I cannot seem to be able to get to the lvm configurations. What am I missing. They are in Manual Partitioning, probably listed inside Unknown. You'll need to make sure you've manually created an LV because neither anaconda autopart or Manual Partitioning can create an LV from available VG free space. When I click on a VG that contains free space (no LVs) I get a message: This device cannot be edited directly. You can remove it or select a different device. If I have a VG with many LVs, but still has free space, I can't get anaconda to make new LVs. I believe this is intended to be implemented but not done yet. I'm not sure if it's expected to show up between 18 Beta and Final, or if it'll only show up in 19. Gene, as Chris says, if you have existing LVs you want to use in the F18 install, they should appear in the 'Unknown' group on the left-hand pane of custom partitioning. You can select the LV you want to use for / , and enter '/' in the 'Mount point' box on the right, then do the same for an LV you want to use for /home or /var or whatever. Then if you like you can hit 'Apply Changes' and you should see those LVs show up as the relevant partitions in the 'New Fedora 18 Beta installation' group at the top of the left-hand pane. -- 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: Manual Partitioning and LVM, Re: Puzzled
On Dec 4, 2012, at 3:13 PM, Chris Murphy li...@colorremedies.com wrote: You'll need to make sure you've manually created an LV because neither anaconda autopart or Manual Partitioning can create an LV from available VG free space. By this I mean, create the LV outside of anaconda. Slightly off topic, I'm kinda liking system-storage-manager new to F18 and installable from the live cd. yum install system-storage-manager ssm list And you'll get a listing of all devices, pools, volumes, and their mount points, better layout all in one place rather than having to go dig for info with multiple tools: fdisk, df, pvscan, lvscan, etc. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Disadvantages of offline updates
Hi, I have a couple issues with the new offline updates feature (Install Updates Restart in the GNOME Shell menu). The first issue: users can no longer review the updates before they install them. The list of updates is not shown at any step of the update process anymore for offline updates. That seems weird to me, and it's a departure from other Linux distros, as well as Windows and OS X. You *can* manually look at the list with the PackageKit GUI or yum itself, but you have to go out of your way to do that - it doesn't pop up as a notification anymore. Are there any plans to let users review these updates, or is that considered something users shouldn't see anymore? The second issue: forcing people to restart to install updates will lead to some users (like me) putting off those updates because they don't want to restart, which is insecure. Even though with the way Linux file handles work, running applications wouldn't automatically get security updates anyway, at least newly launched or restarted applications would. Logging out would work for user applications as well. Both of those are less intrusive than a restart. I know you can go to Software - Check for Updates and bypass offline updates entirely, but that's a lot less convenient than waiting for a software updates are available notification and clicking the button there. Was it deemed that increased update procrastination from users is still a worthy trade-off? Thanks. -- Brian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Sorted Blocker Display
We still have quite a few proposed blockers for F18 final and could use some more votes in bug. Instead of sending out email after email of bugs that could use voting or testing, I wrote some code to help me keep track of the bug states and display a reasonably up-to-date list of the bugs. http://tflink.fedorapeople.org/blockerbugs/sorted/sortedBlockers.html I know it's ugly, isn't awesome at detecting votes in-bug and has issues with non-ascii characters but IMHO, it works for now. I don't want to put too much effort into the code behind this because I hope we won't need it for long but I'll probably make some small improvements before F18 final is released. Proposed Blockers in Need of Testing: http://tflink.fedorapeople.org/blockerbugs/sorted/sortedBlockers.html#needs-testing Anyhow, if you have the time and inclination, please go through that list and help pick off bugs that either need testing or voting. Thanks, Tim signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: community etiquette (Re: Rename anaconda to cryptoconda?)
On 2012-12-04 09:46 (GMT-0800) Adam Williamson composed: On Tue, 2012-12-04 at 05:35 -0500, Felix Miata wrote: The results I found have been two years in the making? Yikes!!! Yes. I do keep saying this stuff is hard and encouraging you to read the design documentation and relevant blogs to understand how we got to where we are. I don't know why this is apparently so difficult. Maybe not everyone here knows why, but I refuse to believe _you_ don't. Combing docs is un-fun, made less fun by their mass, and even more so by Fedora's web doc presentation. no 'n00b' has tried it at all yet, as n00bs don't run Fedora betas. I don't know. It's often the case a n00b with a new puter wants to try Linux, does so, finds his hardware is too new to be supported by the latest release version, and gets a suggestion from a general purpose forum to try a nearing-next-release beta. Sometimes being a multibooting expert who refuses to read documentation or explanations makes things harder, not easier. :) It's really not so much refusal as un-fun impediment. Mailing list posts are _much_ more fun, because they're virtually always legible, and presented by normal humans instead of deezignerz. saying you'll only test something if it works really well appears to be putting the cart before the horse. There's only really one feature I want from Anaconda, one which doesn't seem to exist. Neither seems to exist a workaround or substitute for its absence. I won't be the only one who wants it. Looking for it in a release version would be too late, but looking for it often seems pointless. For now, yum upgrading a minimal F17 installation in order to test F18B function lets me spend more time evaluating things I can understand and less time frustrated by unfamiliar paradigms. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: community etiquette (Re: Rename anaconda to cryptoconda?)
On Tue, 2012-12-04 at 19:37 -0500, Felix Miata wrote: saying you'll only test something if it works really well appears to be putting the cart before the horse. There's only really one feature I want from Anaconda, one which doesn't seem to exist. Neither seems to exist a workaround or substitute for its absence. I won't be the only one who wants it. Looking for it in a release version would be too late, but looking for it often seems pointless. For now, yum upgrading a minimal F17 installation in order to test F18B function lets me spend more time evaluating things I can understand and less time frustrated by unfamiliar paradigms. I don't know why you'd expect a 'partition assignment only' mode to exist, given that there wasn't one in F17 and there was no indication of one in any of the design documents for newui. -- 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: community etiquette (Re: Rename anaconda to cryptoconda?)
On 2012-12-04 16:58 (GMT-0800) Adam Williamson composed: I don't know why you'd expect a 'partition assignment only' mode to exist, given that there wasn't one in F17 and there was no indication of one in any of the design documents for newui. want != expect -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Disadvantages of offline updates
On Tue, 2012-12-04 at 15:19 -0800, Brian Marshall wrote: Hi, I have a couple issues with the new offline updates feature (Install Updates Restart in the GNOME Shell menu). The first issue: users can no longer review the updates before they install them. The list of updates is not shown at any step of the update process anymore for offline updates. That seems weird to me, and it's a departure from other Linux distros, as well as Windows and OS X. You *can* manually look at the list with the PackageKit GUI or yum itself, but you have to go out of your way to do that - it doesn't pop up as a notification anymore. Are there any plans to let users review these updates, or is that considered something users shouldn't see anymore? I believe yes, this is just that it hasn't all been hooked up between packagekit-gnome and the offline update feature yet. There's a few relevant bugs - https://bugzilla.redhat.com/show_bug.cgi?id=863592 , https://bugzilla.gnome.org/show_bug.cgi?id=687149 , https://bugzilla.gnome.org/show_bug.cgi?id=683745 are entry points, I think. The second issue: forcing people to restart to install updates will lead to some users (like me) putting off those updates because they don't want to restart, which is insecure. Even though with the way Linux file handles work, running applications wouldn't automatically get security updates anyway, at least newly launched or restarted applications would. Logging out would work for user applications as well. Both of those are less intrusive than a restart. I know you can go to Software - Check for Updates and bypass offline updates entirely, but that's a lot less convenient than waiting for a software updates are available notification and clicking the button there. Was it deemed that increased update procrastination from users is still a worthy trade-off? Note that you're not 'forced' to restart to install updates - you can still do them online with yum. -- 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
libudev?
It wasn't long ago that I had to change several program to use libudev instead of libhal. Now in fedora 18 it says there is no libudev? What the heck is the flavor of the month now for querying hardware and how much different is it than libudev? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Disadvantages of offline updates
On Tue, Dec 04, 2012 at 05:04:34PM -0800, Adam Williamson wrote: On Tue, 2012-12-04 at 15:19 -0800, Brian Marshall wrote: Hi, I have a couple issues with the new offline updates feature (Install Updates Restart in the GNOME Shell menu). The first issue: users can no longer review the updates before they install them. The list of updates is not shown at any step of the update process anymore for offline updates. That seems weird to me, and it's a departure from other Linux distros, as well as Windows and OS X. You *can* manually look at the list with the PackageKit GUI or yum itself, but you have to go out of your way to do that - it doesn't pop up as a notification anymore. Are there any plans to let users review these updates, or is that considered something users shouldn't see anymore? I believe yes, this is just that it hasn't all been hooked up between packagekit-gnome and the offline update feature yet. There's a few relevant bugs - https://bugzilla.redhat.com/show_bug.cgi?id=863592 , https://bugzilla.gnome.org/show_bug.cgi?id=687149 , https://bugzilla.gnome.org/show_bug.cgi?id=683745 are entry points, I think. That's good to hear, thanks for the links. The second issue: forcing people to restart to install updates will lead to some users (like me) putting off those updates because they don't want to restart, which is insecure. Even though with the way Linux file handles work, running applications wouldn't automatically get security updates anyway, at least newly launched or restarted applications would. Logging out would work for user applications as well. Both of those are less intrusive than a restart. I know you can go to Software - Check for Updates and bypass offline updates entirely, but that's a lot less convenient than waiting for a software updates are available notification and clicking the button there. Was it deemed that increased update procrastination from users is still a worthy trade-off? Note that you're not 'forced' to restart to install updates - you can still do them online with yum. Indeed, sorry if I implied that. I know that you can bypass it manually - I meant that since I didn't receive a Shell notification, the default way to install most updates seems to be to use the update restart menu item. Although, after reading those GNOME bugs, is not receiving a notification a bug on its own? I haven't seen an updates available notification since I installed the F18 beta last week. -- Brian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Disadvantages of offline updates
On Tue, 2012-12-04 at 17:58 -0800, Brian Marshall wrote: Although, after reading those GNOME bugs, is not receiving a notification a bug on its own? I haven't seen an updates available notification since I installed the F18 beta last week. I'm not sure the current status. When I filed my bug, which was a bit pre-Beta, I was getting notifications, obviously (the bug being that clicking on them triggered an online update). I can't say I've noticed any lately, but I don't know if that means there aren't any or I just forgot about them, or if it's intentional or a bug... -- 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: libudev?
On Tue, 2012-12-04 at 20:55 -0500, Tom Horsley wrote: It wasn't long ago that I had to change several program to use libudev instead of libhal. Now in fedora 18 it says there is no libudev? What the heck is the flavor of the month now for querying hardware and how much different is it than libudev? [adamw@adam tmp]$ rpm -qf /usr/lib64/libudev.so.1 systemd-libs-195-8.fc18.x86_64 -- 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: Anaconda Accolades
On Tue, Dec 04, 2012 at 01:53:21PM -0500, Scott Robbins wrote: On Tue, Dec 04, 2012 at 10:14:59AM -0800, Adam Williamson wrote: (Hrrm, the Archer episode, where he and Lana are going to become human prey, comes to mind. When the villain says to go, Archer pushes Lana to the ground to get a head start--she shouts, Archer, are you really that self-centered? He shouts back, Apparently.) MANY POINTS FOR ARCHER Oops, she said selfish, not self-centered. For Archer fans... http://www.scottro.net/selfish.mp4 -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Buffy: Are you crazy? You just don't sneak up on people in a graveyard. You make noise when you walk, you stomp, or... yodel. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] 2012-12-05 @ 17:00 UTC - F18 Final Blocker Bug Review #2
# F18 Final Blocker Review meeting #2 # Date: 2012-12-05 # Time: 17:00 UTC (12:00 EST, 09:00 PST) # Location: #fedora-bugzappers on irc.freenode.net We're still working to get the proposed blocker list down to something manageable, so it would be time for another blocker review meeting! Note the IRC channel change - doing the blocker meeting in #fedora-qa is far too disruptive to other testing work that goes on. We'll be running through the final blockers and nice-to-haves. The current list of blocker bugs is available at: http://qa.fedoraproject.org/blockerbugs/current Since there are quite a few proposed blockers yet, we'll be focusing on the ones that I've already identified as needing discussion: http://tflink.fedorapeople.org/blockerbugs/sorted/sortedBlockers.html#needs-discussion We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Disadvantages of offline updates
On Tue, 2012-12-04 at 18:11 -0800, Adam Williamson wrote: On Tue, 2012-12-04 at 17:58 -0800, Brian Marshall wrote: Although, after reading those GNOME bugs, is not receiving a notification a bug on its own? I haven't seen an updates available notification since I installed the F18 beta last week. I'm not sure the current status. When I filed my bug, which was a bit pre-Beta, I was getting notifications, obviously (the bug being that clicking on them triggered an online update). I can't say I've noticed any lately, but I don't know if that means there aren't any or I just forgot about them, or if it's intentional or a bug... We are only showing a notification about 'important' updates - which are currently defined as security updates. And there's another inconsistency there in that the notification lets you launch the update viewer, which lets you review the updates and install them 'online' - the opposite of what you get for regular updates. So yes, the user experience is not as consistent as we want it to, yet. I think Adam already pointed to the relevant upstream bugs. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Disadvantages of offline updates
On Tue, Dec 04, 2012 at 11:12:22PM -0500, Matthias Clasen wrote: On Tue, 2012-12-04 at 18:11 -0800, Adam Williamson wrote: I'm not sure the current status. When I filed my bug, which was a bit pre-Beta, I was getting notifications, obviously (the bug being that clicking on them triggered an online update). I can't say I've noticed any lately, but I don't know if that means there aren't any or I just forgot about them, or if it's intentional or a bug... We are only showing a notification about 'important' updates - which are currently defined as security updates. And there's another inconsistency there in that the notification lets you launch the update viewer, which lets you review the updates and install them 'online' - the opposite of what you get for regular updates. So yes, the user experience is not as consistent as we want it to, yet. I think Adam already pointed to the relevant upstream bugs. Thanks for the explanation. I think it'd be best if the user was given an opportunity to review updates for every time the Install Updates Restart menu item exists. That could involve showing a notification for every type of update (which might be too much), although am I right in thinking that the minimum time between showing notifications is longer than the minimum time between auto-downloading updates? If so, you'd still run into cases where the install updates menu item is available but you haven't gotten a notification yet. Another solution could be to change the menu item so it opens the update application and lets you review the updates there, with a button to install and restart. (Basically the equivalent of an update notification with View, but integrated into the Shell user menu.) That would add an extra step to people who don't want to review their updates, but would remove several steps from people who do. I think that last solution would solve the issue of my current workflow: 1. See updates can be installed in the menu 2. Switch to Activities mode 3. Open Software (gpk-application) 4. App menu - Check for Updates 5. Quit the application after reviewing updates 6. Go back to Shell menu to install them offline ...which seems overly complicated, unless I'm missing something. -- Brian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: f18: Quick switching between gnome-shell desktop and some tty1 lets my box freeze
On 12/04/2012 08:00 PM, Michael Schwendt wrote: On Tue, 04 Dec 2012 07:38:10 +0100, Joachim Backes wrote: Hi all, I'm using kernel-3.6.9-1.fc18.x86_64 and a fully updated f18. Problem: If I switch bewteen the gnome-shell desktop and some tty (ctrl+alt+Fn) rather quickly, then it happens very often that after some time my box freezes if switching back from that tty to the gnome-shell desktop. Anybody has seen this too? Well, I just gave it a try and lost this session. ;) Arrived at the virtual console, switched back to X, but screen turnt black, monitor lost signal and entered power-saving mode. System didn't respond anymore. ATI Radeon. Hi Michael, exactly the same problem with my ATI Radeon 5450. Thank you for your comment. I will file a BZ! Kind regards Joachim Backes joachim.bac...@rhrk.uni-kl.de https://www-user.rhrk.uni-kl.de/~backes PGP key ID: 0x1BB12F9E -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: php failed to run
On Tue, 2012-12-04 at 19:20 -0800, Luya Tshimbalanga wrote: [Mon Dec 03 17:16:52.319181 2012] [autoindex:error] [pid 5233] [client 127.0.0.1:38664] AH01276: Cannot serve directory /var/www/html/: No matching DirectoryIndex (index.html,index.php) found, and server-generated directory index forbidden by Options directive I'm guessing that's the problem? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: php failed to run
On Tue 04 Dec 2012 09:17:03 PM PST, Adam Williamson wrote: On Tue, 2012-12-04 at 19:20 -0800, Luya Tshimbalanga wrote: [Mon Dec 03 17:16:52.319181 2012] [autoindex:error] [pid 5233] [client 127.0.0.1:38664] AH01276: Cannot serve directory /var/www/html/: No matching DirectoryIndex (index.html,index.php) found, and server-generated directory index forbidden by Options directive I'm guessing that's the problem? IIRunning index.php inside /var/www./html works fine, still does not resolve ~/public_html I am investigating. -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.thefinalzone.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Manual Partitioning and LVM, Re: Puzzled
On 12/04/2012 05:37 PM, Adam Williamson wrote: On Tue, 2012-12-04 at 15:13 -0700, Chris Murphy wrote: On Dec 4, 2012, at 1:43 PM, Gene Czarcinski g...@czarc.net wrote: My problem is that I have a test system with almost all of the disk space pre-allocated into various partitions. There are /boot partitions on the sda disk but the remainder are in lvm. I cannot seem to be able to get to the lvm configurations. What am I missing. They are in Manual Partitioning, probably listed inside Unknown. You'll need to make sure you've manually created an LV because neither anaconda autopart or Manual Partitioning can create an LV from available VG free space. When I click on a VG that contains free space (no LVs) I get a message: This device cannot be edited directly. You can remove it or select a different device. If I have a VG with many LVs, but still has free space, I can't get anaconda to make new LVs. I believe this is intended to be implemented but not done yet. I'm not sure if it's expected to show up between 18 Beta and Final, or if it'll only show up in 19. Gene, as Chris says, if you have existing LVs you want to use in the F18 install, they should appear in the 'Unknown' group on the left-hand pane of custom partitioning. You can select the LV you want to use for / , and enter '/' in the 'Mount point' box on the right, then do the same for an LV you want to use for /home or /var or whatever. Then if you like you can hit 'Apply Changes' and you should see those LVs show up as the relevant partitions in the 'New Fedora 18 Beta installation' group at the top of the left-hand pane. I am not sure how things are suppose to work but I do not see ANY LVs There are regular old partitions which I can use for /boot but all of the rest of my disk space is in PVs. IMO, the whole way storage is being handled in F18 needs to be rethought! Guessing how to do something should never happen. Can someone point me to some documentation which describes (and maybe has some pictures) how to do manual allocation using pre-defined LVM partitions? I sure hope the fedup [boy oh boy, this sure seems to be an appropriately named package] works because that may be the only way to install F18 as far as I am concerned. BTW, I am no happy about software selection either but I can live it that. The current dusk configuration stuff, no I will not be using it. And, I am not blaming the developers here. They are trying their best. I do hold F18 leadership responsible! Gene -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 16 updates-testing report
The following Fedora 16 Security updates need testing: Age URL 74 https://admin.fedoraproject.org/updates/FEDORA-2012-14452/bacula-5.0.3-33.fc16 2 https://admin.fedoraproject.org/updates/FEDORA-2012-19538/weechat-0.3.9.2-2.fc16 47 https://admin.fedoraproject.org/updates/FEDORA-2012-16415/389-ds-base-1.2.10.16-1.fc16 31 https://admin.fedoraproject.org/updates/FEDORA-2012-17553/libproxy-0.4.10-1.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-19267/plexus-cipher-1.5-11.fc16 0 https://admin.fedoraproject.org/updates/FEDORA-2012-19347/cups-1.5.4-10.fc16 152 https://admin.fedoraproject.org/updates/FEDORA-2012-10314/revelation-0.4.14-1.fc16 72 https://admin.fedoraproject.org/updates/FEDORA-2012-14654/tor-0.2.2.39-1600.fc16 11 https://admin.fedoraproject.org/updates/FEDORA-2012-18927/cups-pk-helper-0.1.3-4.fc16 53 https://admin.fedoraproject.org/updates/FEDORA-2012-16032/cobbler-2.4.0-beta2.fc16 14 https://admin.fedoraproject.org/updates/FEDORA-2012-18687/libssh-0.5.3-1.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-19227/squashfs-tools-4.2-5.fc16 3 https://admin.fedoraproject.org/updates/FEDORA-2012-19449/drupal6-ctools-1.10-1.fc16 35 https://admin.fedoraproject.org/updates/FEDORA-2012-17291/thunderbird-16.0.2-1.fc16 3 https://admin.fedoraproject.org/updates/FEDORA-2012-19455/php-symfony2-HttpFoundation-2.0.19-1.fc16 0 https://admin.fedoraproject.org/updates/FEDORA-2012-19715/qt-4.8.4-1.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-18330/perl-CGI-3.52-203.fc16,perl-5.14.3-203.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-19195/php-symfony-symfony-1.4.20-2.fc16 0 https://admin.fedoraproject.org/updates/FEDORA-2012-19740/bogofilter-1.2.3-1.fc16 0 https://admin.fedoraproject.org/updates/FEDORA-2012-19750/kernel-3.6.9-2.fc16 0 https://admin.fedoraproject.org/updates/FEDORA-2012-19752/dovecot-2.0.21-4.fc16 14 https://admin.fedoraproject.org/updates/FEDORA-2012-18661/firefox-17.0-1.fc16,xulrunner-17.0-3.fc16,thunderbird-enigmail-1.4.6-2.fc16,thunderbird-lightning-1.9-1.fc16,thunderbird-17.0-1.fc16 The following Fedora 16 Critical Path updates have yet to be approved: Age URL 0 https://admin.fedoraproject.org/updates/FEDORA-2012-19750/kernel-3.6.9-2.fc16 0 https://admin.fedoraproject.org/updates/FEDORA-2012-19715/qt-4.8.4-1.fc16 3 https://admin.fedoraproject.org/updates/FEDORA-2012-19471/xulrunner-17.0.1-1.fc16,firefox-17.0.1-1.fc16 3 https://admin.fedoraproject.org/updates/FEDORA-2012-19486/phonon-backend-gstreamer-4.6.2-2.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-19265/lxpanel-0.5.10-3.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-19227/squashfs-tools-4.2-5.fc16 11 https://admin.fedoraproject.org/updates/FEDORA-2012-18927/cups-pk-helper-0.1.3-4.fc16 12 https://admin.fedoraproject.org/updates/FEDORA-2012-18857/koji-1.7.1-1.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-18330/perl-CGI-3.52-203.fc16,perl-5.14.3-203.fc16 The following builds have been pushed to Fedora 16 updates-testing bogofilter-1.2.3-1.fc16 clamtk-4.43-1.fc16 cups-1.5.4-10.fc16 dovecot-2.0.21-4.fc16 drupal7-views_bulk_operations-3.1-3.fc16 fedora-packager-0.5.10.1-1.fc16 htop-1.0.2-1.fc16 ibus-table-chinese-1.4.6-1.fc16 imsettings-1.2.9-4.fc16 kernel-3.6.9-2.fc16 libmate-1.4.0-17.fc16 libmatecanvas-1.4.0-8.fc16 libmatecomponent-1.4.0-14.fc16 libnetfilter_conntrack-1.0.2-1.fc16 libnetfilter_queue-1.0.2-1.fc16 libnfnetlink-1.0.1-1.fc16 mate-conf-1.4.0-21.fc16 mate-desktop-1.5.5-1.fc16 mate-file-manager-1.5.2-1.fc16 mate-media-1.5.0-1.fc16 mate-panel-1.5.2-4.fc16 mate-settings-daemon-1.5.4-1.fc16 mawk-1.3.4-20121129.1.fc16 nagios-3.4.3-1.fc16 opendkim-2.7.3-2.fc16 perl-Text-CSV_XS-0.82-3.fc16 python-inotify-0.9.4-1.fc16 qt-4.8.4-1.fc16 rubygem-bunny-0.7.9-2.fc16 rubygem-scoped_search-2.4.0-5.fc16 seamonkey-2.14.1-1.fc16 Details about builds: bogofilter-1.2.3-1.fc16 (FEDORA-2012-19740) Fast anti-spam filtering by Bayesian statistical analysis Update Information: updated to 1.2.3 (fixes #883358, CVE-2012-5468) ChangeLog: * Tue Dec 4 2012 Adrian Reber adr...@lisas.de - 1.2.3-1 - updated to 1.2.3 (fixes #883358, CVE-2012-5468) * Thu Jul 26 2012 Adrian Reber adr...@lisas.de - 1.2.2-5 - add new libdb4 include path to configure options * Wed Jul 18 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.2.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Thu Jan 12 2012 Fedora Release Engineering
Re: Manual Partitioning and LVM, Re: Puzzled
On Wed, 2012-12-05 at 01:52 -0500, Gene Czarcinski wrote: I am not sure how things are suppose to work but I do not see ANY LVs There are regular old partitions which I can use for /boot but all of the rest of my disk space is in PVs. IMO, the whole way storage is being handled in F18 needs to be rethought! Guessing how to do something should never happen. Well, your mail rather gave the impression you wanted to re-use existing LVs as backing for the F18 mount points. If that's not the case, obviously the instructions we gave you don't apply. Can someone point me to some documentation which describes (and maybe has some pictures) how to do manual allocation using pre-defined LVM partitions? We are trying to help you here, but it's not easy, as you aren't explaining what it is you want to do exactly very well. So to clarify, you have existing PVs but no LVs, and you want to create new LVs? -- 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: Manual Partitioning and LVM, Re: Puzzled
On Dec 4, 2012, at 11:52 PM, Gene Czarcinski g...@czarc.net wrote: I am not sure how things are suppose to work but I do not see ANY LVs In Manual Partitioning, on the left side, you do not have an +Unknown listing located under -New Fedora 18 Installation? Or there are no LV's listed? There are regular old partitions which I can use for /boot but all of the rest of my disk space is in PVs. What do you get for pvscan and lvscan? Are there inactive LVs? IMO, the whole way storage is being handled in F18 needs to be rethought! Guessing how to do something should never happen. I agree. But I think in your case the trail is leading to a bug not flawed design. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
