Some people may have noticed the new git tree located at:
rsync.kernel.org:/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
This tree will directly reflect the Ubuntu Linux Kernel that is available
in our distribution (along with build system). First use of this kernel
tree is slated for Dapper Drake (Ubuntu 6.04), and will stay synced with
the just released 2.6.14(.y).
There are several reasons for making this repo available on kernel.org.
Primary reasons include a more open development model, better visibility
with the kernel developer community, and to make the kernel available to
other distro's who may want to base their kernel off of ours.
Primary goals include:
* A kernel geared toward a real world Linux distribution, supporting
drivers and subsystems that end users need. You will find a lot of
external drivers in our tree, that for whatever reason, are not included
in the upstream kernel. We hope that including these drivers will give
users a one-stop kernel (no downloading and compiling external modules),
and also provide much needed testing for modules hoping to be included
into the mainstream kernel.
* Real world configurations. We will provide default kernel configs for a
variety of architectures and system "flavors".
* Any feature and/or driver included will attempt to be configurable. That
is, if you don't select to compile it, it will not cause any significant
changes from the stock kernel we are using at that point.
* Open development model. We want to be as close to the kernel community
as possible. Integrating ideas, getting feedback, and causing as little
havoc as possible :)
--
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk - http://www.swissdisk.com/
On 11/6/05, Ben Collins <[email protected]> wrote:
> Some people may have noticed the new git tree located at:
>
> rsync.kernel.org:/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
>
> This tree will directly reflect the Ubuntu Linux Kernel that is available
> in our distribution (along with build system). First use of this kernel
> tree is slated for Dapper Drake (Ubuntu 6.04), and will stay synced with
> the just released 2.6.14(.y).
No, I hadn't. But suddently the comment Mark made recently that the
Ubuntu kernel is available from kernel.org makes a lot more sense :-)
There was me thinking WTF? But I can see it was just a secret plan for
world domination all along.
Jon.
On Nov 05 2005, Ben Collins wrote:
> Some people may have noticed the new git tree located at:
>
> rsync.kernel.org:/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
>
> This tree will directly reflect the Ubuntu Linux Kernel that is available
> in our distribution (along with build system). First use of this kernel
> tree is slated for Dapper Drake (Ubuntu 6.04), and will stay synced with
> the just released 2.6.14(.y).
(...)
Will you be providing patches against 2.6.14 for those that don't use
Ubuntu proper (using pure Debian here), but might want to give some
feedback on other kernel trees?
Thanks, Rog?rio Brito.
--
Rog?rio Brito : [email protected] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
Ben Collins wrote:
> Some people may have noticed the new git tree located at:
>
> rsync.kernel.org:/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
>
> This tree will directly reflect the Ubuntu Linux Kernel that is available
> in our distribution (along with build system). First use of this kernel
> tree is slated for Dapper Drake (Ubuntu 6.04), and will stay synced with
> the just released 2.6.14(.y).
>
> There are several reasons for making this repo available on kernel.org.
> Primary reasons include a more open development model, better visibility
> with the kernel developer community, and to make the kernel available to
> other distro's who may want to base their kernel off of ours.
Nice.
Do other distros publish their trees anywhere? It would be handy to collect
links and publish them in an article on distrodev.org or some place like that.
(are there any kernel wikis?)
I try to 'open' Gentoo's kernel patchset at http://dev.gentoo.org/~dsd/genpatches
Daniel
On 11/6/05, Daniel Drake <[email protected]> wrote:
> (are there any kernel wikis?)
There's a really cool one over at http://www.kernelnewbies.org/ and
perhaps there could be one on kernel.org if the powers that be thought
that we a good idea (Wikimedia perhaps?).
Jon.
Hi!
> Some people may have noticed the new git tree located at:
>
> rsync.kernel.org:/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
>
> This tree will directly reflect the Ubuntu Linux Kernel that is available
> in our distribution (along with build system). First use of this kernel
> tree is slated for Dapper Drake (Ubuntu 6.04), and will stay synced with
> the just released 2.6.14(.y).
>
> There are several reasons for making this repo available on kernel.org.
> Primary reasons include a more open development model, better visibility
> with the kernel developer community, and to make the kernel available to
> other distro's who may want to base their kernel off of ours.
Heh, I'm interested. We were thinking about using git for internal
suse kernel trees, but we thought it would not work, as we need more
something like quilt. Do you really use git internally, or do you just
export to it? If git is usable for distro develompent... that would be
good news.
Pavel
--
Thanks, Sharp!
On Sat, Nov 05, 2005 at 05:37:52PM -0800, Ben Collins wrote:
> * A kernel geared toward a real world Linux distribution, supporting
> drivers and subsystems that end users need. You will find a lot of
> external drivers in our tree, that for whatever reason, are not included
> in the upstream kernel. We hope that including these drivers will give
> users a one-stop kernel (no downloading and compiling external modules),
> and also provide much needed testing for modules hoping to be included
> into the mainstream kernel.
Does this include the various closed source drivers that you include in
your distro releases?
thanks,
greg k-h
On Sul, 2005-11-06 at 14:48 +0000, Daniel Drake wrote:
> Do other distros publish their trees anywhere? It would be handy to collect
> links and publish them in an article on distrodev.org or some place like that.
> (are there any kernel wikis?)
>
> I try to 'open' Gentoo's kernel patchset at http://dev.gentoo.org/~dsd/genpatches
The FC kernel trees rpms and source rpms are distributed from the fedora
site. 'Production' kernels go to the updates directory, others which are
intended for testing go to the update testing directory and may or may
not work wonderfully.
RHEL kernel source trees are also on redhat.com, although I suspect they
are of somewhat limited interest to most of the development community.
Alan Cox wrote:
> The FC kernel trees rpms and source rpms are distributed from the fedora
> site. 'Production' kernels go to the updates directory, others which are
> intended for testing go to the update testing directory and may or may
> not work wonderfully.
Source RPM's will just contain a Linux kernel tree with your patches already
applied, right?
Is there an easier way to see what redhat/fedora have patched in, short of
finding the closest vanilla tree and using "diff"?
Daniel
On Llu, 2005-11-07 at 16:33 +0000, Daniel Drake wrote:
> Source RPM's will just contain a Linux kernel tree with your patches already
> applied, right?
Of course not. Its an rpm file. RPM files contain a set of broken out
patches and base tar ball plus controlling rules for application. It's
rather more advanced than .deb sources.
Alan
Daniel Drake wrote:
> Is there an easier way to see what redhat/fedora have patched in, short of finding the closest vanilla tree and using "diff"?
[ http://cvs.fedora.redhat.com/viewcvs/devel/kernel/ ]
--
Romanes eunt domus
On Mon, 2005-11-07 at 18:08, Alan Cox wrote:
> On Llu, 2005-11-07 at 16:33 +0000, Daniel Drake wrote:
> > Source RPM's will just contain a Linux kernel tree with your patches already
> > applied, right?
>
> Of course not. Its an rpm file. RPM files contain a set of broken out
> patches and base tar ball plus controlling rules for application. It's
> rather more advanced than .deb sources.
That's a troll, Alan. .deb contain exactely the same things.
Xav
Xavier Bestel <[email protected]> writes:
> On Mon, 2005-11-07 at 18:08, Alan Cox wrote:
>> On Llu, 2005-11-07 at 16:33 +0000, Daniel Drake wrote:
>> > Source RPM's will just contain a Linux kernel tree with your patches already
>> > applied, right?
>>
>> Of course not. Its an rpm file. RPM files contain a set of broken out
>> patches and base tar ball plus controlling rules for application. It's
>> rather more advanced than .deb sources.
>
> That's a troll, Alan. .deb contain exactely the same things.
Some packages use dpatch and related tools like this, and give you a
pristine upstream tarball and broken-out patches, but it is not
supported at the level that RPMs do---which is to say, in the core
tool.
Seriously, I pulled apart a whole lot of RPMs when I was doing the
first real (libc6) port of Debian to the Alpha in '96, and it was a
lot easier than dealing with the generally mashed-together patches in
a debian package's .diff.gz.
Mike
On Mon, Nov 07, 2005 at 06:05:44PM +0100, Xavier Bestel wrote:
> On Mon, 2005-11-07 at 18:08, Alan Cox wrote:
> > On Llu, 2005-11-07 at 16:33 +0000, Daniel Drake wrote:
> > > Source RPM's will just contain a Linux kernel tree with your patches already
> > > applied, right?
> >
> > Of course not. Its an rpm file. RPM files contain a set of broken out
> > patches and base tar ball plus controlling rules for application. It's
> > rather more advanced than .deb sources.
>
> That's a troll, Alan. .deb contain exactely the same things.
No, he's right.
The changes a package maintainer does in a .deb are shipped in one big
diff containing all the differences between the pristine upstream
sources and the tree used for building the package.
There are now ways how to arrange the patches in a way that they are
visible as separate patches inside the unpackaged source tree used for
building the package [1], but if all you are interested in is to get the
patches applied against the upstream sources RPM is still superior
(even on my Debian system mc can extract the patches as if the RPM was a
tar file).
> Xav
cu
Adrian
[1] that are used by a subset of the packages shipped by Debian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Nov 07, 2005 at 06:32:01PM +0100, Adrian Bunk wrote:
> On Mon, Nov 07, 2005 at 06:05:44PM +0100, Xavier Bestel wrote:
> > On Mon, 2005-11-07 at 18:08, Alan Cox wrote:
> > > On Llu, 2005-11-07 at 16:33 +0000, Daniel Drake wrote:
> > > > Source RPM's will just contain a Linux kernel tree with your patches already
> > > > applied, right?
> > >
> > > Of course not. Its an rpm file. RPM files contain a set of broken out
> > > patches and base tar ball plus controlling rules for application. It's
> > > rather more advanced than .deb sources.
> >
> > That's a troll, Alan. .deb contain exactely the same things.
>
> No, he's right.
That's only right in the simplest form. However, the debian kernel and a
huge portion of other complex packages contain a debian/patches/ directory
that gets applied at build time. Each patch is broken out seperately, with
description embedded in the patch.
--
Ben Collins <[email protected]>
Developer
Ubuntu Linux
On Sun, Nov 06, 2005 at 12:36:36PM -0800, Greg KH wrote:
> On Sat, Nov 05, 2005 at 05:37:52PM -0800, Ben Collins wrote:
> > * A kernel geared toward a real world Linux distribution, supporting
> > drivers and subsystems that end users need. You will find a lot of
> > external drivers in our tree, that for whatever reason, are not included
> > in the upstream kernel. We hope that including these drivers will give
> > users a one-stop kernel (no downloading and compiling external modules),
> > and also provide much needed testing for modules hoping to be included
> > into the mainstream kernel.
>
> Does this include the various closed source drivers that you include in
> your distro releases?
I don't have anything to do with the restricted modules package found
outside of our main distro tree.
--
Ben Collins <[email protected]>
Developer
Ubuntu Linux
On Sun, Nov 06, 2005 at 09:26:09PM +0100, Pavel Machek wrote:
> Hi!
>
> > Some people may have noticed the new git tree located at:
> >
> > rsync.kernel.org:/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
> >
> > This tree will directly reflect the Ubuntu Linux Kernel that is available
> > in our distribution (along with build system). First use of this kernel
> > tree is slated for Dapper Drake (Ubuntu 6.04), and will stay synced with
> > the just released 2.6.14(.y).
> >
> > There are several reasons for making this repo available on kernel.org.
> > Primary reasons include a more open development model, better visibility
> > with the kernel developer community, and to make the kernel available to
> > other distro's who may want to base their kernel off of ours.
>
> Heh, I'm interested. We were thinking about using git for internal
> suse kernel trees, but we thought it would not work, as we need more
> something like quilt. Do you really use git internally, or do you just
> export to it? If git is usable for distro develompent... that would be
> good news.
Prior to this we were using baz (arch derivative), but all the patches
were still applied at build time.
We're giving git a go just to see. It's all being done right there, I push
directly to master.kernel.org (and also mirror it to a local machine where
ubuntu devs can make better use of it).
--
Ben Collins <[email protected]>
Developer
Ubuntu Linux
On Wed, Nov 09, 2005 at 06:12:16AM -0800, Ben Collins wrote:
> We're giving git a go just to see. It's all being done right there, I push
> directly to master.kernel.org (and also mirror it to a local machine where
> ubuntu devs can make better use of it).
I think over time, a set of patches and a clean kernel tree to apply
them to, is easier to handle. Especially with such excellent tools
availble to do this now (like quilt and patch-utils).
But good luck with this, it will be interesting to see how long you can
handle maintaining the kernel in this manner.
greg k-h