kernel July 2010

kernel@lists.fedoraproject.org

10 participants
9 discussions

dist-git kernel
by Roland McGrath 02 Aug '10

02 Aug '10

The upshot of the scary, scary migration lossage was that Jesse and I became positive we would be eaten by a grue, and just ran away. The old migration was all bad. We don't know why, and we don't really want to know, but might resume an attempt to find out later on after the giant dist-git wildfire is more under control generally. If nobody cares, we probably just won't bother with it. The old pkgs cvs repository exists read-only and, I presume, will exist forever at least in some accessible archive somewhere. If that is enough to satisfy needs to look at old history, then we can just start forgetting all we ever knew about CVS quickly. If we want to recover the old threads of history and integrate them with the new git history that starts today, then we can suffer the great pain of figuring out what the hell to do. If we get some cvs->git guru to sort out the pure conversion of the old cvs repositories, then we'll have perhaps as many as two options. The option that's easier to be sure about is that we can then 'git rebase' our post- G-day commits on top of the new conversion. That has the downside of invalidating all the old commit ids and repos that we all have in our checkouts, and any commit ids that koji stored or whatever. The other option that might exist is some git magic to knit together the separate old and new histories. I vaguely recall something like that exists, but I actually have no idea how to do it or what it really makes possible. So, what we have now is: remotes/origin/HEAD -> origin/master remotes/origin/f10/master 64ba2e5 Initial setup of the repo remotes/origin/f11/master 64ba2e5 Initial setup of the repo remotes/origin/f12/master 2f82dda initial srpm import remotes/origin/f13/master 3494df0 initial srpm import remotes/origin/f14/master 7a32965 initial srpm import remotes/origin/f7/master 64ba2e5 Initial setup of the repo remotes/origin/f8/master 64ba2e5 Initial setup of the repo remotes/origin/f9/master 64ba2e5 Initial setup of the repo remotes/origin/master 7f2b706 Restore TODO file. remotes/origin/olpc2/master 64ba2e5 Initial setup of the repo All those 64ba2e5's are actually just empty, we have not actually imported anything for those branches yet. The f1[234]/master branches were made with 'fedpkg import' of the result of 'make srpm' from each old CVS pseudo-branch's HEAD. (I think--Jesse actually did it all.) So it should have what was last committed in CVS even if it wasn't ever built. On master, from which f14/master only just today branched, I've just put: 377da6d First crack at adaptation to dist-git. 7f2b706 Restore TODO file. 11487c5 Restore README.txt, scripts. The first one is the .spec and Makefile patches I posted yesterday. I didn't use any of the Makefile stuff, but I figure we might want it sitting there until we clean it up into some scripts/ stuff or whatever we are going to do. (IMHO almost none of that belongs in make, though Makefile.config is probably OK.) The second is adding back the TODO file verbatim. I just assumed we're actually still using that. Then I noticed that scripts/ was gone too, and put that back. Some scripts and README.txt are probably out of date talking about cvs and make stuff that doesn't exist. You should get right on that. Then I merged master back onto f14/master, so they are now the same. Until we actually doing f15 separately, these are both the same and it doesn't really matter which branch you use for commits. Just make sure it's the same one every time, and merge the other one in first. There should not be any non-fast-forward merges until we really want to work separately on f15. I figure we should spend a few days kicking the tires on f14 and/or rawhide builds and clean up the scripts. Then we can apply the same .spec and script stuff to the f13 branch to get it building again. Thanks, Roland

3 6

kernel dist-git
by Roland McGrath 29 Jul '10

29 Jul '10

The new repo at ssh://pkgs.fedoraproject.org/kernel is supposedly live, but I suggest that nobody attempt to touch it. I think the CVS migration might need to be redone and invalidate that old git repo. Do: cvs -Q -d cvs.fedoraproject.org:/cvs/pkgs co -P -d cvs-devel rpms/kernel/devel git clone ssh://pkgs.fedoraproject.org/kernel git-devel diff -ru --exclude={CVS,.git,.{cvs,git}ignore} {cvs,git}-devel and marvel at the lossage. cvs -Q -d cvs.fedoraproject.org:/cvs/pkgs co -P -d cvs-f13 rpms/kernel/F-13 git clone -b f13/master ssh://pkgs.fedoraproject.org/kernel git-f13 diff -ru --exclude={CVS,.git,.{cvs,git}ignore} {cvs,git}-f13 is not nearly as bad, but still disturbingly wrong. And then f12 looks perfectly fine, and I didn't check the rest. The "master" branch (aka devel aka rawhide) is just all messed up. The kernel.spec is the right one, but nearly all the other files are the entirely wrong ones, as if it got everything else from another branch (including adding/removing files). The f13/master branch is only somewhat messed up. Mostly it just has some files that were previously removed in CVS. But it is also missing one patch file, and apparently has an older revision for a couple of patch files. The only differences that there should be in this comparison are: * no "branch" files * .cvsignore -> .gitignore * files with embedded $Tag: ...$ -> $Tag$ In fact, there are "branch" files in git though there should not be any. We have the $Tag$ differences and .gitignore as we expect. Everything else is just scary, scary, bogons. My best guess is that the use of (real) CVS branches confused the repository converter (I don't know which one he used). It did convert some real CVS branches to git branches, so it at least thinks it knows about the concept. But it sure got confused somehow. Before I noticed this lossage, I was trying to start fiddling our magic to cope with dist-git. What I did is below. Since the git repo is scrod, I didn't commit anything anywhere. The kernel.spec changes mean, as the comment says, that you have to start using rpmdev-bumpspec to make your log entries and update the release, or else remember to do it by hand. No more $Revision$ magic. We discussed on IRC doing newfangled git versions of that magic, but it was just going to get entirely silly. If we can't keep our rear ends in gear, we can consider some git hooks to bludgeon ourselves for errors. But since the new dist-git scheme means no git tags get made for builds until you do them right, you probably won't manage to leave any evidence of your pilot error that makes it obvious you didn't mean to do that. The next person to rebase will get to rewrite rebase.sh to work in the new world order. When you do that, make it fiddle baserelease back to 1 while you're at it. That and rpmdev-bumpspec will probably make for all the release-number-setting magic we should really care to think we need. The Makefile changes are just the first cut at basic decrufting. IMHO we should rid of most of the rest of what's in Makefile. Probably most of it belongs in separate scripts/foo scripts. Thanks, Roland diff --git a/Makefile b/Makefile index 42d84b2..6cdec44 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,4 @@ # Makefile for source rpm: kernel -# $Id$ -NAME := kernel SPECFILE := kernel.spec # use noarch for make prep instead of the current CPU @@ -11,25 +9,12 @@ PREPARCH = noarch # we only check the .sign signatures UPSTREAM_CHECKS = sign -# local targets we need to carry around in addition to the default sources -TARGETS = download +.PHONY: help +help: +%: + @echo "Try fedpkg $@ or something like that" + @exit 1 -define find-makefile-common -for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done -endef - -MAKEFILE_COMMON := $(shell $(find-makefile-common)) - -ifeq ($(MAKEFILE_COMMON),) -# attept a checkout -define checkout-makefile-common -test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo "common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to checkout the 'common' module." ; exit -1 ; } >&2 -endef - -MAKEFILE_COMMON := $(shell $(checkout-makefile-common)) -endif - -include $(MAKEFILE_COMMON) include Makefile.config ifndef KVERSION @@ -182,9 +167,6 @@ reconfig: @VERSION=$(KVERSION) make -f Makefile.config configs @scripts/reconfig.sh -force-tag: $(SPECFILE) $(COMMON_DIR)/branches - @$(MAKE) tag TAG_OPTS="-F $(TAG_OPTS)" - unused-kernel-patches: @for f in *.patch; do if [ -e $$f ]; then (egrep -q "^Patch[[:digit:]]+:[[:space:]]+$$f" $(SPECFILE) || echo "Unused: $$f") && egrep -q "^ApplyPatch[[:space:]]+$$f|^ApplyOptionalPatch[[:space:]]+$$f" $(SPECFILE) || echo "Unapplied: $$f"; fi; done diff --git a/kernel.spec b/kernel.spec index 1a7fab9..21f34bc 100644 --- a/kernel.spec +++ b/kernel.spec @@ -38,19 +38,18 @@ Summary: The Linux kernel %endif %endif -# fedora_build defines which build revision of this kernel version we're -# building. Rather than incrementing forever, as with the prior versioning -# setup, we set fedora_cvs_origin to the current cvs revision s/1.// of the -# kernel spec when the kernel is rebased, so fedora_build automatically -# works out to the offset from the rebase, so it doesn't get too ginormous. -# -# If you're building on a branch, the RCS revision will be something like -# 1.1205.1.1. In this case we drop the initial 1, subtract fedora_cvs_origin -# from the second number, and then append the rest of the RCS string as is. -# Don't stare at the awk too long, you'll go blind. -%define fedora_cvs_origin 2037 -%define fedora_cvs_revision() %2 -%global fedora_build %(echo %{fedora_cvs_origin}.%{fedora_cvs_revision $Revision$} | awk -F . '{ OFS = "."; ORS = ""; print $3 - $1 ; i = 4 ; OFS = ""; while (i <= NF) { print ".", $i ; i++} }') +# baserelease defines which build revision of this kernel version we're +# building. We used to call this fedora_build, but the magical name +# baserelease is matched by the rpmdev-bumpspec tool, which you should use. +# +# We used to have some extra magic weirdness to bump this automatically, +# but now we don't. Just use: rpmdev-bumpspec -c 'comment for changelog' +# When changing base_sublevel below or going from rc to a final kernel, +# reset this by hand to 1 (or to 0 and then use rpmdev-bumpspec). +# scripts/rebase.sh should be made to do that for you, actually. +# +%global baserelease 57 +%global fedora_build %{baserelease} # 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,

4 3

[F-12 PATCH BZ592785] usbhid: fix oops in dev_get_drvdata
by Stanislaw Gruszka 28 Jul '10

28 Jul '10

commit 57ab12e418ec4fe24c11788bb1bbdabb29d05679 Author: Jiri Kosina <jkosina(a)suse.cz> Date: Wed Feb 17 14:25:01 2010 +0100 HID: usbhid: initialize interface pointers early enough Move the initialization of USB interface pointers from _start() over to _probe() callback, which is where it belongs. This fixes case where interface is NULL when parsing of report descriptor fails. LKML-Reference: <20100213135720.603e5f64(a)neptune.home> Reported-by: Alan Stern <stern(a)rowland.harvard.edu> Tested-by: Bruno Prémont <bonbons(a)linux-vserver.org> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c index 74bd3ca..ceaf4a1 100644 --- a/drivers/hid/usbhid/hid-core.c +++ b/drivers/hid/usbhid/hid-core.c @@ -1005,9 +1005,6 @@ static int usbhid_start(struct hid_device *hid) spin_lock_init(&usbhid->lock); - usbhid->intf = intf; - usbhid->ifnum = interface->desc.bInterfaceNumber; - usbhid->urbctrl = usb_alloc_urb(0, GFP_KERNEL); if (!usbhid->urbctrl) { ret = -ENOMEM; @@ -1178,6 +1175,8 @@ static int usbhid_probe(struct usb_interface *intf, const struct usb_device_id * hid->driver_data = usbhid; usbhid->hid = hid; + usbhid->intf = intf; + usbhid->ifnum = interface->desc.bInterfaceNumber; ret = hid_add_device(hid); if (ret) { commit fde4e2f73208b8f34f123791e39c0cb6bc74b32a Author: Alan Stern <stern(a)rowland.harvard.edu> Date: Fri May 7 10:41:10 2010 -0400 HID: fix suspend crash by moving initializations earlier Although the usbhid driver allocates its usbhid structure in the probe routine, several critical fields in that structure don't get initialized until usbhid_start(). However if report descriptor parsing fails then usbhid_start() is never called. This leads to problems during system suspend -- the system will freeze. This patch (as1378) fixes the bug by moving the initialization statements up into usbhid_probe(). Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-by: Bruno Prémont <bonbons(a)linux-vserver.org> Tested-By: Bruno Prémont <bonbons(a)linux-vserver.org> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c index 56d06cd..7b85b69 100644 --- a/drivers/hid/usbhid/hid-core.c +++ b/drivers/hid/usbhid/hid-core.c @@ -999,13 +999,6 @@ static int usbhid_start(struct hid_device *hid) } } - init_waitqueue_head(&usbhid->wait); - INIT_WORK(&usbhid->reset_work, hid_reset); - INIT_WORK(&usbhid->restart_work, __usbhid_restart_queues); - setup_timer(&usbhid->io_retry, hid_retry_timeout, (unsigned long) hid); - - spin_lock_init(&usbhid->lock); - usbhid->urbctrl = usb_alloc_urb(0, GFP_KERNEL); if (!usbhid->urbctrl) { ret = -ENOMEM; @@ -1179,6 +1172,12 @@ static int usbhid_probe(struct usb_interface *intf, const struct usb_device_id * usbhid->intf = intf; usbhid->ifnum = interface->desc.bInterfaceNumber; + init_waitqueue_head(&usbhid->wait); + INIT_WORK(&usbhid->reset_work, hid_reset); + INIT_WORK(&usbhid->restart_work, __usbhid_restart_queues); + setup_timer(&usbhid->io_retry, hid_retry_timeout, (unsigned long) hid); + spin_lock_init(&usbhid->lock); + ret = hid_add_device(hid); if (ret) { if (ret != -ENODEV)

1 0

files listed twice.
by Dave Jones 21 Jul '10

21 Jul '10

This has been bugging me for a while. At the end of every build, the generation of the kernel-debug package spews out hundreds of lines like.. warning: File listed twice: /usr/src/kernels/2.6.35-0.51.rc5.git6.fc14.x86_64 warning: File listed twice: /usr/src/kernels/2.6.35-0.51.rc5.git6.fc14.x86_64/.config warning: File listed twice: /usr/src/kernels/2.6.35-0.51.rc5.git6.fc14.x86_64/Makefile ... The only references to these files are.. /usr/src/kernels/%{KVERREL}%{?2:.%{2}} in the -devel stanza, and %{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:.%{2}} in the -debuginfo part, which should be a different directory. Anyone spot what I'm missing here ? Roland ? Dave

2 3

exec-shield=2
by Roland McGrath 14 Jul '10

14 Jul '10

Do we care about the exec-shield=2 configuration? Does anybody use that? In the execshield patch we have in Fedora at this point, the (exec_shield & 2) special cases are the only arch-independent changes that are not fairly clean and isolated. The patch puts a comment in sysctl.c about several bit flags in exec_shield, but actually only &2 and !=0 are really meaningful in our code. If we could get rid of exec_shield&2 then it would be down to just exec_shield!=0 and as of now that already only affects NX-emulation in fact. If someone does want a behavior akin to exec_shield&2 that could be done cleanly (and upstreamed) with a saner sysctl or two. What it does now is a little incoherent. Thanks, Roland

4 8

F-13 kernel rebased to 2.6.34
by Chuck Ebbert 09 Jul '10

09 Jul '10

I've committed 2.6.34.1 to the F-13 branch (2.6.33 is now in the private-f13-2_6_33 branch tag.) It's still a little rough around the edges (mostly just needs stale patches cleaned up) but I've kicked off a build so people can try it.

1 0

perf package
by Roland McGrath 08 Jul '10

08 Jul '10

After talking to Kyle on IRC a bit, I committed some changes to how we build and package perf. Kyle didn't so much endorse a plan as first say he just didn't care what I shoved up there, and then suggest a new and different shape that might be more pleasing than what I'd proposed. So what I've committed and built (2.6.35-0.29.rc4.git0.fc14) is entirely contrary to what I described before. It's all easy to revert or change if we don't like it. We have no new kernel-perf subpackage that I talked about. Instead, the perf package is no longer noarch and no longer a wrapper script. That package has the perf binary and its man pages and attendant hooey, just as if it were any random userland package. I made it use tools/perf/Makefile's 'make install', so we get everything them geniuses upstream think we want. Various things (I don't know what) that I presume didn't work before should work now, since we package /usr/libexec/perf-core with various internal scripts that are for whatever. perf is now in /usr/bin rather than /usr/sbin, cause bindir is what upstream thinks we want and I ain't the kind to argue. This might mean some kind of pain for wrong-dominant multilib distros, but those people can pummel us later. Or maybe ppc32-built perf can talk to a ppc64 kernel OK, hell if I know. This lovely plan follows from the new presumption that perf binaries and kernels of the present and future can handle each other sanely enough. acme said this was true, and you can assign all your bugs about perf vs kernel mismatches to him. ;-) Complaints and suggestions welcomish. But, it done built now, so, you know, by default, we're shippin' it. Thanks, Roland

2 1

kernel-2.6.35-0.24.rc3.git7.fc14
by Frank Murphy 07 Jul '10

07 Jul '10

Any point opening a bug? It Won't boot, virt-man guest 32bit rawhide. stops at checking for edd No logs whatsoever. Guest boots from saved F13 kernel. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora

2 3

more bug triage fun
by Kevin Fenzi 06 Jul '10

06 Jul '10

Greetings. Finally sat down to look at moving forward on the kernel bug traging stuff (see https://fedoraproject.org/wiki/KernelBugTriage ) Some more thoughts: Would it be useful to add tracker bugs for [PATCH] bugs? Or is that easy enough to query for if you are looking for them? Should we ask submitters to make sure they also submit upstream? Should we have any tracker for [RFE] bugs as well? I noticed we have: Bug 126342 Meta bug: custom built kernels - https://bugzilla.redhat.com/show_bug.cgi?id=126342 Should we close any crazy custom kernel config issues as a duplicate of that one? kevin

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel July 2010