Re: Recompile kernel without SMP
On Monday 17 August 2009 20:17:29 Paul Grinberg wrote: Josh, I have a good reason for that. I use Cisco VPN client for Linux, and it does not work with SMP kernel. I vaguely recall using the cisco vpn client for linux on an smp kernel just fine, but I stopped using it years ago, as vpnc works well enough as a replacement for it. Thank you for the reply! Do you know how to fix it. What needs to be done to compile non-SMP? I do know how, but its semi-involved, and I'm afraid I'm a bit tied up with other slightly more pressing work. Short version is that you need to add a config-foo target in merge.pl, iirc, add that to the spec as another Source, tweak instances of %with_up within the spec file, and that would at least get you close. But again, I think this is really pointless, since 1) I'm pretty sure the cisco vpn client runs fine on smp 2) if it doesn't, vpnc works reasonably well to replace it and 3) you can likely just boot the current smp-enabled kernel with maxcpus=1 added to the command line to get up behavior if you absolutely must run the cisco vpn client in a single-processor environment. -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Recompile kernel without SMP
On Friday 14 August 2009 17:24:22 Paul Grinberg wrote:
Markus,
Thank you for your reply! I already feel better knowing that I'm not
alone :)
Maybe someone might have a clue Why
Fedora doesn't ship any single-proc kernels anymore except for on
powerpc32. The spec file and sources don't contain an UP target or
the necessary support bits (config-foo) to build one for anything but
powerpc32, because its mostly pointless.
-Original Message-
From: Markus Kesaromous [mailto:remotes...@live.com]
Sent: Friday, August 14, 2009 4:52 PM
To: Paul Grinberg; Linux Kernel List
Subject: RE: Recompile kernel without SMP
Date: Fri, 14 Aug 2009 14:35:22 -0400
From: pgrinb...@nyc.saic.com
To: fedora-kernel-list@redhat.com
Subject: Recompile kernel without SMP
Hi there,
I am trying to recompile kernel without SMP. So far I've been
unsuccessful. Meaning I am able to compile, but it was still SMP..
Can someone tell me what I am doing wrong?
And why I don't get kernel-headers build?
It is probably related to spec parameters
So far this is what I've done:
cd ~/
rpmdev-setuptree # as regular user
cd rmpbuild
yumdownloader --source kernel # as regular user
cd ~/rpmbuild/BUILD/kernel-2.6.29/linux-2.6.29.i686/
cp configs/kernel-2.6.29.6-i586.config .config
make menuconfig # console setup
Select option: Processor type and features.
Disable Symmetric multi-processing support (SMP)
cp .config ~/rpmbuild/SOURCES/config-i686-generic
cp .config ~/rpmbuild/SOURCES/config-i686
cd ~/rpmbuild/SPECS
nano kernel.spec
Add line:
% define buildid .NONSMP
Replace:
# Allow kernel-firmware building
#%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0}
%define with_firmware %{?_with_firmware: 0} %{?!_with_firmware: 1}
#%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware:
1}
%define with_firmware %{?_without_firmware: 1} %{?!_without_firmware:
0}
# Allow kernel-headers building
# Allow kernel-devel building
# Create RPM package
rpmbuild -bb --with firmware --target=i686 kernel.spec
# To actually install kernel
su
rpm -ivh kernel-firmware-2.6.29.6-217.2.3.nonsmp.fc11.i686.rpm
kernel-PAE-2.6.29.6-217.2.3.nonsmp.fc11.i686.rpm
kernel-PAE-devel-2.6.29.6-217.2.3.nonsmp.fc11.i686.rpm
Just in case:
$ cat config-i686-PAE | egrep -i smp | more
CONFIG_BROKEN_ON_SMP=y
# CONFIG_SMP is not set
CONFIG_X86_FIND_SMP_CONFIG=y
# CONFIG_X86_VSMP is not set
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_VIDEO_VP27SMPX=m
Best,
Paul
I just got bit by a similar problem in trying to build
kernel-2.6.31-0.125.4.2.rc5.git2.fc12.src.rpm
I followed the steps outlined in
http://fedoraproject.org/wiki/Docs/CustomKernel
I only wanted to build i686 architecture
- without SMP
- without cpu id support
- without multicore support
- without hyperthreading support
- with kernel config support
- with kernel config via /proc support
- with frequency default governor set to Performance
- with preemptible kernel
- with rt2860 module support
- with NTFS read/write support
Well, it ended up building i686-PAE Debug kernel with SMP support.
It seems as if the architecture is i686, then only i686 PAE Debug gets
built.
I do not know where the problem lies, but SOURCES/Makefile.config
might be the place where the target kernel build is being selected.
To get around it, I edited
...SOURCES/Makefile.config and removed all rules and definitions
pertaining to i686-PAE and only left the simple i686 def and rule.
PS: I do not know if this is necessary, but after I copied .config to
...SOURCES/config-i686
I also copied it to
...SOURCES/config-x86-generic
Then running rpmbuild -v -bb --target=i686 kernel.spec
is proceeding without problems
MK
--
Jarod Wilson
ja...@redhat.com
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel Loading Sequence
On Monday 06 July 2009 11:57:47 Ahmad Al-Yaman wrote: Hi all, I came across a problem when trying to compile a custom kernel for F11: both the stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock kernel the loading screen starts up immediately when the kernel starts loading, but using the custom kernel, some text is displayed before the loading screen starts up (the kernel finishes loading without problems). I'm trying to figure out the reason for this and if there's a way to fix it so that the user doesn't see this text. Could the reason be the order in which different parts of the kernel are loaded? If yes, how can I control which parts load first? Is your 'custom kernel' an F11 kernel + your patches, or starting from an upstream tarball + your patches? (In which case, its lacking all the patches Fedora has added, and therein probably lies your answer to why things are behaving differently). -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: EDAC on AMD with Fedora 10
On Wednesday 15 April 2009 05:13:36 Jeremy Sanders wrote: Chuck Ebbert wrote: According to the kernel Kconfig file it's only available for old 32-bit Athlons, and it is in the i686 kernel(s). config EDAC_AMD76X tristate AMD 76x (760, 762, 768) depends on EDAC_MM_EDAC PCI X86_32 help Support for error detection and correction on the AMD 76x series of chipsets used with the Athlon processor. Thanks. I didn't realise it was only 32 bit athlons only. Any idea what EDAC modules 64 bit Athlon 64s should use? Under RHEL the k8_edac module provides ECC checking, but this module no longer exists as far as I can tell in Fedora 10. I seems strange that Fedora doesn't support ECC on AMD systems, but RHEL does! The k8_edac module in RHEL5 is there via an out-of-tree patch. I can't recall why, but upstream had issues with the code, so it has yet to be merged into Linus' kernel, thus the reason its not in the Fedora kernel. CC'ing Aris, who might have a better idea on upstream progress of that code... -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] squashfs broken when pageszie blocksize
On Tuesday 14 April 2009 08:57:07 Josh Boyer wrote: On Tue, Apr 14, 2009 at 08:18:40AM -0400, Doug Chapman wrote: Not sure if we are too late for F11 on this or not but this patch is needed to be able to mount squashfs (as used by anaconda) on ia64. Our goal is to be able to build Fedora on ia64 with no custom SRPMs so it would be appreciated if this could be pulled in. It would be needed for ppc64 kernels using a 64KiB pagesize as well from what I can see. Sounds like a good idea to me. Committed to the F11 branch. Not needed for F10 and earlier, since they're still using squashfs v3, even for the 2.6.29.x builds. Will just let it trickle in via upstream for the devel branch. -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] x86: fix DMI for EFI
On Friday 06 March 2009 15:38:40 Brian Maly wrote: I had attached the patch in my previous post but the patch seems to have been stripped off once it got posted to the list. I can forward a patch to whomever needs it if its undesirable to extract from the commit info. Just let me know what works best. It'll get picked up via an upstream rebase long before then. I saw it last night in rc7-git2, and that or later is bound to be pulled into rawhide long before April (its likely to get in today). -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: File conflicts between alsa-firmware and kernel-firmware
On Saturday 28 February 2009 11:47:57 Tim Jackson wrote: I maintain alsa-firmware and the following bug regarding file conflicts between recent versions of kernel-firmware and alsa-firmware got raised today: https://bugzilla.redhat.com/show_bug.cgi?id=487873 I'm not really familiar with the kernel package maintenance, nor who/what governs what firmware goes into kernel-firmware (and indeed how that is related to the upstream kernel). I had a cursory look at the kernel spec in CVS but that didn't appear to have any relevant recent changes that were obvious. I did a diff between the firmware in alsa-firmware and in kernel-firmware-2.6.29-0.172.rc6.git4.fc11 and it's clear that although there are some overlaps, much of the audio firmware in alsa-firmware isn't in kernel-firmware. The current conflicting files are: ess/* korg/* sb16/* yamaha/ds1_ctrl.fw yamaha/ds1_dsp.fw yamaha/ds1e_ctrl.fw Things that are in alsa-firmware but NOT in the above version of kernel-firmware are: asihpi/* digiface* 3g* ea/* emu/* mixart/* multiface* pcxhr/* vx/* yamaha/yss225_registers.bin [usx2y, which does something funky so it's not in /lib/firmware] Either way, it looks like we need to work together on this. - I'm happy to just drop the conflicting files from alsa-firmware - is that the right thing to do? I'd say yes. The versions shipped in the kernel are (supposed to be) known to work with the matching shipped kernel code. - Are the above audio firmware files in kernel-firmware there to stay? They're put into kernel-firmware as part of the kernel's firmware build process, so as long as they're part of the kernel, yeah, they'll be there. - Is there a long term goal to bring all the firmware from alsa-firmware upstream into the kernel-firmware package? No clue... Would have to talk to some alsa folks. -- Jarod Wilson ja...@redhat.com ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Friday 10 October 2008 17:27:00 Chris Snook wrote: Dave Jones wrote: For a while, diffs in the Fedora kernel have followed the form linux-2.6-*.patch Then, we started seeing some git snapshots show up as git-*.diff and lately, everything seems to have gone bananas, with no particular scheme at all.. nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc. Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else. So, what are peoples thoughts on this? Dave If we'd prefix them with the source package name, in this case kernel, it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream. Yeah, I'd be happy with pkgname-tree id-description.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch naming scheme.
On Friday 10 October 2008 20:37:24 Dave Jones wrote: On Fri, Oct 10, 2008 at 05:55:50PM -0400, Jarod Wilson wrote: On Friday 10 October 2008 17:27:00 Chris Snook wrote: Dave Jones wrote: For a while, diffs in the Fedora kernel have followed the form linux-2.6-*.patch Then, we started seeing some git snapshots show up as git-*.diff and lately, everything seems to have gone bananas, with no particular scheme at all.. nvidia-agp.patch, percpu_counter_sum_cleanup.patch, xfs-barrier-fix.patch etc etc. Maybe I'm being overly anal. The linux-2.6- prefix is kind of pointless (given that duh, they're all going to be against Linux 2.6), but it does group things nicely in an ls output if nothing else. So, what are peoples thoughts on this? Dave If we'd prefix them with the source package name, in this case kernel, it would make it a lot easier to find things in /usr/src/redhat/SOURCES when we've got SRPMs from different packages installed. We should probably avoid using names that refer to a specific upstream version, because the name becomes misleading once we rebase. When there's a suitable upstream patch name, like the names Andrew Morton uses in -mm, we should probably use those (perhaps prepended with kernel-) to make it clear what it corresponds to upstream. Yeah, I'd be happy with pkgname-tree id-description.patch, omitting the tree id portion if there isn't one, or some variant thereof. Being able to do an 'ls kernel*.patch' is definitely useful. kernel-* is sacred. Tab completion ftw. :) Ah, good point, s/kernel/linux/ then maybe? -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: boot failures on very-large systems with CONFIG_SYSFS_DEPRECATED not set
On Monday 25 August 2008 14:27:16 Doug Chapman wrote: Sometime leading up to the F9 kernel my very large ia64 system (64 cpu 1TB ram, bunch of PCI busses and I/O) fails to boot. It appears to be something in how nash/mkinitrd gets information from sysfs. Since this is an early boot-time issue and nash isn't very easy to debug I am having trouble getting to the root of the issue (but I am still investigating). I have however found what change triggered this. The default config file used to have CONFIG_SYSFS_DEPRECATED=y set. Upstream kernel commit d47846c5866b7d98a1173c86a39d810a06647329 renamed this to CONFIG_SYSFS_DEPRECATED_V2. It appears the default is still y however somehow with the transition the Fedora kernel now has this off. If possible I would like to see this get set to y for now. I will continue to debug this as it certainly _should_ boot just fine without this set. Even if we just turn it on for ia64 that works for me (but I imagine some new big x86_64 systems may run into it once they grow this large). Just committed the change to flip those on for ia64-only. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
RFC: split changelog out of spec
Hey all,
Been toying with the idea of splitting the changelog out of the kernel spec
itself, to reduce the size of the spec file. Basically, instead of %changelog
followed by all the entries, it'd be %include %{SOURCE1}, which is a file
'fedora-kernel-changelog', which carries all the usual changelog entries. Its
reasonably trivial to implement, though my current hack-around for 'make clog'
complains about me redefining the clog target. Is shaving 800+ lines out of
the spec file (only to put them in another file) worth the hassle though?
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: split changelog out of spec
John W. Linville wrote:
On Mon, Aug 18, 2008 at 07:43:49PM +0200, drago01 wrote:
On Mon, Aug 18, 2008 at 7:41 PM, Jarod Wilson [EMAIL PROTECTED] wrote:
We could also, if so desired, install the split-out changelog as a %doc
file, the thought being that not everyone knows to look at 'rpm -q
--changelog' output or look in the srpm/cvs/etc to see what's changed.
This would just confuse user and is inconsistent with the rest of the distro...
How so?
I presume the rpm command would still work
Correct.
so I would see no harm
in adding the changelog as a %doc (if/when it is broken-out from the
spec file).
Just to be clear... To make sure its 100% clear which kernel the changelog
matches up with, it'd have to be %doc'd for each kernel and kernel-flavour, so
it winds up in /usr/share/doc/kernel%{?flavour:-%{flavour}}-%{version}. If its
part of kernel-doc, I think its not always obvious which actual kernel package
it matches.
With those clarifications, I don't see how it'd be confusing, or how it would
cause any meaningful consistency problems with other distros. But please do
enlighten me if I'm missing something. :)
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware --without vdso_install build options
On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote: Chuck Ebbert wrote: Steve Dickson wrote: Now that devel kernels rpms require the kernel-firmware rpm, it makes sense to me that one should be able to build both of them at the same time. So this patch adds the --with firmware build option which will allow kernel-firmware rpms to built with kernel rpms. This patch also adds the --without vdso_install build option which stop the VDSO binaries from being installed. This cuts down the overall build time especially when you build over NFS like I do.. Signed-Off-By: Steve Dickson [EMAIL PROTECTED] With one small change we can still support --without firmware. That way the default behavior can be overridden in either case. See below... Sure.. that works... Is there an ETA for these two changes? I don't quite follow how the firmware change is supposed to work... The firmware is currently supposed to be a noarch package, and it gets built in the same pass as the kernel-docs sub-package, so it *shouldn't* be built in the same pass as the kernel. Is this flag to simply override that and build the firmware as an arch-specific package for simplified one-off builds? -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel module options for cpufreq
On Monday 30 June 2008 05:54:32 am Richard Hughes wrote: Right, cheers for your feedback. In view of everybodies comments, what about the following: * Compile _into_ the kernel ondemand, performance, powersave and userspace. Sounds reasonable. * Default to performance in the kernel rather than userspace What's the difference? Both leave the cpu at its max speed all the time, unless the cpuspeed daemon gets started up in the userspace case. * Build as a module conservative with the view of just fixing ondemand if there are any special use-cases that conservative is better at * Export the P and C state latency to userspace and let the system policy dictate the governor. For instance, even for machines that have a long latency for changing P states should be able to use ondemand if we want to save maximum power. How does that sound? Mostly sane. System policy dictating governor over the ugliness we do in the cpuspeed init script would be nice. Even nicer would be if we could outright get rid of the initscript (not sure what people who need the cpuspeed daemon are to do in that case though). -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
On Monday 09 June 2008 06:04:08 am David Woodhouse wrote: Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. Other comments? We actually *can* make it noarch without much effort -- remember, the kernel is a special beast that actually does get a noarch build pass done on it for kernel-docs. No reason kernel-firmware couldn't be spit out from the same build run, so far as I know. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
David Woodhouse wrote: Been playing with how I'd make the kernel package deal with the new 'make firmware_install' stuff. Currently looks something like this. I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Yeah, seems the sanest thing to do at least initially, so people don't suddenly wind up with non-functional devices. Should the package own the /lib/firmware/ directory? Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
David Woodhouse wrote: On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote: Not quite sure. udev owns it right now. Could have multiple ownership so as to not Requires: udev. Could possibly be something that should move to the filesystem package. I think I might lean toward making that directory owned by filesystem, so you have singular ownership and both udev and kernel-firmware can use it without either one explicitly requiring the other. I'm content with requiring udev -- since it's udev which is going to load anything that lives in /lib/firmware anyway, that actually makes some sense. Ah, okay, I figured udev typically would be wanted, but wasn't sure if some of this could be done sans-udev in some particular case. Just requiring udev does sound like the way to go then. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Don Zickus wrote: I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup? The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included. Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..). I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :) We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice. Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work. Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally. Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Jarod Wilson wrote: We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice. Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work. Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally. Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware. But of course, you've still got a system that at least boots, and can back-rev the firmware if needed, so not a big issue vs. boot-path-dependent firmware. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Firmware
Don Zickus wrote: On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote: Don Zickus wrote: I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware? Should the package own the /lib/firmware/ directory? Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm. I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup? The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included. Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..). I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :) Hmm, that would cause issues. But then when folks like qlogic have new fw, how do you update it successfully? Not sure. What happens in such cases today? Have to install a new kernel or kmod? A stub kernel? Ew. Perhaps creating a new initrd based on the same kernel and a corresponding new grub entry (entry would consist of old kernel / new initrd image) would allow people to fallback to the old initrd image if the new one was bunk? Could get messy, littering /boot with old initrds that aren't cleaned up, and your bootloader with extra entries you may never use -- what would trigger their removal and when? I just assume leave out the auto-rebuilding of the initrd though. I think if you know you need/want new firmware for a device, you should be able to figure out how to create a new initrd with it (and save the old initrd as a fallback). I didn't find that scenario interesting because you already have your rootfs mounted so you could do other tricks to recover from that. Yeah, I sent a follow-up email saying the same, didn't take that into account until after hitting send, and my unsend button never seems to work... :) -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: how to recompile/rebuild fedora core 7 kernel
On Saturday 24 May 2008 03:11:04 am Nooruddin Dar wrote: i have linux-2.6.25.tar.bz2 kernel source i want to rebuild it and also want to add a system call in the kernel if any one knows about that plz reply i will wait for ur response This: http://fedoraproject.org/wiki/BuildingUpstreamKernel and this: http://fedoraproject.org/wiki/Docs/CustomKernel should help. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Package: kernel-2.6.25.1-1.fc10 Tag: dist-f10 Status: failed Built by: jwilson
On Saturday 03 May 2008 12:37:22 am Koji Build System wrote: Package: kernel-2.6.25.1-1.fc10 Tag: dist-f10 Status: failed Built by: jwilson ID: 47960 Started: Sat, 03 May 2008 03:42:41 UTC Finished: Sat, 03 May 2008 04:20:53 UTC Changelog: * Fri May 02 2008 Jarod Wilson [EMAIL PROTECTED] 2.6.25.1-1 - Linux 2.6.25.1 - Drop patches merged in 2.6.25.1: * linux-2.6-netdev-tehuti-check-register-size.patch * linux-2.6-netdev-tehuti-move-ioctl-perm-check-closer-to-function-start.patc h * linux-2.6-selinux-ssinitialized-bugon.patch * bits of wireless patches * Thu May 01 2008 Dave Airlie [EMAIL PROTECTED] 2.6.25-14 - fix radeon fast-user-switch oops + i915 breadcrumb oops * Wed Apr 30 2008 Chuck Ebbert [EMAIL PROTECTED] 2.6.25-13 - Fix drive detection on some Macbook models (#439398) - Fix oops in RAID code (#441765) kernel-2.6.25.1-1.fc10 (47960) failed on ppc4.fedora.phx.redhat.com (noarch), ppc4.fedora.phx.redhat.com (ppc): BuildrootError: error building package (arch ppc), mock exited with status 1 SRPMS: kernel-2.6.25.1-1.fc10.src.rpm Failed tasks: - Task 593871 on ppc4.fedora.phx.redhat.com Task Type: build (dist-f10, devel:kernel-2_6_25_1-1_fc10) Task 593873 on ppc4.fedora.phx.redhat.com Task Type: buildArch (kernel-2.6.25.1-1.fc10.src.rpm, ppc) logs: http://koji.fedoraproject.org/koji/getfile?taskID=593873name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=593873name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=593873name=state.log Anyone have any idea why the ppc build tanked like this? Will have to try a mock build once I have my ppc box back up and running in the new office... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Compiling a module outside kernel
On Wednesday 30 April 2008 11:28:15 am Robert M. Albrecht wrote: Hi Sam, I have a problem in compiling a kernel module (outside the kernel) in F9 (rawhide). Perhaps someone could enlighten me. [EMAIL PROTECTED] toshiba_acpi]# ll insgesamt 24 -rw-r--r-- 1 root root 145 29. Apr 17:49 Makefile -rw-r--r-- 1 root root 19774 28. Apr 21:46 toshiba_acpi.c [EMAIL PROTECTED] toshiba_acpi]# make make: F?r das Ziel ?default? ist nichts zu tun. [EMAIL PROTECTED] toshiba_acpi]# cat Makefile obj-m := toshiba_acpi.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) M=$(PWD) modules [EMAIL PROTECTED] toshiba_acpi]# Nothing happens. Has the Makefile to be changed for F9 or do I make a stupid mistake ? The Makefile looks correct at a glance... Do you kernel-devel installed? If not, build will be a dangling symlink... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: patch to remove utrace patch for ia64
On Tuesday 01 April 2008 10:40:02 am Doug Chapman wrote: As discussed in another thread the utrace support for ia64 is not complete upstream yet. The current utrace patch breaks building on ia64. To allow us to continue progress on ia64 can we apply this patch until these issues are resolved? Done. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
On Monday 31 March 2008 03:00:00 am Ananth N Mavinakayanahalli wrote: Hi, Updating my rawhide box, I found: kernel-debuginfo i686 2.6.25-0.172.rc7.git4.fc9 rawhide-debuginfo 47 k kernel-debuginfo-common i686 2.6.25-0.172.rc7.git4.fc9 rawhide-debuginfo 486 M - Did anything in the F9 builds change that lead to this more than two-fold increase in the debuginfo size? - Or is it that the common rpm needs updation once every kernel release with just updates for every update to the same release thereafter? There's a problem with some of the changes I made to add arch to our uname -r output screwing with debuginfo a bit. The size isn't double though. Before -- kernel-debuginfo: ~198M kernel-debuginfo-common: ~32M Now --- kernel-debuginfo: 47k kernel-debuginfo-common: 230M So same size overall, I just haven't got all the bits getting into the right sub-packages. Working on fixing that now. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Rawhide kernel debuginfo size more than doubled!
On Monday 31 March 2008 03:45:25 pm Roland McGrath wrote:
I had a fix for this test-building when I went to watch some schlock TV
last night and forgot to check on it and commit before I went to bed.
This was my .spec diff. The regexp has three chars different from your
version.
+%{expand:%%global debuginfo_args %{?debuginfo_args} -p
'/.*/%%{KVERREL}%{?1:.?%{1}}?/.*|/.*%%{KVERREL}%{?1:.%{1}}(\.debug)?' -o
debuginfo%{?1}.list}\ ^
what's that ? for?
I wondered that myself, but it was already there... Might have been a typo I
inserted earlier. Yanking it works for me.
The other differences are \. instead of . for matching
literal . in two places.
Ah, that's even better. Forgot this is essentially regex passed down to
find-debuginfo.sh... I'll drop the ? and add the \'s.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
arch-in-uname tweaks (was: rpms/kernel/devel...)
On Wednesday 26 March 2008 09:19:56 am Thorsten Leemhuis wrote:
[...]
Just wondering: If we are working in this area why not finally chose one
of the two variants (%{KVERREL}-$Flavour or %{KVERREL}$Flavour) and
stick to it everywhere as well? Or even use a . as delimiter here as
well?
Then the duplication due to the if [ -n $Flavour ] could be removed
in this area of the spec file by using something like this everywhere:
DevelDir=/usr/src/kernels/%{KVERREL}${Flavour:+-${Flavour}}
I thought about trying to yank that extra symlink and the if clause, but
wasn't sure exactly what they were there for, so I didn't want to cause
any further breakage...
Understood.
But yeah, I'd be all for simplifying there, if its not
going to cause someone/something headaches.
+1 -- let's remove it and see what breaks; we can easily re-add later if
it's needed somewhere
To be consistent with the rest of
the paths laid down, it really should be %{KVERREL}${Flavour} without any
- or .
+1
(unless we also change all the other paths to also use - or ..)
Hmmm. This would look cleaner IMHO. But it likely would create even more
trouble for kmods and other kernel module stuff. But as there are
adjustments needed already due to the other changes it might be a good
idea to do this change now as well.
But I'm not really sure if that's really worth the effort.
I'm trying out a local build now that eliminates the DevelLink and uses your
suggestion above for DevelDir, and makes use of %{KVERREL}-%{Flavour} right
now, which as discussed on irc, looks more correct to both of us. :)
i.e., this changes uname -r for kernel-PAE from 2.6.25-1.fc9.i686PAE to
2.6.25-1.fc9.i686-PAE, and all paths laid down are changed accordingly.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
On 24.03.2008 20:53, Jarod Wilson wrote:
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
[...]
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer -touch
$RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+install -m 644 .config
$RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} +install -m 644
System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} +
touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
For the sake of consistency, [...]
For the sake of consistency we IMHO should use the same delimiter
between $(uname -r) and arch in all places. E.g. either . (like
quoted above) everywhere or a -, like we already use in the devel
packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64).
One thing I like about using . over - is that you'd get
2.6.25-xzy.fc9.x86_64 for uname -r output, which matches up nicely with what
rpm -q outputs, now that we're defaulting to outputting n-v-r.arch.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Tuesday 25 March 2008 12:54:07 pm Jarod Wilson wrote:
On Tuesday 25 March 2008 12:49:28 pm Jarod Wilson wrote:
On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote:
On 25.03.2008 13:47, Jarod Wilson wrote:
On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
On 24.03.2008 20:53, Jarod Wilson wrote:
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
[...]
Test build up and running:
[EMAIL PROTECTED] x86_64]# ls /boot/*.x86_64*
/boot/config-2.6.25-0.152.rc6.git7.fc9.x86_64
/boot/initrd-2.6.25-0.152.rc6.git7.fc9.x86_64.img
/boot/System.map-2.6.25-0.152.rc6.git7.fc9.x86_64
/boot/vmlinuz-2.6.25-0.152.rc6.git7.fc9.x86_64
[EMAIL PROTECTED] x86_64]# uname -r
2.6.25-0.152.rc6.git7.fc9.x86_64
[EMAIL PROTECTED] x86_64]# ls /lib/modules/
2.6.25-0.152.rc6.git7.fc9.x86_64
[EMAIL PROTECTED] x86_64]# ls /usr/src/kernels/
2.6.25-0.152.rc6.git7.fc9.x86_64
And here's the patch I came up with for the above:
Crap, disregard that version. Things blow up on flavo{,u}red builds, because
the flavo{,u}r gets inserted between the f9 and .arch instead of after arch
(the ppc64 build blew up on kdump bits). So a teeny bit more spec hackage
required, but its still doable.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
Aparently pm-utils will need a change to cope with the changed
filename, but I think that should be the limit of the damage.
(oprofile will need to append the archname on the end of System.map-$ver
filenames, but they're user-passed anyway, and not coded anywhere afaik
Hmm. Not sure about Systemtap).
Comments?
Yep!
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
-touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch}
+install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch}
+touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
For the sake of consistency, I'd try to keep $KernelVer and %{_arch} together.
The above would give
us for example config-2.6.25-1.fc9.x86_64, System.map-2.6.25-1.fc9.x86_64 and
initrd-2.6.25-1.fc9.img.x86_64. I'd make the initrd either
initrd-2.6.25-1.fc9.x86_64.img or
initrd.img-2.6.25-1.fc9.x86_64.
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*} || exit
$?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*}.
%{_arch} || exit $?\ %{nil}
I suspect this will make new-kernel-package very unhappy, since I think its
expecting to be fed what
essentially amounts to $(uname -r).
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Monday 24 March 2008 06:36:49 pm Roland McGrath wrote:
[...]
All this suggests to me that the only thing we really can make fly is to
include the differentiator in EXTRAVERSION. It will be noticeable to
users and probably draw a lot of questions and look redundant in many
places that display the arch too. But it would not be any new can of
worms on technical grounds.
That's basically the conclusion I came to too, and I've got a 2-line spec
patch (actually also using %{_target_cpu} instead of %{_arch}) that I'm
prodding at. Definitely way too many things that'll go boom if its not there
after some discussion on irc (and on this list).
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Another question on module unloading
On Wednesday 20 February 2008 09:25:46 am Matt Domsch wrote: On Wed, Feb 20, 2008 at 04:20:33PM +0200, Eugene Goubine wrote: Where can I get an information about the order in which the modules are unloaded when the system shuts down.I am writing a module which is going to be sort of networking protocol so the unloading order is crucial for me. In general, kernel modules are not unloaded at system shutdown. If they are unloaded, that's done so by the initscripts of various programs. A quick grep 'modprobe -r' /etc/init.d/* shows that cpuspeed, ip6tables, ip6tables, and lm_sensors initscripts (on my system) unload kernel modules. Nb: in the cpuspeed case, the module unloads aren't on shutdown either. They're done when we try loading a cpufreq driver that we think will work on the system, but it doesn't find supported hardware. Rather than leaving a useless module loaded, we do some clean-up in this case. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bug 384281: acpi-cpufreq reports ENODEV on Q6600
On Wednesday 20 February 2008 09:56:53 am davide rossetti wrote: As soon as I unwrapped my brand new Core 2 Quad, I discovered that acpi-cpufreq seems not able to offer its services :( the point is why ? is there anything (code, debugging, testing) I can do to support it (or its BIOS) ? https://bugzilla.redhat.com/show_bug.cgi?id=384281 Your cpu (core 2 quad Q6600) is definitely supported, so I'm about 99% certain the fault lays with the bios. HP has been notorious about shipping bioses with broken linux cpufreq support... I'd look for a bios update, and if you can't find one, yell at HP. :) -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Bug 384281: acpi-cpufreq reports ENODEV on Q6600
On Wednesday 20 February 2008 10:36:12 am davide rossetti wrote: On Feb 20, 2008 4:11 PM, Jarod Wilson [EMAIL PROTECTED] wrote: On Wednesday 20 February 2008 09:56:53 am davide rossetti wrote: As soon as I unwrapped my brand new Core 2 Quad, I discovered that acpi-cpufreq seems not able to offer its services :( the point is why ? is there anything (code, debugging, testing) I can do to support it (or its BIOS) ? https://bugzilla.redhat.com/show_bug.cgi?id=384281 Your cpu (core 2 quad Q6600) is definitely supported, so I'm about 99% certain the fault lays with the bios. HP has been notorious about shipping bioses with broken linux cpufreq support... I'd look for a bios update, and if you can't find one, yell at HP. :) isn't there something low-level, driving the CPU/chipset registers directly ? Like... The BIOS? :) Seriously, the acpi-cpufreq driver needs good data from the BIOS's ACPI tables to be able to do anything. Try booting with 'cpufreq.debug=7' added to your kernel boot params, and you should get some more data on why its failing to work, but pretty sure its the BIOS at fault. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
On Monday 11 February 2008 02:01:01 pm Kyle McMartin wrote: On Mon, Feb 11, 2008 at 01:54:25PM -0500, Jarod Wilson wrote: On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: git trees: firewire - commented out, pending didn't apply Yeah, the pending bits depend on some bits that are in linux1394-git that haven't yet made their way over to Linus, I believe. Figure I'll just fix things up after the rebase. if you want, you can attach a diff here and i'll put it into the first upload, or commit it with something like pending-rc1.patch or something and i'll move it when we update. Didn't get back around to it until the new bits were already in cvs, but have since fixed things up, so its all good now. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: importing 2.6.25-rc1
On Monday 11 February 2008 12:53:40 pm Kyle McMartin wrote: git trees: firewire - commented out, pending didn't apply Yeah, the pending bits depend on some bits that are in linux1394-git that haven't yet made their way over to Linus, I believe. Figure I'll just fix things up after the rebase. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fwd: Re: rawhide report: 20080130 changes
On Wednesday 30 January 2008 02:55:08 pm Jarod Wilson wrote: On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: Roland, I don't suppose any of the recent changes I seem to recall hearing you were going to make to debuginfo might have anything to do with this... Seems unlikely since I haven't actually made any yet. D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) Chuck figured it out. The output of file 4.23 when looking at unstripped binaries changed, which broke find-debuginfo.sh... :\ -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Fwd: Re: rawhide report: 20080130 changes
On Wednesday 30 January 2008 03:47:26 pm Jarod Wilson wrote: On Wednesday 30 January 2008 02:55:08 pm Jarod Wilson wrote: On Wednesday 30 January 2008 02:17:17 pm Roland McGrath wrote: Roland, I don't suppose any of the recent changes I seem to recall hearing you were going to make to debuginfo might have anything to do with this... Seems unlikely since I haven't actually made any yet. D'oh, didn't realize that, sorry. Okay, back to the drawing board... :) Chuck figured it out. The output of file 4.23 when looking at unstripped binaries changed, which broke find-debuginfo.sh... :\ Okay, I should just go home. My head hurts like hell right now, and I can't seem to get anything right... It seems the new file only has issues with .ko files, other binaries it reports on as it always has. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: 2.6.24
On Saturday 26 January 2008 05:19:14 am Roland McGrath wrote: Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 fairly soon? Chuck was talking about branching in cvs to start doing 2.6.24 builds for at least F8 as soon as possible for people to test w/o committing to an immediate upgrade from 2.6.23, but I'd assume if testing goes well with 2.6.24, we'll move to it fairly soon. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFC: Minor specfile rework for rawhide
Christopher Brown wrote: On 21/01/2008, Adam Jackson [EMAIL PROTECTED] wrote: http://people.freedesktop.org/~ajax/kernel-autopatch.patch Based on something I did for the xserver specfile. Essentially this makes it so you only have to name the patches once, in the order you want to apply them, which makes it both easier to work with and harder to forget things. I've tried to make this as friendly and robust as possible, including bailing out appropriately when faced with a bad patch, and explicitly naming patches that fail to apply right at the end of build output. Feedback would be appreciated, even if it's of the form no, that's gross. Can't speak from an implementation point of view but you must be a mind-reader. Several people will appreciate the thought behind it, myself included. On #fedora-kernel recently: kylem i really find it irritating that i need to edit Patchxx: *and* add an ApplyPatch. * kylem ponders converting the spec file to use quilt. j-rod fark j-rod not a fan of that either jwb why not j-rod ? f13 I think he meant he's not a fan of editing twice. f13 not that he wasn't a fan of quilt. jwb oh kylem i always forget to do one or the other :\ First glance says oh hell yeah, check it in. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [libdc] IDCC camera's firewire juju stack
Stefan Richter wrote: Hans de Goede wrote: Thanks for all the help, I have it working now by building a 2.6.23 kernel with the patchset from here applied: http://me.in-berlin.de/~s5r6/linux1394/updates/ Then it works if I lower the number of buffer passed to dc1394_capture_setup() to 2, after also applying this patch: http://marc.info/?l=linux1394-develm=119965813322642 ? This is no longer needed and even coriander (from cvs) works fine! This is with a via vt6306 in OHCI 1.1 mode (which is the factory default for this pci card), should the above patches be enough to also get it to work in 1.0 mode? If that is the case I can try flashing it to 1.0 mode and see if that will also work. I can take care of testing on an VT6306 OHCI 1.0 controller, as well as a VT6307 OHCI 1.0 controller. Just bumping to the latest linux1394 git code wasn't enough to get dv capture working (via dvgrab) on one of my VT6307 1.0 controllers, but I'm about to give it a go with the addition of David's dynamic buffer allocation patch. No, according to what several people saw with VT630x in OHCI 1.0 mode, there is still the bug that the DMA program stops after receiving one or a few frames. This is 100% reproducible with coriander + IIDC camera and dvgrab + DV camcorder. https://bugzilla.redhat.com/show_bug.cgi?id=415841 As far as I understood, this presumably happens because the problem which David Moore addressed with fw-ohci: Fix for dualbuffer three-or-more buffers is also present but unfixed in the packet-per-buffer code. I can probably get a similar fix added on top of the packet-per-buffer code today, if it is indeed still needed. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [libdc] IDCC camera's firewire juju stack
Jarod Wilson wrote: David Moore wrote: On Fri, 2008-01-11 at 10:44 +0100, Stefan Richter wrote: No, according to what several people saw with VT630x in OHCI 1.0 mode, there is still the bug that the DMA program stops after receiving one or a few frames. This is 100% reproducible with coriander + IIDC camera and dvgrab + DV camcorder. https://bugzilla.redhat.com/show_bug.cgi?id=415841 As far as I understood, this presumably happens because the problem which David Moore addressed with fw-ohci: Fix for dualbuffer three-or-more buffers is also present but unfixed in the packet-per-buffer code. I thought I had fixed that in my fw-ohci: Bug fixes for packet-per-buffer support patch That's what I was thinking/hoping, but... but maybe it's still not working perfectly yet. ...I still can't get more than 1 or 2 frames of dv w/the OHCI 1.0 VT6307 I'm working with right now. :( On the positive side, I *do* have coriander displaying video from a Unibrain Fire-i hooked to this same controller now, so the remaining problems appear to be dv-specific. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: IIDC camera's and the juju firewirestack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: In the thread I started about Fedora perhaps being to cutting edge, it was said that I shouldn't complain as there is only one problem left with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. Oh, there's definitely more than one problem left... :) Further analysis of the problem has learned that this is not true, I'm using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 mode doing dv capture. iidc is much less tested. I already know where at least a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting you... I've also got an idea or two on what's up with dv capture, just need to get the spare cycles to test (which could happen shortly, just finished a major piece of lirc...) However most documents talk about using the juju stack with either harddisks or DV for homevideo camera's. However I'm trying to use an industrial cam which used the IIDC protocol, and support in the new juju stack (kernel + userspace) for the IIDC protocol isn't very good. I believe David Moore's patch in linux1394-2.6.git[*] should help, and it looks like that also needs to be ported over to the OHCI 1.0 code paths... As the consensus from the other thread seems to be that having 2 parallel stacks is not a good plan, I have decided to spend some time to get the IIDC situation with the juju stack improved. However I'm pretty new to all this, so I will need a couple of pointers to get me up to speed. Awesome, we definitely need more help. Neither krh nor I is able to spend quite as much time on juju as we'd like right now... I've been testing with the grab_gray_image example from libdc1394-2.0.0. The problem is that it hangs at the dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT, frame) call. The camera does seem to be sending data, as its activity led is flickering. Any clues for further debugging this would be much appreciated That git patch would be the first step. I'll look at doing similar for OHCI 1.0, as well as testing out an idea I had wrt dv capture on OHCI 1.0... shall I put this in bugzilla? Might as well. Some of it is already there, but nothing iidc-specific yet. If so against which component? I'd file it against kernel, but assign it to me and cc [EMAIL PROTECTED] and [EMAIL PROTECTED] [*] http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394-2.6.git;a=commitdiff;h=e9f5ca46377ac60a6b7d52c6c19a1661c87c6e20 - -- Jarod Wilson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhjlqtO+bni+75QMRAptqAJ4ndhFsNe9yyHVzjKVv7Mlzq7wHbACg0FFB eOsRcGVaAUtv7QbgEus+np4= =K0/M -END PGP SIGNATURE- ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Precision 490 Reboot Hang
Thomas J. Baker wrote: On Thu, 2007-12-06 at 16:47 -0500, Jarod Wilson wrote: Thomas J. Baker wrote: I've got a Precision 490 that hangs at reboot unless I use reboot=bios on the kernel command line. A bug filed against the kernel should include what other information? I might suggest looking for a BIOS update and/or downgrade before you file any bugs. I've got a Precision 490 here that reboots just peachy. Dell actually has bios updates that can be done from Linux on these boxes. I'm running the latest BIOS as it was shipped with the machine. I'd rather use reboot=bios than run an old BIOS. Sorry, I was suggesting it more as a see if this is a bios issue and not a kernel issue than fix it by running an old bios. Did you see Roland's note about his own 490? He said his only fails to reboot when running an i386 kernel, but works fine w/an x86_64 kernel, which doesn't conflict with what I've seen, since mine's also running an x86_64 kernel. He also mentioned that this started sometime between 2.6.22 and 2.6.23. If you are indeed running a 32-bit kernel, it sounds like an i686-specific kernel bug. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Precision 490 Reboot Hang
Thomas J. Baker wrote: I've got a Precision 490 that hangs at reboot unless I use reboot=bios on the kernel command line. A bug filed against the kernel should include what other information? I might suggest looking for a BIOS update and/or downgrade before you file any bugs. I've got a Precision 490 here that reboots just peachy. Dell actually has bios updates that can be done from Linux on these boxes. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: How can I develop loadable module for Fedora 7 and later?
Cary Fu wrote: When I tried to build a loadable module for Fedora 7, there are lots of error warning came up regarding the line of #include linux/module.h. Is there anyone knows where can I find the information about making a loadable module for Fedora 7. Thanks in advance for any input. Just take a look at the source to any of the umpteen modules in the kernel... May also want to visit http://kernelnewbies.org/. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: help! My re-compiled kernel always got crashed in a machine with scsi/sata disk
Feng Xian wrote: Thanks! Now I know what confused me. What I downloaded was linux kernel from Linux Archive website instead of fedora source from redhat. I used to believe that these two sources are the same. From your message, they are apparently different. As far as the code itself goes, we try to stay as close to upstream as possible. We start with the upstream kernel tarball and apply some patches and our own kernel config from there. Generally, if you take an upstream tarball and just use the Fedora kernel config, you'll get a booting system (usually works for me, anyhow). -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: help! My re-compiled kernel always got crashed in a machine with scsi/sata disk
Feng Xian wrote: I downloaded a clean version of 2.6.23 and didnt do any modification on it (athough I am about to modify it in the future). By default, the clean version doesnt enable sata features, so I enabled these features and compiled this clean version. But I couldn't boot linux with the compiled kernel like I mentioned in my previous posts. Like I said, its not a Fedora kernel, and thus not something we can reasonably support here. The only possible list-relevant bit of info here would be knowing *why* you're building your own, such that we can make the Fedora kernel provide what you need so you don't have to, if possible and/or relevant. That said, seeing as how a Fedora kernel does boot your system, you'll probably get a lot closer to a bootable system with your own kernel if you start with the Fedora kernel config file instead of the upstream kernel config file, and go from there. On 11/12/07, *Jarod Wilson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Feng Xian wrote: Thanks for all your help. I ran into another problem. My 16-core machine has a scsi/sata disk. I have enabled all important features related with scsi and sata. I built 2.6.23 kernel on this machine. But the kernel always got crashed randomly. Sometimes it couldnot even boot, reporting some random errors, like segment violation, sleep for 40 seconds, or Group volume VolGroup00 uses lvm2 metadata: read-only, then jump to a strange login window that I cannot log in using my root password. Another thing is that Linux works perfect if I installed Fecore Core 7 on this multi-core machine with scsi/sata disk. Why it didnt work if I used re-compiled kernel. I guess it is because I didnt config kernel right (although I enabled all important features related with scsi/sata) in make menuconfig. If you happen to know how to enable scsi/sata features correctly, please let me know. Thanks! I don't think this is the correct forum for this question. This list is targeted at issues surrounding the Fedora kernel, and you're building your own kernel. Once you start building your own, with a config that obviously differs significantly from the Fedora config, we can't realistically provide support here. Furthermore, I'm not quite sure I understand why you think you need to build your own kernel either. To be bluntly honest, if you can't figure out what's going wrong there on your own, you probably shouldn't be building your own. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: install System.map in kernel-devel
Chuck Ebbert wrote: On 10/23/2007 06:28 PM, Dave Jones wrote: Are the addresses in System.map accurate? On the F7 2.6.23 kernel, I had to subtract 0x40 and add 0x100 to the address in an oops message to get an address to use with eu-addr2line. Relocatable kernel is another thing that really screws with this. CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x40 CONFIG_PHYSICAL_START=0x100 Address in oops was c04622db. I had to use eu-addr2line -e vmlinux 0xc10622db And objdump just flat refuses to show line number information from vmlinux containing debug info. (But on Fedora 8 it will.) I vaguely recall seeing a bug about this one, and I thought the solution was to set _ALIGH and _START to the same value, but these are only vague recollections... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Building a kernel --without debuginfo is kind of broken
Chuck Ebbert wrote:
I got a 160MB kernel package and discovered that the kernel and
modules contained debug info. This seems to fix it, does anyone
see a problem with it?
make -s mrproper
cp configs/$Config .config
+%if !%{with_debuginfo}
+perl -p -i -e 's/^CONFIG_DEBUG_INFO=y$/# CONFIG_DEBUG_INFO is not set/'
.config
+%endif
Arch=`head -1 .config | cut -b 3-`
echo USING ARCH=$Arch
I believe at one point in the past, debuginfo was still getting
stripped, just not packaged, with that option. Then things changed
around a bit, and with that option, stripping didn't happen. The above
seems like a sane remedy to me.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: RFE: Switch usbhid.pb_fnmode to 2 for Macbook Pro users
Dave Jones wrote: On Thu, Sep 27, 2007 at 09:11:38PM +0100, Christopher Brown wrote: It would appear Macbook Pro users need to additionally press the fn key to make F1 - F10 work as expected under Linux. Therefore to switch to a vt they have to perform a wierd kind of hand twister to get it to work as it now requires Ctrl+Alt+Fn+F1. Just as an fyi, this is also the case on my 2+ year old PowerBook G4. And I'm pretty sure it was also the case on the iBook I had prior to that, which I got roughly 5 years ago. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Enabling Secure Computing (SECCOMP)
Chuck Ebbert wrote: We have a bug report requesting that we enable SECCOMP: https://bugzilla.redhat.com/show_bug.cgi?id=295841 I suggest we enable it in Fedora 8 but leave it disabled in F7. That way we're not changing a config item in a stable release, and we don't have to carry patches to lower the feature's overhead and make its API match 2.6.23's. Saw that one too. Turning it on just in F8 sounds sane to me. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] lirc IR receiver drivers
Jarod Wilson wrote: Eric Sandeen wrote: Jarod Wilson wrote: Hey all, So... As I've mentioned on various forums here and there in the recent past, I'd really like to see fedora carry the lirc drivers (http://www.lirc.org/) in-kernel, and help push them into the upstream kernel. I finally got around to doing something significant about it this evening. The link below is the completion of my first attempt at a patch tailored for upstream, based partially on work done by Mario Limonciello for Ubuntu (cc'd). http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch Cool, I tossed a few build-related fixes (warnings, deprecated interfaces/flags, etc..) on top of this up at http://people.redhat.com/esandeen/lirc/ Very nice. Gah, at least one of those fixes some things I screwed up merging in the latest bits from cvs... (There's also usb stuff going on I don't understand in the commandir driver :) but with the warning about the callback it will probably explode when run.) Hrm, that's not so good... I was thinking of seeing if I could find one somewhere for cheap, but ouch, those things look pricey... http://www.commandir.com/order/ Also given that each subdir under drivers/input/lirc generally has just one .c file, I'd probably flatten it out, and drop everything into drivers/input/lirc/*.c Yeah, that idea crossed my mind too after I'd sent the mail off before drifting off to sleep. I'll do that for the next rendition. Also in Kconfig, INPUT_LIRC and LIRC_DEV seem a little redundant - perhaps each individual driver should just do select LIRC_DEV rather than depends on? and remove the prompt for LIRC_DEV? Sounds like a good idea to me. All of the work Eric and I did over the weekend is now in a proper git tree, which can be browsed (and cloned) here: http://git.wilsonet.com/linux-2.6-lirc.git/ A few more clean-ups and we'll slap this puppy into an actual rawhide kernel build to start getting some wider testing... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] lirc IR receiver drivers
Eric Sandeen wrote: Jarod Wilson wrote: Hey all, So... As I've mentioned on various forums here and there in the recent past, I'd really like to see fedora carry the lirc drivers (http://www.lirc.org/) in-kernel, and help push them into the upstream kernel. I finally got around to doing something significant about it this evening. The link below is the completion of my first attempt at a patch tailored for upstream, based partially on work done by Mario Limonciello for Ubuntu (cc'd). http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch Cool, I tossed a few build-related fixes (warnings, deprecated interfaces/flags, etc..) on top of this up at http://people.redhat.com/esandeen/lirc/ Very nice. Gah, at least one of those fixes some things I screwed up merging in the latest bits from cvs... (There's also usb stuff going on I don't understand in the commandir driver :) but with the warning about the callback it will probably explode when run.) Hrm, that's not so good... I was thinking of seeing if I could find one somewhere for cheap, but ouch, those things look pricey... http://www.commandir.com/order/ Also given that each subdir under drivers/input/lirc generally has just one .c file, I'd probably flatten it out, and drop everything into drivers/input/lirc/*.c Yeah, that idea crossed my mind too after I'd sent the mail off before drifting off to sleep. I'll do that for the next rendition. Also in Kconfig, INPUT_LIRC and LIRC_DEV seem a little redundant - perhaps each individual driver should just do select LIRC_DEV rather than depends on? and remove the prompt for LIRC_DEV? Sounds like a good idea to me. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: New Intel e1000 device support
Chuck Ebbert wrote: I just put Intel's latest cut at ICH9 e1000 support into rawhide, removing the preliminary hack that backported the support into the old driver. Since this new one *only* supports ICH9, it looks pretty safe to put it into Fedora 6 and 7 as well. Comments? Assuming there are no pci device id overlap w/the older driver, it shouldn't break anything already working, so it really can't cause any regressions. I'd say do it. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: macrofied kernel.spec
Axel Thimm wrote: On Thu, Aug 02, 2007 at 04:34:43PM -0400, Jarod Wilson wrote: Damn, it'd be nice if koji could spread kernel variant builds of the same arch across multiple builders... That's not difficult to do - just have exactly one kernel built in the specfile and pass the flavour on the rpmbuild command line in koji. Same is already happening with the kmdl builds since quite some time: Each one is an independent build entity, just copy the idioms from there. Of course koji needs to support several builds per src.rpm which it already does in a way, and also to pass custom --define arguments to the builds, but that's not difficult to embed in koji and would make koji also the platform of choice for building kmdls (which is not an argument for Fedora-internal consumption, but for wider spread use of koji). With the desire to spin kernel-vanilla rpms off the same source rpm as the current fedora kernels in a way that they aren't scratch builds, I've talked to release engineering about adding support for passing custom flags through the build system before. Unfortunately, they're currently against adding said support, both because of the technical work that would have to be done, and because of some policy matters. If we let builds pass in random flags, the end result binaries might be different than a simple rpmbuild --rebuild would be, we're less sure what was actually built, people could do crazy things, etc., etc., etc. (paraphrasing rel-eng loosely there). Despite that, I'd certainly still like the functionality added, even if its use were restricted to kernels (just what rel-eng wants, more exceptions for the kernel!). Heck, if we could get same-arch kernel variant builds going across multiple build hosts from a single 'make build' invocation, we could maybe even turn on building of a kernel-vanilla package by default without incurring a massive slowdown in 'make build' to 'all builds finished'... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: macrofied kernel.spec
Jarod Wilson wrote: Just realized it looks like you also snuck in a kernel-PAE-debug build= variant... ;) Damn, it'd be nice if koji could spread kernel variant builds of the same arch across multiple builders... =20 I didn't add it, it was already there. I just made it uniform with the= others. Maybe the hand-editted duplication had left it not working? O= r not entirely removed when it was intended to be? Huh. So it is... Hrm. Something is apparently causing it to not get built right now though: http://koji.fedoraproject.org/packages/kernel/2.6.23/0.61.rc1.git9.fc8/i6= 86/ (the lack of it showing up there was what made me think you'd added that, serves me right for not looking at the current spec) I'll poke around and see if I can figure out why it isn't getting built. Not obvious at first glance... Oh. I'm an idiot. Of course they aren't building for rawhide. *ALL* kernels are debug kernels in rawhide, so we don't have a separate one. They're building just fine for F7. /me goes back in his hole... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kqemu inclusion in kernel
Chuck Ebbert wrote: On 08/02/2007 02:20 PM, dragoran wrote: well but kqemu seems not to break that often I just recompile it after each kernel release and it just works. the code might be big but it does not depend on (fast) changing interfaces. Maybe I missed the earlier discussions, but just what does kqemu give you that KVM doesn't? Acceleration of non-hardware-virt guests. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: typo in new spec file (F7)
Ignacio Vazquez-Abrams wrote: On Sun, 2007-07-29 at 20:43 -0400, Jarod Wilson wrote: Tom spot Callaway wrote: On Sat, 2007-07-28 at 16:23 -0400, Ignacio Vazquez-Abrams wrote: On Sat, 2007-07-28 at 16:02 -0400, Sam Folk-Williams wrote: I noticed this in the kernel-2.6.22.1-33.fc7.src.rpm spec file as I was revising the kernel build docs: #% define buildid .local Just need to remove that space before 'define', otherwise we get the following after uncommenting. error: line 15: Unknown tag: % define buildid .local Better yet, double up the percent sign so that rpm doesn't try to interpret the %define macro. My guess is that the space is there specifically to prevent rpm from interpreting the %define macro (simply # commenting doesn't prevent it). Yup. Originally, I think it was a # replacing a %, but at some point, moved to #% ... Same difference. %% is a cleaner way to do it, but some packagers may not realize it disables the macro. While %% may be a bit cleaner, a # in front of it makes more sense to more people I think. My point is that you need *both* since rpm will interpret the macro regardless of whether or not it's commented out. ...unless of course there's a space after the %, as is currently the case. :) -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [RFC PATCH] Switch to including config-* instead of kernel-*.config
Josh Boyer wrote: On Wed, 2007-07-11 at 16:49 -0400, Jarod Wilson wrote: Chuck Ebbert wrote: On 07/11/2007 01:37 PM, Jarod Wilson wrote: The attached patch switches the kernel rpm over from including the current static kernel-*.config files to instead including the config-* files that are actually in cvs. It means we don't leave kernel-*.config droppings all over the place (following a rebase, its entirely too easy to end up with kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, which can sometimes cause odd things to happen), and we don't modify SOURCE files in %prep (see bug 232602), which could otherwise result in repacking an srpm with the same n-v-r with different kernel-*.config files. As a bonus, along the way, this cleans up a number of rpmlint warnings (though there are still a TON to poke at). In the future, this would also make life easier for the RHEL6 and later maintainers, as we typically prefer config changes against the config-* files, rather than against the kernel-*.config files, but (most) non-rh folks don't have cvs access to get at the config-* files right now. Thus far, the only real downside is that it requires moving all the config-* files up to the root of the kernel cvs dir, which is 1) a bit messy and 2) results in losing prior versioning history on those files, since cvs blows. 1) No big deal, though. 2) There's not much relevant history in there anyway. My thoughts exactly. (Hell, I'd even like to 'mv kernel-2.6.spec kernel.spec', but davej seems to not like that idea so much... ;) Why? I'm going to assume you're asking why doesn't davej like that idea, since the mv desire is probably obvious (compliance w/packaging standards). Basically, because cvs sucks, and all revision history goes bye-bye if we do the move. Though really... Dave, how big a deal is that really if we do it this early in rawhide? You can always go to the attic if you *really* need to see some historical info on the spec, and we'll have plenty built back up by the time we get to F8... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: cpuspeed und cpuidle
Chuck Ebbert wrote: On 07/11/2007 12:35 PM, Jarod Wilson wrote: Cpuspeed afaics needs an adjustment if cpuidle stays: $ LC_ALL=C sudo /etc/init.d/cpuspeed restart Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory [ OK ] /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory Enabling ondemand cpu frequency scaling: [ OK ] Jarod checked a fix in a day or so ago, might be working its way through koji somewhere. Yep, it was sitting for a day or two waiting for someone to notice my bodhi push request. It just got pushed over to stable updates a few hours ago. Fedora 6 too? I submitted a push request for the FC6 update I did w/the other pre-F7 update system, but haven't got any notice about it being pushed just yet. I'll ping someone in rel-eng. Can't wait for FC-6 to die now, so we don't have two different ways of doing things (er, make that three w/the RHEL stuff I do too)... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: cpuspeed und cpuidle
Chuck Ebbert wrote: On 07/11/2007 12:48 PM, Jarod Wilson wrote: I submitted a push request for the FC6 update I did w/the other pre-F7 update system, but haven't got any notice about it being pushed just yet. I'll ping someone in rel-eng. Can't wait for FC-6 to die now, so we don't have two different ways of doing things (er, make that three w/the RHEL stuff I do too)... Not until December... Yeah, I know. Damned users wanting us to support stuff for more than 6mo... ;) I wonder if we shouldn't just be very conservative with FC6 and drop the cpuidle there patch as well. Then that update wouldn't be needed. Otherwise we've got to add another 'requires' to the kernel package. worksforme, but I don't really run fc6 anywhere anymore either. (And I assume the cpuspeed update still works with old 2.6.18 kernels in case someone updates cpuspeed but not the kernel?) Yep, the change is really minor (just a slightly stricter pattern match when looking for per-cpu cpufreq bits in /sys -- match cpu[0-9]* instead of cpu*), works just fine with older kernels. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[RFC PATCH] Switch to including config-* instead of kernel-*.config
The attached patch switches the kernel rpm over from including the current static kernel-*.config files to instead including the config-* files that are actually in cvs. It means we don't leave kernel-*.config droppings all over the place (following a rebase, its entirely too easy to end up with kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, which can sometimes cause odd things to happen), and we don't modify SOURCE files in %prep (see bug 232602), which could otherwise result in repacking an srpm with the same n-v-r with different kernel-*.config files. As a bonus, along the way, this cleans up a number of rpmlint warnings (though there are still a TON to poke at). In the future, this would also make life easier for the RHEL6 and later maintainers, as we typically prefer config changes against the config-* files, rather than against the kernel-*.config files, but (most) non-rh folks don't have cvs access to get at the config-* files right now. Thus far, the only real downside is that it requires moving all the config-* files up to the root of the kernel cvs dir, which is 1) a bit messy and 2) results in losing prior versioning history on those files, since cvs blows. (For the record, I've also done a number of successful builds w/this patch now.) Comments appreciated! -- Jarod Wilson [EMAIL PROTECTED] Index: Makefile.config === RCS file: /cvs/pkgs/rpms/kernel/devel/Makefile.config,v retrieving revision 1.58 diff -u -p -r1.58 Makefile.config --- Makefile.config 3 Jul 2007 05:30:45 - 1.58 +++ Makefile.config 11 Jul 2007 15:53:04 - @@ -27,70 +27,70 @@ configs: $(CONFIGFILES) clean :: @rm -fv $(CONFIGFILES) $(TEMPFILES) temp-generic kernel-$(VERSION)*config -temp-generic: configs/config-generic Makefile Makefile.config - cat configs/config-generic configs/config-nodebug temp-generic +temp-generic: config-generic + cat config-generic config-nodebug temp-generic -temp-debug-generic: configs/config-generic Makefile Makefile.config - cat configs/config-generic configs/config-debug temp-debug-generic +temp-debug-generic: config-generic + cat config-generic config-debug temp-debug-generic -temp-x86-generic: configs/config-x86-generic temp-generic +temp-x86-generic: config-x86-generic temp-generic perl merge.pl $^ $@ -temp-x86-debug-generic: configs/config-x86-generic temp-debug-generic +temp-x86-debug-generic: config-x86-generic temp-debug-generic perl merge.pl $^ $@ -temp-x86_64-generic: configs/config-x86_64-generic temp-generic +temp-x86_64-generic: config-x86_64-generic temp-generic perl merge.pl $^ $@ -temp-x86_64-debug-generic: configs/config-x86_64-generic temp-debug-generic +temp-x86_64-debug-generic: config-x86_64-generic temp-debug-generic perl merge.pl $^ $@ -temp-sparc-generic: configs/config-sparc-generic temp-generic +temp-sparc-generic: config-sparc-generic temp-generic perl merge.pl $^ $@ -temp-sparc64-generic: configs/config-sparc64-generic temp-generic +temp-sparc64-generic: config-sparc64-generic temp-generic perl merge.pl $^ $@ -temp-powerpc-generic: configs/config-powerpc-generic temp-generic +temp-powerpc-generic: config-powerpc-generic temp-generic perl merge.pl $^ $@ -temp-powerpc32-generic: configs/config-powerpc32-generic temp-powerpc-generic +temp-powerpc32-generic: config-powerpc32-generic temp-powerpc-generic perl merge.pl $^ $@ -temp-s390-generic: configs/config-s390x temp-generic +temp-s390-generic: config-s390x temp-generic perl merge.pl $^ $@ -temp-ia64-generic: configs/config-ia64-generic temp-generic +temp-ia64-generic: config-ia64-generic temp-generic perl merge.pl $^ $@ -temp-x86-xen-generic-tmp: configs/config-xen-generic temp-x86-generic +temp-x86-xen-generic-tmp: config-xen-generic temp-x86-generic perl merge.pl $^ $@ -temp-x86-xen-generic: configs/config-xen-x86 temp-x86-xen-generic-tmp +temp-x86-xen-generic: config-xen-x86 temp-x86-xen-generic-tmp perl merge.pl $^ $@ -temp-x86_64-xen-generic-tmp: configs/config-xen-generic temp-x86_64-generic +temp-x86_64-xen-generic-tmp: config-xen-generic temp-x86_64-generic perl merge.pl $^ $@ -temp-x86_64-xen-generic: configs/config-xen-x86_64 temp-x86_64-xen-generic-tmp +temp-x86_64-xen-generic: config-xen-x86_64 temp-x86_64-xen-generic-tmp perl merge.pl $^ $@ -temp-ia64-xen-generic: configs/config-xen-generic temp-ia64-generic +temp-ia64-xen-generic: config-xen-generic temp-ia64-generic perl merge.pl $^ $@ -kernel-$(VERSION)-i686.config: configs/config-i686 temp-x86-generic +kernel-$(VERSION)-i686.config: config-i686 temp-x86-generic perl merge.pl $^ i386 $@ -kernel-$(VERSION)-i686-debug.config: configs/config-i686 temp-x86-debug-generic +kernel-$(VERSION)-i686-debug.config: config-i686 temp-x86-debug-generic perl merge.pl $^ i386 $@ -kernel-$(VERSION)-i686-PAE.config: configs/config-i686-PAE temp-x86-generic +kernel-$(VERSION
Re: [RFC PATCH] Switch to including config-* instead of kernel-*.config
Chuck Ebbert wrote: On 07/11/2007 01:37 PM, Jarod Wilson wrote: The attached patch switches the kernel rpm over from including the current static kernel-*.config files to instead including the config-* files that are actually in cvs. It means we don't leave kernel-*.config droppings all over the place (following a rebase, its entirely too easy to end up with kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, which can sometimes cause odd things to happen), and we don't modify SOURCE files in %prep (see bug 232602), which could otherwise result in repacking an srpm with the same n-v-r with different kernel-*.config files. As a bonus, along the way, this cleans up a number of rpmlint warnings (though there are still a TON to poke at). In the future, this would also make life easier for the RHEL6 and later maintainers, as we typically prefer config changes against the config-* files, rather than against the kernel-*.config files, but (most) non-rh folks don't have cvs access to get at the config-* files right now. Thus far, the only real downside is that it requires moving all the config-* files up to the root of the kernel cvs dir, which is 1) a bit messy and 2) results in losing prior versioning history on those files, since cvs blows. 1) No big deal, though. 2) There's not much relevant history in there anyway. My thoughts exactly. (Hell, I'd even like to 'mv kernel-2.6.spec kernel.spec', but davej seems to not like that idea so much... ;) -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
Jarod Wilson wrote: Roland McGrath wrote: What's Patch5? D'oh. Meant to nuke that. Inserted for testing purposes -- 'spectool kernel-2.6.spec -p 5 -d somemacro value' to verify expected N-V-R's being set properly. Disregard the -v2 patch, use this guy instead. :) (or just drop the Patch5 line out of the resulting spec). At davej's behest, went ahead and checked this version in, and started up a build in koji. Keeping an eye on the build (http://koji.fedoraproject.org/koji/taskinfo?taskID=55435) so as to fix any possible breakage asap. One buglet with make prep already found and fixed, yell loudly if anything else crops up. Otherwise, looking good so far, koji is starting in on building binaries now... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
Dave Jones wrote:
On Tue, Jul 03, 2007 at 11:47:18AM -0500, Tom spot Callaway wrote:
This is why Fedora adopted the pre-release versioning scheme that we
did:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages
In the Fedora scheme, this would be
0.%{X}.%{alphatag}
Or, in your specific example:
kernel-2.6.22-0.2.rc7.git1.fc8 vs kernel-2.6.22-0.1.rc7.fc8
Ok, that looks fixable by doing this..
Damn, I looked at that particular case and everything was just fine with
it in my head... Stupid head.
Jarod, want to give this a quick once-over?
Yup.
Index: kernel-2.6.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v
retrieving revision 1.3257
diff -u -p -r1.3257 kernel-2.6.spec
--- kernel-2.6.spec 3 Jul 2007 16:45:36 - 1.3257
+++ kernel-2.6.spec 3 Jul 2007 18:45:22 -
@@ -15,7 +15,7 @@ Summary: The Linux kernel (the core of t
# fedora_build defines which build revision of this kernel version we're
building. In the
# non-kernel world, this is analogous to the Release: field, and is
formatted similarly.
-%define fedora_build 2%{?dist}
+%define fedora_build 2
I might change the comment here slightly, since w/o %{?dist} right
there, its not quite the same as Release: anymore, but that's neither
here nor there for actually fixing the problem... :)
# base_sublevel is the kernel version we're starting with and patching
# on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base,
@@ -107,7 +107,7 @@ Summary: The Linux kernel (the core of t
# pkg_release is what we'll fill in for the rpm Release: field
%if %{released_kernel}
-%define pkg_release %{fedora_build}%{?buildid}
+%define pkg_release %{fedora_build}%{?dist}%{?buildid}
%else
%if 0%{?rcrev}
%define rctag .rc%rcrev
@@ -118,7 +118,7 @@ Summary: The Linux kernel (the core of t
%define rctag .rc0
%endif
%endif
-%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid}
+%define pkg_release 0.%{fedora_build}%{?buildid}%{?rctag}%{?gittag}%{?dist}
%endif
# The kernel tarball/base version
Note that for this to work, you need to increment %{X} upon every new
package.
It's non-obvious to me what %{?buildid} is, but it seems to
auto-increment.
The %buildid is for one-off builds, there's a blurb at the top of the
spec where we request people to set it for their own custom builds for
identifying non-official kernels. Never set in official fedora builds.
The order of it in pkg_release probably doesn't matter too much, though
I personally like it at the very end. Otherwise, the changes look fine
to me.
The other crazy idea I had was to call 2.6.22-rc7
2.6.22-0.rc7.git0.1.fc8. Making fedora_build auto-increment is probably
cleaner, though it'd be nice to also have it reset on a kernel major
version rebase (either manually or automagically).
--
Jarod Wilson
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
On Tue, Jul 03, 2007 at 03:01:16PM -0400, Jarod Wilson wrote:
snip
The other crazy idea I had was to call 2.6.22-rc7
2.6.22-0.rc7.git0.1.fc8. Making fedora_build auto-increment is probabl=
y
cleaner, though it'd be nice to also have it reset on a kernel major
version rebase (either manually or automagically).
=20
=20
I was going to propose something similar[1], but the proposal of using
0.%{fedora_build}.rc7 sounded much better to me and I dropped it
before sending to the list.
=20
=20
[1] My idea was using something like this:
=20
2.6.22-rc7 =3D kernel-2.6.22-0.rc7.0.%{something else}
2.6.22-rc7-git1 =3D kernel-2.6.22-0.rc7.1.git1.%{something else}
2.6.22 =3D kernel-2.6.22-%{something else}
=20
Well, we've already done something to address this, but for giggles,
I'll throw out one more idea that would have worked:
2.6.22-0.rc7.1.fc8 2.6.22-0.rc7_git2.1.fc8
But eh. What's there now worksforme, and it actually lines up better
with the official fedora packaging guidelines (we'll just ignore the
bazillion other things the kernel spec does that don't ;).
/me heads out the door for a mini-vacation, back Saturday...
--=20
Jarod Wilson
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
Dave Jones wrote: On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote: Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8. I'd like to give this a shot for f8. Doing it for the -vanilla packages is a 'must-have', and if it works out there, there's no reason not to do it in all the packages. Cool, I've got an implementation of this for kernel-vanilla I did a while back that I can resurrect and fire along for review. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Kernel rpm versioning changes
Okay, here's the first draft of spec changes to alter the kernel rpm
version and release fields to more closely match what the actual
upstream kernel base is. Its heavily commented at the moment to try to
explain what's going on.
The basic approach is this:
1st fedora build of 2.6.21.5:
kernel-2.6.21.5-1.fc7
2nd fedora build of 2.6.21.5:
kernel-2.6.21.5-2.fc7
1st fedora build of 2.6.22-rc6-git3:
kernel-2.6.22-0.rc6.git3.1.fc8
2nd fedora build of 2.6.22-rc7:
kernel-2.6.22-0.rc7.2.fc8
...and so on. Added bonus on rc/git builds: you set the rc and git
revisions near the top of the spec, and the needed patches are
automagically generated in the right place.
At least from spectool's point of view, I've got this working perfectly
from the generated n-v-r standpoint for all of the above combos and then
some. A test build of kernel-2.6.22-0.rc7.1.fc8 just finished building
with one error, which I've traced the source of -- debug files come from
the source tree, which is still versioned with the base kernel version.
This should be fixed in the attached diff, but the build is still
underway to verify that. Regardless of that, I'd like some feedback
before going much further down the current path. Everything between
hey, that looks good! and what in the blue hell are you thinking?
welcomed. :) (Even better if you have suggestions for improvement).
--
Jarod Wilson
[EMAIL PROTECTED]
Index: kernel-2.6.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v
retrieving revision 1.3245
diff -u -p -r1.3245 kernel-2.6.spec
--- kernel-2.6.spec 2 Jul 2007 17:07:41 - 1.3245
+++ kernel-2.6.spec 2 Jul 2007 20:17:31 -
@@ -1,5 +1,50 @@
Summary: The Linux kernel (the core of the Linux operating system)
+# For a stable, released kernel, released_kernel should be 1. For rawhide and/or
+# a kernel built from an rc or git snapshot, released_kernel should be 0.
+%define released_kernel 0
+
+# Versions of various parts
+
+# Polite request for people who spin their own kernel rpms:
+# please modify the buildid define in a way that identifies
+# that the kernel isn't the stock distribution kernel, for example,
+# by setting the define to .local or .bz123456
+#
+#% define buildid .local
+
+# fedora_build defines which build revision of this kernel version we're building. In the
+# non-kernel world, this is analogous to the Release: field, and is formatted similarly.
+%define fedora_build 1%{?dist}
+
+# base_sublevel is the kernel version we're starting with and patching
+# on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base,
+# which yields a base_sublevel of 21.
+%define base_sublevel 21
+
+# If this is a released kernel
+%if %{released_kernel}
+# Do we have a 2.6.21.y update to apply?
+%define stable_update 5
+# Set rpm version accordingly
+%if 0%{stable_update}
+%define stablerev .%{stable_update}
+%endif
+%define rpmversion 2.6.%{base_sublevel}%{stablerev}
+
+# The not-released-kernel case
+%else
+# The next upstream release sublevel
+%define upstream_sublevel 22
+# The rc snapshot level
+%define rcrev 7
+# The git snapshot level
+%define gitrev 0
+# Set rpm version accordingly
+%define rpmversion 2.6.%{upstream_sublevel}
+%endif
+# Nb: The above rcrev and gitrev values automagically define Patch00 and Patch01 below.
+
# What parts do we want to build? We must build at least one kernel.
# These are the kernels that are built IF the architecture allows it.
# All should default to 1 (enabled) and be flipped to 0 (disabled)
@@ -54,23 +99,25 @@ Summary: The Linux kernel (the core of t
# See also 'make debug' and 'make release'.
%define debugbuildsenabled 0
-%if ! %{debugbuildsenabled}
-%define with_debug 0
+# Want to build a vanilla kernel build without any non-upstream patches?
+# (well, almost none, we need nonintconfig for build purposes). Default to 0 (off).
+%define with_vanilla %{?_with_vanilla: 1} %{?!_with_vanilla: 0}
+
+# pkg_release is what we'll fill in for the rpm Release: field
+%if %{released_kernel}
+%define pkg_release %{fedora_build}%{?buildid}
+%else
+%if 0%{?rcrev}
+%define rctag .rc%rcrev
+%if 0%{?gitrev}
+%define gittag .git%gitrev
+%endif
+%endif
+%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid}
%endif
-# Versions of various parts
-
-# Polite request for people who spin their own kernel rpms:
-# please modify the buildid define in a way that identifies
-# that the kernel isn't the stock distribution kernel, for example,
-# by setting the define to .local or .bz123456
-#
-#% define buildid .local
-%define sublevel 21
-%define kversion 2.6.%{sublevel}
-%define rpmversion 2.6.%{sublevel}
-%define specrelease %(R=$Revision: 1.3245 $; RR=${R##: }; echo ${RR%%?})%{?dist}%{?buildid}
-%define release %{specrelease}
+# The kernel tarball/base version
+%define kversion 2.6.%{base_sublevel}
%define make_target bzImage
%define kernel_image x86
@@ -87,6 +134,10 @@ Summary: The Linux kernel
Re: spec hacks for vanilla and git-based kernel rpm builds
Roland McGrath wrote:
So I finally got around to poking at these bits again myself (in
relation to bug 240878), but ran into an issue with a vanilla/nopatches
build:
$ rpmbuild -bb --with baseonly --define 'nopatches 1' kernel-2.6.spec
RPM build errors:
File not found:
/data/buildroot/tmp/kernel-2.6.21-1.3243.fc8-root-x86_64/usr/src/debug/kernel-vanilla-2.6.21/linux-2.6.21.x86_64
There exists a .../debug/kernel-2.6.21/linux-2.6.21.x86_64 though.
(Looking into it more now, but figured I'd throw it out there, in case
someone already knows what's up).
Hmm. There are various magic things that use %{name} and others that use
kernel explicitly. I'm sure this worked when I checked the stuff in. So
something must have changed. I had to tweak something or other because of
this issue, probably the %setup -n arg, but I don't quite recall. I made
it use plain kernel-%{version} for the source dir name mostly so that an
rpmbuild in your working dir reuses the kernel-V/vanilla dir and links.
For having both installed in debuginfo rpms, it might make more sense to
let it all use %{name}.
It looks like all the debug stuff is in a directory structure that
matches whatever resulted from %setup, and the %files section references
them using %{name}, but needs to use kernel instead of %{name}.
Also, anyone have thoughts on re-versioning, at least in the vanilla
case, so as to more accurately describe what's being built? For example,
the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets
churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such
thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
My gen-patches script used for the git-based rpms does something vaguely
like this based on: git describe | sed 's/-g[0-9a-f]*$//;s/-/./g;s/^v//'.
The -gitN names are not actual tags so git tools don't tell you about them,
but the newfangled git-describe number of commits since version number
makes for something that increases and can be resolved into an upstream rev.
I just sent off a spec diff a few minutes ago that basically implements
what I was thinking of (and now I see you've already commented on...).
The main rc and git numbers I was interested in are those from the
upstream Linus tree snapshots, which usually end up getting manually
entered in the form of the patches added to the build, so I figured no
magic necessary. The new stuff should interoperate with your bits as
well for other-tree-git-based rpms too though.
--
Jarod Wilson
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
Roland McGrath wrote: What about before the first -rcN tag? I presume you're referring to the likes of say kernel 2.6.21-gitX, which was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn't thought about that case. Okay, will have to do some further twiddling to cover that case... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Kernel rpm versioning changes
Roland McGrath wrote:
I presume you're referring to the likes of say kernel 2.6.21-gitX, which
was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn't thought about that
case. Okay, will have to do some further twiddling to cover that case...
Yes, that's what I meant. Faking it as rc0 might be the easiest thing to
keep the scheme's release numbers increasing.
It winds up being a touch out of phase with reality, since 2.6.21-git1
ends up being called 2.6.22-rc0-git1, but the updated attached patch
does account for this case now in that fashion. If we call it anything
else, its out of N-V-R order. Ughlay, but still much closer than we've
been, and outside of that window, it should be spot-on to see what
exactly we're packaging.
Oh, and this version does result in a fully-completed rpm build (also
has the kernel-vanilla fix).
--
Jarod Wilson
[EMAIL PROTECTED]
Index: kernel-2.6.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v
retrieving revision 1.3245
diff -u -p -r1.3245 kernel-2.6.spec
--- kernel-2.6.spec 2 Jul 2007 17:07:41 - 1.3245
+++ kernel-2.6.spec 2 Jul 2007 21:29:22 -
@@ -1,5 +1,50 @@
Summary: The Linux kernel (the core of the Linux operating system)
+# For a stable, released kernel, released_kernel should be 1. For rawhide and/or
+# a kernel built from an rc or git snapshot, released_kernel should be 0.
+%define released_kernel 0
+
+# Versions of various parts
+
+# Polite request for people who spin their own kernel rpms:
+# please modify the buildid define in a way that identifies
+# that the kernel isn't the stock distribution kernel, for example,
+# by setting the define to .local or .bz123456
+#
+#% define buildid .local
+
+# fedora_build defines which build revision of this kernel version we're building. In the
+# non-kernel world, this is analogous to the Release: field, and is formatted similarly.
+%define fedora_build 1%{?dist}
+
+# base_sublevel is the kernel version we're starting with and patching
+# on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base,
+# which yields a base_sublevel of 21.
+%define base_sublevel 21
+
+# If this is a released kernel
+%if %{released_kernel}
+# Do we have a 2.6.21.y update to apply?
+%define stable_update 5
+# Set rpm version accordingly
+%if 0%{stable_update}
+%define stablerev .%{stable_update}
+%endif
+%define rpmversion 2.6.%{base_sublevel}%{stablerev}
+
+# The not-released-kernel case
+%else
+# The next upstream release sublevel (base_sublevel+1)
+%define upstream_sublevel 22
+# The rc snapshot level
+%define rcrev 0
+# The git snapshot level
+%define gitrev 10
+# Set rpm version accordingly
+%define rpmversion 2.6.%{upstream_sublevel}
+%endif
+# Nb: The above rcrev and gitrev values automagically define Patch00 and Patch01 below.
+
# What parts do we want to build? We must build at least one kernel.
# These are the kernels that are built IF the architecture allows it.
# All should default to 1 (enabled) and be flipped to 0 (disabled)
@@ -54,23 +99,28 @@ Summary: The Linux kernel (the core of t
# See also 'make debug' and 'make release'.
%define debugbuildsenabled 0
-%if ! %{debugbuildsenabled}
-%define with_debug 0
+# Want to build a vanilla kernel build without any non-upstream patches?
+# (well, almost none, we need nonintconfig for build purposes). Default to 0 (off).
+%define with_vanilla %{?_with_vanilla: 1} %{?!_with_vanilla: 0}
+
+# pkg_release is what we'll fill in for the rpm Release: field
+%if %{released_kernel}
+%define pkg_release %{fedora_build}%{?buildid}
+%else
+%if 0%{?rcrev}
+%define rctag .rc%rcrev
+%endif
+%if 0%{?gitrev}
+%define gittag .git%gitrev
+%if !0%{?rcrev}
+%define rctag .rc0
+%endif
+%endif
+%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid}
%endif
-# Versions of various parts
-
-# Polite request for people who spin their own kernel rpms:
-# please modify the buildid define in a way that identifies
-# that the kernel isn't the stock distribution kernel, for example,
-# by setting the define to .local or .bz123456
-#
-#% define buildid .local
-%define sublevel 21
-%define kversion 2.6.%{sublevel}
-%define rpmversion 2.6.%{sublevel}
-%define specrelease %(R=$Revision: 1.3245 $; RR=${R##: }; echo ${RR%%?})%{?dist}%{?buildid}
-%define release %{specrelease}
+# The kernel tarball/base version
+%define kversion 2.6.%{base_sublevel}
%define make_target bzImage
%define kernel_image x86
@@ -87,6 +137,10 @@ Summary: The Linux kernel (the core of t
%define nopatches 0
%endif
+%if %{with_vanilla}
+%define nopatches 1
+%endif
+
%if %{nopatches}
%define includexen 0
%define with_xen 0
@@ -99,7 +153,11 @@ Summary: The Linux kernel (the core of t
%if 0%{?upstream_branch:1}
%define using_upstream_branch 1
%define variant -%{upstream_branch}%{?variant_fedora}
-%define release %{upstream_branch_release}.%{specrelease}
+%define pkg_release %{upstream_branch_release}.%{pkg_release
Re: Kernel rpm versioning changes
Roland McGrath wrote:
What's Patch5?
D'oh. Meant to nuke that. Inserted for testing purposes -- 'spectool
kernel-2.6.spec -p 5 -d somemacro value' to verify expected N-V-R's
being set properly. Disregard the -v2 patch, use this guy instead. :)
(or just drop the Patch5 line out of the resulting spec).
--
Jarod Wilson
[EMAIL PROTECTED]
Index: kernel-2.6.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v
retrieving revision 1.3245
diff -u -p -r1.3245 kernel-2.6.spec
--- kernel-2.6.spec 2 Jul 2007 17:07:41 - 1.3245
+++ kernel-2.6.spec 2 Jul 2007 21:48:39 -
@@ -1,5 +1,50 @@
Summary: The Linux kernel (the core of the Linux operating system)
+# For a stable, released kernel, released_kernel should be 1. For rawhide and/or
+# a kernel built from an rc or git snapshot, released_kernel should be 0.
+%define released_kernel 0
+
+# Versions of various parts
+
+# Polite request for people who spin their own kernel rpms:
+# please modify the buildid define in a way that identifies
+# that the kernel isn't the stock distribution kernel, for example,
+# by setting the define to .local or .bz123456
+#
+#% define buildid .local
+
+# fedora_build defines which build revision of this kernel version we're building. In the
+# non-kernel world, this is analogous to the Release: field, and is formatted similarly.
+%define fedora_build 1%{?dist}
+
+# base_sublevel is the kernel version we're starting with and patching
+# on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base,
+# which yields a base_sublevel of 21.
+%define base_sublevel 21
+
+# If this is a released kernel
+%if %{released_kernel}
+# Do we have a 2.6.21.y update to apply?
+%define stable_update 5
+# Set rpm version accordingly
+%if 0%{stable_update}
+%define stablerev .%{stable_update}
+%endif
+%define rpmversion 2.6.%{base_sublevel}%{stablerev}
+
+# The not-released-kernel case
+%else
+# The next upstream release sublevel (base_sublevel+1)
+%define upstream_sublevel 22
+# The rc snapshot level
+%define rcrev 7
+# The git snapshot level
+%define gitrev 0
+# Set rpm version accordingly
+%define rpmversion 2.6.%{upstream_sublevel}
+%endif
+# Nb: The above rcrev and gitrev values automagically define Patch00 and Patch01 below.
+
# What parts do we want to build? We must build at least one kernel.
# These are the kernels that are built IF the architecture allows it.
# All should default to 1 (enabled) and be flipped to 0 (disabled)
@@ -54,23 +99,28 @@ Summary: The Linux kernel (the core of t
# See also 'make debug' and 'make release'.
%define debugbuildsenabled 0
-%if ! %{debugbuildsenabled}
-%define with_debug 0
+# Want to build a vanilla kernel build without any non-upstream patches?
+# (well, almost none, we need nonintconfig for build purposes). Default to 0 (off).
+%define with_vanilla %{?_with_vanilla: 1} %{?!_with_vanilla: 0}
+
+# pkg_release is what we'll fill in for the rpm Release: field
+%if %{released_kernel}
+%define pkg_release %{fedora_build}%{?buildid}
+%else
+%if 0%{?rcrev}
+%define rctag .rc%rcrev
+%endif
+%if 0%{?gitrev}
+%define gittag .git%gitrev
+%if !0%{?rcrev}
+%define rctag .rc0
+%endif
+%endif
+%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid}
%endif
-# Versions of various parts
-
-# Polite request for people who spin their own kernel rpms:
-# please modify the buildid define in a way that identifies
-# that the kernel isn't the stock distribution kernel, for example,
-# by setting the define to .local or .bz123456
-#
-#% define buildid .local
-%define sublevel 21
-%define kversion 2.6.%{sublevel}
-%define rpmversion 2.6.%{sublevel}
-%define specrelease %(R=$Revision: 1.3245 $; RR=${R##: }; echo ${RR%%?})%{?dist}%{?buildid}
-%define release %{specrelease}
+# The kernel tarball/base version
+%define kversion 2.6.%{base_sublevel}
%define make_target bzImage
%define kernel_image x86
@@ -87,6 +137,10 @@ Summary: The Linux kernel (the core of t
%define nopatches 0
%endif
+%if %{with_vanilla}
+%define nopatches 1
+%endif
+
%if %{nopatches}
%define includexen 0
%define with_xen 0
@@ -99,7 +153,11 @@ Summary: The Linux kernel (the core of t
%if 0%{?upstream_branch:1}
%define using_upstream_branch 1
%define variant -%{upstream_branch}%{?variant_fedora}
-%define release %{upstream_branch_release}.%{specrelease}
+%define pkg_release %{upstream_branch_release}.%{pkg_release}
+%endif
+
+%if !%{debugbuildsenabled}
+%define with_debug 0
%endif
# if requested, only build base kernel
@@ -109,7 +167,6 @@ Summary: The Linux kernel (the core of t
%define with_xen 0
%define with_kdump 0
%define with_debug 0
-%define debugbuildsenabled 0
%endif
# if requested, only build smp kernel
@@ -119,7 +176,6 @@ Summary: The Linux kernel (the core of t
%define with_xen 0
%define with_kdump 0
%define with_debug 0
-%define debugbuildsenabled 0
%endif
# if requested, only build xen kernel
@@ -129,7 +185,6
Re: Spinning kernel-vanilla packages via standard spec
Roland McGrath wrote: I kinda like it in %name whichever route we go here. Along the same lines as Ingo's kernel-rt packages, it makes it easier to install them in parallel with normal kernels for testing. I was just remembering about Ingo's -rt builds. I hadn't looked. What he uses is nearly identical to what I wind up with. It should be easy to use a unified spec file for his -rt patch version too. Definitely doable. Probably lots more %if'age in the spec, but hey, there's already a ton... I've tweaked my hacks slightly to use name: kernel-vanilla and kernel-branch for the git stuff. For git builds, it now produces e.g. kernel-upstream-2.6.20-2.6.21.rc5.97.1.3025 or kernel-roland-fedora-PAE-2.6.20-2.6.18.rc6.256.1.3025 using the tag and commit number from git (1.5) describe, so upgrades for the same branch package should work right without the ginormous date string release numbers I had before. If I'm understanding correctly, my current implementation isn't quite as flexible as yours, as it only adds the ability to build kernel-vanilla (and all sub-variants/bits), but it does do so for both released and in-development -rc and -rc-git vanilla kernels. I've been toying around with a few different variations, shuffling %name, %version and %release around a bit, and I think I've come upon one that I'm liking. My current version outputs a kernel-vanilla-2.6.21-0.rc5.git9.1.fc7 from a 1.3040-based spec, which is (hopefully) obviously 2.6.21-rc5-git9. A 2.6.20.4-based build should wind up being kernel-vanilla-2.6.20-4.1.fc6 using similar spec tweaks, and a forthcoming F7 2.6.21 kernel ought to wind up being kernel-vanilla-2.6.21-0.1.fc7. (Those changes are small but I don't have intermediate diffs on hand since I didn't commit the old version. I can send you the new files if you want.) Absolutely, shoot me whatcha got. I still have your prior changes in patch form (as well as a good portion merged into a working copy), extracting the diffs is no prob. Renaming to kernel-vanilla while still using the same spec does introduce a few problems I hadn't considered... 1) it breaks some build setups, where spec and sources are both somewhere like %_topdir/sources/%name. The build gets confused if %name is now kernel-vanilla. I can work around it locally with a symlink in my build root, but something programmatic would be good. Haven't looked into this much just yet. 2) kernel-xyz-headers is going to conflict with kernel-headers. Perhaps solved by simply 'if kernel-xyz, kernel-xyz-headers Provides: kernel-headers'. I've got this in my latest edition, will see how it behaves... Despite those issues, I still vote for the %name change. -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Needed: An easier way to build a subset of kernel packages
David Woodhouse wrote: On Fri, 2007-03-30 at 21:20 -0400, Jarod Wilson wrote: Hrm, not sure why that doesn't pass the option through, but I hadn't even thought to look at the Makefile to see how these flags would work at that level. Out of curiosity, does the following work?: $ make RPM_DEFINES=--define 'with_kdump 0' I suppose I ought to poke at that some myself... Adding to my todo list. I used the trick I learned from the end of the existing Makefile... [EMAIL PROTECTED] devel]# tail -4 Makefile compile compile-short: DIST_DEFINES += --target $(shell uname -m) ppc64: DIST_DEFINES += --without kdump ppc: DIST_DEFINES += --without smp Now I just have to remember never to commit the Makefile :) Ooh, I like it... Along those lines, what if we had Makefile include a Makefile.local if it existed, which was .cvsignore'd? Then you could tweak your local default build prefs to your hearts content without having to worry about accidentally committing them... /me still needs to actually *read* the Makefile at this point... ;) -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Needed: An easier way to build a subset of kernel packages
Dave Jones wrote:
On Thu, Mar 29, 2007 at 02:06:58PM -0400, Jarod Wilson wrote:
Dave Jones wrote:
On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote:
I was thinking about adding something like this to the .spec file
at the beginning:
%define allowup 1
%define allowsmp 1
%define allowpae 1
%define allowxen 1
%define allowdoc 1
%define allowdump 1
%define allowheaders 1
%define allowdebug 1
Then, after all the automatic enable/disable of various options is
done,
turn off everything that's not allowed.
This would make it much easier to change what gets built.
The amount of %define's we've grown recently does seem to be
getting out of hand. I'm not sure it's a good/bad thing, but it
does make the spec a little harder to read.
Not sure about your proposal tbh. I'll think about it more
when I'm back from vacation :)
I like it, at least in theory. Invariably, I'll do a test build, and to
speed the process, I twiddle bits at the top of the spec to disable
certain builds. In the i686 case, I almost always forget to hunt down
lower to turn off pae.
I probably don't really notice, because my workflow for test builds is usually
make prep
cd kernel-2.6.20/linux-2.6.20.noarch
cp configs/$whateverconfigIwant .config
make oldconfig bzImage modules
sudo make modules_install install
But I've not objection to making it easier for people who don't follow
my workflow and do things differently.
Rather than wasting Chuck's time implementing this, what say a
lower-level grunt like myself try to implement something along these
lines? :) I've got a few ideas on how to do it using either %bcond or
%with{,out}...
--
Jarod Wilson
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Needed: An easier way to build a subset of kernel packages
Chuck Ebbert wrote:
Jarod Wilson wrote:
The minimalist approach that comes to mind is to make all the %define
build* bits all set to 1/enabled by default, and only flip them to
disabled where appropriate, so they'd be equivalent to your allow* idea,
in that if you disable them at the top of the spec, they'd stay disabled.
I like this; right now there are surprises there for the unwary who
think they can disable things that way.
I've implemented enabling/disabling certain builds at the very top of
the spec file, and anything you set to not build at the top will NOT be
turned back on later by an ifarch/ifnarch/etc -- all those have been
modified such that they only disable things compared with the defaults
set at the top.
Turns out the complexity of adding --with/--without support only
resulted in the on/off lines at the top of the spec being slightly
longer, so one can now additionally pass in, say, --without xen, on the
rpmbuild line to disable building a xen kernel. For example, here's the
results of a test build using the modified spec:
$ rpmbuild -bb --without xen --without kdump --without debug kernel-2.6.spec
[...]
Wrote: /data/buildroot/RPMS/x86_64/kernel-2.6.20-1.2937.fc6.x86_64.rpm
Wrote:
/data/buildroot/RPMS/x86_64/kernel-debuginfo-2.6.20-1.2937.fc6.x86_64.rpm
Wrote:
/data/buildroot/RPMS/x86_64/kernel-debuginfo-common-2.6.20-1.2937.fc6.x86_64.rpm
Wrote: /data/buildroot/RPMS/x86_64/kernel-devel-2.6.20-1.2937.fc6.x86_64.rpm
Wrote:
/data/buildroot/RPMS/x86_64/kernel-headers-2.6.20-1.2937.fc6.x86_64.rpm
Executing(%clean): /bin/sh -e /data/buildroot/tmp/rpm-tmp.44498
+ umask 022
+ cd /data/buildroot/BUILD
+ cd kernel-2.6.20
+ rm -rf /data/buildroot/tmp/kernel-2.6.20-1.2937.fc6-root
+ exit 0
Results are exactly as expected/desired. Similar results have been
observed on an i686 build.
Here's another thought... Would be simple enough to add one more flag,
along the lines of --without flavo{,u}rs that automagically flipped
off everything but the base kernel build (+debuginfo, devel and
headers). That's actually likely to be the thing folks would most
commonly want to do. Worth adding?
Still touching up a few things, but should have this completely
presentable before lunch tomorrow...
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
