dist-git kernel
by Roland McGrath
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
13 years, 7 months
kernel dist-git
by Roland McGrath
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,
13 years, 7 months
[F-12 PATCH BZ592785] usbhid: fix oops in dev_get_drvdata
by Stanislaw Gruszka
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)
13 years, 7 months
files listed twice.
by Dave Jones
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
13 years, 8 months
exec-shield=2
by Roland McGrath
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
13 years, 8 months
F-13 kernel rebased to 2.6.34
by Chuck Ebbert
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.
13 years, 8 months
perf package
by Roland McGrath
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
13 years, 8 months
kernel-2.6.35-0.24.rc3.git7.fc14
by Frank Murphy
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
13 years, 8 months
more bug triage fun
by Kevin Fenzi
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
13 years, 8 months