relative objtree change broke tar builds?

PATCH In review J. Bruce Fields 5 participants 18 messages Jun 17, 2014 – Jul 7, 2014 Kbuild

Share & tools

J. Bruce Fields

author

2014-06-17 22:38 UTC #0 lore raw

The scripts I use for my kernel testing rely on the targz-pkg make target. After updating to 3.16-rc1 my scripts started failing. In scripts/package/buildtar:

tmpdir="${objtree}/tar-install" tarball="${objtree}/linux-${KERNELRELEASE}-${ARCH}.tar"
..
#
# Create the tarball
#
(

        cd "${tmpdir}"
        opts=
        if tar --owner=root --group=root --help >/dev/null 2>&1; then
                opts="--owner=root --group=root"
        fi
        tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"

)

After 7e1c04779efd511 "kbuild: Use relative path for $(objtree)", that's a relative instead of absolute path so the tarball's dumped by default into tmpdir, not what was intended.

The changelog there says

The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.

But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.

--b.

Michal Marek

2014-06-18 09:06 UTC #1 lore raw

Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):

Quoted 11 lines

The scripts I use for my kernel testing rely on the targz-pkg make target. After updating to 3.16-rc1 my scripts started failing. In scripts/package/buildtar:
tmpdir="${objtree}/tar-install" tarball="${objtree}/linux-${KERNELRELEASE}-${ARCH}.tar"
..
#
# Create the tarball
#
(

Quoted 7 lines

        cd "${tmpdir}"
        opts=
        if tar --owner=root --group=root --help >/dev/null 2>&1; then
                opts="--owner=root --group=root"
        fi
        tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"

)

Thanks for the report, I'll fix it.

Quoted 8 lines

The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.

Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?

Thanks,
Michal

J. Bruce Fields

author

2014-06-18 12:20 UTC #2 lore raw

Quoted 20 lines · Michal Marek

Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 11 lines
The scripts I use for my kernel testing rely on the targz-pkg make target. After updating to 3.16-rc1 my scripts started failing. In scripts/package/buildtar:
tmpdir="${objtree}/tar-install" tarball="${objtree}/linux-${KERNELRELEASE}-${ARCH}.tar"
..
#
# Create the tarball
#
(
Quoted 7 lines
        cd "${tmpdir}"
        opts=
        if tar --owner=root --group=root --help >/dev/null 2>&1; then
                opts="--owner=root --group=root"
        fi
        tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"
)

Quoted 1 line

Thanks for the report, I'll fix it.

Thanks!

Quoted 11 lines

Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?

I haven't looked.

I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert. But I don't know if there's other work that now depends on the change.

In any case, your call.

--b.

Michal Marek

2014-06-18 12:33 UTC #3 lore raw

Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):

Quoted 11 lines · Michal Marek

Quoted 10 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.

Quoted 8 lines

Quoted 2 lines
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.

Do these 47 files change the working directory before referencing the variable?

Thanks,
Michal

J. Bruce Fields

author

2014-06-18 13:14 UTC #4 lore raw

Quoted 15 lines · Michal Marek

Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
Quoted 14 lines · Michal Marek
Quoted 12 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?

Quoted 8 lines

Quoted 5 lines
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.
Do these 47 files change the working directory before referencing the variable?

Sorry, I'm not volunteering to check.

Note also that other variables are defined in terms of objtree, and they may be exported or passed to other scripts.

--b.

Randy Dunlap

2014-06-18 15:58 UTC #5 lore raw

Quoted 22 lines · J. Bruce Fields

Quoted 21 lines · Michal Marek
Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
Quoted 19 lines · Michal Marek
Quoted 7 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 6 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
Quoted 5 lines
Quoted 2 lines
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.

Quoted 7 lines

Quoted 2 lines
Do these 47 files change the working directory before referencing the variable?
Sorry, I'm not volunteering to check.
Note also that other variables are defined in terms of objtree, and they may be exported or passed to other scripts.

I'll note one side effect that I really dislike:
If not in silent mode, scripts/mkmakefile tells me that the it is generating ./Makefile. I want to see the real path there instead of '.'.

Signature · 1 line

~Randy

Michal Marek

2014-06-18 19:47 UTC #6 lore raw

Dne 18.6.2014 17:58, Randy Dunlap napsal(a):

Quoted 28 lines · J. Bruce Fields

Quoted 27 lines · Michal Marek
Quoted 15 lines
Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
Quoted 14 lines · Michal Marek
Quoted 12 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?
Quoted 8 lines
Quoted 5 lines
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.
Do these 47 files change the working directory before referencing the variable?
Sorry, I'm not volunteering to check.

Quoted 7 lines

Quoted 2 lines
Note also that other variables are defined in terms of objtree, and they may be exported or passed to other scripts.
I'll note one side effect that I really dislike:
If not in silent mode, scripts/mkmakefile tells me that the it is generating ./Makefile. I want to see the real path there instead of '.'.

The idea is that one should be able to compare as much as possible between the build of /usr/src/linux-<version_a> built in /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in /usr/src/linux-<version_b>/build. One can now even compare the build log with -j1, although that was not the primary goal. So if the changed message is considered problematic, I can change it to show the full path again, like

scripts/mkmakefile +1 -1

index 84af27b..9d291f5 100644
@@ -18,7 +18,7 @@ then
        exit 0
 fi
 if [ "${quiet}" != "silent_" ]; then
-       echo "  GEN     $2/Makefile"
+       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
 fi
 
 cat << EOF > $2/Makefile

Opinions?

Thanks,
Michal

Sam Ravnborg

2014-06-18 19:53 UTC #7 lore raw

Quoted 59 lines · Michal Marek

Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
Quoted 28 lines · J. Bruce Fields
Quoted 27 lines · Michal Marek
Quoted 15 lines
Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
Quoted 14 lines · Michal Marek
Quoted 12 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?
Quoted 8 lines
Quoted 5 lines
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.
Do these 47 files change the working directory before referencing the variable?
Sorry, I'm not volunteering to check.
Quoted 7 lines
Quoted 2 lines
Note also that other variables are defined in terms of objtree, and they may be exported or passed to other scripts.
I'll note one side effect that I really dislike:
If not in silent mode, scripts/mkmakefile tells me that the it is generating ./Makefile. I want to see the real path there instead of '.'.
The idea is that one should be able to compare as much as possible between the build of /usr/src/linux-<version_a> built in /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in /usr/src/linux-<version_b>/build. One can now even compare the build log with -j1, although that was not the primary goal. So if the changed message is considered problematic, I can change it to show the full path again, like
scripts/mkmakefile +1 -1
index 84af27b..9d291f5 100644
@@ -18,7 +18,7 @@ then
        exit 0
 fi
 if [ "${quiet}" != "silent_" ]; then
-       echo "  GEN     $2/Makefile"
+       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
 fi
 
 cat << EOF > $2/Makefile

Quoted 1 line

Opinions?

I agree with Randy - the full path is more informative.

Sam

Randy Dunlap

2014-06-18 21:13 UTC #8 lore raw

Quoted 58 lines · Sam Ravnborg

Quoted 57 lines · Michal Marek
Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
Quoted 28 lines · J. Bruce Fields
Quoted 27 lines · Michal Marek
Quoted 15 lines
Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
Quoted 14 lines · Michal Marek
Quoted 12 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?
Quoted 8 lines
Quoted 5 lines
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.
Do these 47 files change the working directory before referencing the variable?
Sorry, I'm not volunteering to check.
Quoted 7 lines
Quoted 2 lines
Note also that other variables are defined in terms of objtree, and they may be exported or passed to other scripts.
I'll note one side effect that I really dislike:
If not in silent mode, scripts/mkmakefile tells me that the it is generating ./Makefile. I want to see the real path there instead of '.'.
The idea is that one should be able to compare as much as possible between the build of /usr/src/linux-<version_a> built in /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in /usr/src/linux-<version_b>/build. One can now even compare the build log with -j1, although that was not the primary goal. So if the changed message is considered problematic, I can change it to show the full path again, like
scripts/mkmakefile +1 -1
index 84af27b..9d291f5 100644
@@ -18,7 +18,7 @@ then
        exit 0
 fi
 if [ "${quiet}" != "silent_" ]; then
-       echo "  GEN     $2/Makefile"
+       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
 fi
 

Quoted 6 lines

Quoted 3 lines
scripts/mkmakefile +0 -0
 cat << EOF > $2/Makefile
Opinions?
I agree with Randy - the full path is more informative.
Sam

Yes, just '.' discards some very useful information.

Signature · 1 line

~Randy

Michal Marek

2014-07-04 21:37 UTC #9 lore raw

Dne 18.6.2014 23:13, Randy Dunlap napsal(a):

Quoted 59 lines · Sam Ravnborg

Quoted 58 lines · Michal Marek
Quoted 57 lines
Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
Quoted 28 lines · J. Bruce Fields
Quoted 27 lines · Michal Marek
Quoted 15 lines
Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
Quoted 14 lines · Michal Marek
Quoted 12 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?
Quoted 8 lines
Quoted 5 lines
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.
Do these 47 files change the working directory before referencing the variable?
Sorry, I'm not volunteering to check.
Quoted 7 lines
Quoted 2 lines
Note also that other variables are defined in terms of objtree, and they may be exported or passed to other scripts.
I'll note one side effect that I really dislike:
If not in silent mode, scripts/mkmakefile tells me that the it is generating ./Makefile. I want to see the real path there instead of '.'.
The idea is that one should be able to compare as much as possible between the build of /usr/src/linux-<version_a> built in /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in /usr/src/linux-<version_b>/build. One can now even compare the build log with -j1, although that was not the primary goal. So if the changed message is considered problematic, I can change it to show the full path again, like
scripts/mkmakefile +1 -1
index 84af27b..9d291f5 100644
@@ -18,7 +18,7 @@ then
        exit 0
 fi
 if [ "${quiet}" != "silent_" ]; then
-       echo "  GEN     $2/Makefile"
+       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
 fi
 

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
scripts/mkmakefile +0 -0
 cat << EOF > $2/Makefile
Opinions?
I agree with Randy - the full path is more informative.
Sam
Yes, just '.' discards some very useful information.

With commit c2e28dc9 ("kbuild: Print the name of the build directory"), it now prints the full path at the beginning of each make invocation. So I think it is not necessary to repeat the full path a few lines later, do you agree?

Thanks,
Michal

Randy Dunlap

2014-07-04 21:40 UTC #10 lore raw

Quoted 65 lines · Michal Marek

Dne 18.6.2014 23:13, Randy Dunlap napsal(a):
Quoted 64 lines · Sam Ravnborg
Quoted 63 lines · Michal Marek
Quoted 59 lines
Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
Quoted 28 lines · J. Bruce Fields
Quoted 27 lines · Michal Marek
Quoted 15 lines
Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
Quoted 14 lines · Michal Marek
Quoted 12 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?
Quoted 8 lines
Quoted 5 lines
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.
Do these 47 files change the working directory before referencing the variable?
Sorry, I'm not volunteering to check.
Quoted 7 lines
Quoted 2 lines
Note also that other variables are defined in terms of objtree, and they may be exported or passed to other scripts.
I'll note one side effect that I really dislike:
If not in silent mode, scripts/mkmakefile tells me that the it is generating ./Makefile. I want to see the real path there instead of '.'.
The idea is that one should be able to compare as much as possible between the build of /usr/src/linux-<version_a> built in /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in /usr/src/linux-<version_b>/build. One can now even compare the build log with -j1, although that was not the primary goal. So if the changed message is considered problematic, I can change it to show the full path again, like
scripts/mkmakefile +1 -1
index 84af27b..9d291f5 100644
@@ -18,7 +18,7 @@ then
        exit 0
 fi
 if [ "${quiet}" != "silent_" ]; then
-       echo "  GEN     $2/Makefile"
+       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
 fi
 
 cat << EOF > $2/Makefile
Quoted 1 line
Opinions?
I agree with Randy - the full path is more informative.

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
Sam
Yes, just '.' discards some very useful information.
With commit c2e28dc9 ("kbuild: Print the name of the build directory"), it now prints the full path at the beginning of each make invocation. So I think it is not necessary to repeat the full path a few lines later, do you agree?

Sounds possible, but I'll test it early next week. BTW, you are offline. :)

Signature · 1 line

~Randy

Randy Dunlap

2014-07-07 01:04 UTC #11 lore raw

In reply to Michal Marek

Quoted 65 lines · Michal Marek

Dne 18.6.2014 23:13, Randy Dunlap napsal(a):
Quoted 64 lines · Sam Ravnborg
Quoted 63 lines · Michal Marek
Quoted 59 lines
Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
Quoted 28 lines · J. Bruce Fields
Quoted 27 lines · Michal Marek
Quoted 15 lines
Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
Quoted 14 lines · Michal Marek
Quoted 12 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?
Quoted 8 lines
Quoted 5 lines
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.
Do these 47 files change the working directory before referencing the variable?
Sorry, I'm not volunteering to check.
Quoted 7 lines
Quoted 2 lines
Note also that other variables are defined in terms of objtree, and they may be exported or passed to other scripts.
I'll note one side effect that I really dislike:
If not in silent mode, scripts/mkmakefile tells me that the it is generating ./Makefile. I want to see the real path there instead of '.'.
The idea is that one should be able to compare as much as possible between the build of /usr/src/linux-<version_a> built in /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in /usr/src/linux-<version_b>/build. One can now even compare the build log with -j1, although that was not the primary goal. So if the changed message is considered problematic, I can change it to show the full path again, like
scripts/mkmakefile +1 -1
index 84af27b..9d291f5 100644
@@ -18,7 +18,7 @@ then
        exit 0
 fi
 if [ "${quiet}" != "silent_" ]; then
-       echo "  GEN     $2/Makefile"
+       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
 fi
 
 cat << EOF > $2/Makefile
Quoted 1 line
Opinions?
I agree with Randy - the full path is more informative.

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
Sam
Yes, just '.' discards some very useful information.
With commit c2e28dc9 ("kbuild: Print the name of the build directory"), it now prints the full path at the beginning of each make invocation. So I think it is not necessary to repeat the full path a few lines later, do you agree?

Yes, I am OK with this directory output now.

Thanks.

Signature · 1 line

~Randy

Randy Dunlap

2014-06-18 21:20 UTC #12 lore raw

In reply to Michal Marek

Quoted 59 lines · Michal Marek

Dne 18.6.2014 17:58, Randy Dunlap napsal(a):
Quoted 28 lines · J. Bruce Fields
Quoted 27 lines · Michal Marek
Quoted 15 lines
Dne 18.6.2014 14:20, J. Bruce Fields napsal(a):
Quoted 14 lines · Michal Marek
Quoted 12 lines
Dne 18.6.2014 00:38, J. Bruce Fields napsal(a):
Quoted 8 lines
The changelog there says
The main Makefile sets its working directory to the object tree and never changes it again. Therefore, we can use '.' instead of the absolute path.
But the main Makefile also exports objtree, and a quick grep suggests lots of other uses outside the main Makefile.
Do you have examples? Besides your report, I'm only aware of make deb-pkg and make *docs. What else?
Quoted 8 lines
Quoted 5 lines
I haven't looked.
I only note that grep finds 47 files referencing that variable, and absent some argument that the remaining ones are correct, I'd be inclined to revert.
Do these 47 files change the working directory before referencing the variable?
Sorry, I'm not volunteering to check.
Quoted 7 lines
Quoted 2 lines
Note also that other variables are defined in terms of objtree, and they may be exported or passed to other scripts.
I'll note one side effect that I really dislike:
If not in silent mode, scripts/mkmakefile tells me that the it is generating ./Makefile. I want to see the real path there instead of '.'.
The idea is that one should be able to compare as much as possible between the build of /usr/src/linux-<version_a> built in /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in /usr/src/linux-<version_b>/build. One can now even compare the build log with -j1, although that was not the primary goal. So if the changed message is considered problematic, I can change it to show the full path again, like
scripts/mkmakefile +1 -1
index 84af27b..9d291f5 100644
@@ -18,7 +18,7 @@ then
        exit 0
 fi
 if [ "${quiet}" != "silent_" ]; then
-       echo "  GEN     $2/Makefile"
+       echo "  GEN     $(cd $2 && /bin/pwd)/Makefile"
 fi
 
 cat << EOF > $2/Makefile

Quoted 1 line

Opinions?

works for me. Thanks.

Signature · 1 line

~Randy

Ken Moffat

2014-06-19 01:21 UTC #13 lore raw

In reply to Michal Marek

Quoted 5 lines · Michal Marek

The idea is that one should be able to compare as much as possible between the build of /usr/src/linux-<version_a> built in /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in /usr/src/linux-<version_b>/build.

Michal,

Now that you have sent a pull request to Linus, and therefore
addressed the main problem, may I dare to question your example ?

I only started building kernels in (approximately) spring 2000, so I
am sure that I am missing a lot of history. But /usr/src/linux* smells of "tradition" in the Scots sense of "whit ma faither telt me that his faither telt him" ("what my father told me that his father told him" in english). I am sure that /usr/src/linux might have been an expectation in the distant past, but it tends to bring along the assumption that kernels are _built_ by that dangerous guy called 'root'.

Some of us (me included) often build things as root, but it has
many risks and people ought not to be led to believe it is necessarily the correct way to do things. Over the past 14 years I have built kernels in ~/ as well as in other user-writable directories and I am puzzled about why the idea of /usr/src/linux* continues to exist.

ĸen

Signature · 2 lines

Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.

Michal Marek

2014-07-04 21:42 UTC #14 lore raw

Dne 19.6.2014 03:21, Ken Moffat napsal(a):

Quoted 6 lines · Michal Marek

Quoted 5 lines
The idea is that one should be able to compare as much as possible between the build of /usr/src/linux-<version_a> built in /usr/src/linux-<version_a>/build and /usr/src/linux-<version_b> built in /usr/src/linux-<version_b>/build.

Quoted 7 lines

[...]
Some of us (me included) often build things as root, but it has
many risks and people ought not to be led to believe it is necessarily the correct way to do things. Over the past 14 years I have built kernels in ~/ as well as in other user-writable directories and I am puzzled about why the idea of /usr/src/linux* continues to exist.

I just used /usr/src/linux as an example. If I wrote /dev/shm/linux-2.6/build, which is where I often builf kernels, then I'm sure somebody would complain that they tried it and ran out of memory :-).

Michal

Michal Marek

2014-06-18 14:26 UTC #15 lore raw

PATCH 1/1 kbuild: Fix tar-pkg with relative $(objtree)

In reply to J. Bruce Fields

Commit 7e1c0477 (kbuild: Use relative path for $(objtree)) assumes that the build process does not change its working directory. make tar-pkg was a couterexample, fix this by changing directory only for the tar command and not for the whole script, which at one point references the now relative $(objtree).

Reported-by "J. Bruce Fields" <[email protected]>

Signed-off-by Michal Marek <[email protected]>

---
 scripts/package/buildtar | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

scripts/package/buildtar +1 -2

index 995c1ea..e046bff 100644
@@ -125,12 +125,11 @@ esac
 # Create the tarball
 #
 (
-	cd "${tmpdir}"
 	opts=
 	if tar --owner=root --group=root --help >/dev/null 2>&1; then
 		opts="--owner=root --group=root"
 	fi
-	tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"
+	tar cf - -C "$tmpdir" boot/ lib/ $opts | ${compress} > "${tarball}${file_ext}"
 )
 
 echo "Tarball successfully created in ${tarball}${file_ext}"

Signature · 1 line

1.9.2

J. Bruce Fields

author

2014-06-18 15:29 UTC #16 lore raw

Re: [PATCH] kbuild: Fix tar-pkg with relative $(objtree)

Quoted 5 lines · Michal Marek

Commit 7e1c0477 (kbuild: Use relative path for $(objtree)) assumes that the build process does not change its working directory. make tar-pkg was a couterexample, fix this by changing directory only for the tar command and not for the whole script, which at one point references the now relative $(objtree).

Works for me, thanks.--b.

Quoted 28 lines

Reported-by "J. Bruce Fields" <[email protected]>

Signed-off-by Michal Marek <[email protected]>

---
 scripts/package/buildtar | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

scripts/package/buildtar +1 -2

index 995c1ea..e046bff 100644
@@ -125,12 +125,11 @@ esac
 # Create the tarball
 #
 (
-	cd "${tmpdir}"
 	opts=
 	if tar --owner=root --group=root --help >/dev/null 2>&1; then
 		opts="--owner=root --group=root"
 	fi
-	tar cf - boot/* lib/* $opts | ${compress} > "${tarball}${file_ext}"
+	tar cf - -C "$tmpdir" boot/ lib/ $opts | ${compress} > "${tarball}${file_ext}"
 )
 
 echo "Tarball successfully created in ${tarball}${file_ext}"

Signature · 1 line

1.9.2

Michal Marek

2014-06-18 15:34 UTC #17 lore raw

Re: [PATCH] kbuild: Fix tar-pkg with relative $(objtree)

Dne 18.6.2014 17:29, J. Bruce Fields napsal(a):

Quoted 8 lines · Michal Marek

Quoted 5 lines
Commit 7e1c0477 (kbuild: Use relative path for $(objtree)) assumes that the build process does not change its working directory. make tar-pkg was a couterexample, fix this by changing directory only for the tar command and not for the whole script, which at one point references the now relative $(objtree).
Works for me, thanks.--b.

Thanks for testing!

Michal