Re: Promoting i386 version over x86_64?
On Wed, Nov 18, 2009 at 7:27 PM, Kevin Kofler kevin.kof...@chello.atwrote: Gregory Maxwell wrote: I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight? This is, sadly, intentional. I and others have been complaining about this for months, we got ignored, all in the names of making things work for people who are not smart enough to figure out whether their computer is 64- bit or not. The argument that almost all new non-netbook machines are 64-bit anyway also got ignored. IMHO, the right solution is to make the 64-bit edition the default download and to work on making the error message people get when trying to install it on a 32-bit machine nicer: We're sorry, but your computer is too old to install this 64-bit version of Fedora. Please download the legacy 32-bit edition instead. Kevin Kofler Is it right to call 32-bit legacy though? As it is, the Intel architecture doesn't seem like a true 64-bit architecture. It seems more like it extends the 32-bit arch and wraps 64-bitness around it. In any case, 32-bit shouldn't be considered legacy until every type of computer sold is 64-bit. And the fact is, that isn't true. Netbooks are entirely 32-bit currently, and a majority of low end desktops are still 32-bit only. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Wed, Nov 18, 2009 at 8:04 PM, Ikem Krueger ikem.krue...@googlemail.comwrote: IMHO, the right solution is to make the 64-bit edition the default download and to work on making the error message people get when trying to install it on a 32-bit machine nicer: We're sorry, but your computer is too old to install this 64-bit version of Fedora. Please download the legacy 32-bit edition instead. That would be an aweful first experience. Imagine her thoughts: Oh. I made something wrong.. Maybe it's nothing for me.. I suggest to let it as it is and check the system (if 64bit or 32bit) when it is running. Maybe then a little popup comes up with something like: You're pc could be run faster, if you upgrade this operating system to the 64bit version of it. You can download them here if you like: [Link] Even better would be: You're pc could be run faster, if you upgrade this operating system to the 64bit version of it. You can do so by clicking here: [Button] Except, that could be false advertising. In most cases, where CPU computation is not used heavily, 64-bit is actually SLOWER than the 32-bit counterpart. Optimizations are narrowing the gap, but it still remains true. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger ikem.krue...@googlemail.comwrote: Except, that could be false advertising. In most cases, where CPU computation is not used heavily, 64-bit is actually SLOWER than the 32-bit counterpart. Optimizations are narrowing the gap, but it still remains true. Why then should someone prefer 64bit over 32bit? 4 Reasons: 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not really affecting us much, most of us will replace our PCs long before then) 2: Access more than 4GB of RAM (definitely becoming increasingly important) 3: Enhanced performance-critical computational capabilities (if you do a lot of complex HD photo, HD video, or HD audio work, or if you do a lot of raw complex math on your computer, this is EXTREMELY important) 4: Better virtual machine performance -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Wed, Nov 18, 2009 at 8:30 PM, Ikem Krueger ikem.krue...@googlemail.comwrote: Why then should someone prefer 64bit over 32bit? 4 Reasons: 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not really affecting us much, most of us will replace our PCs long before then) What do the people with 32bit cpus who won't/can't upgrade? Then the Y2k38 problem occurs, which is what the theoretical Y2K problem would have been. 2: Access more than 4GB of RAM (definitely becoming increasingly important) I hope for the apps, not for the system. I don't want to become Linux the next Vista.. It isn't the OS itself that will be requiring more than 4GB of RAM (at least I hope not in Linux, Windows is a lost cause... Perhaps ReactOS will pull it off?), but rather the applications used on the computer. Nowadays, it isn't unusual for applications to require at least 512MB of RAM. That builds up, quite quickly. 3: Enhanced performance-critical computational capabilities (if you do a lot of complex HD photo, HD video, or HD audio work, or if you do a lot of raw complex math on your computer, this is EXTREMELY important) 4: Better virtual machine performance Thanks for the answer. :) You're welcome ;) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Help! Broken Dependencies in oggconvert?
Hello, I got a warning from the buildsystem about OggConvert having broken dependencies on PowerPC, when I know OggConvert is a noarch package. What am I supposed to do? This is what I got from the buildsystem: oggconvert has broken dependencies in the development tree: On ppc: oggconvert-0.3.2-7.fc12.noarch requires gstreamer = 0:0.10.12 oggconvert-0.3.2-7.fc12.noarch requires gstreamer-plugins-base oggconvert-0.3.2-7.fc12.noarch requires python(abi) = 0:2.6 oggconvert-0.3.2-7.fc12.noarch requires /usr/bin/python On ppc64: oggconvert-0.3.2-7.fc12.noarch requires gstreamer = 0:0.10.12 oggconvert-0.3.2-7.fc12.noarch requires gstreamer-plugins-base oggconvert-0.3.2-7.fc12.noarch requires python(abi) = 0:2.6 oggconvert-0.3.2-7.fc12.noarch requires /usr/bin/python Please resolve this as soon as possible. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB2 In Fedora
On Sun, Nov 8, 2009 at 1:44 PM, Jesse Keating jkeat...@redhat.com wrote: On Sun, 2009-11-08 at 14:34 +0530, Rahul Sundaram wrote: Wouldn't it be easier to work with GRUB2 folks to add the missing features we need? In theory yes, that's how it's supposed to go. In practice, with grub, it doesn't work that way. From what I gather they just aren't interested in working on the things we need at this point in grub2's development. What do we need in grub2? Didn't they work with Ubuntu to get things working for their distribution? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Tue, Nov 3, 2009 at 8:53 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Chris Adams cmad...@hiwaay.net wrote: You have refused to cite specific legal problems with cdrkit, so there are no known legal problems that anyone can see. The proper reporting method is bugzilla.redhat.com; can you point to where you reported them? It seems that you did never check this as otherwise you did know the reports. Jörg Just with a quick search in the Red Hat Bugzilla, only though distro section Fedora, I found this: https://bugzilla.redhat.com/buglist.cgi?component=cdrkitproduct=Fedora https://bugzilla.redhat.com/buglist.cgi?component=cdrkitproduct=FedoraListed 39 bugs. A quick look shows a disturbing amount of WONTFIX (ignoring rhbz#472924). But I also see things have still been progressing. However, what I want to know is what prompted the relicense to CDDL in the first place? From what I can see, Jörg Schilling, you are the maintainer and creator of the original software cdrtools. Also, why are you so hostile to cdrkit? The implicitly permits forking via its redistribution clause. If you wanted to be able to mix with proprietary code and non-Linux systems, the LGPL would have been just as good. While it is true that the GPL permits linking to CDDL libraries, that is only in the case if the library is a system library, which is a library that is NECESSARY for working on a particular OS. This is usually how it is justified that GPL software can be built using Visual Studio on Windows, even if I personally don't like it. The runtime library in Windows is almost certainly not GPL compatible, as was the case for many other UNIX application runtime libraries at the time. That is what they built into the GPL, not a free for all library linking exception. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
GPLv2: End of Section 3, middle of the paragraph right after clause 3c. GPLv3: Explicit separate definition in Section 1. GPLv2 Quote: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. GPLv3 Quote: The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. I hope this satisfies you. On Tue, Nov 3, 2009 at 9:19 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: King InuYasha ngomp...@gmail.com wrote: While it is true that the GPL permits linking to CDDL libraries, that is only in the case if the library is a system library, which is a library that is NECESSARY for working on a particular OS. This is usually how it is Please show me the exact place in the GPL text thatyou have in mind to prove your claim. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.deemail%3ajo...@schily.isdn.cs.tu-berlin.de(home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Mon, Nov 2, 2009 at 5:48 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: That may be true, but since cdrecord is not shippable, it's a pretty vacuous truth. The solution is obviously to fix the bug and help revive upstream, or else host a development tree on fh if upstream stays idle. Note that is is just the other way: It is cdrkit that is undistributable as it is cdrkit that in conflict with the Copyright law and the GPL. Cdrtools has been checked for legal problems by several lawyers including the Sun legal department and none could find any legal problem. Cdrkit was created by a hostile downstream, see: http://cdrecord.berlios.de/private/linux-dist.html and nobody so far was able to prove the claims about so called license problems spread by Eduard Bloch by using quotes from the GPL text. The problem with the existence is a social problem and we, the people in the OSS community need to fid a way to deal with this social problem. P.S.: Libburn is no alternative too: it misses most important features it is non-prtable and we recently learned that the Authors of libburn do not care much about where they take the software from. Note that they claimed not to use any bit from the original cdrtools project's source but they really did use code from cdrtools. I would call this a social problem Jörg What is going on here? I thought Fedora only shipped upstream code? What's all this business about having broken forks and licensing issues? The only thing I can figure out from this conversation is that the CDDL is supposed to be incompatible with the GPL. If that's the case, why not simply ask the original creator to kindly dual license it? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora PPC for oldworld Mac?
On Thu, Oct 29, 2009 at 7:18 AM, David Woodhouse dw...@infradead.orgwrote: On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote: On 09-10-28 18:24:49, Josh Boyer wrote: On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote: Sorry to bug developers, but I didn't get any bites from PPC users on fedora-list. Does Fedora PPC work or install on oldworld PCI Macs, such as a beige G3 desktop? My impression is that no one has tried it on an oldworld No, it doesn't. The ppc specific release notes cover that here: http://docs.fedoraproject.org/release-notes/f11/en-US/ index.html#sect-Release_Notes-Hardware_Requirements I'd looked at the release notes. They says Minimum CPU: PowerPC G3... and Although Old World machines should work, they require a special bootloader which is not included in the Fedora distribution. My question is whether anyone has tried it in any recent Fedora release and knows whether should means do or don't. (FWIW, the special bootloader is BootX, and Debian Lenny is installing now, so /some/ form of Linux works. I just don't know anything but hearsay about Debian. I see it uses apt.) I don't know of anyone who's tried it recently, but in the past we've fixed things in the kernel to make it work properly on OldWorld Macs and it _has_ been known to work fine. It _ought_ to work if you sort out the bootloader. -- dwmw2 If Mac OS isn't bootable, then you need to use quik ( http://penguinppc.org/bootloaders/quik/ ) instead of BootX. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
Well, possibly the only thing fatELF would be needed for would be to rid ourselves of multilib. Applications don't even need to be FatELF to link to FatELF libraries. On Mon, Oct 26, 2009 at 11:28 AM, Ikem Krueger ikem.krue...@googlemail.comwrote: I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. I don't suggest to do that. As already mentioned, that would double the size of the distro/iso. I would use this technic only, if neccessary. About fat-elf in general: As long as it is optional, I am fine with it. May it at compile time or after compiling by stripping binaries. (I'd like to see both options.) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking into LLVM
On Sun, Oct 25, 2009 at 12:21 PM, Kevin Kofler kevin.kof...@chello.atwrote: Rahul Sundaram wrote: LLVM 2.6 has been announced with Clang declared as production quality in this release http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/33.html Has anyone been looking into building Fedora with it to see how the performance impact is? A lot of upstream software on GNU/Linux only supports GCC. Clang tries to support GCC extensions, but I strongly doubt it'll compile all upstream code unchanged, and upstream projects might even reject patches to fix the build with Clang because they only support GCC. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Also, clang's support with C++ ABI is still very broken. It's listed under known issues. While most applications are made with C or Python, there are still a fair number of C++ applications... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora with Universal Binaries?
Hello, I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. http://icculus.org/fatelf/ There is even a proof of concept VM of Ubuntu 9.04 that has both 32-bit and 64-bit kernels and all the apps compiled as FatELF binaries -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
On Thu, Oct 22, 2009 at 12:57 PM, Kevin Kofler kevin.kof...@chello.atwrote: King InuYasha wrote: I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. http://icculus.org/fatelf/ Yuck!!! Please don't infect GNU/Linux with this completely braindead crap! This wastes a lot of disk space and download bandwidth and probably also increases loading times for NO reason whatsoever. It also doubles the build times for any and all software. Just figure out what arch your machine is and install the correct package for your arch! Fat binaries are a method to make crappy binary-only software distribution easier, they have no room on a Free Software system. Let the Mac folks keep their fat crap and leave our binaries as native for the appropriate arch! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I dunno, it could be useful for Live CDs/USBs. It would let you pack multiple arches onto a single LiveCD/USB. You sound like one of those crazy people that disregard everything that may slightly help proprietary software. It's probably possible to strip out arches when they become unneeded, if so desired. I know it is possible under Mac OS X to do that. If you had a system that had extra arches you didn't need, you probably could just go and strip them out to save disk space. There isn't much proof to your statement about loading fat binaries. I don't notice a slow down in load times of Universal binaries on my Mac, but I do notice the disk space. As it is, Snow Leopard now uses Universal binaries to pack x86_32 and x86_64 into a single application container and can strip out PowerPC binary code. Don't knock it till you try it... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switch from OpenAL to OpenAL-Soft
Because there is still no significant change in functionality, just compatibility with current audio systems. On Tue, Aug 11, 2009 at 7:27 AM, drago01 drag...@gmail.com wrote: On Tue, Aug 11, 2009 at 1:08 AM, LinuxDonaldlinuxdon...@linuxdonald.de wrote: I have add the openal-soft package into fedora 12 that will replace openal. At all packager when you have openal as dependency please change it to openal-soft and recompile your package for f-12 please Any reason why you decided to do this after the freeze? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switch from OpenAL to OpenAL-Soft
I thought Obsoletes took care of that? On Tue, Aug 11, 2009 at 4:11 AM, LinuxDonald linuxdon...@linuxdonald.dewrote: The problem is openal-devel and openal-soft-devel package conflicts. The Second one is to use OpenAL-Soft you must update the spec file in the packages that use openal and recompile it. Am 11.08.2009 02:29, schrieb King InuYasha: Shouldn't it also be possible for openal-soft to replace the crappy old OpenAL package included in previous versions of Fedora? The openal-soft library is supposed to be compatible with applications that normally use the older OpenAL SI library that has been rotting for years. On Mon, Aug 10, 2009 at 6:08 PM, LinuxDonald linuxdon...@linuxdonald.dewrote: I have add the openal-soft package into fedora 12 that will replace openal. At all packager when you have openal as dependency please change it to openal-soft and recompile your package for f-12 please -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Wed, Jul 29, 2009 at 10:50 AM, Adam Williamson awill...@redhat.comwrote: On Wed, 2009-07-29 at 15:56 +0200, Lennart Poettering wrote: On Wed, 29.07.09 09:47, Jeff Garzik (jgar...@pobox.com) wrote: mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. Please don't forget that hardware mixing... is more than just mixing. Modern audio hardware can offload sample rate conversion, attenuation, 3D processing, and other goodies. Interesting in which parallel universe you must be living. Modern audio hardware is usually locked to a specific sample rate, got rid of all mixer controls by going to 24bit and letting the CPU attenuate using the 8bit extra headroom. And 3d processing, and other goodies aren't avilable in newer hw designs anymore either. In fact haven't been available since quite some time in any design anymore. (With the excption of those creative cards) Just get over it, the new designs are really dumbed down but high-quality 24bit dacs. That's all. It may be easier to resolve this if both of you would say exactly what hardware you're talking about... for the sake of argument, my local PC store sells a range of cheap cards that are just what Lennart says. For expensive consumer cards it has several Asus cards (appear to be based on CMI chips), some AuzenTechs (also CMI), and some HT Omegas (CMI again, I think I'm seeing a pattern here :). The Asus cards claim specifically that they support DirectSound in hardware. Aside from that, all the expensive cards make loud claims about Dolby and/or DTS systems for multiplexing and headphone processing, but don't make clear whether they're done in hardware or software. I didn't see anything about hardware SRC, though they probably wouldn't advertise that, it's hard to tell until you own one. My card, a Chaintech AV-710, does do SRC in hardware (you can set it to any output sampling rate you like, via the mixer), but you can't buy it any more, it was discontinued. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list If these controls and hardware accelerated audio isn't going to work anymore, then why does Fedora still include the older OpenAL sample implementation instead of the new OpenAL Soft implementation that comes with a PulseAudio backend? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Time for 2.6.30 in F-11?
On Sat, Jul 4, 2009 at 5:51 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, Users with Intel's integrated chips need the updated DRM in that kernel. I think that an update is highly recommended. -Ilyes On Sat, Jul 4, 2009 at 11:40 AM, Bojan Smojverbo...@rexursive.com wrote: Now that .1 is out, is there anything in particular stopping F-11 from having this kernel? -- Bojan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I concur I have five laptops and a few desktops with Intel graphics, and it would definitely be great if the update would be pushed through! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
If your desktop doubles as a server, then no you don't turn off the computer... On Wed, Jul 1, 2009 at 10:55 AM, Jochen Schmitt joc...@herr-schmitt.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 01.07.2009 17:48, schrieb Kevin Kofler: Whose behavior? Turning the computer off completely definitely saves more power than suspend to RAM and on some machines also suspend to disk (hibernate). Yes, and this is the reason why a desktop user should turns his coputer completely of to save the maximum of power. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpLhsMACgkQT2AHK6txfgzw0ACfSRYdJFzpAlVwM9lY9SURmx+F eeUAoMx9JmTHe4Vob2KvUDbiE885eJwP =aLyW -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
On Mon, Jun 29, 2009 at 3:14 AM, Matej Cepl mc...@redhat.com wrote: Frank Murphy, Mon, 29 Jun 2009 08:38:45 +0100: Is there any contingency plans in place, for a worst case scenario if C#, is lost? FesCo? Sure, there is, but no need to panic ... sky is not falling yet (and there are many reasons to believe it never will). Note for example, that default installation of Fedora 12 probably won't require Mono at all (Tomboy was replaced by Gnotes, although the main reason was savings of many megabytes instead of legal concerns). Best, Matěj P.S.: Says the one who does yum remove mono-\* after every upgrade of Fedora. I don't think you need to really worry about Mono itself. If you really are worried about Microsoft suing your brains out, just remove mono-web and mono-winforms. You don't even need those two for most packaged Mono apps on Linux. Only if you want to run applications compiled for .NET framework on Visual Studio/SharpDevelop. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KSplice in Fedora?
I was reading an article today in ComputerWorld about something called KSplice, which allows Linux users to install critical updates and patch in without rebooting the computer. I tried it and while it was a bit odd for installing (not auto-disabling the Ubuntu update system), it worked very well. I think something like this would be great for Fedora as well, possibly something for Fedora 12. Would it be possible to implement this or something similar for Fedora? Note: Article: http://blogs.computerworld.com/never_reboot_again_with_linux_and_ksplice -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
On Mon, Jun 29, 2009 at 7:12 PM, Josh Boyer jwbo...@gmail.com wrote: On Mon, Jun 29, 2009 at 11:19:53PM +, Christopher Brown wrote: I understand Microsoft has patented this technology so it is currently no-go for inclusion. [jwbo...@hansolo ~]$ koji latest-pkg dist-f11 ksplice Build Tag Built by ksplice-0.9.7-3.fc11 dist-f11 s4504kr [jwbo...@hansolo ~]$ koji latest-pkg dist-f11 fedora-ksplice Build Tag Built by fedora-ksplice-0.5-5.fc11 dist-f11 s4504kr [jwbo...@hansolo ~]$ josh Then Linux shouldn't be compiled using kmods and instead as a monolithic binary, since kernel modules fall under the patent. Besides, there are tons of prior art on it. KSplice is a good technology that could possibly be integrated in. fedora-ksplice is only build scripts for the kernel it looks like. ksplice is there as a package, but what about the GNOME frontend? The screenshot for ksplice in Ubuntu looks like PackageKit, so maybe it would be possible to integrate ksplice into PackageKit/yum so that rebooting for updates would be unnecessary. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KSplice in Fedora?
On Mon, Jun 29, 2009 at 10:58 PM, Bill McGonigle b...@bfccomputing.comwrote: On 06/29/2009 10:49 PM, Kevin Kofler wrote: It can only handle small patches which don't change any data structures. So the official Fedora kernel updates will never be suitable to be distributed through KSplice. And to date there hasn't really been any compelling reason to issue tiny patch security-updated kernels, 'cause you have to reboot anyway, right? But as the technology improves, more opportunities arise. I recall deploying some sort of hack workaround for the vmsplice exploit a while back on a whole bunch of machines (Fedora or downstreams) that were going to need a reboot scheduled up to a week in the future. This kind of technology would have been really swell to have then. Lots of reasons to not want to reboot machines - most of the arguments for supporting laptop suspend would fit. Some of them may fall into the protecting users from themselves category, but that's not a bad thing either. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf Also, while KSplice is currently being used for kernel updates, it isn't limited to those. It could be adapted to work for other updates that normally force a reboot. Though, I can't think of any off the top of my head, it has been over a week since I ran the updater... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Odd omission for qt4-devel package
I found a very strange omission for the qt4-devel package. The path to qt4-devel binaries (/usr/lib/qt4/bin) isn't automatically added to $PATH like qt3's are. Additionally, when I removed the qt3-devel package, the path to qt3-devel binaries (/usr/lib/qt-3.3/bin) isn't automatically removed from the $PATH. Shouldn't these be fixed? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Odd omission for qt4-devel package
On Fri, Jun 26, 2009 at 4:11 AM, Michael Schwendt mschwe...@gmail.comwrote:
On Fri, 26 Jun 2009 03:05:41 -0500, King wrote:
I found a very strange omission for the qt4-devel package. The path to
qt4-devel binaries (/usr/lib/qt4/bin) isn't automatically added to $PATH
like qt3's are.
Additionally, when I removed the qt3-devel package, the path to qt3-devel
binaries (/usr/lib/qt-3.3/bin) isn't automatically removed from the
$PATH.
Shouldn't these be fixed?
It's qt3 that alters $PATH via /etc/profile.d/qt.{c,}sh
qt only puts symlinks into /usr/lib/qt4/bin that point to /usr/bin,
so the executables are found with default $PATH already.
What do you find very strange about it? Have you run into any source
tarball that fails with qt-devel/qt because it makes strange assumptions?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Yes I have. I was unable to build Mozilla with the cairo-qt option because
it was unable to detect Qt4's moc. Even after uninstalling Qt3 and
reinstalling Qt4, moc still was never detected. No, wait, Qt3's moc was
detected but it caused problems building cairo-qt, so I uninstalled it and
discovered that it wasn't able to detect Qt4's moc. I had to temporarily
export /usr/lib/qt4/bin to $PATH to make it get detected.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Tue, Jun 16, 2009 at 10:51 AM, Kevin Kofler kevin.kof...@chello.atwrote: Seth Vidal wrote: 1. we're going to need split media for dvds - we're SOL there anyway - so the code will need to live on. Just kick out all the i18n stuff and you won't. It doesn't make sense to force people to download the translations for all the languages spoken anywhere on the planet. People normally need one or at most a handful of langpacks. It's best to add that post install, that way one only has to download the actually needed langpack(s) and not all of them. As for Everything DVD sets, that's also something Fedora doesn't produce, so it should also be FedoraUnity's problem. Kevin Kofler Even if it is Fedora Unity's problem, Fedora Project would still have to maintain the anaconda code that allows split media installation. Ubuntu seems to do fine including quite a few language packs on their LiveCD while providing a decent desktop. Unless a flat-file dpkg database makes a huge difference to the BerkleyDB rpmdb in terms of size, there isn't any reason that Fedora cannot make available a desktop just as functional as the Ubuntu one (like having OpenOffice included). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Tue, Jun 16, 2009 at 3:17 PM, Tomas Mraz tm...@redhat.com wrote: On Tue, 2009-06-16 at 11:42 -0400, Bill Nottingham wrote: Chris Adams (cmad...@hiwaay.net) said: Removing support for still-functional hardware is a trademark of Microsoft, not Linux. I'd also argue that doing another full rebuild of the OS for a 1% performance gain on a single architecture is not a particularly production use of resources. The 1% comes from i586 - i686; SSE2 would be additional on top of that. But given the vehement opposition, I can see dropping the SSE2 requirement. I'm still fairly convinced that going to i686 is the right move - we really don't support i586 as a practical matter, and even the Geode should still work with that. Furthermore, it's likely we'll have a mass rebuild for LZMA support and/or debuginfo changes, so it's no additional cost. Great, i686 without SSE(2) seems OK to me. I even wonder why we did not go to that requirement in F11 already without the intermediate ~i586 requirement. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb Because Pentium II and lower support i586 arch. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Tue, Jun 16, 2009 at 3:17 PM, Tomas Mraz tm...@redhat.com wrote: On Tue, 2009-06-16 at 11:42 -0400, Bill Nottingham wrote: Chris Adams (cmad...@hiwaay.net) said: Removing support for still-functional hardware is a trademark of Microsoft, not Linux. I'd also argue that doing another full rebuild of the OS for a 1% performance gain on a single architecture is not a particularly production use of resources. The 1% comes from i586 - i686; SSE2 would be additional on top of that. But given the vehement opposition, I can see dropping the SSE2 requirement. I'm still fairly convinced that going to i686 is the right move - we really don't support i586 as a practical matter, and even the Geode should still work with that. Furthermore, it's likely we'll have a mass rebuild for LZMA support and/or debuginfo changes, so it's no additional cost. Great, i686 without SSE(2) seems OK to me. I even wonder why we did not go to that requirement in F11 already without the intermediate ~i586 requirement. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb Because Pentium II and lower support i586 arch. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Sat, Jun 13, 2009 at 11:38 PM, Bradley Baetz bba...@gmail.com wrote: On 14/06/09 04:53, Robert 'Bob' Jensen wrote: - Frank Murphyfrankl...@gmail.com wrote: Just curious. But if a user has bandwidth problems, how is\are mutiple CD's going to help, or is it purely on hardware grounds, no dvd-rom. Does no one remember what happened last time the CD ball was dropped? Lets not repeat history just for fun. We have been down this road before, it was ugly and only lasted one release. Torrent tracker numbers BTW do not always tell the truth. In many cases in these less fortunate areas one person will download the ISO images, then make CDs for any one in the surrounding villages. Sneakernet is alive and well. I asked about this topic a few minutes ago in the #fedora-social IRC channel because we seemed to have a pretty diverse mix of people chatting. There was a resounding response that the CDs need to be kept. What about a script that takes the DVD image and produces CD .isos? That saves on mirror space, but still allows people who want/need CDs to make them. Although it would require (temporarily) 2-3 times the disk space for that process, I guess. Bradley A script that takes the DVD image to produce the CD versions would basically require extracting the whole DVD image and then generating new ISOs from that tree. Maybe mirrors could do it if you want to save space on the main server or whatever. Also, maybe we should support PXE/network booting the Live version from mirrors or whatever with the advent of netbooks and other computers without an optical drive. While doing it via USB is preferable, it is not always possible. For example I have a laptop with a completely damaged drive bay where the CD drive is and it does not support booting from USB devices. Being able to boot the Live distro from a network would be a great alternative. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Sun, Jun 14, 2009 at 9:47 AM, Jesse Keating jkeat...@j2solutions.netwrote: On Jun 14, 2009, at 1:30, King InuYasha ngomp...@gmail.com wrote: On Sat, Jun 13, 2009 at 11:38 PM, Bradley Baetz bba...@gmail.com bba...@gmail.com wrote: On 14/06/09 04:53, Robert 'Bob' Jensen wrote: - Frank Murphy frankl...@gmail.comfrankl...@gmail.com wrote: Just curious. But if a user has bandwidth problems, how is\are mutiple CD's going to help, or is it purely on hardware grounds, no dvd-rom. Does no one remember what happened last time the CD ball was dropped? Lets not repeat history just for fun. We have been down this road before, it was ugly and only lasted one release. Torrent tracker numbers BTW do not always tell the truth. In many cases in these less fortunate areas one person will download the ISO images, then make CDs for any one in the surrounding villages. Sneakernet is alive and well. I asked about this topic a few minutes ago in the #fedora-social IRC channel because we seemed to have a pretty diverse mix of people chatting. There was a resounding response that the CDs need to be kept. What about a script that takes the DVD image and produces CD .isos? That saves on mirror space, but still allows people who want/need CDs to make them. Although it would require (temporarily) 2-3 times the disk space for that process, I guess. Bradley A script that takes the DVD image to produce the CD versions would basically require extracting the whole DVD image and then generating new ISOs from that tree. Maybe mirrors could do it if you want to save space on the main server or whatever. Also, maybe we should support PXE/network booting the Live version from mirrors or whatever with the advent of netbooks and other computers without an optical drive. While doing it via USB is preferable, it is not always possible. For example I have a laptop with a completely damaged drive bay where the CD drive is and it does not support booting from USB devices. Being able to boot the Live distro from a network would be a great alternative. Why the live and not the normal install via pxe? -- Jes It's more useful, and its smaller. Being able to use the live version through a network would make it easier for remote or thin client setup, where you don't want the state of the OS to change in any form of permanence. For example, loading the live image without persistence to older machines and when client users are done and shutdown the machine, nothing is saved. No viruses, documents, personal information, etc. Additionally, diagnosing issues with machines using PXE live would be much nicer than using DOS disks or the Windows recovery console, which is practically useless. Or even diagnosing issues with installed versions of Linux or BSD. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 8:00 PM, Matthew Garrett m...@redhat.com wrote: On Wed, Jun 10, 2009 at 05:03:56PM -0500, King InuYasha wrote: Well, not necessarily Mac OS X itself. Wouldn't the Darwin kernel require it anyway? I have been installing Chameleon so I could boot the regular Darwin kernel and userland because I was told I needed a form of EFI to use the Darwin kernel. The Darwin kernel runs absolutely fine without EFI. -- Matthew Garrett | mj...@srcf.ucam.org Oh, thanks. Then I guess I don't need that... That makes my life a lot easier. It is quite difficult to install chameleon without a Darwin system already on hand, and I cringe every time I have to do it... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Tue, Jun 9, 2009 at 8:11 AM, Michal Nowak mno...@redhat.com wrote: Just noticed Canonical is pushing GRUB 2 as default in Ubuntu 9.10 [1]. There are some hints on testing [2] and from what I can see there are 40 bugs opened against GRUB 2 in launchpad [3] v. zero in our Bugzilla. Was wondering what's the plan for Fedora and GRUB 2 as I can see there's quite old snapshot in current Rawhide -- 1.98-0.5.20080827svn.fc11. -- [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-June/000573.html [2] https://wiki.ubuntu.com/KernelTeam/Grub2Testing [3] https://bugs.launchpad.net/ubuntu/+source/grub2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 3:43 AM, Christopher Brown snecklif...@gmail.comwrote: 2009/6/10 King InuYasha ngomp...@gmail.com: I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much Actually the reverse is true, in that you will find that GRUB 2 will support fewer machines than GRUB Legacy. This is why, as the ubuntu page quite correctly states, upgrading a bootloader is at best frightening and risky. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list While that is true, I have already seen two of my machines unable to boot through GRUB Legacy that could through GRUB 2. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 9:50 AM, Dennis J. denni...@conversis.de wrote: On 06/10/2009 10:43 AM, Christopher Brown wrote: 2009/6/10 King InuYashangomp...@gmail.com: I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much Actually the reverse is true, in that you will find that GRUB 2 will support fewer machines than GRUB Legacy. This is why, as the ubuntu page quite correctly states, upgrading a bootloader is at best frightening and risky. So what is the deal with GRUB development? I find it strange that upstream already has declared the old GRUB Legacy even though GRUB 2 isn't ready for prime time yet. Has the patch for full ext4 support that has been mentioned before landed in upstream yet? What is the timetable to get GRUB 2 ready for primetime? Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 11:41 AM, Dennis J. denni...@conversis.de wrote: On 06/10/2009 06:36 PM, Adam Jackson wrote: On Wed, 2009-06-10 at 11:07 -0500, King InuYasha wrote: Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 The grub we're already shipping has EFI support. I have yet to hear of a problem we're actually having that would be solved with grub2. If that's the case then it obviously makes sense to stick with grub legacy but given it's status who is going to be upstream for this? What I fear is a similar situation like we had with rpm where nobody really took ownership and vendors carried their own individual patches wich doesn't really work well with fedoras stay close to upstream mantra. Regards, Dennis We are already in that position. However, with Ubuntu's apparent willingness to test and see if GRUB 2 is worthy of being used in Ubuntu 9.10, other distros may actually do so as well. Perhaps Fedora should do a test day or something after figuring out what features we need our boot loader to actually support and if GRUB 2 would fulfill the requirements. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 4:53 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2009-06-10 at 15:13 -0500, King InuYasha wrote: EFI support is not the same as fake-EFI. Your mail client has atrociously bad indentation. Fix it. It appears from light googling that what you mean by fake EFI is a boot loader that fakes enough of EFI to be able to boot OSX on a non-Apple machine. I wasn't aware it was a goal of the Fedora project to enable you to boot some _other_ OS on arbitrary hardware, when the license of that other OS expressly forbids you from doing so. - ajax -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Well, not necessarily Mac OS X itself. Wouldn't the Darwin kernel require it anyway? I have been installing Chameleon so I could boot the regular Darwin kernel and userland because I was told I needed a form of EFI to use the Darwin kernel. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mono ( Moonlight) Licensing? Revisited
On Sat, Jun 6, 2009 at 11:36 AM, Kevin Kofler kevin.kof...@chello.atwrote: King InuYasha wrote: Then don't use FFmpeg. And since Moonlight itself will not contain the MS codec pack, it can still fit in main Fedora repositories. So you're suggesting we should promote the proprietary M$ codec pack instead of the Free alternative just so we can ship a semi-working Moonlight with no audio/video support in Fedora rather than RPM Fusion? That makes no sense whatsoever. And as has been said in this thread, Moonlight itself is also patent-encumbered. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Fedora has no trouble crippling software, so why would you think otherwise? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mono ( Moonlight) Licensing? Revisited
On Sun, May 31, 2009 at 12:15 PM, Kevin Kofler kevin.kof...@chello.atwrote: King InuYasha wrote: I really don't see why you should freak out over Moonlight, if Mono is protected, then Moonlight 2 should be protected, since it is a form of Mono itself. Moonlight needs to go to RPM Fusion anyway because it needs to link to FFmpeg, unless you want to use the proprietary codec pack from M$ (yuck!). So it's no use arguing about whether Moonlight itself is patent-encumbered or not. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Then don't use FFmpeg. And since Moonlight itself will not contain the MS codec pack, it can still fit in main Fedora repositories. If you don't want to do that, then find someone knowledgeable in GStreamer to write a GStreamer media backend for Moonlight. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 Test Day survey
On Wed, Jun 3, 2009 at 9:10 AM, James Laska jla...@redhat.com wrote: Greetings, The Fedora QA team would like your feedback on Fedora 11 Test Days. You may have seen Adam Williamson's planet post [1] kicking off Fedora 12 Test Day planning. We're interested in identifying areas for improvement to increase participation and improve effectiveness. Please take 10-15 minutes to answer any/all of the questions below. You may reply to the mailing list, or send feedback directly to me. Your responses to this survey are instrumental in making Fedora 12 Test Days successful. Many thanks to Chris Ward for his help in getting things moving with the survey questions! === 1. How did you find out about Fedora Test Days? 2. Was sufficient documentation available to help you participate in a Fedora Test Day? If not, what did you find missing or in need of improvement? 3. Did you encounter any obstacles preventing participation in Fedora test Days? How might they have been avoided? Did you discover any workaround? 4. Were you able to locate and download installation media for testing? Did it function as expected? 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? 6. Would you participate again in future Fedora Test Days? 7. Do you have any more general comments or any suggestions for improving future test days? === Thanks, James [1] http://www.happyassassin.net/2009/06/02/whats-goin-on-f12-test-days/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I'll answer these in order. 1. I got lucky when I looked in the mailing list. 2. Yes there was good enough docs for the test days to help me participate. 3. My biggest obstacle with test days was that they were not planned early enough. Most of the test days seemed to be planned less than 48 hours ahead of time. If test days were planned better, I could actually participate more. 4. Yes, I was able to download them. No, the media didn't work. It generally hung the computer, but that's not the fault of the test days. 5. I would expect a recap of the testing efforts so that Fedora people could analyze what the issues were, track them, and fix them. I suppose they are. The mailing list enabled them to do this, but there was no formal method of doing it. 6. If they were planned better, then maybe I would be able to set aside time to do them. I would like to participate in future Test Days. 7. Set up a reporting center just for Test Day feedback. Using the wiki is definitely not good enough. Additionally, Do not limit the test days to people subscribed to the mailing list. Take a page from Mozilla's books and announce those test days to the world. Unfortunately, to do that, test days need to be planned better. Hopefully this feedback helps :) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
