| Submitter | Koen Kooi |
|---|---|
| Date | May 15, 2012, 9:32 a.m. |
| Message ID | <1337074341-12708-1-git-send-email-koen@dominion.thruhere.net> |
| Download | mbox | patch |
| Permalink | /patch/27757/ |
| State | Accepted |
| Commit | 7163ebd92a799b8f000b2b6f303b20de468b5f90 |
| Headers | show |
Comments
On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported. > > This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92. while this is what I had initially it doesn't go well with kmod living in /sbin and accessing libraries from /usr due to our QA checks although I am all for simplifying it where we don't make this check at all.
On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote: > On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > > The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported. > > > > This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92. > > while this is what I had initially it doesn't go well with kmod living in > /sbin and accessing libraries from /usr due to our QA checks although > I am all for simplifying it where we don't make this check at all. I've had requests for it along with a commitment to fix it and patches. If we decide we don't want this, fine and that will be the case if patches are not forthcoming to fix the QA issues. I don't think we've reached that point at this with that yet. I've decided to accept this patch and "unbreak" meta-oe/udev at the expense of screwing up OE-Core. I am however still deeply unhappy people are trying to bypass OE-Core this way and then "blackmail" OE-Core using breaking meta-oe as a reason. The whole systemd thing has been badly handled and needs to get fixed properly. I am trying not to make a big thing about that although I do feel provoked on other issues and its hard to resist replying in kind. Cheers, Richard
Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven: > On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote: >> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: >>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported. >>> >>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92. >> >> while this is what I had initially it doesn't go well with kmod living in >> /sbin and accessing libraries from /usr due to our QA checks although >> I am all for simplifying it where we don't make this check at all. > > I've had requests for it along with a commitment to fix it and patches. > If we decide we don't want this, fine and that will be the case if > patches are not forthcoming to fix the QA issues. I don't think we've > reached that point at this with that yet. > > I've decided to accept this patch and "unbreak" meta-oe/udev at the > expense of screwing up OE-Core. I am however still deeply unhappy people > are trying to bypass OE-Core this way and then "blackmail" OE-Core using > breaking meta-oe as a reason. The whole systemd thing has been badly > handled and needs to get fixed properly. What does systemd have to do with this? This is about a broken commit breaking udev 182 for over a week. If you have issues with systemd, send patches to meta-oe to fix it. Or at least bug reports that are more than the insinuations above.
On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote: > Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven: > > > On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote: > >> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > >>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported. > >>> > >>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92. > >> > >> while this is what I had initially it doesn't go well with kmod living in > >> /sbin and accessing libraries from /usr due to our QA checks although > >> I am all for simplifying it where we don't make this check at all. > > > > I've had requests for it along with a commitment to fix it and patches. > > If we decide we don't want this, fine and that will be the case if > > patches are not forthcoming to fix the QA issues. I don't think we've > > reached that point at this with that yet. > > > > I've decided to accept this patch and "unbreak" meta-oe/udev at the > > expense of screwing up OE-Core. I am however still deeply unhappy people > > are trying to bypass OE-Core this way and then "blackmail" OE-Core using > > breaking meta-oe as a reason. The whole systemd thing has been badly > > handled and needs to get fixed properly. > > What does systemd have to do with this? Why does meta-oe has its own udev recipe? Is systemd related to that at all? > This is about a broken commit breaking udev 182 for over a week. OE-Core worked fine and the commit fixes QA warnings which are now back. > If you have issues with systemd, send patches to meta-oe to fix it. Or > at least bug reports that are more than the insinuations above. I looked in the README and followed that to other README files but couldn't find any indication about what to do with bugs other than write patches which I obviously don't have. When will you be sending the patch to fix the QA warning your revert has introduced? Yes this is a rhetorical question since I've seen your view on this problem previously. Cheers, Richard
On Thu, May 17, 2012 at 10:02:43PM +0100, Richard Purdie wrote: > On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote: > > Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven: > > > > > On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote: > > >> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > > >>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported. > > >>> > > >>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92. > > >> > > >> while this is what I had initially it doesn't go well with kmod living in > > >> /sbin and accessing libraries from /usr due to our QA checks although > > >> I am all for simplifying it where we don't make this check at all. > > > > > > I've had requests for it along with a commitment to fix it and patches. > > > If we decide we don't want this, fine and that will be the case if > > > patches are not forthcoming to fix the QA issues. I don't think we've > > > reached that point at this with that yet. > > > > > > I've decided to accept this patch and "unbreak" meta-oe/udev at the > > > expense of screwing up OE-Core. I am however still deeply unhappy people > > > are trying to bypass OE-Core this way and then "blackmail" OE-Core using > > > breaking meta-oe as a reason. The whole systemd thing has been badly > > > handled and needs to get fixed properly. > > > > What does systemd have to do with this? > > Why does meta-oe has its own udev recipe? Is systemd related to that at > all? I would imagine it's part of the tight coupling of parts here, yes. > > This is about a broken commit breaking udev 182 for over a week. > > OE-Core worked fine and the commit fixes QA warnings which are now back. Isn't the rule for QA errors supposed to be that you fix real problems and tell the automated checks "we know what we're doing, be quiet" ? All that's happened is that meta-oe has been working as intended and put in a newer version of a recipe, before oe-core can move to it, and found problems that need to be addressed.
On Thursday 17 May 2012 14:16:37 Tom Rini wrote: > All that's happened is that meta-oe has been working as intended and put > in a newer version of a recipe, before oe-core can move to it, and found > problems that need to be addressed. This is where I disagree - IMHO meta-oe should be split such that you can get the additional recipes in it without unexpected surprises like critical system components (like udev) being up-revved and then breakage resulting. There is some work needed to get to this point but we need to keep moving towards it I think. Cheers, Paul
On Thu, May 17, 2012 at 6:25 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote: > On Thursday 17 May 2012 14:16:37 Tom Rini wrote: >> All that's happened is that meta-oe has been working as intended and put >> in a newer version of a recipe, before oe-core can move to it, and found >> problems that need to be addressed. > > This is where I disagree - IMHO meta-oe should be split such that you can get > the additional recipes in it without unexpected surprises like critical system > components (like udev) being up-revved and then breakage resulting. There is > some work needed to get to this point but we need to keep moving towards it I > think. From time to time it is easier to avoid to work in OE-Core and work in meta-oe or another layer; udev is no different. It has been update in meta-oe long time ago and many people use and depends on it. It is important to state that if OE-Core breaks Meta-OE this is crticial. It is not Yocto that people use and many active contributors use Meta-OE so it is important and critical to that people. Seems more health to the project to give the deserved value to Meta-OE instead of badmouth it...
On Thursday 17 May 2012 18:51:05 Otavio Salvador wrote: > It is important to state that if OE-Core breaks Meta-OE this is > crticial. It is not Yocto that people use and many active contributors > use Meta-OE so it is important and critical to that people. Seems more > health to the project to give the deserved value to Meta-OE instead of > badmouth it... The sooner people can start using it without fear of it doing unexpected things, the sooner people will be able to have more confidence in it and stop making negative comments about it. As it stands the way a lot of people treat meta-oe is a source of recipes to be copied elsewhere because they feel they cannot use the layer as a whole. I think that's a big shame. Cheers, Paul
On Thu, May 17, 2012 at 7:01 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote: > On Thursday 17 May 2012 18:51:05 Otavio Salvador wrote: >> It is important to state that if OE-Core breaks Meta-OE this is >> crticial. It is not Yocto that people use and many active contributors >> use Meta-OE so it is important and critical to that people. Seems more >> health to the project to give the deserved value to Meta-OE instead of >> badmouth it... > > The sooner people can start using it without fear of it doing unexpected > things, the sooner people will be able to have more confidence in it and stop > making negative comments about it. As it stands the way a lot of people treat > meta-oe is a source of recipes to be copied elsewhere because they feel they > cannot use the layer as a whole. I think that's a big shame. Agreed; the nice thing about Free Software is that we can do something about it; do negative comments help nothing. Most people on Yocto do not contribute actively to Meta-OE. As example, you did 12 commits in total to it...
On Thursday 17 May 2012 19:11:20 Otavio Salvador wrote: > On Thu, May 17, 2012 at 7:01 PM, Paul Eggleton > <paul.eggleton@linux.intel.com> wrote: > > On Thursday 17 May 2012 18:51:05 Otavio Salvador wrote: > >> It is important to state that if OE-Core breaks Meta-OE this is > >> crticial. It is not Yocto that people use and many active contributors > >> use Meta-OE so it is important and critical to that people. Seems more > >> health to the project to give the deserved value to Meta-OE instead of > >> badmouth it... > > > > The sooner people can start using it without fear of it doing unexpected > > things, the sooner people will be able to have more confidence in it and > > stop making negative comments about it. As it stands the way a lot of > > people treat meta-oe is a source of recipes to be copied elsewhere > > because they feel they cannot use the layer as a whole. I think that's a > > big shame. > > Agreed; the nice thing about Free Software is that we can do something > about it; do negative comments help nothing. > > Most people on Yocto do not contribute actively to Meta-OE. As > example, you did 12 commits in total to it... No, we don't, but that's probably because we have our hands full maintaining BitBake and OE-Core (with the help of others in the community, of course). Not to mention that when we do enable it on top of OE-Core / Poky without wanting to use systemd, it makes a whole raft of changes that usually cause breakage of some kind because that configuration is rarely tested. This just makes using and contributing to meta-oe harder. We really do recognise that there has to be a source of recipes outside OE- Core, and meta-oe is the current place for a lot of those. However there is just so much work to be done on BitBake and OE-Core that venturing into meta- oe as well is something a lot of us don't have time for in our daily work, especially with its current state. I do use meta-oe when I'm building stuff at home but there I more or less have my hands full maintaining meta-handheld, meta-opie and a bunch of other things. I hope during the current development cycle that I will have time to contribute to meta-oe further. I can't make any promises though. Cheers, Paul
On Thu, 2012-05-17 at 18:51 -0300, Otavio Salvador wrote: > It is important to state that if OE-Core breaks Meta-OE this is > crticial. It is not Yocto that people use and many active contributors > use Meta-OE so it is important and critical to that people. Seems more > health to the project to give the deserved value to Meta-OE instead of > badmouth it... No doubt meta-oe's welfare is indeed critical to those who use it, but there is a substantial population of oe-core users who don't. Without wishing to badmouth meta-oe too much, I do get the impression that its relationship with oe-core is based more on taking than on giving, and also that meta-oe seems a bit unclear about what exactly its own mission is. On the one hand it seems to try to be a sort of unofficial mod for oe-core which adds newer/older/different versions of some recipes and adjusts features in others. On the other hand it seems to be a repository for recipes which are of general interest but not quite "core" enough to be in oe-core. And on the third hand, there seems to be a view (as Tom alluded to in this thread) that meta-oe should serve as some sort of staging area for changes which are ultimately intended for oe-core but perhaps not quite stable enough yet. As Paul mentioned, the combination of these three things is somewhat toxic. Personally I would like to see the meta-oe folks make a bit more of an effort to contribute worthwhile improvements back to oe-core (and/or put them in other layers, as seems to be happening with the systemd bits) rather than just keeping them as part of the meta-oe monolith indefinitely. And, in parallel with that, I think it would make sense to split meta-oe into three or maybe more separate layers: one which is purely a collection of "extra" recipes, one which contains all the policy changes that meta-oe wishes to make compared to what's in oe-core, and one which is a sort of "oe-core-next", containing changes which are theoretically candidates for merging into oe-core but for whatever reason are not quite ready to submit. p.
On Thu, May 17, 2012 at 2:51 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > > From time to time it is easier to avoid to work in OE-Core and work in > meta-oe or another layer; udev is no different. It has been update in > meta-oe long time ago and many people use and depends on it. if udev has been in meta-oe for long enough and verdict is that its tested well enough now lets move it to OE-Core.
On Fri, May 18, 2012 at 12:50 AM, Khem Raj <raj.khem@gmail.com> wrote: > On Thu, May 17, 2012 at 2:51 PM, Otavio Salvador > <otavio@ossystems.com.br> wrote: >> >> From time to time it is easier to avoid to work in OE-Core and work in >> meta-oe or another layer; udev is no different. It has been update in >> meta-oe long time ago and many people use and depends on it. > > if udev has been in meta-oe for long enough and verdict is that its > tested well enough now lets move it to OE-Core. > To make meta-oe less 'frightening' - what are the culprits. Up to now we heard: * systemd: a layer was born and will be filled (at least by trolls :) * udev: suggestion above What else? Andreas
Op 17 mei 2012, om 23:02 heeft Richard Purdie het volgende geschreven: > On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote: >> Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven: >> >>> On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote: >>>> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: >>>>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported. >>>>> >>>>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92. >>>> >>>> while this is what I had initially it doesn't go well with kmod living in >>>> /sbin and accessing libraries from /usr due to our QA checks although >>>> I am all for simplifying it where we don't make this check at all. >>> >>> I've had requests for it along with a commitment to fix it and patches. >>> If we decide we don't want this, fine and that will be the case if >>> patches are not forthcoming to fix the QA issues. I don't think we've >>> reached that point at this with that yet. >>> >>> I've decided to accept this patch and "unbreak" meta-oe/udev at the >>> expense of screwing up OE-Core. I am however still deeply unhappy people >>> are trying to bypass OE-Core this way and then "blackmail" OE-Core using >>> breaking meta-oe as a reason. The whole systemd thing has been badly >>> handled and needs to get fixed properly. >> >> What does systemd have to do with this? > > Why does meta-oe has its own udev recipe? Because it's too much trouble to get the updated recipe into oe-core > Is systemd related to that at all? No >> This is about a broken commit breaking udev 182 for over a week. > > OE-Core worked fine So you say that moving the pkgconfig files from /usr/lib to /lib was fine. Good to know.
Op 17 mei 2012, om 23:02 heeft Richard Purdie het volgende geschreven: > On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote: >> Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven: >> >>> On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote: >>>> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: >>>>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported. >>>>> >>>>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92. >>>> >>>> while this is what I had initially it doesn't go well with kmod living in >>>> /sbin and accessing libraries from /usr due to our QA checks although >>>> I am all for simplifying it where we don't make this check at all. >>> >>> I've had requests for it along with a commitment to fix it and patches. >>> If we decide we don't want this, fine and that will be the case if >>> patches are not forthcoming to fix the QA issues. I don't think we've >>> reached that point at this with that yet. >>> >>> I've decided to accept this patch and "unbreak" meta-oe/udev at the >>> expense of screwing up OE-Core. I am however still deeply unhappy people >>> are trying to bypass OE-Core this way and then "blackmail" OE-Core using >>> breaking meta-oe as a reason. The whole systemd thing has been badly >>> handled and needs to get fixed properly. >> >> What does systemd have to do with this? > > Why does meta-oe has its own udev recipe? Is systemd related to that at > all? > >> This is about a broken commit breaking udev 182 for over a week. > > OE-Core worked fine and the commit fixes QA warnings which are now back. > >> If you have issues with systemd, send patches to meta-oe to fix it. Or >> at least bug reports that are more than the insinuations above. > > I looked in the README and followed that to other README files but > couldn't find any indication about what to do with bugs other than write > patches which I obviously don't have. > > When will you be sending the patch to fix the QA warning your revert has > introduced? Yes this is a rhetorical question since I've seen your view > on this problem previously. Those QA checks are a joke. I can fix the QA warnings by moving all kmod binaries to $bindir or $sbindir since binaries in /usr/bin and /usr/bin are exempt from the checks. That would break the split /usr case as well. These checks are global as well when they only should apply to recipes needed to get /usr mounted. That's why I consider the current checks misguided and harmfull. As seen from the breakage it allows people to break pkgconfig, which didn't get picked up by QA checks. And then it turns out that you an fix the QA warnings in such a way that it breaks the intent of the warnings. But this is all a false dillemma, you could have merged Otavio's patch (which I Ack'ed) which supports split /usr and puts the pkgconfig in the right place.
Op 18 mei 2012, om 08:19 heeft Koen Kooi het volgende geschreven: > > Op 17 mei 2012, om 23:02 heeft Richard Purdie het volgende geschreven: > >> On Thu, 2012-05-17 at 22:44 +0200, Koen Kooi wrote: >>> Op 17 mei 2012 om 22:29 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven: >>> >>>> On Tue, 2012-05-15 at 13:54 -0700, Khem Raj wrote: >>>>> On Tue, May 15, 2012 at 2:32 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: >>>>>> The commit breaks pkgconfig and after discussing it with the kmod and udev maintainers the conclusion was reached that putting the libraries in /lib instead of /usr/lib is not supported. >>>>>> >>>>>> This reverts commit 6b74f2461735272bd950a4f060dab6e778a36f92. >>>>> >>>>> while this is what I had initially it doesn't go well with kmod living in >>>>> /sbin and accessing libraries from /usr due to our QA checks although >>>>> I am all for simplifying it where we don't make this check at all. >>>> >>>> I've had requests for it along with a commitment to fix it and patches. >>>> If we decide we don't want this, fine and that will be the case if >>>> patches are not forthcoming to fix the QA issues. I don't think we've >>>> reached that point at this with that yet. >>>> >>>> I've decided to accept this patch and "unbreak" meta-oe/udev at the >>>> expense of screwing up OE-Core. I am however still deeply unhappy people >>>> are trying to bypass OE-Core this way and then "blackmail" OE-Core using >>>> breaking meta-oe as a reason. The whole systemd thing has been badly >>>> handled and needs to get fixed properly. >>> >>> What does systemd have to do with this? >> >> Why does meta-oe has its own udev recipe? > > Because it's too much trouble to get the updated recipe into oe-core And I admit that is not necessarily a bad thing. I would go as far as saying that for recipes like udev it's a good thing. OE-core has seen too many upgrades for the sake of upgrades that were only build tested.
On Fri, 2012-05-18 at 09:52 +0200, Koen Kooi wrote: > Op 17 mei 2012, om 23:02 heeft Richard Purdie het vo > Those QA checks are a joke. I can fix the QA warnings by moving all > kmod binaries to $bindir or $sbindir since binaries in /usr/bin > and /usr/bin are exempt from the checks. That would break the > split /usr case as well. These checks are global as well when they > only should apply to recipes needed to get /usr mounted. > > That's why I consider the current checks misguided and harmfull. As > seen from the breakage it allows people to break pkgconfig, which > didn't get picked up by QA checks. And then it turns out that you an > fix the QA warnings in such a way that it breaks the intent of the > warnings. So we need to improve the QA checks, no argument here. > But this is all a false dillemma, you could have merged Otavio's patch > (which I Ack'ed) which supports split /usr and puts the pkgconfig in > the right place. I likely still will but I was worried when he replied saying it still needed more testing. I took your reply to the consolidated pull request to refer to your patch. Cheers, Richard
Op 18 mei 2012, om 12:29 heeft Richard Purdie het volgende geschreven: > On Fri, 2012-05-18 at 09:52 +0200, Koen Kooi wrote: >> Op 17 mei 2012, om 23:02 heeft Richard Purdie het vo >> Those QA checks are a joke. I can fix the QA warnings by moving all >> kmod binaries to $bindir or $sbindir since binaries in /usr/bin >> and /usr/bin are exempt from the checks. That would break the >> split /usr case as well. These checks are global as well when they >> only should apply to recipes needed to get /usr mounted. >> >> That's why I consider the current checks misguided and harmfull. As >> seen from the breakage it allows people to break pkgconfig, which >> didn't get picked up by QA checks. And then it turns out that you an >> fix the QA warnings in such a way that it breaks the intent of the >> warnings. > > So we need to improve the QA checks, no argument here. Would a new, additional check for /lib/pkgconfig/*.pc make sense? > >> But this is all a false dillemma, you could have merged Otavio's patch >> (which I Ack'ed) which supports split /usr and puts the pkgconfig in >> the right place. > > I likely still will but I was worried when he replied saying it still needed more > testing. I took your reply to the consolidated pull request to refer to > your patch. I was indeed very unspecific there, my apologies. regards, Koen
Patch
diff --git a/meta/recipes-kernel/kmod/kmod_git.bb b/meta/recipes-kernel/kmod/kmod_git.bb index d9c4d8b..fd38d87 100644 --- a/meta/recipes-kernel/kmod/kmod_git.bb +++ b/meta/recipes-kernel/kmod/kmod_git.bb @@ -3,7 +3,7 @@ require kmod.inc -PR = "${INC_PR}.1" +PR = "${INC_PR}.2" PROVIDES += "module-init-tools-insmod-static module-init-tools-depmod module-init-tools" RPROVIDES_${PN} += "module-init-tools-insmod-static module-init-tools-depmod module-init-tools" @@ -16,7 +16,7 @@ RCONFLICTS_libkmod2 += "module-init-tools-insmod-static module-init-tools-depmod # autotools set prefix to /usr, however we want them in /bin and /sbin bindir = "${base_bindir}" sbindir = "${base_sbindir}" -libdir = "${base_libdir}" +# libdir = "${base_libdir}" do_install_append () { install -dm755 ${D}${base_bindir}