Review request begs
So I know lots of people submit these sort of begs offering to do reviews in return, but... I'm a wee bit way too tied up to do any reviews in return right now, so I'm asking for reviewers to look at these simply because they're awesome packages we want in the distro... :) rinputd - A server for receiving input events over the network https://bugzilla.redhat.com/show_bug.cgi?id=553705 Neat little daemon that listens for a network connection from something such as the remotux app for iphone/ipod touch, and feeds received data through the linux kernel input subsystem. Basically, remotux turns the touchscreen into a trackpad, complete with tap-to-click, scrolling, etc., and you can pop up the standard keyboard and use it for, well, keyboard input. libcrystalhd - Broadcom Crystal HD device interface library https://bugzilla.redhat.com/show_bug.cgi?id=553717 I just got the driver for these cards merged into the linux kernel staging tree a few days ago. Now we need the device interface library to talk to the thing and add support to apps to use it. This is a hardware h.264, mpeg2 and vc1 decoder board. That's right. 100% free and open-source drivers and libs from Broadcom, and they give us a way to decode digital video on Fedora w/o violating any codec patents, since the decoding is done entirely in hardware (this is pretty similar to the mpeg2 decoder on the Hauppauge WinTV PVR-350 in that respect). Please and thank you, etc., etc. -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On 1/6/10 11:07 AM, Adam Jackson wrote: On Wed, 2010-01-06 at 16:00 +0100, nodata wrote: I'd like to suggest an enhancement for Fedora 13: nothing should ever steal focus from the window I am typing in. If I am typing in a shell window, or in a word processor, or an e-mail, nothing should ever take keyboard focus away from that window. Clearly I'm missing something, otherwise we would have this, hence the posting to the list :) PGA. Here's the challenge. To reply to this mail, I hit control-shift-r in one evo window, and evo opened a new window for me to compose into. Get it? I typed into one window, and then started typing into another, and that's exactly what was desired. If the window manager suppressed focus changes on the basis of you were just typing into some other window, this must be a focus steal, then the new compose window would have mapped unfocused, and I'd have to have alt-tabbed to get to it. So if you can come up with an algorithm that can reliably classify focus change requests as stealing or not, then great. I'd go with don't let a different app steal focus. Windows for the same currently focused app are allowed to. This works pretty well under Mac OS X. Might depend on some of the stuff being done by the gnome-shell folks though, to be able to group windows together as belonging to the same process/application to be able to do it Right under a Linux DE... -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On 1/6/10 1:41 PM, Adam Jackson wrote: On Wed, 2010-01-06 at 17:32 +, Andrew Haley wrote: On 01/06/2010 05:00 PM, Adam Jackson wrote: On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote: I'd go with don't let a different app steal focus. Windows for the same currently focused app are allowed to. This works pretty well under Mac OS X. Might depend on some of the stuff being done by the gnome-shell folks though, to be able to group windows together as belonging to the same process/application to be able to do it Right under a Linux DE... Now make that work for the (not uncommon) case of clicking a link in evo or control-clicking one in gnome-terminal and expecting firefox to pop forward with that page. Well, this works right in Mac OS X too... :) Er, why would you want Firefox to be holding focus when it pops up? I can't think of any reason. To pick an example from my daily life: Someone pastes a bugzilla URL at me on IRC, and I need to go scroll through it to see what they're talking about. But that's a requested please change focus event, vs. something that happened in the background and decided to pop over the top of what you were doing while you were in the middle of typing. Please bear in mind that I have absolutely no clue how hard it is to distinguish between these sorts of things in X/Gnome/Linux... All I know is that other operating systems manage to get this right (or at least, righter than we do). -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On 12/23/09 3:21 PM, Jesse Keating wrote: On Wed, 2009-12-23 at 19:28 +0100, Kevin Kofler wrote: The whole problem is that such branches do not exist at all in the new git setup! If you get eaten by raptors, you can't expect another maintainer to come in after you and have to dig around for a private branch to update a build. That's why we need non-private branches (more than one per release), as allowed by our current CVS setup. Perhaps we have a terminology clash. The dist-git proof of concept allows branches to be created by maintainers, and pushed to the central repo, so long as the branch name starts with private-. These repos can be written to by anybody with file system write access, that is anybody in the 'packager' group. At this time, I am not planning to allow official tagged builds to come from these branches, instead they can only come from origin/master or origin/F-?? Okay, we've definitely got some slight misunderstanding here... :) I was objecting to Kevin's suggestion that we should be able to build official packages from branches named ^private-*. But building from a branch tagged something !^private- is actually necessary sometimes. The kernel folks have had to do just that from time to time. For example, say the F12 cvs head moves on towards 2.6.32 and an official build is submitted to updates-testing. Meanwhile, a security update for the already-released-to-users 2.6.31.x kernel needs to get pushed out. We create an F12-specific 2.6.31.x branch and build an *official* kernel to push to updates post-haste to fix the security issue. This *does* need to be allowed. But it wouldn't be on a branch named private-*, it would be quite blatant and obvious in naming, such as f12-2_6_31_x-kernel-branch or similar. I think there was some confusion in my use of private branch, where I was referring to branches with a name ^private-*, while Kevin was thinking in a more general sense, which would encompass the above kernel example. -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On 12/22/09 2:45 AM, Kevin Kofler wrote: Jesse Keating wrote: Nobody should be able to create any branches that do not start with private-. I really don't see the point of this, why can't we just allow any branch name that isn't a reserved name (master or F-[0-9]+)? We'll make sure that the buildsystem will not allow any official (non-scratch) builds to happen from a private-* branch. And as I wrote before, I don't like this at all, it's a regression from our current workflow Define our. In my personal opinion, Jesse is spot-on, we should NOT allow official builds from a private branch. That's just insane. Scratch builds are fine. Official builds need to be from the main branch, or a common non-private branch (such as the kernel has done for maintaining both e.g. 2.6.29 and 2.6.30 trees simultaneously for F10). If you get eaten by raptors, you can't expect another maintainer to come in after you and have to dig around for a private branch to update a build. -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo election results December 2009
On 12/18/09 12:19 PM, Paul W. Frields wrote: Election Results for FESCo - Fedora 13 Cycle Voting Period: 05 December 2009 00:00:00 UTC to 16 December 2009 23:59:59 UTC Nominations: * Adam Jackson (ajax) * Christoph Wickert (cwickert) * Justin M. Forbes (jforbes) * Matthew Garrett (mjg59) * Peter Jones (pjones) * Richard June (rjune) * Robert Scheck (rsc) Outcomes: As defined in the election text, the four (4) candidate(s) with the greatest number of votes will be elected for full 2 release term. Information: At close of voting there were: 216 valid ballots Using the Fedora Range Voting method, each candidate could attain a maximum of 864 votes (4*216). Results: 1. Adam Jackson (ajax) 1028 2. Christoph Wickert (cwickert) 934 3. Peter Jones (pjones) 820 4. Matthew Garrett (mjg59)753 * * * * * 5. Robert Scheck (rsc)663 6. Justin M. Forbes (jforbes) 535 7. Richard June (rjune) 415 As such, Adam Jackson, Christoph Wickert, Peter Jones, and Matthew Garrett are elected to FESCo for a full 2 release term. As others have said to *me* recently for other reasons... Congrats and condolences to the new FESCo members. ;) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xorg and multitouch
On 11/17/09 9:14 PM, Chris Ball wrote: Hi, Multitouch means, several mousepointers and you can move them all seperately. No, that's what multi-pointer means. Multi-Pointer X is already in F12. ... Multitouch refers to technologies that involve extrapolating from motion of finger-shaped blobs on your input device to the idea that a user has performed some continuous motion with said finger(s), and reacting appropriately. It's not the same as multi-pointer X, but it does use the same core technology. Isn't two-finger-drag for scrolling and two-finger-taps for right-click a form of multitouch? Or are we talking about extending that to pinch, rotate, etc? -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: linuxwacom maintenance
On 11/9/09 9:14 PM, Luya Tshimbalanga wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/2009 02:35 PM, Peter Hutterer wrote: On Mon, Nov 09, 2009 at 01:59:12PM -0500, Aristeu Rozanski wrote: I don't have time to maintain the linuxwacom package anymore. Anyone willing to do it? I'll pick it up. Note that it will become obsolete soon anyway once xorg-x11-drv-wacom gets past the new package review. Just curious, was xorg-x11-drv-wacom available on past Fedora release (Moonshine version comes in mind)? No. xorg-x11-drv-wacom is a new package that will obsolete linuxwacom. -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora PPC for oldworld Mac?
On 11/2/09 1:07 PM, Dan Williams wrote: On Thu, 2009-10-29 at 12:18 +, David Woodhouse wrote: On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote: On 09-10-28 18:24:49, Josh Boyer wrote: On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote: ... Does Fedora PPC work or install on oldworld PCI Macs, such as a beige G3 desktop? My impression is that no one has tried it on an oldworld ... It _ought_ to work if you sort out the bootloader. oldworld topped out at 366MHz anyway right? (the 333 and 366 Beige G3 were only sold from 1998-08-12 - 1999-01-01 too) That's pretty much the minimum you'd need to run Fedora anyway these days... Not sure it's really worth it, you'll need at least 256MB of RAM anyway, and those things used 168-pin 3.3V DIMMs which are pretty hard to find these days. Stock might have topped out around there, but there were assorted aftermarket upgrades one could purchase. I had a Beige G3 tower running at 533MHz with 768MB of RAM at one point in time, iirc. -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: net-snmp soname bump in rawhide
On 09/29/2009 01:16 PM, Jesse Keating wrote: On Tue, 2009-09-29 at 12:13 -0400, Josh Boyer wrote: Rawhide is still based on dist-f12. We have no cute name for dist-f13. Futurehide Runandhide -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible packages...
On 09/16/2009 08:02 AM, Pim Zandbergen wrote: Nathanael D. Noblet wrote: On 07/09/2009 02:31 PM, Jarod Wilson wrote: That said, I have it up and running on an F11 host at home right now, satisfying everything else w/Fedora packages. Yeah same here. Did any of you create a calendarserver RPM ? Nope, never got around to it, too many other more pressing things. :( -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
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: No Frozen Rawhide
On Tuesday 21 July 2009 19:04:50 Jesse Keating wrote: I've done some updating to the no frozen rawhide proposal[1]. There is still time to enact this for Fedora 12, which would take effect when we reach Alpha freeze in a couple weeks. I'd like another round of people reviewing it and giving feedback before we take it to FESCo. Thanks! Only thing I'm not terribly wild about is storing the pre-release tree in /pub/fedora/linux/releases/#/Everything/. Its bound to cause some confusion amongst the general population. Any reason not to keep it at /pub/fedora/linux/releases/test/#/Everything/ instead? -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No Frozen Rawhide
On Wednesday 22 July 2009 11:58:11 Jesse Keating wrote: On Wed, 2009-07-22 at 10:57 -0400, Jarod Wilson wrote: Only thing I'm not terribly wild about is storing the pre-release tree in /pub/fedora/linux/releases/#/Everything/. Its bound to cause some confusion amongst the general population. Any reason not to keep it at /pub/fedora/linux/releases/test/#/Everything/ instead? Churn on the mirror configs and the repo files, That much sort of sucks, yeah, but meh. We change it at least once anyway though, going from rawhide to release, so is one more change here a huge undertaking? (I ask because have no idea) as well as on the mirrors when we move to the final destination. $ cd .../pub/fedora/linux/releases/test/ $ mv 12 ../ ? Of course, most mirrors are auto-updating via rsync, so perhaps that doesn't translate particularly well... But it would also make it easier for mirror admins who don't want to mirror anything but the actual released releases. Also it makes having test/12/Everything and test/12-Alpha and test/12-Beta a tad bit confusing when all in the same dir. I think this is less confusing than having a release/12 well before the actual release of 12 though. Perhaps test/12/Everything would more accurately be called test/12/Nightly in this scenario? But those are just my gut feelings, I'm not particularly sold on any way and welcome suggestions. Okay, I'll keep 'em coming 'til you say otherwise. :) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No Frozen Rawhide
On Wednesday 22 July 2009 14:14:32 Jesse Keating wrote: ... Churn on the mirror configs and the repo files, That much sort of sucks, yeah, but meh. We change it at least once anyway though, going from rawhide to release, so is one more change here a huge undertaking? (I ask because have no idea) Well every change has potential to break users who have had to do some customization, and it hurts 3rd party repo setups. It'd be nice to install a repo config at Alpha and have the paths used remain useful and valid through the entire release. Would make it easier to attract users at Alpha/Beta and not suddenly drop them off the face or drag them into the next rawhide. ... Of course, most mirrors are auto-updating via rsync, so perhaps that doesn't translate particularly well... But it would also make it easier for mirror admins who don't want to mirror anything but the actual released releases. Yeah, sucks for mirrors. If you don't do hardlinks for a while first, they'd have to re-sync the entire pile of packages. And if you're going to do the hardlink dance, might as well use the base location first. Most of our mirrors tend to use the fedora-enchilada path so we're not likely to break too many expectations by having something in releases/ change, any more than by having something in releases/test/ change. ... This is why we'll set the expectation of the release on having the Fedora/ path show up. Since that's really what signifies the release, having gpg signed checksummed isos show up, and torrents getting turned on, etc.. There will have to be some expectation changes, but really the kind of people digging at raw mirror paths are going to be the kind of people that can adjust their expectations. All good points... Okay, I think I've been sufficiently convinced that dropping the bits into /pub/fedora/linux/releases/ is just fine after all. Thank you for the enlightenment. ;) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal to Drop Fedora 12 Features
On Thursday 16 July 2009 20:25:36 Jon Ciesla wrote: On Thu, Jul 16, 2009 at 10:11 PM, John Poelstrapoels...@redhat.com wrote: Hi FESCo, https://fedoraproject.org/wiki/Features/XZRpmPayloads https://fedoraproject.org/wiki/Features/F12X86Support Afaik those are blocking on 1) xz review request 2) rel-eng to coordinate a mass rebuild Has anyone taken concrete steps for a i586 secondary arch yet? For the most part, its not (yet) necessary. We throttled back the definition of i686 from i686 + cmov + sse2 or some such to just i686 + cmov, so there are very few systems that would be served by an i586 secondary arch right now. i.e., Athlon XP, Pentium III, etc., which *would* have been relegated to i586, are still going to be supported by i686, and we've talked about adding a cmov trap-and-emu function to keep supporting the few i686 procs w/o cmov, which really leaves only the original Pentium series that would benefit from an i586 secondary arch. At least, that's my vague recollection of it all right now... :) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Purging the F12 orphans
On Tuesday 14 July 2009 13:58:43 Jesse Keating wrote: On Tue, 2009-07-14 at 09:40 -0700, Jesse Keating wrote: It's that time of the release cycle again, to purge the orphans before we get to feature freeze. Any unblocked orphans will be purged by the 28th of this month. Here is a current list of unblocked orphans: The first list was incomplete due to an API change. Here is the complete list: ... Unblocked orphan ctrlproxy User 'bernie' has watchbugzilla, watchcommits, commit and approveacls on ctrlproxy, but not ownership. He's more than welcome to take over ownership too, but for the moment, I've taken ownership of the devel branch to stave off purging, since I use ctrlproxy myself... -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On Tuesday 14 July 2009 11:50:06 Richard W.M. Jones wrote: On Tue, Jul 14, 2009 at 09:27:08AM -0600, Douglas McClendon wrote: As with a current LiveOS installation, the installation media kernel is the running kernel. Even if the f11 installer already allows you to trigger a chrooted yum update as part of the install, you won't be running the updated kernel until after a reboot. Is it the case that the installation kernel is always UP, whereas the real kernel would probably be SMP nowadays? On everything but ppc32, we don't even ship an UP kernel any longer, the base kernel used by the installer *is* an SMP kernel. ... Same as RebootlessInstaller ... until ksplice ... I don't think ksplice changes things -- it seems to only work for very minor kernel patches. For example, any change to the layout of a kernel structure would appear to be incompatible with ksplice. Thus it seems highly unlikely it'll ever work in its current form for arbitrary kernel revisions. Trying to ksplice from 2.6.29.4 in the installer to say 2.6.30.1 or even to 2.6.31 does sound like massive fail... -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible packages...
On Monday 06 July 2009 10:49:31 Eric Sandeen wrote: Nathanael Noblet wrote: On Jul 5, 2009, at 9:33 PM, Eric Sandeen wrote: ... Well their python run script checks for its dependancies, and if not met will do a svn checkout of the right copy, however, they don't keep copies of the libraries within their own repository. So if you fulfill all its dependancies that shouldn't be an issue. Ah, ok - maybe that was it. Currently, it looks like it still requires its own builds of a few things. Stuff (apparently) not in Fedora: -pydirector -PyKerberos (might just be named something slightly different) Stuff in Fedora, but simply not used for whatever reason: -vobject (we have python-vobject) -pyflakes Stuff in Fedora, but still heavily patched for CalendarServer: -Twisted (the web2 portion, specifically) -xattr (requires Bob Ippolito's implementation) That said, I have it up and running on an F11 host at home right now, satisfying everything else w/Fedora packages. I'm a little curious about the one library that F11 packages (libevent at 1.4.x, where calendar server seems to download a 1.5.x...) Do I repackage libevent as part of my packages to be reviewed? Or simply talk to the maintainer of libevent to see if it can be bumped? On my system the only package that required libevent was something related to nfs... though I guess there could be others but I haven't checked... Looking at http://monkey.org/~provos/libevent/ there's no mention of 1.5.x on the front page anyway. Where does it get it? Fedora 11 has libevent 1.4.5. The calendarserver auto-build script tries to build 1.4.8. If you install libevent 1.4.11 from rawhide, its perfectly happy with that. -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible packages...
On Thursday 09 July 2009 17:02:45 Nathanael D. Noblet wrote: On 07/09/2009 02:31 PM, Jarod Wilson wrote: On Monday 06 July 2009 10:49:31 Eric Sandeen wrote: Nathanael Noblet wrote: On Jul 5, 2009, at 9:33 PM, Eric Sandeen wrote: .. Well their python run script checks for its dependancies, and if not met will do a svn checkout of the right copy, however, they don't keep copies of the libraries within their own repository. So if you fulfill all its dependancies that shouldn't be an issue. Ah, ok - maybe that was it. Currently, it looks like it still requires its own builds of a few things. Stuff (apparently) not in Fedora: -pydirector Yeah I don't think this is in fedora -PyKerberos (might just be named something slightly different) I thought this was I could be wrong though. Ah, python-kerberos seems to be it: Name : python-kerberos Arch : x86_64 Version: 1.1 Release: 4.1.fc11 Size : 23 k Repo : fedora Summary: A high-level wrapper for Kerberos (GSSAPI) operations URL: http://trac.calendarserver.org/projects/calendarserver/browser/PyKerberos License: ASL 2.0 ... Didn't look hard enough then. Good. (Why must our python bits so haphazardly mismatch upstream's name? PyKerberos would have been a perfectly acceptable package name too...) Stuff in Fedora, but simply not used for whatever reason: -vobject (we have python-vobject) -pyflakes I thought they were used if found... I'd have to look at the run file to see if they ignore the system versions.. They weren't here. Had 'em already installed, and the run script still insisted on downloading private copies. Stuff in Fedora, but still heavily patched for CalendarServer: -Twisted (the web2 portion, specifically) -xattr (requires Bob Ippolito's implementation) I've got it using the fedora version of xattr I think, I tried that first, it explicitly blows up when trying to start the server, and says something about using the wrong version of xattr. and didn't notice the patches to Twisted... Its not as bad as I first thought, but: $ ls CalendarServer-trunk/lib-patches/Twisted/ twisted.application.app.patch twisted.web2.dav.method.report.patch twisted.mail.imap4.patchtwisted.web2.dav.resource.patch twisted.python.util.patch twisted.web2.error.patch twisted.web2.auth.digest.patch twisted.web2.server.patch -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible packages...
On Thursday 09 July 2009 17:15:47 Jarod Wilson wrote: Stuff in Fedora, but simply not used for whatever reason: -vobject (we have python-vobject) -pyflakes I thought they were used if found... I'd have to look at the run file to see if they ignore the system versions.. They weren't here. Had 'em already installed, and the run script still insisted on downloading private copies. There are two patches they have for vobject, so that might explain why a local copy of that is still being used. No clue on pyflakes though. (also, Fedora's python-kerberos, aka PyKerberos, does indeed work) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-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: Changing the default 32-bit x86 arch for Fedora 12
On Wednesday 17 June 2009 20:46:30 Peter Robinson wrote: I'm not sure I understand why not. Are you saying that if RedHat decided that RHEL7 was to support Sparc , there'd be no interest in making that a primary arch? ppc/ppc64 is supported in RHEL. It is no longer a primary arch in Fedora. Sorry? I thought it was still primary until after F-12. So yes its scheduled to be a secondard arch for F-13 in 12 months time. Its not one yet. Correct. Though in the context of the discussion, it won't be in the RHEL7 timeframe. I was simply using it as a counter to the but RHEL argument. I don't see RHEL as any form of argument. RedHat does a mass recompile anyway even if its just to remove the fcXX release tag Actually, historically[1], no, Red Hat (its two words, not one) has NOT recompiled just to remove the tag. Take a look at a Red Hat Enterprise Linux 5.0 GA tree some time, its littered with packages that have a .fc6 tag in them. :) But RHEL does X is indeed irrelevant either way. [1] doesn't mean a mass rebuild won't happen for RHEL6. Also doesn't mean that it will. Hand-wavy can't talk about unreleased products... -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Wednesday 17 June 2009 15:17:28 Jesse Keating wrote: On Wed, 2009-06-17 at 15:14 -0400, Jarod Wilson wrote: I thought an official spin could only be a live image. i.e., once you start letting the user choose packages in anaconda, it can't be an official spin anymore. At least, I'm pretty sure that was the case a while back, unless the guidelines have changed while I had my head buried in the sand. I don't know that we forced spins to be live, I just don't think anybody came up with a good spin concept for a choose your own adventure. I have vague recollections of the topic coming up at FUDCon Boston '09 in the spins group discussion, and I swear there was something specific said about only live spins being an option at the time, but I now see at least a header for non-live spins on https://fedoraproject.org/wiki/Spins_Guidelines, so I'll go back in my hole now... :) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Wednesday 17 June 2009 14:01:02 Bill Nottingham wrote: Jeroen van Meeuwen (kana...@kanarip.com) said: Something else not terribly unreasonable, instead of split CD media, a single CD offered that is netinst.iso plus the contents of @core and @base if it'll fit on a CD. Then they can do whatever custom install they want, and add packages after install, either from a DVD media or from a local mirror, or from the Internet. That's exactly what Fedora Unity is about to release for Fedora 11. Any particular reason why this is (or isn't) a spin? I thought an official spin could only be a live image. i.e., once you start letting the user choose packages in anaconda, it can't be an official spin anymore. At least, I'm pretty sure that was the case a while back, unless the guidelines have changed while I had my head buried in the sand. -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Plan for tomorrow's (20090612) FESCo meeting
On Thursday 11 June 2009 17:04:03 Jon Stanley wrote: Here's a list of topics for tomorrow's FESCo meeting, taking place in #fedora-meeting on freenode at 17:00UTC. 160 Announce EOL date for F-9 162 Milestone Adjustment Proposal 161 Proposal for fedora-release version-release naming for rawhide For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. Arch support in F12. During F11, we went from i386-i586, while there was a lot of desire to go straight to i686. The sooner we can make a go/no-go call if we're moving F12 to i686, the better... Not sure if there is a formal feature page for this yet or not... -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Friday 05 June 2009 08:56:47 Tom spot Callaway wrote: On 06/05/2009 06:23 AM, Bastien Nocera wrote: Heya, Yesterday, I was browsing Ubuntu's Blueprints for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Perhaps we could target some specific scanners on the first attempt? We might be able to get some hardware donated to the effort. ~spot, who has several scanners of varying age and quality in a box nb: I have two scanners up here as well that can be utilized, they're actually dual firewire/usb scanners that krh got when working on the firewire stack (and I inherited when I was working on it). Of course, last I knew, they both worked just fine using the gimp sane plugin, so they may not be all that interesting. (One is an Epson somethingorother, one is a Microtek, both are reasonably nice scanners) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-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: [Fedora-music-list] F10 in trouble?
On Wednesday 21 January 2009 14:45:27 Fernando Lopez-Lezcano wrote: Sigh. Firewire. Fedora. Sigh. Faado will only work with the Planet CCRMA kernel because the Fedora kernel still insists in shipping with the new stack only The new stack beats the pants off the old one in pretty much every single area except this one. In a pinch, you can replaced *just* the firewire drivers in the Fedora kernel w/o having to use an entirely different kernel. Note that as of 2.6.30, I believe ffado should work just fine with the new firewire stack (based on a discussion I vaguely recall on the linux1394 mailing list). Quite a bit of work has gone into libraw1394, libiec61883 and the firewire drivers in the past month. -- Jarod Wilson ja...@redhat.com ___ Fedora-music-list mailing list Fedora-music-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-music-list
Re: [Fedora-music-list] How can I fib to yum?
On Monday 10 November 2008 15:01:52 [EMAIL PROTECTED] wrote: I am running Fedora 9.93 and so far I'm very happy with it. The problem is though that I would like to be able to install some packages and this doesn't happen because yum reports version 9.93 instead of 9. This has always been a problem for me on pre-release versions and I probably should know some way around it but I don't. So how do I get yum to install version 9 packages? Conflicts/crashes are not any problem since I keep at least one laptop and desktop just for testing things and these are completely backed up to a external hard drive. Thanks, Replace $releasever with a hard-coded 9 in the yum repos where you want the F9 packages. -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-music-list mailing list Fedora-music-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-music-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: [Fedora-music-list] ffado package up for review
On Wednesday 23 July 2008 12:06:58 pm Christoph Doerbeck wrote: Hi Jarod, We need to figure out how to package an older version of jack for fedora with ffado support enabled. From a previous conversation I've had: I've put up a modified version of jack 0.106.0 (aka 'the last know good') that includes the most recent firewire backend at: http://subversion.ffado.org/attachment/wiki/DevelopmentReleases/jack-audio- connection-kit-0.106.99.tar.gz?format=raw I think it's a good idea to use that for packaging. Anything post 0.106.0 has too many issues, and there is no real need for more testing of these problems. We've fixed some of them, but there are still some well-described test cases that fail consistently. I can personally confirm that the current SVN is not workable. Crud. This is gonna be messy, if it can be done at all. Given that Fedora is at 0.109.2 already, we'd have a hard time talking the maintainer into using that build, so we'd be looking at a compat package or an ffado-jackd package or something along those lines. :\ For grins, I started poking at a local build of it (simply as jack) here. At the moment, its falling down like so: [...] gcc -shared .libs/alsa_driver.o .libs/generic_hw.o .libs/memops.o .libs/hammerfall.o .libs/hdsp.o .libs/ice1712.o .libs/usx2y.o -Wl,--whole-archive ../alsa-midi/.libs/libalsamidi.a -Wl,--no-whole-archive -lasound -lm -lpthread -ldl -m64 -mtune=generic -m64 -mtune=generic -Wl,-soname -Wl,jack_alsa.so -o .libs/jack_alsa.so /usr/bin/ld: ../alsa-midi/.libs/libalsamidi.a(alsa_seqmidi.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ../alsa-midi/.libs/libalsamidi.a(alsa_seqmidi.o): could not read symbols: Bad value Might be some requirements on an older ALSA as well, I dunno... On Tue, 2008-07-22 at 23:28 -0400, Jarod Wilson wrote: So tonight, I finally spent some time hacking on ffado and a spec file for it... Got it building, and even at least basically working... (ffadomixer sees my device, that's as far as I got, ship it!). I've submitted it for Fedora package review: https://bugzilla.redhat.com/show_bug.cgi?id=456353 Reviewers would be greatly appreciated... Even more so if you actually know how to use this stuff (I have no clue myself :). -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-music-list mailing list Fedora-music-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-music-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
