Re: kernel headers - Now a BIGGER Issue
On Mon, 2013-01-14 at 09:16 -0700, Christopher A Williams wrote: > O > n Mon, 2013-01-14 at 09:20 -0600, Justin M. Forbes wrote: > > > > > > > > ...And because of the way Workstation 9.0.1 is trying to deal with it, I > > > believe this now falls squarely back on the Fedora team to look at and > > > resolve. You can't blame Workstation or its licensing model - don't even > > > start. > > > > > > > The UAPI changes are upstream starting with 3.7 kernels, and won't be going > > away. VMWare should fix their build scripts at some point, everyone else > > seems to have figured it out early in the RC phase of 3.7. There is nothing > > Fedora specific about this. We aren't doing anything wonky. > > OK, so you're not doing anything unusual with the kernel. Fine. But I > doubt everyone else has figured this out in the 3.7 RC series. > > That said, I am pointing this out within VMware circles as well. I don't > really have the cycles to go poking through everyone's scripts right now > (else I would have already). After some digging tonight, I found the appropriate work-around to get this going on the current 3.7 kernel. Ironically, the statement "The UAPI changes are upstream..." tipped me off. The correct symlink command for the current 3.7 kernel is: ln -s /usr/src/kernels/3.7.2-201.fc18.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.2-201.fc18.x86_64/include/linux/version.h When new kernel versions come out, this will need to be modified again until VMware patches their scripts to handle the UAPI changes. Once this symlink is done, Workstation 9.0.1 runs as it should. Chris -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel headers - Now a BIGGER Issue
O n Mon, 2013-01-14 at 09:20 -0600, Justin M. Forbes wrote: > > > > > ...And because of the way Workstation 9.0.1 is trying to deal with it, I > > believe this now falls squarely back on the Fedora team to look at and > > resolve. You can't blame Workstation or its licensing model - don't even > > start. > > > > The UAPI changes are upstream starting with 3.7 kernels, and won't be going > away. VMWare should fix their build scripts at some point, everyone else > seems to have figured it out early in the RC phase of 3.7. There is nothing > Fedora specific about this. We aren't doing anything wonky. OK, so you're not doing anything unusual with the kernel. Fine. But I doubt everyone else has figured this out in the 3.7 RC series. That said, I am pointing this out within VMware circles as well. I don't really have the cycles to go poking through everyone's scripts right now (else I would have already). Chris -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel headers - Now a BIGGER Issue
On Sun, 2013-01-13 at 07:49 -0800, Tom London wrote: -- Christopher A Williams > > found in: > > > > /usr/src/kernels/3.6.11-3.fc18.x86_64/include/linux > > > > Put that all together and I suspect that the actual issue isn't so much > > the different tree structure - it's consistent on F18 between the 3.6 > > and 3.7 series kernels. Rather, something has changed in the > > updates-testing kernel package which is causing the Workstation scripts > > to not be able to properly traverse the tree to find what they need. > > > > Hope that makes sense! As mentioned, I believe an appropriate symlink > > will provide a work-around, but we should look at both the development > > packages and the workstation scripts to evaluate where the most > > appropriate fix should go. I'm sure this won't be the only package that > > has this issue. > > > > Unfortunately, since I'm getting on another airplane today, I won't have > > much more opportunity to look at this for a while. Hopefully someone > > else will be able to pick things up from here... > > > > Chris > > > > -- > > Christopher A. Williams > > > > Not sure this helps, but: > > [root@tlondon ~]# locate /usr/\*/linux/version.h > /usr/include/linux/version.h > /usr/src/kernels/3.8.0-0.rc2.git3.1.fc19.x86_64/include/generated/uapi/linux/version.h > /usr/src/kernels/3.8.0-0.rc2.git4.2.local.fc19.x86_64/include/generated/uapi/linux/version.h > /usr/src/kernels/3.8.0-0.rc2.git4.2.local2.fc19.x86_64/include/generated/uapi/linux/version.h > /usr/src/kernels/3.8.0-0.rc3.git0.3.local.fc19.x86_64/include/generated/uapi/linux/version.h > [root@tlondon ~]# > [root@tlondon ~]# ls -l $(locate /usr/\*/linux/version.h) > -rw-r--r--. 1 root root 97 Jan 11 10:40 /usr/include/linux/version.h > -rw-r--r--. 4 root root 97 Jan 7 15:25 > /usr/src/kernels/3.8.0-0.rc2.git3.1.fc19.x86_64/include/generated/uapi/linux/version.h > -rw-r--r--. 4 root root 97 Jan 7 15:25 > /usr/src/kernels/3.8.0-0.rc2.git4.2.local2.fc19.x86_64/include/generated/uapi/linux/version.h > -rw-r--r--. 4 root root 97 Jan 7 15:25 > /usr/src/kernels/3.8.0-0.rc2.git4.2.local.fc19.x86_64/include/generated/uapi/linux/version.h > -rw-r--r--. 4 root root 97 Jan 7 15:25 > /usr/src/kernels/3.8.0-0.rc3.git0.3.local.fc19.x86_64/include/generated/uapi/linux/version.h > [root@tlondon ~]# OK - Thanks for extra info. I'm now in a situation where I must do something. The latest kernel update came through this morning and we now have the kernel 3.7 headers problem with Workstation hitting the branched repo as opposed to the updates-testing repo. ...And because of the way Workstation 9.0.1 is trying to deal with it, I believe this now falls squarely back on the Fedora team to look at and resolve. You can't blame Workstation or its licensing model - don't even start. The update to kernel 3.7.2-201.fc18.x86_64 has the same kernel headers problem. Except Workstation comes back with a specific error message saying that it cannot find the header files. It then specifically asks for the location of the header files. it even gives you a nic file picker that's defaulting to the directory /usr/src/kernels for you to start looking. Giving it the location /usr/src/kernels/3.7.2-201.fc18.x86_64 doesn't work. I'm assuming this is the correct location for the kernel header files. Since Workstation is clearly allowing you to specify the location of the header files and still can't find them, something with the new kernel 3.7 is, in my opinion, broken. Can we please have a look at this? I will BZ as necessary... Chris -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel headers
On Sat, 2013-01-12 at 19:32 -0700, Christopher A. Williams wrote: > ...Looked again at this. It's actually not quite what's needed. It says > to make a symbolic link from: > > /usr/src/linux-3.7/include/generated/uapi/linux/version.h > > to > > /usr/src/linux-3.7/include/linux/version.h > > only problem is that this first directory doesn't exist in Fedora from > what I can see. the file is actually located in: > > /usr/src/kernels//include/linux/version.h > > Is this a departure in Fedora from the stock kernel 3.7 series? I'll bet > this is really messing with VMware's scripts if it is. Since I am not > running Kernel 3.7 at the moment and don't have time to do so now, we'll > need someone else to have a look at this. I'm sure it's probably an easy > fix. More info from Lawrence Graves (apologize for the cross-post in threads, but I thought it was important to keep this on the initial thread...) this is the results of trying to apply the fix to kernel headers problem I am experiencing. [root@Jehovah ~]# ln -s /usr/src/linux-3.7/include/generated/uapi/linux/version.h /usr/src/linux-3.7/include/linux/version.h ln: failed to create symbolic link ‘/usr/src/linux-3.7/include/linux/version.h’: No such file or directory [root@Jehovah ~]# vmware-modconfig --console --install-all gcc and kernel headers must be installed [root@Jehovah ~]# ln /usr/src/linux-3.7/include/generated/uapi/linux/version.h /usr/src/linux-3.7/include/linux/version.h ln: accessing ‘/usr/src/linux-3.7/include/generated/uapi/linux/version.h’: No such file or directory [root@Jehovah ~]# ln -s /usr/src/linux-3.7/include/generated/uapi/linux/version.h /usr/src/linux-3.7/include/linux/version.h ln: failed to create symbolic link ‘/usr/src/linux-3.7/include/linux/version.h’: No such file or directory This confirms what I was reporting before. The referenced directory structure reported as a kernel 3.7 fix will not work with the current 3.7 series kernel in updates-testing. Combine this with that Workstation works fine on the 3.6 series kernel using the same overall directory structure leads me to that the symlink needs to be adjusted to fit the F18 kernel development directory tree, at least as a temporary work-around. Also note that the appropriate version.h file for kernel 3.6 is indeed found in: /usr/src/kernels/3.6.11-3.fc18.x86_64/include/linux Put that all together and I suspect that the actual issue isn't so much the different tree structure - it's consistent on F18 between the 3.6 and 3.7 series kernels. Rather, something has changed in the updates-testing kernel package which is causing the Workstation scripts to not be able to properly traverse the tree to find what they need. Hope that makes sense! As mentioned, I believe an appropriate symlink will provide a work-around, but we should look at both the development packages and the workstation scripts to evaluate where the most appropriate fix should go. I'm sure this won't be the only package that has this issue. Unfortunately, since I'm getting on another airplane today, I won't have much more opportunity to look at this for a while. Hopefully someone else will be able to pick things up from here... Chris -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel headers
On Sat, 2013-01-12 at 09:23 -0700, Christopher A. Williams wrote: > On Sat, 2013-01-12 at 15:26 +, Frank Murphy wrote: > > On Sat, 12 Jan 2013 07:56:40 -0700 > > "Christopher A. Williams" wrote: > > > > > > http://slackblogs.blogspot.ie/2012/12/linux-kernel-37-vmware-workstation-and.html > > thank the great God Google, > > now why didn't I think of that ;) > > Now why didn't I try _that_ search string... > > Ask Google the right question and you get amazing results. ;-) ...Looked again at this. It's actually not quite what's needed. It says to make a symbolic link from: /usr/src/linux-3.7/include/generated/uapi/linux/version.h to /usr/src/linux-3.7/include/linux/version.h only problem is that this first directory doesn't exist in Fedora from what I can see. the file is actually located in: /usr/src/kernels//include/linux/version.h Is this a departure in Fedora from the stock kernel 3.7 series? I'll bet this is really messing with VMware's scripts if it is. Since I am not running Kernel 3.7 at the moment and don't have time to do so now, we'll need someone else to have a look at this. I'm sure it's probably an easy fix. Chris -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel headers
On Sat, 2013-01-12 at 15:26 +, Frank Murphy wrote: > On Sat, 12 Jan 2013 07:56:40 -0700 > "Christopher A. Williams" wrote: > > > http://slackblogs.blogspot.ie/2012/12/linux-kernel-37-vmware-workstation-and.html > thank the great God Google, > now why didn't I think of that ;) Now why didn't I try _that_ search string... Ask Google the right question and you get amazing results. ;-) Chris -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel headers
On Sat, 2013-01-12 at 15:26 +, "Jóhann B. Guðmundsson" wrote: > On 01/12/2013 02:56 PM, Christopher A. Williams wrote: > > On Sat, 2013-01-12 at 07:26 -0500, Scott Robbins wrote: > >> On Sat, Jan 12, 2013 at 05:09:41AM -0700, Lawrence Graves wrote: > > .. > > > ... > Aren't you just experiencing that broken vmware scripts which cant find > the relocated version.h in the 3.7 series kernels ? > > And that's simply solved by running "ln -s > /usr/src/linux-3.7-X/include/generated/uapi/linux/version.h > /usr/src/linux-3.7-X/include/linux/version.h" Probably. I didn't have much time to really dig into it at the time and it wouldn't surprise me at all if it wasn't something as simple as that. When I looked, a lot of the stuff showing up on Google now wasn't there and I've been riding a lot of airplanes lately. I'll tell Graves (OP) to try this and get back to us. Chris -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel headers
On Sat, 2013-01-12 at 10:29 -0500, Matthew Miller wrote: > On Sat, Jan 12, 2013 at 07:56:40AM -0700, Christopher A. Williams wrote: > > On Sat, 2013-01-12 at 07:26 -0500, Scott Robbins wrote: > > VMware Workstation for my work (some things needed for my job require > > Windows - arrgh!!!), I had to roll back to the 3.6 kernel. Currently, I > > Any particular reason not to use KVM? Save you some headache. Yes. Actually I do also play around with KVM and a ton of other hypervisors. But I get Workstation basically for free as well. Call it a fringe benefit of having a VCP, VCAP-DCA, and a VCAP-DCD, while leading a rather large Cloud infrastructure practice that specializes in virtualizing business critical applications (aka VBCA) :-) Workstation also works very nicely with all of my vSphere systems that I have to take care of as well. And, to be fair, trading out Workstation for KVM is trading one set of headaches for another. Voice of experience on that one... Chris PS: If you want to know more about VBCA stuff, just Google "Cognizant VBCA" and look for the video VMware posted of me. I'll be teaching the Oracle virtualization course next month at the VBCA Boot Camp at Partner Exchange. Look me up if you're going. -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel headers
On Sat, 2013-01-12 at 07:26 -0500, Scott Robbins wrote: > On Sat, Jan 12, 2013 at 05:09:41AM -0700, Lawrence Graves wrote: > > what the error message says is that it could not find the kernel headers for > > kernel 3.7.1-5. I know that they were installed. So where are the kernel > > header > > file if in fact it was installed. > > Usually, if VMware can't find kernel-headers, you need the kernel-devel > package. > > The kernel-devel package number has to match the result of uname -r. What > I frequently see on the forums is that someone updated, got a newer package > of kernel-devel, but hasn't rebooted, so there will be a version mismatch. > > Also, if running a PAE kernel, one has to specify kernel-PAE-devel. (Which > doesn't seem relevant in your case). Actually, in this case, the kernel-headers and kernel-devel packages are installed. Further, this appears to only happen with the 3.7 series of the kernel. I know this because I was having the same problem and, because I need VMware Workstation for my work (some things needed for my job require Windows - arrgh!!!), I had to roll back to the 3.6 kernel. Currently, I can confirm that VMware Workstation 9.0.1 is working with kernel version 3.6.11-3.fc18.x86_64 - and is working with that kernel unmodified (no patches from VMware needed). Now, I don't recall the exact error message with kernel 3.7 because I reverted back to the 3.6 series (via yum distro-sync), but VMware Workstation 9.0.1 clearly is having trouble finding the kernel headers and other associated components with the 3.7 series of the kernel that is in the updates-testing repository. So, what that means is that something with respect to where the header files are placed and located between these two series of kernels has been changed to the point that applications like VMware Workstaion can no longer find them. I would need to go back to the 3.7 series kernel to get the exact error message. I may have it in an old VMware log file, so I'll check that too next chance. In my case, I'm running the 64-bit kernel, so there's no PAE stuff to worry about. I know that's not all of the information people are asking for, but hopefully it does shed some additional light on the situation... Cheers, Chris -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Blocker Tracking App Reskin - Feedback on New Mockups
On Wed, 2012-09-12 at 08:18 -0600, Tim Flink wrote: > On Wed, 12 Sep 2012 04:33:57 -0400 (EDT) > Kamil Paral wrote: > > > > The two mockups that I'm looking at right now (identical other than > > > the table column ordering) are: > > > http://tflink.fedorapeople.org/blockerbugs/reskin-draft3/blockers-3.html > > > http://tflink.fedorapeople.org/blockerbugs/reskin-draft3/blockers.html > > > > Tim, I love it! > > > > The first way of column ordering seems better to me. > > I've been going back and forth between the two column layouts - one > follows the idea that the primary key (bug_id) is on the far right and > the second most important key (status, changed indicator, update info) > is on the far right to make scanning the table easier for either the > primary or secondary key. FWIW, having the status key on the far right seemed a little more natural to me in terms of scanning. It implies an order of 1) what am I looking at, 2)what's the high-level detail I need to know about it, and 3) what's the status. The other column order winds up splitting the description between two status oriented columns. But I really like the look regardless. Just my 2 cents worth... Hope it's helpful! Chris -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: will F18 allow simultaneous installation of more than one desktop?
ironment, great. Install it > some way other than in anaconda's GUI. I also provided two alternatives > very early on in this discussion: use kickstart for install or use the > package manager of your choice, post-install. I said this in my first or > second post on this subject. I should have ignored the follow-ups. > Hopefully next time I will. I didn't miss these alternatives, but rather took issue with them. The issue is that both of these alternatives increase the level of inconvenience (time and effort) for installing multiple DEs, and this change in the installer as implemented leads to a loss of function that is clearly being used by at least some. Whenever you advocate taking away function that others are using, especially when positioning it as an upgrade or enhancement, you will always get push-back. That will be true no matter how strongly (right or wrong) you believe that function needs to be taken away. Again, if that is a short-term sacrifice for the sake of consistency, OK. I would still advocate that the base libraries for at least GNOME and KDE should still be installed so that applications from each DE are not limited in the same way up front. Most folks use apps from both today, and F17 still has at least some KDE apps available by default even if you only install GNOME. I doubt that's going to change anytime soon since, as others have pointed out, best of breed apps come from both DEs. ...And thanks for being a stand-up guy about all this in the end. Chris -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: will F18 allow simultaneous installation of more than one desktop?
On Mon, 2012-07-09 at 12:49 -0500, David Lehman wrote: > On Mon, 2012-07-09 at 11:23 -0600, Christopher A. Williams wrote: > > On Mon, 2012-07-09 at 11:52 -0500, David Lehman wrote: > > > > Exactly what is so bad with "that practice" (of installing both > > > > desktops) as to "frown upon it"? > > > > > > > > I am a KDE user and yet I still install Gnome on my machine. Exactly > > > > what crime do I commit? > > > > > > Only being unwilling to choose a camp. Not even a crime, really. > > > > And choosing a camp is good? Not choosing a camp or deciding to remain > > flexible is bad? Not really. > > I didn't say flexible is bad. What I am saying is that flexible is > _hard_ (for those of us doing the work). Hard is not necessarily bad, > either, but at some point one must begin to choose one's battles. So... Lots of stuff is hard. But it's also worth it. We don't achieve excellence by taking the simple route. I do really hard stuff both in my job and on my own time as a volunteer most every day. > > > > I am another _real_ data point showing that Fedora users actually do > > > > that (that = install both > > > > desktops to have access to packages from both of them). > > > > > > There are plenty of very vocal minority groups here. > > > > Please show researched statistics to support your claim and implication > > that this is a minority group. I question and doubt you actually have > > statistics on any of these groups. > > Too busy trying to actually do work, but thanks for offering to help. Nice try. I didn't offer to help on this one. You alleged something as a point without anything to back it up. I just asked you to back up what you're saying. If you can't do that, it's not my problem. It just means I'm winning on this part of the argument. > > > I can tell you from personal experience that Fedora has both real and > > > imaginary idiots. Just kidding. We have two opposing groups of users: > > > Those who think the installer should have a knob for whatever their > > > obscure pet option is, and those who believe it should be a > > > highly-polished, streamlined interface along the lines of MacOS. These > > > are fundamentally in opposition and it is impossible to please both > > > camps entirely. > > > > ...Wow - Talk about spin. Only something that's highly polished and > > streamlined like MacOS...? > > I don't have time to sit with you all day picking the fly shit out of > the pepper. You should stop making assumptions and take a look at the UI > before continuing to try and dictate its design from afar. Must be getting you you since you're now resorting to ...umm "colorful" language. I guess you missed the part where I have been contributing in one way or another to Fedora since its start (and RHL before that). While I'm not a coder, I do understand a lot more about this than you want to imply. > > > > Simple is not a requirement for highly polished, and neither simple nor > > streamlined should prevent flexibility in options. Besides, if you > > really want to emulate MacOS like that, why not just go buy a Mac? > > > > I would submit there is a group who wants something highly polished, > > with flexibility and the ability to easily control finer points of the > > process along the way. None of these traits necessarily precludes the > > others. Is that really too much to ask for? > > No, of course not. We'll attain UI perfection while simultaneously > arguing with you about it. Have you even looked at the UI we're working > on? Read the blog posts about what we're doing? ...Well, actually... Yes I have, and I keep up on things quite regularly. I just don't always chime in on things unless I clearly see something truly problematic and have the cycles to engage on it. > Just because I failed to spoonfeed you the entire essence of several > man-years of work in a short email doesn't mean you're ahead of the game > here. Only several man-years? I was in Redomond a couple of weeks ago review just the update to System Center 2012 and Hyper-V Windows Server 2008 (I design and build cloud infrastructure by trade leading a practice for a Fortune 500 company). Microsoft is quite proud of that they have more than 6,000 man-years of work in the update to System Center 2012 alone... > > > > "Applications programming is a race between software engineers, who > > > > strive to produce idiot-proof > > > > programs, and the universe which strives to produc
Re: will F18 allow simultaneous installation of more than one desktop?
On Mon, 2012-07-09 at 11:52 -0500, David Lehman wrote: > > Exactly what is so bad with "that practice" (of installing both desktops) > > as to "frown upon it"? > > > > I am a KDE user and yet I still install Gnome on my machine. Exactly what > > crime do I commit? > > Only being unwilling to choose a camp. Not even a crime, really. And choosing a camp is good? Not choosing a camp or deciding to remain flexible is bad? Not really. > > >> If it's not possible to have more than one desktop installed, it makes > > >> changing > > >> desktops much harder (clean install?) and someone who doesn't like Gnome > > >> Shell, > > >> for example, may well decide to change distros rather than try a > > >> different > > >> desktop. Personally, I use Gnome, but install KDE just to have the KDE > > >> packages > > >> available while using Gnome. Would this become impossible? > > > > > > I dont think this argument holds much water. > > > > I am another _real_ data point showing that Fedora users actually do that > > (that = install both > > desktops to have access to packages from both of them). > > There are plenty of very vocal minority groups here. Please show researched statistics to support your claim and implication that this is a minority group. I question and doubt you actually have statistics on any of these groups. > > > Novice end users would be more likely to download an alternative ( encase > > > of an live cd/usb ) from > > > the same distribution and try it out since they are already familiar with > > > the the process of > > > downloading and ( or re)installing the OS and experience users that want > > > to run multiple DE's can > > > already install another one once they have successfully finished > > > installing the distribution. > > > > This is once again an imaginary, or made-up user, so that you can support > > your arguments and ignore > > real Fedora users. How is it that this practice of making up users to > > support cases for writing > > software for idiots has spread so much lately? Write software for your > > users and not imaginary > > "idiots", please! > > I can tell you from personal experience that Fedora has both real and > imaginary idiots. Just kidding. We have two opposing groups of users: > Those who think the installer should have a knob for whatever their > obscure pet option is, and those who believe it should be a > highly-polished, streamlined interface along the lines of MacOS. These > are fundamentally in opposition and it is impossible to please both > camps entirely. ...Wow - Talk about spin. Only something that's highly polished and streamlined like MacOS...? Simple is not a requirement for highly polished, and neither simple nor streamlined should prevent flexibility in options. Besides, if you really want to emulate MacOS like that, why not just go buy a Mac? I would submit there is a group who wants something highly polished, with flexibility and the ability to easily control finer points of the process along the way. None of these traits necessarily precludes the others. Is that really too much to ask for? > > "Applications programming is a race between software engineers, who strive > > to produce idiot-proof > > programs, and the universe which strives to produce bigger idiots. So far > > the Universe is winning." > > > > Do you really strive to produce more and better idiots? > > We strive to provide an environment in which the idiots can play in > relative safety (the graphical installer) while also offering an > alternative environment for the geniuses to do whatever crazy thing they > think they need to do (kickstart). ...This is evidence of another misconception and misguided strategy (albeit an honest one): We need to save the novice users from themselves, while letting "geniuses" hack kickstart files. This is pitting one extreme vs. another in a situation where neither is realistically encountered. Just because I might be a genius doesn't mean I should be required to hack kickstart files (although the choice to do so should remain available at my own risk). Why not instead have a good set of defaults in the installer, with a "Don't try this at home unless you're a professional" button to open up options for those who choose to do so, and then highly polish the whole thing. Is that just too much to ask despite that reasonably good versions of such have been successfully accomplished in the past? Chris -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: will F18 allow simultaneous installation of more than one desktop?
On Mon, 2012-07-09 at 23:59 +0800, Ed Greshko wrote: > On 07/09/2012 11:43 PM, David Lehman wrote: > > On Sun, 2012-07-08 at 07:49 -0600, Christopher A. Williams wrote: > >> Agreed. And I fear the universe, in this case, may be winning by > >> producing "bigger idiot" developers. > > Indeed -- "bigger idiot" developers who seek to simplify their software > > by eliminating limited-value features that bring needless complexity and > > therefore bugs. All you have to do is run 'yum groupinstall ' > > or use the graphical package manager to install your additional DEs. > > This should not be prohibitively difficult. > > > > > Point taken. > > However, I think the concern is that users new to Linux and/or Fedora may be > coming > from the Windows world and not aware they have a choice in the DeskTop. So, > they > installdon't see a choiceget GNOME and assume that is it. > > Maybe those users will eventually find out that they have a choice. > > Or, they may find themselves unhappy with GNOME and leave Fedora without ever > having > known or looked for help. Precisely. Add to this that my comment, in its full context (of which some was deleted), also was referring to a position advocating that application selection should also be limited based on DE choice. And I would further posit that, since the position has been taken that you can override all of this post-install, the potential complexity is only reduced in the installation process. The installed system remains just as complex and would still require (in proper methodology) testing of all components in the overall repository in any case. Thus the overall workload on developers is not really reduced at all. So we have a proposed change that provides little benefit to perhaps a small group of developers on what should be shared components (Installer / Package Manager) which results in a loss of function to users, and increases the risk of bifurcating the distro on at least a social level (if not a technical one). In all (quoting "Ghost Busters") this just sounds like "...an extraordinarily bad idea". Chris -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: will F18 allow simultaneous installation of more than one desktop?
On Sat, 2012-07-07 at 08:14 -0600, Dariusz J. Garbowski wrote: > On 07/07/12 03:15 AM, "Jóhann B. Guðmundsson" wrote: > > On 07/06/2012 07:10 PM, Andre Robatino wrote: > >> I attempted installation using Fedora-20120703-x86_64-916dfe7-netinst.iso > >> and > >> found that it only allows choosing one desktop. I normally install both > >> Gnome > >> and KDE at this point and asked about it on #anaconda. Dlehman it was not > >> planned to support that, and regarding installing other desktops > >> afterwards and > >> choosing between them at the login prompt, he said that wasn't up to them, > >> but > >> personally he frowned on that practice. > > > > I agree with David the installer should not support that and also frown > > upon that practice. > > Exactly what is so bad with "that practice" (of installing both desktops) as > to "frown upon it"? > > I am a KDE user and yet I still install Gnome on my machine. Exactly what > crime do I commit? Add me to that list. I've been using Fedora since FC1, and RHL before that since RHL 4. I've always installed multiple desktops, and still use and sometimes switch between them today. It used to be that, even if you installed only one DE between Gnome and KDE, you still got the essential libraries to run apps from the other. If anything, it's bad practice to segregate the apps by DE. You are essentially bifurcating the distro by doing so. > > I also think that once the novice end user has choose in his DE in the > > installer he should only be > > presented with packages/applications targeted specifically for that desktop > > environment if he should > > be presented with options to install additional packages et al... > > > >> If it's not possible to have more than one desktop installed, it makes > >> changing > >> desktops much harder (clean install?) and someone who doesn't like Gnome > >> Shell, > >> for example, may well decide to change distros rather than try a different > >> desktop. Personally, I use Gnome, but install KDE just to have the KDE > >> packages > >> available while using Gnome. Would this become impossible? > > > > I dont think this argument holds much water. > > I am another _real_ data point showing that Fedora users actually do that > (that = install both > desktops to have access to packages from both of them). Agreed. Absolutely this argument does hold water. What doesn't hold water is the notion that every DE must be physically segregated. Clearly, people use more than one DE on Fedora today and mix apps from multiple DEs without a second thought. Why should you, in the name of "helping" novice users, take this capability away when it wasn't hurting anything to begin with? > > Novice end users would be more likely to download an alternative ( encase > > of an live cd/usb ) from > > the same distribution and try it out since they are already familiar with > > the the process of > > downloading and ( or re)installing the OS and experience users that want to > > run multiple DE's can > > already install another one once they have successfully finished installing > > the distribution. This argument is sending my BS-O-Meter into overdrive. Novice users don't know there are different DEs, and they won't re-install their entire systems just to try another one out. By going this direction, you are removing flexibility and capability from Fedora. Further, you are segregating the Fedora community by DE. That's neither good nor is it necessary. > This is once again an imaginary, or made-up user, so that you can support > your arguments and ignore > real Fedora users. How is it that this practice of making up users to support > cases for writing > software for idiots has spread so much lately? Write software for your users > and not imaginary > "idiots", please! > > "Applications programming is a race between software engineers, who strive to > produce idiot-proof > programs, and the universe which strives to produce bigger idiots. So far the > Universe is winning." Agreed. And I fear the universe, in this case, may be winning by producing "bigger idiot" developers. Chris -- Christopher A. Williams -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Firefox and Java Plugin on F15
On Thu, 2011-05-05 at 14:06 -0400, Scott Robbins wrote: > On Thu, May 05, 2011 at 11:29:06AM -0600, Christopher A. Williams wrote: > > Before I go ahead and submit a BZ on this, has anyone else noticed that > > the Java plugin is not listed in Firefox on F15? If you do > > about:plugins, everything else you would expect to be there is. The Java > > plugin is visibly absent. > > I added Sun Java, following the steps in the mjmwired guide (using > alternatives to make sure it's using Sun. > > Also ran the command (again from the mjmwired guide > > /usr/sbin/alternatives --install > /usr/lib64/mozilla/plugins/libjavaplugin.so \ > libjavaplugin.so.x86_64 /usr/java/default/lib/amd64/libnpjp2.so 2 > > (I think it pretty much echoes what's on the Fedora SOLVED wiki page.) Thanks - to all on this thread. Installing the package icedtea-web indeed enabled the OpenJDK pligin, and, although I have followed the above, I also was able to get the Sun JDK working as well. That said, icedtea-web should be a part of the install. Leaving it out should be considered an oversight or bug... Cheers, Chris -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Firefox and Java Plugin on F15
Before I go ahead and submit a BZ on this, has anyone else noticed that the Java plugin is not listed in Firefox on F15? If you do about:plugins, everything else you would expect to be there is. The Java plugin is visibly absent. I've even tried adding the latest Java (Update 25) from Sun/Oracle. Everything works fine, except for the Java plugin itself. So, I don't know why Firefox is missing this, but it clearly is not allowing use of either Sun/Oracle or the OpenJDK plugins. I'll BZ if no one else has noticed it. Otherwise, if there is an existing BZ that I've missed, please let me know and I'll add comments there. Cheers, Chris -- == "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: !! NVIDIA WORKS !!!
On Fri, 2010-10-15 at 17:00 -0500, Bruno Wolff III wrote: > You can run whatever you what, but when you are talking about fixing issues > with nVidia on Fedora then you bring in the expectations of the people who > work on Fedora not run it. For the most part the people who work on the > kernel have no interest in dealing with any nVidia problems. I didn't bring in those expectations. You already had them. And I would hope the main focus of the kernel maintainers is maintaining the kernel. nVidia should handle problems with their module, regardless of where it is discussed - with the understanding that there are appropriate forums for discussing all of these also being taken into consideration. > > 1) You implied, if not almost stated outright, that I have an > > expectation Fedora should fix and debug nVidia packages. That's false. I > > never even remotely went there. I have an expectation that Fedora will > > fix their own bugs, nVidia will fix their own bugs, and the two parties > > will kindly figure out how to work together under the circumstances that > > exist like adults instead of tantrum throwing children. > > If you are running a tainted kernel (for example using nVidia's drivers), > the kernel maintainers aren't going to spend time on any problems with > that configuration. If you can make the problem happen without having a > tainted kernel, then it might get looked at. I just love the "tainted kernel" part almost as much as the "then it might get looked at" statement if the problem really is theirs. If it's the kernel maintainers problem, then the kernel maintainers had better not only look at it, but fix it. The sole reason the nVidia driver "taints" the kernel is because nVidia supplies and links a non-GPL kernel module to the GPL kernel. If the very same module were GPL, the kernel wouldn't be "tainted". Last time I checked, the software license of a piece of software wasn't the primary determinant of that software's quality or supportability. The key is understanding who should be supporting what. For example: If I put an aftermarket engine part on my car and my car has an engine problem, the warranty on my car isn't instantly voided. If the engine had a problem not involving that part, the warranty must cover that repair. If the aftermarket part caused the problem, then the manufacturer of that part is the one on the hook for the repair according to whatever warranty they have (that's the law of the land in the US). In all the time I have run Fedora and nVidia, kernel issues from linking this module were far from the biggest problem I've had, and nVidia seems to do a reasonably good job handling their problems when they do come up. At least most of the time... In the meantime, if I have a problem with the kernel that doesn't deal with the nVidia module, I will rightly expect that the kernel maintainers will do their best to troubleshoot and resolve my bugzilla reports. They have in the past. Why would that change now? > > ...In the meantime I'll continue to play around with and provide > > feedback on Nouveau, and if it eventually suits my needs better than > > nVidia, I'll switch. > > That may be a while yet. 3D is still buggy, and the level of OpenGL support > is significantly behind what's in the closed drivers. Another aspect in > the mix is nVidia's proprietary CUDA stuff. I don't think opencl support > is that far along yet (though i don't follow that very closely), but you also > might not have an easy time switching and nVidia seems to be trying to get > lockin there. ...Which is why I run nVidia's driver. It also happens that I run VMware Workstation 7.0.2, which officially supports 3D graphics on Fedora using the proprietary nVidia drivers. As a VCP4 about to do the VCAP-DCA4 (I passed the version 3 exam last year), VMware is something I use for my job. I run vBox too. VMware doesn't do 3D graphics support on Linux with most of the OpenSource drivers, including Nouveau (since it can't handle 3D very well anyway). I also like the eye candy of Compiz, which Nouveau still chokes on. I'm not going to go out and spend money needlessly for an ATI (which has been a monster can of worms of its own with recent Fedora releases) or an Intel card just to avoid this. By the way, VMware Workstation doesn't support 3D graphics on Intel cards yet either. As to the lock-in, we'll see if they succeed. I have a feeling that they might indeed be trying, but they will probably fail in the end. They don't drive enough of the market to make good on that kind of strategy from what I can see. > > 2) You imply and try to make the case that running Fedora means I have > > to buy fully into the ultimate in "OpenSource Only" ideology. That's > > also false. No, I don't have to. I can run Fedora any way I want to, in > > combination with any other software I want to, as long as I follow the > > applicable licenses (in Fedora's case, the GPL). > > No, I was providing expections on the kind of
Re: !! NVIDIA WORKS !!!
On Fri, 2010-10-15 at 16:49 -0500, Michael Cronenworth wrote: > Christopher A. Williams wrote: > > But the two camps can - and should - at least be expected to "play > > nicely" with each other. The rules of engagement between the two could > > be similar to when two proprietary software companies collaborate while > > each keeps their own code closed from the other. > > From what I have seen there is good interaction between the X.org group > and NVIDIA so I am not losing any sleep over the lack of collaboration. > I'm sure if the suits at NVIDIA could be convinced they wouldn't lose > money from producing an open source driver, we would have one. > > P.S. Good discussion, Christopher. I agree with all of your points. > > P.P.S. The X group also helped fix a VBE bug in F14 that affected many > projects, including VirtualBox. Some debugging that helped pinpoint the > issue came from Frank @ Sun (Oracle). Thanks! And I wasn't aware of those gems of info. Nice to know some of us are working together quite well. Chris -- "The most effective way to do it is to do it." --Amelia Earhart, American Aviation Pioneer -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: !! NVIDIA WORKS !!!
On Fri, 2010-10-15 at 13:08 -0500, Jason L Tibbitts III wrote: > >>>>> "CAW" == Christopher A Williams writes: > > CAW> Actually, this is an oversimplified view based on pure ideology - > CAW> and exactly the one which causes issues between the OpenSource and > CAW> other communities. > > I suppose you're entitled to your opinion, but the simple fact is that > we can't fix what we can't work on. Indeed. Nobody (well at least not me) is asking Fedora Project to fix nVidia's proprietary code. That should, appropriately, be nVidia's job. But the two camps can - and should - at least be expected to "play nicely" with each other. The rules of engagement between the two could be similar to when two proprietary software companies collaborate while each keeps their own code closed from the other. -- "General notions are generally wrong." --Lady Mary Whortley Montagu, British Aristocrat and Writer -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: !! NVIDIA WORKS !!!
On Fri, 2010-10-15 at 13:33 -0500, Bruno Wolff III wrote: > On Fri, Oct 15, 2010 at 11:59:35 -0600, > "Christopher A. Williams" wrote: > > > > The pragmatic reality is that we will all be dealing with a mix of > > OpenSource and proprietary software for the foreseeable future, whether > > we like it or not. Given that, it would help if all parties involved at > > least tried to hold out the proverbial olive branch and get along. That > > way, actual problems might get fixed without the various camps getting > > into pissing contests about who actually broke what and who is > > responsible, and true software choice is preserved for everyone... > > Fedora isn't the distro to use if you have that expectation. There other > distros that would be better if you need to use nVidia's drivers and can't > afford to manage your updates to prevent kernel updates from causing problems. ...Ummm Not necessarily. Perhaps that works for you, but I find that my current combo of Fedora and nVidia (via RPM Fusion), and a mix of several other OpenSource and proprietary tools, works quite nicely, thank you very much. > If you use Fedora the expectations are that you use nouveau, that Fedora > packagers aren't responsible for debugging packages that aren't in our repos, > and that Fedora packagers shouldn't have to slow down development because some > third party is dragging their feet. And no again. Those might be _your_ expectations, but they are not _my_ expectations. And since I'm the one who gets to decide what software I run on _my_ computer, your expectations don't apply. Oh, and I've used and contributed to Fedora since version 1.0 (and, before that, its Red Hat Linux predecessor since the "Halloween" release). Besides, You implied some things about my motivations that I never wrote or implied. Such as: 1) You implied, if not almost stated outright, that I have an expectation Fedora should fix and debug nVidia packages. That's false. I never even remotely went there. I have an expectation that Fedora will fix their own bugs, nVidia will fix their own bugs, and the two parties will kindly figure out how to work together under the circumstances that exist like adults instead of tantrum throwing children. Specifically, in the case of nVidia, that means I have an expectation they will have to compensate somewhat in working with OpenSource providers in helping to find and fix problems. That's the price they pay for wanting to keep their stuff closed. ...In the meantime I'll continue to play around with and provide feedback on Nouveau, and if it eventually suits my needs better than nVidia, I'll switch. 2) You imply and try to make the case that running Fedora means I have to buy fully into the ultimate in "OpenSource Only" ideology. That's also false. No, I don't have to. I can run Fedora any way I want to, in combination with any other software I want to, as long as I follow the applicable licenses (in Fedora's case, the GPL). I find it amazing that people who cry out loudest for OpenSource and software choice somehow seem to be the same group to get upset when that software choice includes a mix of FOSS and proprietary products. If you take that position, aren't you becoming exactly what it is you are so passionately standing up against? I choose, instead, to promote, encourage, and advocate OpenSource software, but will always promote software choice as a part of that. As such I will also refuse to boycott proprietary software. OpenSource can - and should - be allowed to compete and win on its business and technological merits, as opposed to because someone crammed it down my throat. If the 2nd is where we're going, we might as well be Microsoft. Chris -- "The wise man questions the wisdom of others because he questions his own, the foolish man, because it is different from his own." --Leo Stein, American Art Collector -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: !! NVIDIA WORKS !!!
On Fri, 2010-10-15 at 12:33 -0500, Jason L Tibbitts III wrote: > > "SR" == Scott Robbins writes: > > SR> I've never quite understood this logic. If it's working, there is a > SR> change in Fedora, and it doesn't work, this is NVidia's job to fix? > > Yes, precisely. > > Their code is not open; we can't fix it. Who else's job could it > possibly be but their when they are the only ones with the code? Actually, this is an oversimplified view based on pure ideology - and exactly the one which causes issues between the OpenSource and other communities. It assumes that Fedora's code is perfect because it's open, and that because nVidia's code broke from a change in Fedora code that the problem must be nVidia's. History proves something different - that the real problem could be in either code base, and has been before. Since nVidia is not likely to open their code anytime soon, the issues of how to troubleshoot where the problems lie can't be completely collaborative. And this decision by nVidia means they wind up having to look at both code bases to find the problem, with little help from Fedora Project. They then either patch their own code, submit a patch to the Fedora Project team (which then has to go through Fedora's normal approval process), or perhaps do both. The conflict lies in that the Fedora "everything must be OpenSource" ideologues often cop a pretty nasty attitude towards proprietary vendors like nVidia, and that favor is, unfortunately, often returned. The pragmatic reality is that we will all be dealing with a mix of OpenSource and proprietary software for the foreseeable future, whether we like it or not. Given that, it would help if all parties involved at least tried to hold out the proverbial olive branch and get along. That way, actual problems might get fixed without the various camps getting into pissing contests about who actually broke what and who is responsible, and true software choice is preserved for everyone... Cheers, Chris -- "In an age of universal deceit, telling the truth is a revolutionary act." --George Orwell -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: flash player 64bit?
On Wed, 2010-07-07 at 10:43 -0600, Kevin DeKorte wrote: > > The issue with nspluginwrapper and the 64-bit plugin remains, however. > > But since Adobe has pulled the 64-bit plugin for now, we'll have to wait > > and see if the new version still has the problem. Based on the behavior > > I'm seeing, this actually might be an issue with the 64-bit version of > > alsa-plugins-pulseaudio, or that you might still need both the 32-bit > > and 64-bit versions of nspluginwrapper AND alsa-plugins-pulseaudio, > > which is not documented anywhere. Thus, I'd be willing to bet that going > > back to pure 64-bit for everything will still re-produce the problem. > > > I'm not going to get into the comments on the bug but here are some > possible solutions.. > > If you are using all 64bit plugins there is really no need to have > nspluginwrapper. Firefox 3.6.4 has plugin crash protection now so that > removes one of the needs for 64bit pluginwrapper on a 64bit browser. If > you desire to have nspluginwrapper installed due to some plugin needing > it, but you don't want it touching flash. Edit > /etc/sysconfig/nspluginwrapper and add libflash* to the list of > IGNORE_WRAP and then rerun mozilla_plugin_config (as user and root). Thanks! This will be helpful going forward, assuming Adobe keeps their word about re-releasing the 64-bit plugin, and assuming a reason remains for keeping the 64-bit version of nspluginwrapper for other things. > As for the 64bit flash Adobe has yanked it. So you can either run with a > 64bit flash that is very buggy or you can use the 32bit one (less buggy) > wrapped in nspluginwrapper. If there is a bug with the wrapped version. > You might want to try emailing the nsplugginwrapper mailing list as most > likely the developers do not check the fedora bugtracker. Interesting. The BZ was filed under nspluginwrapper as a component. If nobody is watching it, perhaps it shouldn't be there or it should default to another queue so someone picks it up. In the meantime, I've already decided to go with the "less buggy" route for now... -- = "You see things as they are and ask, 'Why?' I dream things as they never were and ask, 'Why not?'" -- George Bernard Shaw -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: flash player 64bit?
On Wed, 2010-07-07 at 17:02 +, Jonathan Kamens wrote: > I wasn't being snarky, I was being pragmatic. > > You're absolutely right that a triager should have looked at the bug > in bugzilla, tried to reproduce it, and comment on the results. I > can't comment on why that didn't happen. What I was commenting on was > the fact that when a bug sits untouched for whatever reason, the > single best way to get it unstuck is for the people who care about it > to provide more information. You have a right to your opinion, and it's not unreasonable in that respect. But you misinterpreted what was really happening though and made a snap decision. > The "most popular bugs" page reflects how many duplicate bugs have > been filed on any particular issue. We most certainly do consider that > as a factor when determining which bugs to work on. Would you rather > have limited resources devoted to the firefox crash bugs which has > been reported hundreds of times, or to the Flash bug reported by only > a few people, none of whom has indicated when reporting the issue that > they actually followed the documented instructions for deploying it? I would have preferred that a triager / maintainer had actually looked at the bug report and requested additional information if they thought it was needed. After that, certainly bugs can be prioritized. But there's no excuse for just simply ignoring bug reports. Period. End. Further, your "documented instructions" argument is a red herring. There are no documented instructions from Fedora for installing the 64-bit plugin. And at the time of the original report, the only available instructions were followed. > And I didn't post details in the ticket because I and others posted > them here, and you are active here, and I knew that you would follow > up on the issue, and my time is limited. I could have decided not to > contribute any help at all here or in the ticket; would that have been > preferable? I think I have been pretty clear about what I would have preferred. Don't act like you're the only one with limited time. It's selfish. You're far from the only one, and we use BZ for a reason. Your "help" was more by accident, and hasn't actually solved the problem reported in BZ, but rather just pointed to an updated way to use a newer version of the 32-bit plugin. The actual issue (64-bit plugins and corresponding nspluginwrapper packages) remains unresolved, and nobody has looked at that issue yet either. Since the 64-bit plugin has been pulled for now, and since (as another poster pointed out) the newer versions of Firefox have crash protection that at least partially negates the reason for wrapping 64-bit plugins, there's now actually a bigger question of if the 64-bit version of nspluginwrapper is really needed. But that's a discussion for another day. -- "Ninety-nine percent of the failures come from people who have the habit of making excuses." --George Washington Carver -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: flash player 64bit?
On Wed, 2010-07-07 at 11:04 -0400, Jonathan Kamens wrote:
> On 7/7/2010 10:44 AM, Christopher A. Williams wrote:
> > Not true. Just because YOU can't reproduce it doesn't mean it isn't
> > happening. Others have reproduced the problem and also commented as such
> > on the bug report.
> Whether or not other commenters on the bug have reproduced the problem
> is mostly irrelevant.
Not true. It shows that others are having the the exact same problem in
exactly the same way.
> What is relevant is whether or not bug triagers and/or the maintainer
> of nspluginwrapper have been able to reproduce it.
...Which the bug shows they haven't because they didn't even try.
> If they haven't, then the bare fact that other people can is useless
> to them. With the volume of bugs that come into the system, it is
> unreasonable to expect triagers and/or package maintainers to spend
> time playing around trying to find the conditions that reproduce a bug
> when they've been given little or no information whatsoever about said
> conditions from the people reporting it.
The conditions that were known at the time were reported. Further, no
additional information was requested by any triager or maintainer.
> The most common reason why a bug doesn't go anywhere in bugzilla is
> because the triagers and package maintainer can't reproduce it. This
> is not a condemnation or criticism; it is just plain fact.
> > ...but I suppose that if you had bothered to go actually read the bug
> > report, you would have known that.
> I did "go actually read the bug report." There's no reason to be
> snarky. There is nothing in the report that provides the triagers and
> package maintainer with enough information for them to be able to
> figure out how to reproduce the issue, if they are unable to reproduce
> it out-of-the-box.
Again, that's not true. And even if it were true, no additional
information was requested. In fact, the bug was never even assigned to
anyone. No action was taken at all. It was basically ignored with no
feedback.
> > So, please list out your system configuration as relevant to this area
> > of function. Perhaps you have somehow stumbled into a workable
> > work-around configuration.
> I have nothing out of the ordinary on my system. I'm running x86_64
> F13 with updates and updates-testing enabled, and I have followed
> exactly the instructions on the Wiki for wrapping the 32-bit Flash
> plugin with nspluginwrapper.
>
> If you want people to fix a bug that is affecting you but they can't
> reproduce, then it is incumbent upon you, not them, to do the work to
> figure out what's different about your system. TANSTAAFL.
OK - Now who is being snarky... Again - no further information was
requested. No action was taken at all. I don't expect triagers and
maintainers to be clairvoyant, but I do expect them to request
additional information if they feel it is needed. That's only fair.
> Note that this bug does not show up on the most frequently reported
> bugs list, which one would expect it to do if it were a widespread
> problem, given how prevalent Flash is on the Web nowadays.
> Furthermore, I scanned all the nspluginwrapper bugs going back almost
> a year and a half and did not find any other reports of this issue.
Now this part IS irrelevant. We don't triage bugs and decide whether to
take action on them based on their being popular.
That said, in your own snarkiness ("I followed the Wiki..."), you
provided what appears to be part of the solution for using the new
32-bit plugin. It still doesn't fix the issue with the 64-bit plugin.
Too bad you didn't provide that info on the BZ. The entirety of your
comment there was, "I cannot reproduce this issue." Talk about not
providing information...
Also note that the Wiki addresses installing the 32-bit plugin only. I
would also note that the wiki was recently updated - after the bug was
reported.
If you go back and re-read the bug report, you will also note that the
original problem was reported with the 64-bit version of the plugin -
not the 32-bit version. That's what was available at the time, as well
as what was the preferred plugin to use on 64-bit systems. The Wiki
doesn't refer to requirements for installing the 64-bit plugin, and
never has from what I have seen. The problem is that nspluginwrapper
also likes to wrap 64-bit plugins - and there still DOES appear to be a
REPRODUCEABLE problem if you were to use the 64-bit version of
nspluginwrapper with its corresponding 64-bit packages.
There was a missing package in the mix on my system if you want to use
the new 32-bit plugin: alsa-plugins-pulseaudio.i686 which also pulled in
9 additional 32-bit packages. I did have the 64-bit vers
Re: flash player 64bit?
On Wed, 2010-07-07 at 10:01 -0400, Jonathan Kamens wrote: > On 7/7/2010 9:55 AM, Christopher A. Williams wrote: > > Thanks for the pointer. Your install method works just great. > > > > ...Unfortunately, it also still means that certain sites still do not > > play video correctly due to issues with nspluginwrapper. I'd hate to > > think that this bug, #579092 which I reported back in April, hasn't even > > been moved to assigned status because the website most affected is > > http://foxnews.com but the fact is that it hasn't even been looked at. > Perhaps that's because others can't reproduce it. > > I have no trouble at all playing videos from http://foxnews.com/ after > using the instructions on the Fedora Wiki for wrapping the 32-bit flash > plugin on my 64-bit system. This is true whether or not I have the > flashblock extension enabled. Not true. Just because YOU can't reproduce it doesn't mean it isn't happening. Others have reproduced the problem and also commented as such on the bug report. ...but I suppose that if you had bothered to go actually read the bug report, you would have known that. So, please list out your system configuration as relevant to this area of function. Perhaps you have somehow stumbled into a workable work-around configuration. -- “If you don't read the newspaper you are uninformed, if you do read the newspaper you are misinformed.” --Mark Twain -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: flash player 64bit?
On Wed, 2010-07-07 at 01:14 -0700, Adam Williamson wrote: > On Tue, 2010-07-06 at 20:53 -0430, Patrick O'Callaghan wrote: > > On Tue, 2010-07-06 at 16:38 -0700, Rob Healey wrote: > > > Greetings: > > > > > > Is there anything that can be used as a substitute for the flash > > > player since Adobe refuses and alienates 64bit users? > > > > > > They either expect us to use i386 software for my 64bit! > > > > Not sure what that sentence means, but I'm using the 32-bit plugin on > > 64-bit Fedora with no problems (at least no more than usual with Flash). > > I have a blog post up with tips on this method: > > http://www.happyassassin.net/2010/06/26/a-quick-reminder-on-64-bit-flash/ > -- Thanks for the pointer. Your install method works just great. ...Unfortunately, it also still means that certain sites still do not play video correctly due to issues with nspluginwrapper. I'd hate to think that this bug, #579092 which I reported back in April, hasn't even been moved to assigned status because the website most affected is http://foxnews.com but the fact is that it hasn't even been looked at. The issue appears to be something with respect to a script loads their Flash Player applet, most likely to queue up advertisements. So now I have to decide between using a 64-bit Alpha version of Flash with known vulnerabilities and using nspluginwrapper. The problems you mention with Flash on Fedora continue... -- "The most effective way to do it is to do it." --Amelia Earhart, American Aviation Pioneer -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
