Re: Sources file audit - 2010-01-05
On Wed, Jan 06, 2010 at 11:38:20AM -0700, Kevin Fenzi wrote:
- BADURL:base-file-name:$PACKAGENAME
This means that the URI provided in the Source(s) line didn't result in
a download of the source. This could be any of: URL changed, version
changed and URL wasn't updated, Site is down, Site is gone, etc.
Also there are a number of packages with incorrect sourceforge links.
(BTW, there are still some packages with ftp://people.redhat.com/
URLs). This could also be a transitory network failure from my checking
host or the project hosting.
davej:BADURL:midisport-firmware-1.2.tar.gz:midisport-firmware
so %{version} in the Source: line isn't allowed any more ?
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Sources file audit - 2010-01-05
On Wed, Jan 06, 2010 at 09:59:06PM +0200, Kalev Lember wrote:
On 01/06/2010 09:24 PM, Dave Jones wrote:
On Wed, Jan 06, 2010 at 11:38:20AM -0700, Kevin Fenzi wrote:
- BADURL:base-file-name:$PACKAGENAME
This means that the URI provided in the Source(s) line didn't result in
a download of the source. This could be any of: URL changed, version
changed and URL wasn't updated, Site is down, Site is gone, etc.
Also there are a number of packages with incorrect sourceforge links.
(BTW, there are still some packages with ftp://people.redhat.com/
URLs). This could also be a transitory network failure from my checking
host or the project hosting.
davej:BADURL:midisport-firmware-1.2.tar.gz:midisport-firmware
so %{version} in the Source: line isn't allowed any more ?
See the logs [1], what really happened was that sourceforge replied
with 504 Gateway Time-out.
[1]
http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20100105/midisport-firmware-dl.txt
Looks like some genius at sourceforge moved stuff to a different host, with a
different dir structure.
If you go to the project pages, you see all the tarballs have been moved.
Before..
Source0:
http://download.sourceforge.net/usb-midi-fw/midisport-firmware-%{version}.tar.gz
After
Source0:
http://downloads.sourceforge.net/project/usb-midi-fw/midisport-firmware/%{version}.tar.gz
sigh.
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Mon, Dec 14, 2009 at 08:22:09PM -0800, Jesse Keating wrote: On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel This was the wrong path: git clone git://publictest5.fedoraproject.org/pkgs/kernel I'm on vacation, but I couldn't resist taking a look-see. Something looks odd. It appears to have collapsed every CVS branch onto the master git branch instead of making a new branch for each CVS branch. Running git log on the master branch should only show the commits that happened to HEAD in cvs. This might not matter much for most packages, but the kernel does have a lot of (mostly useless) branches, so the history looks a bit messy. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, Dec 15, 2009 at 12:54:44PM -0800, Jesse Keating wrote: On Tue, 2009-12-15 at 15:49 -0500, Dave Jones wrote: I'm on vacation, but I couldn't resist taking a look-see. Something looks odd. It appears to have collapsed every CVS branch onto the master git branch instead of making a new branch for each CVS branch. Running git log on the master branch should only show the commits that happened to HEAD in cvs. This might not matter much for most packages, but the kernel does have a lot of (mostly useless) branches, so the history looks a bit messy. That's strange, when I clone and do a git branch -r, I see 142 branches, lots of those private-* branches. Right I see those too. But locally, there's just '* master', and all the private-* commits seem to have been squashed onto that. What things that were CVS branches are you seeing on origin/master ? run git log, and see all the myoung commits for example. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
memset bugs.
There's some obvious bugs below in a bunch of packages. The 2nd and 3rd arguments to memset calls are the wrong way around. I found these after grepping through a make prep'd devel/ tree. 15 hits out of 100G of source code isn't that bad, but we can do better! Dave Checking ./afflib/afflib-3.5.2/lib/s3_glue.cpp Found memset with swapped arguments. 303:memset(b64str,sizeof(b64str),0); Checking ./afflib/afflib-3.5.2/lib/vnode_s3.cpp Found memset with swapped arguments. 205:memset(segname,segname_len,0); Checking ./afflib/afflib-3.5.2/lib/crypto.cpp Found memset with swapped arguments. 975:memset(decrypted,total_encrypted_bytes,0); // overwrite our temp buffer Checking ./panoglview/panoglview-0.2.2/src/panocanvas.cpp Found memset with swapped arguments. 160: memset(tmp,m_maxsize*m_maxsize,0); Checking ./condor/condor-7.2.4/src/condor_c++_util/read_user_log_state.cpp Found memset with swapped arguments. 497:memset( istate-m_base_path, sizeof(istate-m_base_path), 0 ); Checking ./milkytracker/milkytracker-0.90.80/src/milkyplay/LoaderPSM.cpp Found memset with swapped arguments. 999:memset(packed,size-4+5,0); Checking ./sim/sim/sim/sockfactory.cpp Found memset with swapped arguments. 546:memset(addr, sizeof(addr), 0); Checking ./commoncpp2/commoncpp2-1.7.3/src/thread.cpp Found memset with swapped arguments. 525:memset(act, sizeof(act), 0); Checking ./commoncpp2/commoncpp2-1.7.3/src/socket.cpp Found memset with swapped arguments. 1571: memset(group, sizeof(group), 0); Checking ./celestia/celestia-1.5.1/src/celestia/winmain.cpp Found memset with swapped arguments. 2181:memset(info, sizeof(info), 0); Checking ./scummvm/scummvm-0.13.1/engines/tinsel/scene.cpp Found memset with swapped arguments. 132:memset(tempStruc, sizeof(SCENE_STRUC), 0); Checking ./aqsis/aqsis-1.6.0/tools/displays/sdcWin32/d_sdcWin32.cpp Found memset with swapped arguments. 250:memset(g_Data, sizeof(AppData), 0); Checking ./aqsis/aqsis-1.6.0/tools/displays/sdcBMP/d_sdcBMP.cpp Found memset with swapped arguments. 172:memset(g_Data, sizeof(AppData), 0); Checking ./arm4/arm4-0.8.2/src/libarm4db/berkeleydb/BerkeleyDB_report.cpp Found memset with swapped arguments. 1603: memset (summary_ptr, sizeof (*summary_ptr), 0); Checking ./arm4/arm4-0.8.2/src/libarm4db/Arm4dbDaemonSharedMemory.cpp Found memset with swapped arguments. 558:memset (stats_ptr, sizeof (*stats_ptr), 0); -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
On Wed, Nov 25, 2009 at 01:58:38PM -0500, Jakub Jelinek wrote: On Wed, Nov 25, 2009 at 01:43:13PM -0500, Dave Jones wrote: There's some obvious bugs below in a bunch of packages. The 2nd and 3rd arguments to memset calls are the wrong way around. I found these after grepping through a make prep'd devel/ tree. 15 hits out of 100G of source code isn't that bad, but we can do better! glibc headers warn about this (when -D_FORTIFY_SOURCE=2), so a faster way would be just grep through all packages' build.log files (preferrably on the box where they are stored to avoid downloading it all). Can we make it fail the build instead of warning ? A zero sized memset is always a bug. Dave -- 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 Thu, Nov 19, 2009 at 04:13:39PM -0500, Casey Dahlin wrote: Most recent 32-bit Intels can address 32GB of system memory. It might be possible, but it's really not a good idea. Even 16GB is pushing it. At that point, your lower 1GB of memory is so full of page structs, that quickly invoking the oom-killer is inevitable. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Should installkernel be passing --dracut to new-kernel-pkg?
On Thu, Oct 22, 2009 at 08:48:03AM -0400, Stephen Smalley wrote: Hi, /sbin/installkernel doesn't pass --dracut to /sbin/new-kernel-pkg, so a make install from a kernel.org kernel tree tries to invoke /sbin/mkinitrd rather than dracut. Is that intentional? Also, any ideas on why a dracut-generated initramfs image generated for a kernel.org kernel tree would be so much larger than the Fedora kernel one (same .config)? 12M /boot/initramfs-2.6.31.1-56.fc12.x86_64.img 82M /boot/initramfs-2.6.32-rc2.img Do you have CONFIG_DEBUG_INFO set ? The kernel specfile strips the debug info out to separate debuginfo packages. If you build it by hand, that doesn't happen, so you get all the symbols etc attached to every module in your initramfs. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote: The problem I have is that some folks want to include additional drivers into their initrd. examples please. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Fri, Sep 04, 2009 at 08:30:14AM +0200, Jim Meyering wrote: Quick summary: use this tool: http://clang-analyzer.llvm.org/ If you're not using its scan-build tool, then start. Right now. Really. It's that good. Recently I've run it on a variety of packages, from coreutils (of course) to libvirt -- and libxml2 on request by the maintainer. To use them, build the tools described here, from source: (currently, there is no fedora package, afaik) http://clang-analyzer.llvm.org/ I ran them like this for libxml2: scan-build -o clang ./autogen.sh scan-build -o clang make This does look neat. When I tried it though, I ended up with .. scan-build: Removing directory '/mnt/data/src/git-trees/kernel/linux-2.6/clang/2009-09-04-1' because it contains no reports. While I'd love to believe the kernel is bug free, I have a hard time convincing myself that clang is doing the right thing. I added a path to the clang bin/ dir, and copied scan-build to my ~/bin and then ran with 'make defconfig ; scan-build -o clang make bzImage' Am I missing something obvious ? Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Fri, Sep 04, 2009 at 01:15:40PM -0400, Jeff Moyer wrote: I added a path to the clang bin/ dir, and copied scan-build to my ~/bin and then ran with 'make defconfig ; scan-build -o clang make bzImage' Am I missing something obvious ? It may be that the kernel defines $(CC) to gcc, at which point you lose. Try doing a make with CC=/path/to/ccc-analyzer. That was exactly it. Nice. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090902 changes
On Wed, Sep 02, 2009 at 08:44:00AM -0400, James Laska wrote: top post Heads up for anyone installing from rawhide today. A fix didn't land in time for anaconda-12.19 (see bug#520791), I've built an updates.img (http://jlaska.fedorapeople.org/520791-updates.img) for anyone interested in testing the installer today. Information on using an updates.img with anaconda is available at http://fedoraproject.org/wiki/Anaconda/Updates#Updates_from_the_Network. Thanks, James Even with this, it tracebacked during the tz selection screen for me on 2 separate installs.. https://bugzilla.redhat.com/show_bug.cgi?id=520826 kickstart installs seem to be the path to success for todays rawhide. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Policy on removing %changelog entries?
On Thu, Aug 27, 2009 at 01:36:26PM -0400, Tom spot Callaway wrote: On 08/27/2009 01:21 PM, Jeff Garzik wrote: What is the policy regarding deletion of individual entries in the middle of %changelog? A developer added a %changelog entry to each of my cloud daemons' packages, on the main fedora-cvs devel branch of each. Then, a day or so later, after other %changelog entries had been added by me... the same developer removed one %changelog entry from the middle of %changelog, and added another entry at the top. I thought the policy was to never delete %changelog entries, ever? Yeah, you really shouldn't delete %changelog entries. The only reasonable exception is that if you wanted to archive really old entries to keep the spec file small, I think that has been done in the past. We generally cull the kernel.spec once per release, because that thing grows to ridiculous length. For any kind of archaeology, hitting up the cvs server will tell you a lot more than the specfile will anyway. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel 2.6.29 for F10
On Tue, Aug 18, 2009 at 10:13:10AM -0500, Joe Nall wrote: On Aug 18, 2009, at 5:16 AM, Reindl Harald wrote: Hi Is there a reason that since longer time 2.6.29-Kernels for Fedora 10 landing in Updates-testing followed with 2.6.27-Builds in the meantime? On machines with kmods this is a real problem because yum detetects the kmod for 2.6.27-Build and wants to install the 2.6.27 kernel which conflicts with the installed one I use the 2.6.29 since months in the meantime, F11 has it since the release and i do not realize why F10 does not get him I tried to ask this on the fedora kernel list and the moderator never approved the message. Odd, I don't recall seeing it, and there's no non-spam messages in the queue right now. I too would like to see F10 move up to 2.6.29+ prior to end-of-life. In days of old, we were able to get rebases out pretty quickly after their upstream release. These days, we're hindered by the kernel modesetting stuff we're carrying. It's closely tied to the userspace X drivers, and isn't easy to retrofit to a different kernel. One of the reasons we haven't pushed them as proper updates is that getting the regressions fixed is pretty time consuming, and the limited X/KMS manpower we have is better focused on making the F12 stuff work right, and getting it upstream. I really can't wait for the day that it all gets upstream, and we can get back to the old routine of rebasing. Until then, we're kinda stuck. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Annoying kmemleak scans
On Tue, Aug 11, 2009 at 04:53:54PM +0200, Fabian Deutsch wrote: Hello. Starting with F11 kmemleak is part of the kernel huh? It's never been on in F11. In fact, the code isn't even present as an option there. (It's a post 2.6.30 feature) In rawhide, it was switched on for about a week a month or so back, and turned off because of the number of false positives being too high to make it useful. It might come back on for a short time periodically in rawhide, but generally, it's off. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing 11 packages as orphaned
On Fri, Jul 24, 2009 at 04:41:46AM +0530, Rahul Sundaram wrote: On 07/24/2009 04:37 AM, Michał Bentkowski wrote: Hi, due to lack of time and losing some enthusiasm, I want to orphan following packages: aria2 -- High speed download utility with resuming and segmented downloading cowsay -- Configurable speaking/thinking cow Taken these two. Co-maintainers welcome. Thank you for all the time you spend on maintaining these packages and good luck. I'm glad someone picked up cowsay. It's critical to kernel development. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090705 changes
On Sun, Jul 05, 2009 at 11:21:58AM +, Rawhide Report wrote: kernel-2.6.31-0.42.rc2.fc12 --- * Sat Jul 04 2009 Chuck Ebbert cebb...@redhat.com - 2.6.31-rc1-git11 * Sat Jul 04 2009 Dave Jones da...@redhat.com 2.6.31-0.42.rc2 - 2.6.31-rc2 * Fri Jul 03 2009 Hans de Goede hdego...@redhat.com - Disable v4l1 ov511 and quickcam_messenger drivers (obsoleted by v4l2 gspca subdrivers) Why is the changelog out of order in the rawhide report? It's the right way around in CVS. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: more debugging enabled in rawhide kernels.
On Thu, Jun 25, 2009 at 04:53:27PM +0100, Richard W.M. Jones wrote: On Wed, Jun 24, 2009 at 08:08:40PM -0400, Dave Jones wrote: In tomorrows rawhide kernel, I've enabled a debugging option called kmemleak. As the name suggests, this tracks memory allocations, and prints backtraces in cases where the memory is believed to be lost. As a general comment, I see many backtraces when I run the libguestfs testsuite. Most are harmless, in that they don't appear to affect the running of programs, so I don't report them. But is it helpful to report these? If so how - open BZs for each variation that I see? Everything I've seen so far looks like a false positive. The next build should reduce the number of these (hopefully dramatically). So for now, just hold off on filing anything. Dave -- 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 (#2)
On Sun, Jun 21, 2009 at 11:24:35PM +0930, Glen Turner wrote: F12 x86 will not work on i586 (or i686 without CMOV) Intel Pentium Intel Pentium Pro VIA Cyrix III VIA C3 and C3-M (Samuel 2) VIA C3 and C3-M (Ezra) VIA C3 and C3-M (Ezra-T) VIA Eden ESP (Samuel 2) .. Although this is the best I could do, the VIA situation is complex and errors in the above would not shock me. The original Samuel won't work either. Other than this omission, your table looks correct to me. There's also the AMD K5, K6, K6-2, K6-3 that won't work. And all the older Cyrix 6x86/MX/MII/MediaGX CPUs. (Though those things sucked even in 1990's, and I doubt they've improved with age) Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote: I *wish* it made a difference. I did an upgrade am an left with a host of fc10 packages because the fc11 ones weren't considered newer. For example people with updates-testing enabled on fc10 got a non-upgraded yum because the versions were the same (except for fc10/fc11) and it stopped working because python went from 2.5 to 2.6. That's messed up. We used to check just before release time that this situation never occured. It should probably be added to the rel-eng release checklist if it isn't there already. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaned packages fxload, unison*
On Fri, Jun 19, 2009 at 08:37:40PM -0600, Stephen Warren wrote: I've orphaned the fxload, unison213, unison227 packages. unison* have reverted ownership to gemi. fxload now has no maintainer. Unfortunately, with a young child, busy job, and the fact I switched my PC to Ubuntu, I'm not able to maintain these anymore. All of these packages are very low maintenance; since the initial creation, about the only activity has been mass rebuilds. fxload one of my packages (midisport-firmware) depends on this, so I'll take this one. Dave -- 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 Mon, Jun 15, 2009 at 01:53:13PM -0400, Bill Nottingham wrote: Way back when in February [1], FESCo decided that for Fedora 11, i586 would be the default architecture, and for Fedora 12, it would be some variant of i686. It's time to follow through on that action item. I've submitted https://fedoraproject.org/wiki/Features/F12X86Support. It defines the default arch as i686 + SSE2. Why? - Faster and more consistent FP math by using SSE2 registers - Allows for autovectorization by GCC where necessary - More clearly delineates our support set of targets, sticking true to forwards innovation, not necessarily legacy support What CPUs do we lose that F11 supports? - Intel i586 (all) judging by the number of 586 users who register with smolt (less than 0.1% our entire userbase), not that big a deal. - Intel Pentium Pro - Intel Pentium II - Intel Pentium III - 32-bit AMD Athlon These are more of a concern. It's difficult to tell from smolt just how big a deal these are. P3 Athlon especially. I poked Mike privately in the hope that we're gathering enough of /proc/cpuinfo that we can perhaps get some info on how much our userbase we'd be shutting off. I still have two machines that would be affected (one in actual production use as a backup server, the other just a testbox which is tbh rarely powered on) and I'm not even a good representation of our userbase (I ditched all my ancient junk a while back). - VIA C3 Some of the later C3's have SSE2, so wouldn't be affected. - AMD Geode - Transmeta Crusoe Running the shiny latest bits on these CPUs means you're already used to living with pain, so a secondary arch seems like the way forward. Does this lose the PAE/non-PAE kernel split? - Alas, no. Will a Fedora rebuilt in this manner work on ... - OLPC 1.0? No. - OLPC 1.5? Yes. - Atom? Yes. A seconday arch could be done for these older CPUs, if someone is interested enough. Comments? Flames? Predictions of doom? If we 2nd-arch these, I'm wondering if we should still do the kernel builds from the main package. If it's a significant number of users, we're going to end up with the bug reports anyway so it might as well be something we know we built etc.. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Sun, Jun 14, 2009 at 09:57:56PM -0500, Mike McGrath wrote: On Sun, 14 Jun 2009, Mike McGrath wrote: On Mon, 15 Jun 2009, Lennart Poettering wrote: On Mon, 15.06.09 09:15, James Morris (jmor...@namei.org) wrote: On Sun, 14 Jun 2009, Lennart Poettering wrote: much broken. It's a bit like SELinux: it's one of the first features most people disable. False. Most people leave SELinux enabled, according to the smolt stats which have been collecting since the F8 era. Are you speaking of the same smolt that lists es1371 as most popular sound card? i.e. a sound card that has been out of production since about 10 years now? Somehow I have serious doubts about the validity of the smolt data. Based on actual data research or your gut? Sidenote on this specific device, seems vmware emulates it so we should probably continue to support it :) The percentage column seems odd to me. Only 6% of users have the most popular sound device? I'm also surprised that the majority of our users that submit smolt data don't seem have any sound device at all. I always expected the server/desktop balance to be quite heavily skewed towards desktop. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wild and crazy times for the development tree
On Mon, Mar 20, 2006 at 10:04:46PM -0600, Callum Lerwick wrote: Especially with yum backed network installs becoming available. If you don't want to download and burn an entire DVD iso, just download a 10-50mb network install iso. This is what I do with debian on the rare occasion I install a system from scratch. Since I only install a system once every few years, its a huge waste to me to download and burn 5+ disks that I'm only going to use once. Someone on IRC was arguing that in many parts of the world, bandwidth is very expensive. I don't see how 5 CDs to download vs a DVD make a difference here. The real question is, how common are DVD burners, and most importantly, DVD readers in various parts of the world. DVD writers aren't anywhere near as commonplace as CD writers yet. Looking around right now, I have 7 computers near me. CD writers outnumber DVD writers 6:1. (And the majority of the computers with CD writers are less than 2 years old (two of them are 6 months old)) (ironically, the dvd writer is my 3 month old laptop) I'm not claiming to be representative of the majority of Fedora users, but given there are a lot of Fedora users less fortunate than myself, I believe that discontinuing CD iso's would severely impact a huge portion of our userbase. It'd be interesting to see the download stats to see if they agree with this. Dave -- http://www.codemonkey.org.uk
Re: Wild and crazy times for the development tree
On Mon, Mar 20, 2006 at 11:35:47PM -0500, Bill Nottingham wrote: Dave Jones (da...@redhat.com) said: I'm not claiming to be representative of the majority of Fedora users, but given there are a lot of Fedora users less fortunate than myself, I believe that discontinuing CD iso's would severely impact a huge portion of our userbase. It'd be interesting to see the download stats to see if they agree with this. DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64, and 6:1 on ppc. Wow. I'm stunned. I guess I should stop living in the past and get some DVD writables ;) Dave -- http://www.codemonkey.org.uk
Re: Bluetooth missing from i586 kernel config?
On Thu, Mar 09, 2006 at 09:28:16AM +, Brian wrote: I've been struggling trying to get my USB bluetooth dongle to work on my i586 based MiniITX since I started trying FC5 (Test 3). The same BT dongle worked fine under the old FC4 installation. From what I can see, in the installed i586 kernel (2.6.15-1.2025_FC5) the drivers and net modules are all missing. To prove this I just installed the i686 kernel on another machine and bluetooth worked fine and the relevant directories with modules were present: over-aggressive slimming down of the 586 kernel. I had fixing that on my TODO, but it got bubbled down by other things in the last few days. I'll try and get to it tonight. Dave Thanks Dave! I'll stop hitting my head off the it's a configuration issue brick wall and put bluetooth use on hold till it's fixed. :-) I fixed it in CVS, will be in the next build. Dave -- http://www.codemonkey.org.uk
Re: Bluetooth missing from i586 kernel config?
On Wed, Mar 08, 2006 at 11:45:23PM +, Brian wrote: Hi, I've been struggling trying to get my USB bluetooth dongle to work on my i586 based MiniITX since I started trying FC5 (Test 3). The same BT dongle worked fine under the old FC4 installation. From what I can see, in the installed i586 kernel (2.6.15-1.2025_FC5) the drivers and net modules are all missing. To prove this I just installed the i686 kernel on another machine and bluetooth worked fine and the relevant directories with modules were present: i.e. /lib/modules/2.6.15-1.2025_FC5/kernel/drivers/bluetooth /lib/modules/2.6.15-1.2025_FC5/kernel/net/bluetooth This seems to have been the case for all kernel builds I've tried in the past few weeks. Is this just an error in the config file used to compile the i586 kernel, or a concious decision to leave it out (in which case, shouldn't the bluetooth service be removed too as it's throwing errors on every boot?). I'm hoping it's just an error, as I can't bear to think about having to figure out how to manually compile every single new kernel from source just to get bluetooth back on my mini-itx machine! :-( over-aggressive slimming down of the 586 kernel. I had fixing that on my TODO, but it got bubbled down by other things in the last few days. I'll try and get to it tonight. Dave -- http://www.codemonkey.org.uk
