| Summary: | Make sure that copied linux and busybox defconfig are writable before modifying | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Danomi Mocelopolis <d_mo1234> |
| Component: | Other | Assignee: | Yann E. MORIN <yann.morin.1998> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | buildroot |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: |
patch file
patch file |
||
Is it required to also modify the group permission? I'd expect u+rw to be enough. Moreover, can we safely assume that the read permission is already set, so that u+w is the only thing that needs to happen? Thirdly, the same problem is probably present for many other locations, for example the uclibc config file, the default target skeleton (that you may want to modify from a post-build script) etc. To cater for your version control system (Clearcase?) all this should be fixed as well... (In reply to comment #1) > Is it required to also modify the group permission? I'd expect u+rw to be > enough. I'm okay with u+rw. > Moreover, can we safely assume that the read permission is already set, so that > u+w is the only thing that needs to happen? I suppose, but why not do u+rw anyway? I site the line that fixes permissions after uncompressing package archives in buildroot/package/Makefile.package.in: $(Q)chmod -R +rw $(@D) But for my purposes, getting the +w would be good enough, if you feel strongly about this. (BTW, not sure if "+rw" is better than "u+rw". I always specify the u or ug. The man for chmod leads me to believe that +rw might open up beyond u depending on the umask setting. Again, I'm not picky on this point.) > Thirdly, the same problem is probably present for many other locations, for > example the uclibc config file, the default target skeleton (that you may want > to modify from a post-build script) etc. > To cater for your version control system (Clearcase?) all this should be fixed > as well... Actually, we're using Perforce, but I don't think that this is catering to Perforce in particular. I think this would happen with any of the non-distributed version control systems (rcs, cvs, svn, ...). No? But I think you're right, that this probably effects any place that there is a copy from a non-derived file, or a copy from a file that wasn't untared by GENTARGETS, and a subsequent edit of that file is attempted. I just had to fix the ones that screwed my own projects, I didn't try to find other places. So, I have made another patch that includes the changes in the first patch, plus uclibc and target skeleton copies, plus any other untar opts that I could find. See what you think. Created attachment 3685 [details]
patch file
aforementioned patch
I really don't understand why this would be necessary. Could you detail what you mean by "If the custom defconfigs are not checked out, then they are read-only" ? (In reply to comment #4) > I really don't understand why this would be necessary. Could you detail what > you mean by "If the custom defconfigs are not checked out, then they are > read-only" ? For some version control systems, controlled files are read-only unless you actually check the file out for modification. Regardless, if the custom linux or busybox defconfig is read-only (for whatever reason), then the copied file (made by buildroot) will be read-only. When that's the case, "sed -i" fails. I.e., buildroot starts by copying the linux or busybox defconfig from where ever it was set up in menuconfig to output/build/*/.config, then uses sed to modify some of the selections according to other menuconfig settings. If the file comes out of the initial copy with read-only permissions, then the sed will fail, and make will error out. I would imagine that buildroot's Makefile.package.in does the "chmod -R +rw $(@D)" when unpacking archives (prior to patching) for similar reasons, no? Yann has started working on this. Fixed by Yann in git (984524fda1f8260e258421f6676d522591f025da and parents) |
Created attachment 3661 [details] patch file I use buildroot in a source controlled environment, with a custom target skeleton, custom linux defconfig, and custom busybox defconfig. If the custom defconfigs are not checked out, then they are read-only. So when linux.mk and busybox.mk copy their respective customized defconfig to output/build, they get copied as read-only. Then, buildroot tries to modify these files based on the .config settings, it fails. (You have to manually open permissions to get the mods operations to work, and move on.) This problem can be avoided by opening permissions after the copy. To this end, a patch file is attached.