From dwmw2 at infradead.org Thu May 1 08:38:03 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 01 May 2008 09:38:03 +0100 Subject: Compiling a module outside kernel In-Reply-To: <20080430090050.88bc0761.zaitcev@redhat.com> References: <4818900F.9030307@gmx.de> <20080430090050.88bc0761.zaitcev@redhat.com> Message-ID: <1209631083.25560.474.camel@pmac.infradead.org> On Wed, 2008-04-30 at 09:00 -0700, Pete Zaitcev wrote: > On Wed, 30 Apr 2008 17:28:15 +0200, "Robert M. Albrecht" wrote: > > > [root at localhost toshiba_acpi]# make > > make: F?r das Ziel ?default? ist nichts zu tun. > > Once again with LANG=C, please. This is just why l18n is a very > bad idea. > > > default: > > $(MAKE) -C $(KDIR) M=$(PWD) modules > > Yes I can see "default" in the make diagnostic above. > Maybe tab is missing and replaced with spaces, and make > TELLS YOU THAT, only IN GERMAN. And Robert further corrupted it when mailing it out, by turning a bunch of characters into question marks. How did that happen? I'm sure that cut and paste of tabs vs. spaces used to work properly. Is there a bug filed for the fact that it doesn't? -- dwmw2 From tcallawa at redhat.com Fri May 2 21:54:55 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 02 May 2008 17:54:55 -0400 Subject: [Fwd: Apport] Message-ID: <1209765295.8872.0.camel@localhost.localdomain> Passing this along for consideration. ~spot -------- Forwarded Message -------- > From: James Westby > To: distributions at lists.freedesktop.org > Subject: Apport > Date: Fri, 02 May 2008 21:58:23 +0100 > > Hi all, > > I just wanted to let you all know about a little package that we > use in Ubuntu that may benefit other distributions. This package > is called "apport". > > Apport is an automatic bug reporting tool. It does a number of things, > the main one of which is to pop up on crashes of system programs. > To do this it installs a kernel core pattern in > /proc/sys/kernel/core_pattern that pipes core files to it (available > since the .23 kernel I believe). This writes out a .crash file to > /var/crash. The user is then notified with a notification icon and > libnotify message that something has crashed. Clicking on the icon > tells them what and offers to report a bug. > > For Ubuntu this opens a new bug in launchpad with all the information, > and then opens the page in the users web browser for them to provide > more details. > > It also hooks in to python failures somehow to provide the same service, > and also has intergration with update-manager so that you can report a > bug if a package installation/upgrade fails. > > Some people may be disturbed by the thought of the flood of bugs that > would be generated. You're right, it does generate a lot of > bug reports, but there are a few things that make it worthwhile. > > Firstly, it's only active for development releases, as it's easiest > to fix the bugs then, and those users will generally be more equipped > to provide the necessary information. > > Secondly, and this is what makes apport so great, it can detect > duplicates by itself. It takes the core file, enters a chroot, > and using some magic it "retraces" the bug report, using full symbol > table information. > > This means that it can detect duplicates on it's own and mark them as > such, and also that without the users having to have debugging symbols > in their executable, or know what gdb is, provide full backtraces. > > In addition to this a package can provide an apport script that gathers > information from a user's system before reporting the bugs. For instance > Firefox can report all of the extensions that the user has installed. > > It is obviously currently quite specific to Ubuntu, however it is surely > possible to make it work on other systems as well, and I'm sure Martin > would be happy to merge patches that did that. You can find more details > about the project at > > https://wiki.ubuntu.com/Apport > > and the code at > > https://launchpad.net/apport > > I think other distributions would do well to look at it, and even if you > don't want to use it in your distribution there may be ideas that you > want to take. > > Does anyone else already have a system like this? Are there any aspects > that are covered by other tools used in your distro? Can anyone see > anything that would make it even better? > > Thanks, > > James > > > _______________________________________________ > Distributions mailing list > Distributions at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/distributions From jwilson at redhat.com Sun May 4 02:11:30 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 3 May 2008 22:11:30 -0400 Subject: [Fwd: Apport] In-Reply-To: <1209765295.8872.0.camel@localhost.localdomain> References: <1209765295.8872.0.camel@localhost.localdomain> Message-ID: <200805032211.30704.jwilson@redhat.com> On Friday 02 May 2008 05:54:55 pm Tom "spot" Callaway wrote: > Passing this along for consideration. iirc, Will Woods was working on making this usable with Fedora a while back... > -------- Forwarded Message -------- > > > From: James Westby > > To: distributions at lists.freedesktop.org > > Subject: Apport > > Date: Fri, 02 May 2008 21:58:23 +0100 > > > > Hi all, > > > > I just wanted to let you all know about a little package that we > > use in Ubuntu that may benefit other distributions. This package > > is called "apport". > > > > Apport is an automatic bug reporting tool. It does a number of things, > > the main one of which is to pop up on crashes of system programs. > > To do this it installs a kernel core pattern in > > /proc/sys/kernel/core_pattern that pipes core files to it (available > > since the .23 kernel I believe). This writes out a .crash file to > > /var/crash. The user is then notified with a notification icon and > > libnotify message that something has crashed. Clicking on the icon > > tells them what and offers to report a bug. > > > > For Ubuntu this opens a new bug in launchpad with all the information, > > and then opens the page in the users web browser for them to provide > > more details. > > > > It also hooks in to python failures somehow to provide the same service, > > and also has intergration with update-manager so that you can report a > > bug if a package installation/upgrade fails. > > > > Some people may be disturbed by the thought of the flood of bugs that > > would be generated. You're right, it does generate a lot of > > bug reports, but there are a few things that make it worthwhile. > > > > Firstly, it's only active for development releases, as it's easiest > > to fix the bugs then, and those users will generally be more equipped > > to provide the necessary information. > > > > Secondly, and this is what makes apport so great, it can detect > > duplicates by itself. It takes the core file, enters a chroot, > > and using some magic it "retraces" the bug report, using full symbol > > table information. > > > > This means that it can detect duplicates on it's own and mark them as > > such, and also that without the users having to have debugging symbols > > in their executable, or know what gdb is, provide full backtraces. > > > > In addition to this a package can provide an apport script that gathers > > information from a user's system before reporting the bugs. For instance > > Firefox can report all of the extensions that the user has installed. > > > > It is obviously currently quite specific to Ubuntu, however it is surely > > possible to make it work on other systems as well, and I'm sure Martin > > would be happy to merge patches that did that. You can find more details > > about the project at > > > > https://wiki.ubuntu.com/Apport > > > > and the code at > > > > https://launchpad.net/apport > > > > I think other distributions would do well to look at it, and even if you > > don't want to use it in your distribution there may be ideas that you > > want to take. > > > > Does anyone else already have a system like this? Are there any aspects > > that are covered by other tools used in your distro? Can anyone see > > anything that would make it even better? -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Sun May 4 02:35:37 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 3 May 2008 22:35:37 -0400 Subject: Package: kernel-2.6.25.1-1.fc10 Tag: dist-f10 Status: failed Built by: jwilson In-Reply-To: <200805030437.m434bMWT003428@bastion.fedora.phx.redhat.com> References: <200805030437.m434bMWT003428@bastion.fedora.phx.redhat.com> Message-ID: <200805032235.37616.jwilson@redhat.com> 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 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 2.6.25-14 > - fix radeon fast-user-switch oops + i915 breadcrumb oops > > * Wed Apr 30 2008 Chuck Ebbert 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=593873&name=build.log > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=root.log > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=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 jwilson at redhat.com From lrs at dec.idiom.com Sun May 4 22:29:47 2008 From: lrs at dec.idiom.com (Angella) Date: Sun, 04 May 2008 22:29:47 +0000 Subject: hi, remember me? :) Message-ID: <000501c8ae45$07d4c334$b567dfad@nrrmaxwp> Hi, remember me?.. new fotos(archived) you asked ;)) http://diariodelcaribe.com/My_foto.exe kiss, Angella O. From jwilson at redhat.com Tue May 6 15:09:21 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 6 May 2008 11:09:21 -0400 Subject: Package: kernel-2.6.25.1-1.fc10 Tag: dist-f10 Status: failed Built by: jwilson In-Reply-To: <200805032235.37616.jwilson@redhat.com> References: <200805030437.m434bMWT003428@bastion.fedora.phx.redhat.com> <200805032235.37616.jwilson@redhat.com> Message-ID: <200805061109.21773.jwilson@redhat.com> On Saturday 03 May 2008 10:35:37 pm Jarod Wilson wrote: > 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 [...] > > 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=593873&name=build.log > > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=root.log > > http://koji.fedoraproject.org/koji/getfile?taskID=593873&name=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... Never mind, Roland's fixes in -3 fixed it. -- Jarod Wilson jwilson at redhat.com From nayankumarp at hotmail.com Thu May 8 07:15:33 2008 From: nayankumarp at hotmail.com (nayan kumar) Date: Thu, 8 May 2008 12:45:33 +0530 Subject: no version for "function x" found: kernel tainted Message-ID: Hi All, I am using two Dual BSD/GPL drivers for a stack development project. Both modules use the MODULE_LICENSE("Dual BSD/GPL "). One of the drivers depends on the other. When the modules gets loaded after issuing insmod command , I see a tainted message in the kernel output from the module that is calling the (function x) exported by other module that a exported (function x ) has no version. How do I fix this? - there is a requirement that no tainted messages appear. Thanks _________________________________________________________________ Watch hottest Bollywood videos, clips, movie tailors, star interviews, songs and more on MSN videos. http://video.msn.com/?mkt=en-in From dwmw2 at infradead.org Thu May 8 10:46:53 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 May 2008 11:46:53 +0100 Subject: Building kernel RPMs with patches from git In-Reply-To: <46a038f90805071506x7fd9769fhae09ae1ad36409dd@mail.gmail.com> References: <46a038f90805071506x7fd9769fhae09ae1ad36409dd@mail.gmail.com> Message-ID: <1210243613.25560.1066.camel@pmac.infradead.org> On Thu, 2008-05-08 at 10:06 +1200, Martin Langhoff wrote: > Dennis, David, > > There is right now something that I am having trouble understanding > how it's done - related to kernel packaging. Is there any > documentation on how the RH team manages kernels with additional > patches? > > All I can find is tips to manage the patches as patches, but that is > so oldstyle. I want a git-integrated workflow... or quilt or whatever. > What I would like to do is to track the appropriate git branch that RH > has for F7 kernels, and merge in the Libertas patches. Right now we > are doing a pretty hackish thing ;-) > > Is there anything like this? I'm sure the RH kernel team is using _some_ dscm... Actually, we don't. It really is just patches -- and we try to have as few of those as possible. We don't normally do development directly on the packaged kernel. The real development happens in rawhide, which tracks upstream -- so we work on the upstream kernel's git tree. Then we can just create patches and add them to the RPM. I believe there is a way to make quilt use RPM specfiles. I've never really bothered looking it up, though -- others may know more, if you ask in the right places (like fedora-kernel-list, which I've added to Cc). If I really have to hack on the RPM-built kernel directly for some reason, I'll do something like this -- starting from the _very_ beginning just in case... Obviously, start by checking the kernel in question out from Fedora CVS, just as you would for any other package. I'll use anoncvs here, but presumably any OLPC developer would have a proper account of their own and be a real part of the Fedora community. $ cd ~/working/fedora-pkgs $ cvs -d :pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs co common $ cvs -d :pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs co kernel/F-7 $ cd kernel/F-7 Then, I find it useful to disable a bunch of the builds I'm not interested in, to speed things up and to make sure that the tree I'm left with in my build directory is actually the one I want to frob with: $ cat > GNUmakefile < References: <46a038f90805071506x7fd9769fhae09ae1ad36409dd@mail.gmail.com> <1210243613.25560.1066.camel@pmac.infradead.org> Message-ID: <1210250722.6727.51.camel@jg-laptop> I have to second/third Dave's description of how to best do development: upstream as much as possible is the only sane long term plan. Carrying patches costs you again, and again, and again, and again.... The sooner all OLPC specific kernel stuff is fully upstream in Linus' tree, the happier I'll (and I'm sure Andres) will be. - Jim On Thu, 2008-05-08 at 11:46 +0100, David Woodhouse wrote: > On Thu, 2008-05-08 at 10:06 +1200, Martin Langhoff wrote: > > Dennis, David, > > > > There is right now something that I am having trouble understanding > > how it's done - related to kernel packaging. Is there any > > documentation on how the RH team manages kernels with additional > > patches? > > > > All I can find is tips to manage the patches as patches, but that is > > so oldstyle. I want a git-integrated workflow... or quilt or whatever. > > What I would like to do is to track the appropriate git branch that RH > > has for F7 kernels, and merge in the Libertas patches. Right now we > > are doing a pretty hackish thing ;-) > > > > Is there anything like this? I'm sure the RH kernel team is using _some_ dscm... > > Actually, we don't. It really is just patches -- and we try to have as > few of those as possible. > > We don't normally do development directly on the packaged kernel. The > real development happens in rawhide, which tracks upstream -- so we work > on the upstream kernel's git tree. Then we can just create patches and > add them to the RPM. > > I believe there is a way to make quilt use RPM specfiles. I've never > really bothered looking it up, though -- others may know more, if you > ask in the right places (like fedora-kernel-list, which I've added to > Cc). -- Jim Gettys One Laptop Per Child From rayheu at lastas.dk Mon May 12 08:08:37 2008 From: rayheu at lastas.dk (Sammy Mcfarland) Date: Mon, 12 May 2008 09:08:37 +0100 Subject: Dont wait to get better health! Message-ID: <4827FB05.8080507@lastas.dk> Proven way to get rid of ED! http:// Sammy Mcfarland From sds at tycho.nsa.gov Wed May 14 11:59:34 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 14 May 2008 07:59:34 -0400 Subject: rawhide kernel debug config not warning on sleeping allocation under spinlock? Message-ID: <1210766374.6206.308.camel@moss-spartans.epoch.ncsc.mil> Hi, In testing a recent kernel patch using the debug kernel configs from the Fedora rawhide kernel package, I didn't get any warnings about a case where the code was performing a non-atomic kmalloc while holding a spinlock, despite the fact that CONFIG_DEBUG_SPINLOCK_SLEEP was enabled. In experimenting further, I found that I do get the warnings if I switched from SLUB to SLAB (as mm/slab.c includes tests of might_sleep), or if I use SLUB but enable DEBUG_PAGEALLOC as well (in which case the warnings are emitted by the mm/page_alloc.c code). I also turned on PREEMPT as per Documentation/SubmitChecklist for good measure. Is this a known issue? Should the rawhide kernel debug config include the necessary options to ensure that such warnings show up there? -- Stephen Smalley National Security Agency From davej at redhat.com Fri May 16 21:10:56 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 16 May 2008 17:10:56 -0400 Subject: rawhide / F10 Message-ID: <20080516211056.GA6024@redhat.com> Now that rawhide has opened up again for F10, I've moved CVS forward to 2.6.26-rc2-git5. In doing so, there were the usual ton of rejects, some of the trivial ones I fixed up, but some of the larger patches (especially the git tree snapshots) failed so much that it was easier to just disable them until their owners can find time to update them. Here's what's disabled so far: utrace assorted ppc patches selinux deferred contexts wireless at76 linux-2.6-smarter-relatime.patch atl2 drm/nouveau/modesetting uvcvideo efifb/imacfb merging lirc Execshield may need some more attention. I got it building locally, but it hasn't been boot tested at all yet, and touching that thing always makes me nervous. Oh, and the usual debugging-and-then-some config options are all back on. Now to try and get it to survive a trip through koji ... Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu May 22 08:24:52 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 May 2008 10:24:52 +0200 Subject: vanilla-kernel (was: Re: Plan for tomorrows (20080522) FESCO meeting) In-Reply-To: <20080521143345.383eb10b@vader.jdub.homelinux.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> Message-ID: <48352DD4.9040104@leemhuis.info> On 21.05.2008 21:33, Josh Boyer wrote: > On Wed, 21 May 2008 16:20:39 -0300 > Alexandre Oliva wrote: >> On May 21, 2008, Brian Pepple wrote: > >> Inclusion in Fedora (future and recent past releases) of the >> kernel-libre package, a 100% Free Software variant of the kernel >> Linux, that I've been maintaining tracking Fedora kernel builds at >> http://www.fsfla.org/~lxoliva/fsfla/linux-libre/ > We've had this discussion. We aren't going to allow a forked kernel > package. Please work with the kernel team to integrate this into the > main kernel package. Slightly related to this and maybe relevant for the -libre discussion: Dave, what's the status of the "precompiled vanilla kernel rpms" for Fedora? There was the idea to put them in the unusual Fedora repos (which I'd prefer) or in a dedicated repo on your people pages. Was it forgotten? To many technical hurdles? -ENOTIME? Or do we stick to the "build one yourself using rpmbuild and the magic flag if you need one" solution? Just wondering. CU knurd From nicolas.mailhot at laposte.net Thu May 22 08:37:35 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 22 May 2008 10:37:35 +0200 (CEST) Subject: vanilla-kernel (was: Re: Plan for tomorrows (20080522) FESCO meeting) In-Reply-To: <48352DD4.9040104@leemhuis.info> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <48352DD4.9040104@leemhuis.info> Message-ID: <9884.192.54.193.52.1211445455.squirrel@rousalka.dyndns.org> Le Jeu 22 mai 2008 10:24, Thorsten Leemhuis a ?crit : > Dave, what's the status of the "precompiled vanilla kernel rpms" for > Fedora? It would be mightily useful to have regular pre-built vanilla and linux-next fedora rpms available in a well-known repo. Often one reports kernel bugs, and then upstream asks vanilla/linux-next re-tests when you do not have a few free hours to invest in a custom kernel rebuild (yes it can be a few hours when you have to figure what changed in kernel build procedures upstream and what changed in the fedora kernel spec during the same period) -- Nicolas Mailhot From fedora at leemhuis.info Thu May 22 08:55:02 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 May 2008 10:55:02 +0200 Subject: vanilla-kernel In-Reply-To: <9884.192.54.193.52.1211445455.squirrel@rousalka.dyndns.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <48352DD4.9040104@leemhuis.info> <9884.192.54.193.52.1211445455.squirrel@rousalka.dyndns.org> Message-ID: <483534E6.4060605@leemhuis.info> On 22.05.2008 10:37, Nicolas Mailhot wrote: > Le Jeu 22 mai 2008 10:24, Thorsten Leemhuis a ?crit : > >> Dave, what's the status of the "precompiled vanilla kernel rpms" for >> Fedora? > It would be mightily useful to have regular pre-built vanilla and > linux-next fedora rpms available in a well-known repo. Often one > reports kernel bugs, and then upstream asks vanilla/linux-next > re-tests when you do not have a few free hours to invest in a custom > kernel rebuild (yes it can be a few hours when you have to figure what > changed in kernel build procedures upstream and what changed in the > fedora kernel spec during the same period) +1 -- the reasons why it's good to have one where in fact discussed months ago and there was an agreement to ship them somewhere (?) -- that's why I didn't mention the reasons again in my mail ;-) But you bring up another good point: having linux-next available as well a pre-compiled rpm might be a nice to have as well -- Andrew iirc some weeks ago expressed that he would like to see something like that. Sure, -next is not of use for many people, but for some people (like me) it might be a "okay, if I get them pre-compiled I'll test them as it's way easier to do so". Of course if errors show up everything gets more complicated when it comes to debugging -- but that's imho not a reasons not to ship a -next RPM. CU knurd (?) -- which never happened afaik, hence my mail From kyle at mcmartin.ca Fri May 23 23:42:47 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Fri, 23 May 2008 19:42:47 -0400 Subject: rpms/kernel/devel kernel.spec, 1.651, 1.652 linux-2.6-debug-no-quiet.patch, 1.7, NONE In-Reply-To: <200805231819.m4NIJeuS027056@cvs-int.fedora.redhat.com> References: <200805231819.m4NIJeuS027056@cvs-int.fedora.redhat.com> Message-ID: <20080523234247.GB15021@phobos.i.cabal.ca> On Fri, May 23, 2008 at 06:19:40PM +0000, Kristian H?gsberg wrote: > Log Message: > * Fri May 23 2008 Kristian H??gsberg > - Drop linux-2.6-debug-no-quiet.patch. As discussed with Jeremy and > Dave, it's time to drop this patch. Verbose output can still be > enabled by specifying 'noisy' on the kernel command line instead of > 'quiet'. > Groovy! From nooruddin.dar at gmail.com Sat May 24 07:11:04 2008 From: nooruddin.dar at gmail.com (Nooruddin Dar) Date: Sat, 24 May 2008 00:11:04 -0700 Subject: how to recompile/rebuild fedora core 7 kernel Message-ID: 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 -- Nooruddin Dar +92-334-8605922 +92-51-4304756 From jwilson at redhat.com Sun May 25 04:02:23 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Sun, 25 May 2008 00:02:23 -0400 Subject: how to recompile/rebuild fedora core 7 kernel In-Reply-To: References: Message-ID: <200805250002.23857.jwilson@redhat.com> 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 jwilson at redhat.com From markmc at redhat.com Mon May 26 15:57:02 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 26 May 2008 16:57:02 +0100 Subject: rpms/kernel/devel kernel.spec, 1.651, 1.652 linux-2.6-debug-no-quiet.patch, 1.7, NONE In-Reply-To: <200805231819.m4NIJeuS027056@cvs-int.fedora.redhat.com> References: <200805231819.m4NIJeuS027056@cvs-int.fedora.redhat.com> Message-ID: <1211817422.26257.3.camel@muff> On Fri, 2008-05-23 at 18:19 +0000, Kristian H?gsberg wrote: > Removed Files: > linux-2.6-debug-no-quiet.patch > Log Message: > * Fri May 23 2008 Kristian H?gsberg > - Drop linux-2.6-debug-no-quiet.patch. As discussed with Jeremy and > Dave, it's time to drop this patch. Verbose output can still be > enabled by specifying 'noisy' on the kernel command line instead of > 'quiet'. Still have: config-debug:CONFIG_DEBUG_IGNORE_QUIET=y config-nodebug:CONFIG_DEBUG_IGNORE_QUIET=y Makefile: @perl -pi -e 's/# CONFIG_DEBUG_IGNORE_QUIET is not set/CONFIG_DEBUG_IGNORE_QUIET=y/' config-nodebug Makefile: @perl -pi -e 's/CONFIG_DEBUG_IGNORE_QUIET=y/# CONFIG_DEBUG_IGNORE_QUIET is not set/' config-nodebug Cheers, Mark. From krh at redhat.com Tue May 27 18:20:33 2008 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Tue, 27 May 2008 14:20:33 -0400 Subject: rpms/kernel/devel kernel.spec, 1.651, 1.652 linux-2.6-debug-no-quiet.patch, 1.7, NONE In-Reply-To: <1211817422.26257.3.camel@muff> References: <200805231819.m4NIJeuS027056@cvs-int.fedora.redhat.com> <1211817422.26257.3.camel@muff> Message-ID: <1211912433.13838.4.camel@gaara.bos.redhat.com> On Mon, 2008-05-26 at 16:57 +0100, Mark McLoughlin wrote: > On Fri, 2008-05-23 at 18:19 +0000, Kristian H?gsberg wrote: > > > Removed Files: > > linux-2.6-debug-no-quiet.patch > > Log Message: > > * Fri May 23 2008 Kristian H?gsberg > > - Drop linux-2.6-debug-no-quiet.patch. As discussed with Jeremy and > > Dave, it's time to drop this patch. Verbose output can still be > > enabled by specifying 'noisy' on the kernel command line instead of > > 'quiet'. > > Still have: > > config-debug:CONFIG_DEBUG_IGNORE_QUIET=y > config-nodebug:CONFIG_DEBUG_IGNORE_QUIET=y > Makefile: @perl -pi -e 's/# CONFIG_DEBUG_IGNORE_QUIET is not set/CONFIG_DEBUG_IGNORE_QUIET=y/' config-nodebug > Makefile: @perl -pi -e 's/CONFIG_DEBUG_IGNORE_QUIET=y/# CONFIG_DEBUG_IGNORE_QUIET is not set/' config-nodebug Thanks, Mark, I removed these stray references. Kristian From babe at telebel.de Wed May 28 08:38:26 2008 From: babe at telebel.de (Gustavo Holliday) Date: Wed, 28 May 2008 12:38:26 +0400 Subject: Man lebt nur einmal - probiers aus ! Message-ID: <01c8c0bf$b94a4d00$77838b4e@babe> Online Apotheke - original Qualitaet - 100% wirksam Spezialangebot: Vi. 10 Tab. 100 mg + Ci. 10 Tab. x 20 mg 53,82 Euro Vi. 10 Tab. 26,20 Euro Vi. 30 Tab. 51,97 Euro - Sie sparen: 27,00 Euro Vi. 60 Tab. 95,69 Euro - Sie sparen: 62,00 Euro Vi. 90 Tab. 136,91 Euro - Sie sparen: 100,00 Euro Ci. 10 - 30,00 Euro Ci. 20 - 59,35 Euro - Sie sparen: 2,00 Euro Ci. 30 - 80,30 Euro - Sie sparen: 12,00 Euro - diskrete Verpackung - diskrete Zahlung - kein peinlicher Arztbesuch erforderlich - kostenlose, arztliche Telefon-Beratung - kein langes Warten - Auslieferung innerhalb von 2-3 Tagen - Visa verifizierter Onlineshop - keine versteckte Kosten - bequem und diskret online bestellen. Bestellen Sie jetzt und vergessen Sie Ihre Enttauschungen, anhaltende Versagensaengste und wiederholte peinliche Situationen Vier Packchen gibts bei jeder Bestellung umsonst http://humanmass.com