<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/usr/Makefile, branch v2.6.17</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>kbuild: rebuild initramfs if content of initramfs changes</title>
<updated>2006-04-11T11:24:32+00:00</updated>
<author>
<name>Sam Ravnborg</name>
<email>sam@mars.ravnborg.org</email>
</author>
<published>2006-04-11T11:24:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d39a206bc35d46a3b2eb98cd4f34e340d5e56a50'/>
<id>d39a206bc35d46a3b2eb98cd4f34e340d5e56a50</id>
<content type='text'>
initramfs.cpio.gz being build in usr/ and included in the
kernel was not rebuild when the included files changed.

To fix this the following was done:
- let gen_initramfs.sh generate a list of files and directories included
  in the initramfs
- gen_initramfs generate the gzipped cpio archive so we could simplify
  the kbuild file (Makefile)
- utilising the kbuild infrastructure so when uid/gid root mapping changes
  the initramfs will be rebuild

With this change we have a much more robust initramfs generation.

Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
initramfs.cpio.gz being build in usr/ and included in the
kernel was not rebuild when the included files changed.

To fix this the following was done:
- let gen_initramfs.sh generate a list of files and directories included
  in the initramfs
- gen_initramfs generate the gzipped cpio archive so we could simplify
  the kbuild file (Makefile)
- utilising the kbuild infrastructure so when uid/gid root mapping changes
  the initramfs will be rebuild

With this change we have a much more robust initramfs generation.

Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>kbuild: introduce Kbuild.include</title>
<updated>2005-07-25T20:10:36+00:00</updated>
<author>
<name>Sam Ravnborg</name>
<email>sam@mars.(none)</email>
</author>
<published>2005-07-25T20:10:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8ec4b4ff1c89bb280e662b84eba503ca44abe836'/>
<id>8ec4b4ff1c89bb280e662b84eba503ca44abe836</id>
<content type='text'>
Kbuild.include is a placeholder for definitions originally present in
both the top-level Makefile and scripts/Makefile.build.
There were a slight difference in the filechk definition, so the most videly
used version was kept and usr/Makefile was adopted for this syntax.

Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
---
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Kbuild.include is a placeholder for definitions originally present in
both the top-level Makefile and scripts/Makefile.build.
There were a slight difference in the filechk definition, so the most videly
used version was kept and usr/Makefile was adopted for this syntax.

Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
---
</pre>
</div>
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</pre>
</div>
</content>
</entry>
</feed>
