| Message ID | 1425588249-20942-2-git-send-email-gustavo@zacarias.com.ar |
|---|---|
| State | Accepted |
| Headers | show |
Dear Gustavo Zacarias, On Thu, 5 Mar 2015 17:44:09 -0300, Gustavo Zacarias wrote: > Now with support for AD DC, ADS and clustering features. > All dropped patches are upstream. > > Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Ok, I'm going to be annoying on this one, but since this is something we generally ask all developers to do, I think we should ask you to do it too. > ifeq ($(BR2_PACKAGE_ACL),y) > - SAMBA4_CONF_OPTS += --with-acl-support > - SAMBA4_DEPENDENCIES += acl > +SAMBA4_CONF_OPTS += --with-acl-support > +SAMBA4_DEPENDENCIES += acl > else > - SAMBA4_CONF_OPTS += --without-acl-support > +SAMBA4_CONF_OPTS += --without-acl-support > endif > > ifeq ($(BR2_PACKAGE_CUPS),y) > - SAMBA4_CONF_ENV += CUPS_CONFIG="$(STAGING_DIR)/usr/bin/cups-config" > - SAMBA4_CONF_OPTS += --enable-cups > - SAMBA4_DEPENDENCIES += cups > +SAMBA4_CONF_ENV += CUPS_CONFIG="$(STAGING_DIR)/usr/bin/cups-config" > +SAMBA4_CONF_OPTS += --enable-cups > +SAMBA4_DEPENDENCIES += cups > else > - SAMBA4_CONF_OPTS += --disable-cups > +SAMBA4_CONF_OPTS += --disable-cups > endif > > ifeq ($(BR2_PACKAGE_LIBAIO),y) > - SAMBA4_CONF_OPTS += --with-aio-support > - SAMBA4_DEPENDENCIES += libaio > +SAMBA4_CONF_OPTS += --with-aio-support > +SAMBA4_DEPENDENCIES += libaio > else > - SAMBA4_CONF_OPTS += --without-aio-support > +SAMBA4_CONF_OPTS += --without-aio-support > endif > > ifeq ($(BR2_PACKAGE_DBUS)$(BR2_PACKAGE_AVAHI_DAEMON),yy) > - SAMBA4_CONF_OPTS += --enable-avahi > - SAMBA4_DEPENDENCIES += avahi > +SAMBA4_CONF_OPTS += --enable-avahi > +SAMBA4_DEPENDENCIES += avahi > else > - SAMBA4_CONF_OPTS += --disable-avahi > +SAMBA4_CONF_OPTS += --disable-avahi > endif > > ifeq ($(BR2_PACKAGE_GAMIN),y) > - SAMBA4_CONF_OPTS += --with-fam > - SAMBA4_DEPENDENCIES += gamin > +SAMBA4_CONF_OPTS += --with-fam > +SAMBA4_DEPENDENCIES += gamin > else > - SAMBA4_CONF_OPTS += --without-fam > +SAMBA4_CONF_OPTS += --without-fam > endif > > ifeq ($(BR2_PACKAGE_GETTEXT),y) > - SAMBA4_CONF_OPTS += --with-gettext=$(STAGING_DIR)/usr > - SAMBA4_DEPENDENCIES += gettext > +SAMBA4_CONF_OPTS += --with-gettext=$(STAGING_DIR)/usr > +SAMBA4_DEPENDENCIES += gettext > else > - SAMBA4_CONF_OPTS += --without-gettext > -endif > - > -ifeq ($(BR2_PACKAGE_GNUTLS),y) > - SAMBA4_CONF_OPTS += --enable-gnutls > - SAMBA4_DEPENDENCIES += gnutls > -else > - SAMBA4_CONF_OPTS += --disable-gnutls > +SAMBA4_CONF_OPTS += --without-gettext > endif > > ifeq ($(BR2_PACKAGE_NCURSES_TARGET_FORM)$(BR2_PACKAGE_NCURSES_TARGET_MENU)$(BR2_PACKAGE_NCURSES_TARGET_PANEL),yyy) > - SAMBA4_DEPENDENCIES += ncurses > +SAMBA4_DEPENDENCIES += ncurses > else > - SAMBA4_CONF_OPTS += --without-regedit > +SAMBA4_CONF_OPTS += --without-regedit > endif This cleanup of the indentation is definitely good, but has nothing to do with the bump to 4.2.0. It should be part of a separate patch. Thanks! Thomas
On 03/05/2015 07:29 PM, Thomas Petazzoni wrote: > Dear Gustavo Zacarias, > > On Thu, 5 Mar 2015 17:44:09 -0300, Gustavo Zacarias wrote: >> Now with support for AD DC, ADS and clustering features. >> All dropped patches are upstream. >> >> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> > > Ok, I'm going to be annoying on this one, but since this is something > we generally ask all developers to do, I think we should ask you to do > it too. > > This cleanup of the indentation is definitely good, but has nothing to > do with the bump to 4.2.0. It should be part of a separate patch. Well, it's pointless IMHO to split it, since some options changed and it's a major bump, does it really make sense? I won't make a badly-indented 4.2.x package file to fix it later, it would be pointless. It'll give me one more commit that doesn't do anything useful. And "fixing" 4.1.x just to just stomp on it later with the bump would make no sense either, same case, many changes. Regards.
Dear Gustavo Zacarias, On Thu, 05 Mar 2015 21:11:24 -0300, Gustavo Zacarias wrote: > > This cleanup of the indentation is definitely good, but has nothing to > > do with the bump to 4.2.0. It should be part of a separate patch. > > Well, it's pointless IMHO to split it, since some options changed and > it's a major bump, does it really make sense? > I won't make a badly-indented 4.2.x package file to fix it later, it > would be pointless. It'll give me one more commit that doesn't do > anything useful. > And "fixing" 4.1.x just to just stomp on it later with the bump would > make no sense either, same case, many changes. I'm sorry, but I don't buy this. Separating logical changes is something we ask to all contributors. And the specific chunk I pointed at does not change at *all* when doing the 4.1 -> 4.2 bump. And even if some parts of it are changed by the 4.1 -> 4.2 bump, that's OK. Best regards, Thomas
On 03/06/2015 05:40 AM, Thomas Petazzoni wrote: > I'm sorry, but I don't buy this. Separating logical changes is > something we ask to all contributors. And the specific chunk I pointed > at does not change at *all* when doing the 4.1 -> 4.2 bump. And even if > some parts of it are changed by the 4.1 -> 4.2 bump, that's OK. Well, i've done it several times in the past, just search for "While at it" and "Also" in the commit logs - in fact it was you who committed them in many cases (and not only mine). Does this mean that i should separate bumps from adding hash files and/or renaming patches? Because the workload and noise committing will go up higher if that's the choice. And how does a package style fix differ from renaming patches that's another style fix? Regards.
Dear Gustavo Zacarias, On Fri, 06 Mar 2015 06:04:03 -0300, Gustavo Zacarias wrote: > Well, i've done it several times in the past, just search for "While at > it" and "Also" in the commit logs - in fact it was you who committed > them in many cases (and not only mine). > Does this mean that i should separate bumps from adding hash files > and/or renaming patches? There is obviously a line to draw between things that we can do in the same commit, and things that we should not. I believe adding a hash file together with a bump is OK since anyway doing the bump would change the hash file. > Because the workload and noise committing will go up higher if that's > the choice. > And how does a package style fix differ from renaming patches that's > another style fix? I'd say readability. Renaming patches is clearly separated from .mk changes. In the case of your Samba 4.2 bump, the changes within the .mk file are mixed between bump-related changes, and indentation-related changes, and this is what bothers me. Best regards, Thomas
On 03/06/2015 06:26 AM, Thomas Petazzoni wrote: >> Because the workload and noise committing will go up higher if that's >> the choice. >> And how does a package style fix differ from renaming patches that's >> another style fix? > > I'd say readability. Renaming patches is clearly separated from .mk > changes. In the case of your Samba 4.2 bump, the changes within the .mk > file are mixed between bump-related changes, and indentation-related > changes, and this is what bothers me. It doesn't break any bisectability so what's the problem, you don't like a patch that changes too many things at once? Sorry to rehash an old thread but this kind of things don't motivate me at all. One thing is when you say "typo" which well, yes, it's a typo and it's fine to correct it. But this is just personal preference. Regards.
Dear Gustavo Zacarias, On Fri, 06 Mar 2015 06:34:59 -0300, Gustavo Zacarias wrote: > > I'd say readability. Renaming patches is clearly separated from .mk > > changes. In the case of your Samba 4.2 bump, the changes within the .mk > > file are mixed between bump-related changes, and indentation-related > > changes, and this is what bothers me. > > It doesn't break any bisectability so what's the problem, you don't like > a patch that changes too many things at once? Exactly. I'm surprised you even ask, separate logical changes is just the 101 of open-source contribution in many projects. See http://lxr.free-electrons.com/source/Documentation/SubmittingPatches#L74 for example. > Sorry to rehash an old thread but this kind of things don't motivate me > at all. I don't quite understand your feeling here. What I'm asking you to do is something we ask to *all* contributors, including newcomers who have never contributed a single patch to Buildroot. Why would we have more relaxed/special rules for long-term contributors like you ? If I was annoying you with something unusual, which I never bother other people with, I would understand. But here I'm just asking a very basic thing, which I also ask to every other contributor. > One thing is when you say "typo" which well, yes, it's a typo and it's > fine to correct it. Sorry I did not understand this part. Anyway, I'll take care of doing the split of the Samba 4.2 patch and I'll apply. I would have expected a bit more help and understanding from a long term contributor such as you. Thanks, Thomas
Dear Gustavo Zacarias, On Thu, 5 Mar 2015 17:44:09 -0300, Gustavo Zacarias wrote: > Now with support for AD DC, ADS and clustering features. > All dropped patches are upstream. > > Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Applied, after splitting into a separate patch the indentation fixes of samba4.mk. Thanks, Thomas
On 03/06/2015 06:40 AM, Thomas Petazzoni wrote: > Dear Gustavo Zacarias, > > On Fri, 06 Mar 2015 06:34:59 -0300, Gustavo Zacarias wrote: > >>> I'd say readability. Renaming patches is clearly separated from .mk >>> changes. In the case of your Samba 4.2 bump, the changes within the .mk >>> file are mixed between bump-related changes, and indentation-related >>> changes, and this is what bothers me. >> >> It doesn't break any bisectability so what's the problem, you don't like >> a patch that changes too many things at once? > > Exactly. I'm surprised you even ask, separate logical changes is just > the 101 of open-source contribution in many projects. See > http://lxr.free-electrons.com/source/Documentation/SubmittingPatches#L74 > for example. Well i'd say the same applies to trivial/redundant stuff, like "hey bump" + "hey hash" and you never complain with that aspect. Style changes aren't usually very readable in diff format, so why not make it part of a major bump? You'll have to re-read the full package anyway for any QA you do. > I don't quite understand your feeling here. What I'm asking you to do > is something we ask to *all* contributors, including newcomers who have > never contributed a single patch to Buildroot. Why would we have more > relaxed/special rules for long-term contributors like you ? FYI that's a linux kernel rule, it's not how every project out there works. Life isn't just the linux kernel. > If I was annoying you with something unusual, which I never bother > other people with, I would understand. But here I'm just asking a very > basic thing, which I also ask to every other contributor. Sorry to nitpick here, but if we weren't changing little bits of style all the time then we'd have more time for really cool stuff, and that bothers me. My feeling is that lately the patchflow is getting slower, and i'm not talking about my patches, those usually get applied quickly because they're, bluntly speaking, stupid patches. And they're stupid because i don't feel any support/interest/whatever in putting any serious effort in doing anything cool, because i feel intertia in getting real advancement in some areas. When you ask "why would we have more relaxed/special rules for long-term contributors like you?" it sounds very detached to me - kind of saying contributors don't matter. It doesn't mean you should have special rules, but bringing it up that way isn't nice IMO. And, for me personally, it just makes me So, one time offer with no strings attached: if you don't want me around just tell me, i think we are all adults and i'll just move to doing something elsewhere with my free time where i feel more welcome/appreciated. >> One thing is when you say "typo" which well, yes, it's a typo and it's >> fine to correct it. > > Sorry I did not understand this part. It means that i'm not angry/mad at every comment you make in case you got that impression. > Anyway, I'll take care of doing the split of the Samba 4.2 patch and > I'll apply. I would have expected a bit more help and understanding from > a long term contributor such as you. Same goes both ways FYI (understanding). I was going to say i'll do it myself because of a borderline failure that needs fixing that my autobuilder caught, but you already did it so i'll send a followup patch to fix that. Regards.
Dear Gustavo Zacarias, On Fri, 06 Mar 2015 07:32:21 -0300, Gustavo Zacarias wrote: > Well i'd say the same applies to trivial/redundant stuff, like "hey > bump" + "hey hash" and you never complain with that aspect. Yes, because as I said in my earlier e-mail, the "hey bump" and "hey hash" parts are clearly separated in the patch, so having them mixed in the same patch doesn't cause any readability issue. > Style changes aren't usually very readable in diff format, so why not > make it part of a major bump? You'll have to re-read the full package > anyway for any QA you do. Whether style changes are or are not very readable in diff format is your vision, not mine. I do review style changes in diff format, specifically because it allows me to visually check that only style changes are made, and no functional changes are made. So clearly, I want style changes separated from functional changes. > > I don't quite understand your feeling here. What I'm asking you to do > > is something we ask to *all* contributors, including newcomers who have > > never contributed a single patch to Buildroot. Why would we have more > > relaxed/special rules for long-term contributors like you ? > > FYI that's a linux kernel rule, it's not how every project out there > works. Life isn't just the linux kernel. Absolutely. But it happens that we follow quite a few of the rules of the Linux kernel: Signed-off-by, how patch series revisions are handled, how the review process takes place, etc. And the "split patches by logical changes" is not only a kernel rule, a lot of projects want this as well. > > If I was annoying you with something unusual, which I never bother > > other people with, I would understand. But here I'm just asking a very > > basic thing, which I also ask to every other contributor. > > Sorry to nitpick here, but if we weren't changing little bits of style > all the time then we'd have more time for really cool stuff, and that > bothers me. I agree that quite a number of changes are style changes. However, my feeling is that such changes are 1/ trivial to review and apply when cleanly separated from functional changes, and therefore don't consume much time, and 2/ make the code base more homogeneous which is nice for new comers. > My feeling is that lately the patchflow is getting slower, and i'm not > talking about my patches, those usually get applied quickly because > they're, bluntly speaking, stupid patches. > And they're stupid because i don't feel any support/interest/whatever in > putting any serious effort in doing anything cool, because i feel > intertia in getting real advancement in some areas. There is some inertia, but this inertia is mainly due to the lack of review and testing of the patches from other core developers. Yann is doing a lot of this, Vicente is also doing some work in this area, Romain has recently joined. But for example, you almost never ever give a Reviewed-by or a Tested-by tag on a patch submitted by another developer. Whenever there is a patch touching a package you typically take care of (Samba, Squid, etc.) submitted by another developer, I have to ping you to get your feedback/input on the patch. So if you feel there is inertia on a given topic, just help the topic make progress by reviewing the patches, saying you tested the series, etc. When a core developer like you gives his positive feedback on a given patch, for me (and I believe for Peter as well) it's a very strong sign that the patch is good to apply. I never build test your patches because I fully trust you. You can use this trust to help other patches go in. > When you ask "why would we have more relaxed/special rules for long-term > contributors like you?" it sounds very detached to me - kind of saying > contributors don't matter. Contributors don't matter? Do you realize that since a few months, I've basically stopped doing any development of Buildroot on the topics I'm interested in, and switched to spending all my available time to review, test and merge the patches submitted by all the contributors? I'm spending all my evenings and week-ends shrinking the patchwork backlog so that patches sent by contributors get merged at some point. All what I was saying is that I ask new comers to split their patches in logical changes, as a quality rule like we have many others. And I don't see why this quality rule wouldn't apply to a long-term trusted core developer such as you. > It doesn't mean you should have special rules, but bringing it up that > way isn't nice IMO. I'm sorry if you felt it wasn't nice, it really wasn't the intention. > And, for me personally, it just makes me Seems like there's a missing part here :-) > So, one time offer with no strings attached: if you don't want me around > just tell me, i think we are all adults and i'll just move to doing > something elsewhere with my free time where i feel more welcome/appreciated. One time offer rejected. I definitely want you part of the Buildroot core developers. You're doing an invaluable work taking care of many complex packages, doing a lot of very useful work looking at security issues and making the corresponding package updates. I think we should really meet once in person one day so you can feel how much I value the contributions done by all developers, and especially yours. Back on the Samba 4.2, my point is really only: "hey this patch is OK, I would just like it to be split a bit differently". I don't really understand why such a stupid/silly request generates such a huge amount of discussion. > It means that i'm not angry/mad at every comment you make in case you > got that impression. Ok. Glad to hear that :-) > > Anyway, I'll take care of doing the split of the Samba 4.2 patch and > > I'll apply. I would have expected a bit more help and understanding from > > a long term contributor such as you. > > Same goes both ways FYI (understanding). I'm not sure what I should understand? That because you are a long-term contributor, you have the right to do patches that don't comply with the quality rules we request all other contributors to comply with? Sorry, but that doesn't work for me. Do you remember that I already yelled at Peter because he wasn't posting to the list his patches before committing them ? So clearly, this is nothing personal with you, you see ? > I was going to say i'll do it myself because of a borderline failure > that needs fixing that my autobuilder caught, but you already did it so > i'll send a followup patch to fix that. Sure, seen the ncurses fix. I'll apply. Thanks! Thomas
On 03/06/2015 08:35 AM, Thomas Petazzoni wrote: >> Sorry to nitpick here, but if we weren't changing little bits of style >> all the time then we'd have more time for really cool stuff, and that >> bothers me. > > I agree that quite a number of changes are style changes. However, my > feeling is that such changes are 1/ trivial to review and apply when > cleanly separated from functional changes, and therefore don't consume > much time, and 2/ make the code base more homogeneous which is nice for > new comers. Style changes should ideally be done all at once, once said change is documented or agreed upon. It shouldn't be considered any different than the *_CONF_OPT -> *_CONF_OPTS rename. If we just wait for a waterfall effect in updating packages you'll just have mixed styles around the tree which will just confuse users and waste peoples time in mails and respins. > There is some inertia, but this inertia is mainly due to the lack of > review and testing of the patches from other core developers. Yann is > doing a lot of this, Vicente is also doing some work in this area, > Romain has recently joined. > > But for example, you almost never ever give a Reviewed-by or a > Tested-by tag on a patch submitted by another developer. Whenever there > is a patch touching a package you typically take care of (Samba, Squid, > etc.) submitted by another developer, I have to ping you to get your > feedback/input on the patch. This shouldn't be of any surprise, i'm just (not) doing what i said i wouldn't back at the end of the qemu-system thread. Also i'm not territorial, sometimes people add up features to packages that i usually maintain and evidently they're features i normally don't care/use about otherwise i would have done so myself, so i don't have any strong opinion or interest on them. Example: squidguard, i already have a package from a long time ago, but i never submitted it since it's quality is dubious, let alone a release hasn't been forthcoming for years (you gotta use the latest with several security patches or some beta). > So if you feel there is inertia on a given topic, just help the topic > make progress by reviewing the patches, saying you tested the series, > etc. When a core developer like you gives his positive feedback on a > given patch, for me (and I believe for Peter as well) it's a very > strong sign that the patch is good to apply. I never build test your > patches because I fully trust you. You can use this trust to help other > patches go in. ... > Contributors don't matter? > > Do you realize that since a few months, I've basically stopped doing > any development of Buildroot on the topics I'm interested in, and > switched to spending all my available time to review, test and merge > the patches submitted by all the contributors? I'm spending all my > evenings and week-ends shrinking the patchwork backlog so that > patches sent by contributors get merged at some point. This is the kind of inertia i'm refering to. Something needs to change or eventually you'll wear out/wane out of interest. Without wanting to "rub it" and being pretty one-sided the qemu-system package/idea went nowhere, a lot of time passed. I still stand on my original argument for it being split. I don't care what does or doesn't happen with that any more, i'm bringing it up as an example of my lack of interest of doing anything big regarding out-of-the-box experience. Post build scripts are all great, but some things should really be easier for the users. Making the initscripts configurable for example is one of them, but every time i want to start writing the proposal and samples i feel "Bleh, Peter or Thomas won't take it" and just leave it be. And it _really_ needs to happen, right now samba4 AD DC support isn't complete since the initscript isn't adequate for that. You've got scenarios where you start smbd, nmbd and winbindd, more usual without winbindd, but for AD-DC you need to start samba, and it's hard to predict based on smb.conf with dubious grepping. It's also not very feasible to "try" both approaches since some delays must be thrown in for the samba master process to really kick in before checking things are running. >> And, for me personally, it just makes me > > Seems like there's a missing part here :-) Morning rush. It just makes me question if i should continue working with BR. > I definitely want you part of the Buildroot core developers. You're > doing an invaluable work taking care of many complex packages, doing a > lot of very useful work looking at security issues and making the > corresponding package updates. We'll see how much people like my security "updates" once i send the cups deprecation series - it really needs to happen, nobody stepped up and it's pretty bad. I don't have an exact count of how many remotely-exploitable CVEs affect it, but it's probably safe to say a dozen. Maybe it'll entice someone to step up, but it really can't go on like this. Even though we don't guarantee that packages are free of bugs/security holes in them when we do know we should get something done about them, either fix them or kill them. > I think we should really meet once in person one day so you can feel how > much I value the contributions done by all developers, and especially > yours. That'd be hard to achieve i'm afraid, we've got a phrase here which literally translates to "we're in the ass of the world". All of the relevant places (OSS/technology-wise) are no less than a 10 hour flight from here. It's just the way it is. > Back on the Samba 4.2, my point is really only: "hey this patch is OK, > I would just like it to be split a bit differently". I don't really > understand why such a stupid/silly request generates such a huge amount > of discussion. Well, it shouldn't have, i didn't think you'd go all "by the book" on that silly detail and it caught me by surprise. > I'm not sure what I should understand? That because you are a long-term > contributor, you have the right to do patches that don't comply with > the quality rules we request all other contributors to comply with? > > Sorry, but that doesn't work for me. > > Do you remember that I already yelled at Peter because he wasn't > posting to the list his patches before committing them ? So clearly, > this is nothing personal with you, you see ? For me core developer = Peter and you since you're the ones with commit access to the tree, the rest are varying degrees of contributors. And you mixed and matched contributor with core developer here and above where it suited you best, don't be nasty ;) I know it's probably not personal, but writing frankly, we're both wasting time on a technicality that changes nothing, is it worth the (virtual) saliva? Regards.
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Dear Gustavo Zacarias, > On Fri, 06 Mar 2015 06:04:03 -0300, Gustavo Zacarias wrote: >> Well, i've done it several times in the past, just search for "While at >> it" and "Also" in the commit logs - in fact it was you who committed >> them in many cases (and not only mine). >> Does this mean that i should separate bumps from adding hash files >> and/or renaming patches? > There is obviously a line to draw between things that we can do in the > same commit, and things that we should not. I believe adding a hash > file together with a bump is OK since anyway doing the bump would > change the hash file. Exactly, the changes logically belong together and are easy/fast to review. A version bump + whitespace changes leading to a diffstat like this: package/samba4/samba4.mk | 100 +++++++------ Is certainly less so. If it was purely a white space change it would be trivial to verify with git diff -w, E.G.: git show -w 7152a50588 >> Because the workload and noise committing will go up higher if that's >> the choice. We already have 400+ commits/month, so 1 extra commit imho doesn't hurt. It is true that it involves a bit more time on the contributor, but is saves time for the maintainer (E.G. the version bumps, especially yours are normally nobrainers to apply), and the limiting factor these days seems to be maintainer/review cycles.
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: Hi, >> Exactly. I'm surprised you even ask, separate logical changes is just >> the 101 of open-source contribution in many projects. See >> http://lxr.free-electrons.com/source/Documentation/SubmittingPatches#L74 >> for example. > Well i'd say the same applies to trivial/redundant stuff, like "hey > bump" + "hey hash" and you never complain with that aspect. > Style changes aren't usually very readable in diff format, so why not > make it part of a major bump? You'll have to re-read the full package > anyway for any QA you do. Not if it is a pure style change as you can check with 'git diff -w'. >> I don't quite understand your feeling here. What I'm asking you to do >> is something we ask to *all* contributors, including newcomers who have >> never contributed a single patch to Buildroot. Why would we have more >> relaxed/special rules for long-term contributors like you ? > FYI that's a linux kernel rule, it's not how every project out there > works. Life isn't just the linux kernel. Agreed, but we have adapted quite a bit of the same rules as the Linux kernel (git, signed-off-by, review on mailing list, patchwork, single maintainer, ..). >> If I was annoying you with something unusual, which I never bother >> other people with, I would understand. But here I'm just asking a very >> basic thing, which I also ask to every other contributor. > Sorry to nitpick here, but if we weren't changing little bits of style > all the time then we'd have more time for really cool stuff, and that > bothers me. > My feeling is that lately the patchflow is getting slower, and i'm not > talking about my patches, those usually get applied quickly because > they're, bluntly speaking, stupid patches. > And they're stupid because i don't feel any support/interest/whatever in > putting any serious effort in doing anything cool, because i feel > intertia in getting real advancement in some areas. This is not true in absolute numbers (E.G. we keep on increasing the number of changes in each release), but it may be true that Buildroot is getting more mature / stable (and therefore in a sense boring). I don't think it is really a problem if complicated / controversial patches takes longer to get applied than simple version bumps, but if they never get applied or atleast responded to then that is certainly a problem. As a maintainer it isn't always easy to make progress on that kind of patches when: - There's plenty of other patches waiting in patchwork - Patches risk breaking stuff / cause maintenance issues down the road - Nobody else have reviewed / acked those patches. If I look in patchwork, I see very few patches having anything else than 0/0/0 in the acked-by/review-by/tested-by columns. This is one of the reasons why we are doing the dev days, as we then discuss some of these patch series. > So, one time offer with no strings attached: if you don't want me around > just tell me, i think we are all adults and i'll just move to doing > something elsewhere with my free time where i feel more welcome/appreciated. I must say that I'm surprised by this statement and I wonder how come you think Thomas or anybody else feels like that? I very much appreciate your Buildroot contributions, and I'm sure everyone else does as well!
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, > But for example, you almost never ever give a Reviewed-by or a > Tested-by tag on a patch submitted by another developer. Whenever there > is a patch touching a package you typically take care of (Samba, Squid, > etc.) submitted by another developer, I have to ping you to get your > feedback/input on the patch. > So if you feel there is inertia on a given topic, just help the topic > make progress by reviewing the patches, saying you tested the series, > etc. When a core developer like you gives his positive feedback on a > given patch, for me (and I believe for Peter as well) it's a very > strong sign that the patch is good to apply. I never build test your > patches because I fully trust you. You can use this trust to help other > patches go in. Yes, exactly! > I think we should really meet once in person one day so you can feel how > much I value the contributions done by all developers, and especially > yours. Buildroot dev days in Argentina? I'm up for it if we can find a sponsor ;) > Do you remember that I already yelled at Peter because he wasn't > posting to the list his patches before committing them ? So clearly, > this is nothing personal with you, you see ? And that is good, thanks. Open source (to me atleast) is very much about everyone playing according to the same rules.
Dear Peter Korsgaard, On Tue, 10 Mar 2015 22:53:53 +0100, Peter Korsgaard wrote: > > I think we should really meet once in person one day so you can feel how > > much I value the contributions done by all developers, and especially > > yours. > > Buildroot dev days in Argentina? I'm up for it if we can find a sponsor > ;) Me too! But I guess I'll try to avoid flying helicopters. Thomas
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: Hi, >> Do you realize that since a few months, I've basically stopped doing >> any development of Buildroot on the topics I'm interested in, and >> switched to spending all my available time to review, test and merge >> the patches submitted by all the contributors? I'm spending all my >> evenings and week-ends shrinking the patchwork backlog so that >> patches sent by contributors get merged at some point. > This is the kind of inertia i'm refering to. > Something needs to change or eventually you'll wear out/wane out of > interest. > Without wanting to "rub it" and being pretty one-sided the qemu-system > package/idea went nowhere, a lot of time passed. > I still stand on my original argument for it being split. > I don't care what does or doesn't happen with that any more, i'm > bringing it up as an example of my lack of interest of doing anything > big regarding out-of-the-box experience. > Post build scripts are all great, but some things should really be > easier for the users. > Making the initscripts configurable for example is one of them, but > every time i want to start writing the proposal and samples i feel > "Bleh, Peter or Thomas won't take it" and just leave it be. > And it _really_ needs to happen, right now samba4 AD DC support isn't > complete since the initscript isn't adequate for that. > You've got scenarios where you start smbd, nmbd and winbindd, more usual > without winbindd, but for AD-DC you need to start samba, and it's hard > to predict based on smb.conf with dubious grepping. > It's also not very feasible to "try" both approaches since some delays > must be thrown in for the samba master process to really kick in before > checking things are running. I understand. Working on new features are nice (and yes, reviewing other peoples patches all day does get boring after some time), but we also need to keep in mind that Buildroot should stay a simple system (otherwise you might as well use one of the other bigger systems) and we should try to keep it stable. We simply cannot cater to everyones needs. With that said, we have merged a number of new features over the years to automate some of these things (rootfs overlays, getty settings, root password, users, init systems, /bin/sh handling, timezones, network config, ..), and I'm sure we will merge even more in the future. > remotely-exploitable CVEs affect it, but it's probably safe to say a dozen. > Maybe it'll entice someone to step up, but it really can't go on like this. > Even though we don't guarantee that packages are free of bugs/security > holes in them when we do know we should get something done about them, > either fix them or kill them. Agreed (and not only about security issues). If a package has serious issues and nobody cares enough to fix it then we need to deprecate and remove the package. We keep on adding new packages every single release, so we also need to cleanup unloved ones. >> I think we should really meet once in person one day so you can feel how >> much I value the contributions done by all developers, and especially >> yours. > That'd be hard to achieve i'm afraid, we've got a phrase here which > literally translates to "we're in the ass of the world". Heh ;)
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: >> Buildroot dev days in Argentina? I'm up for it if we can find a sponsor >> ;) > Me too! But I guess I'll try to avoid flying helicopters. Yeah :/
Gustavo Zacarias <gustavo@zacarias.com.ar> wrote in
news:1425588249-20942-2-git-send-email-gustavo@zacarias.com.ar:
> + depends on BR2_TOOLCHAIN_USES_GLIBC # needs nss.h, $ORIGIN support
Hi,
is this really necessary? Building samba4 with uclibc worked here and I guess
the problem you saw with nss.h was fixed in 4.2.0rc3:
https://bugzilla.samba.org/show_bug.cgi?id=11026
Please note that I tested compilation only, for a runtime test I need more
time.
Regards, Bernd
On 04/09/2015 07:33 AM, Bernd Kuhls wrote: > Hi, > > is this really necessary? Building samba4 with uclibc worked here and I guess > the problem you saw with nss.h was fixed in 4.2.0rc3: > https://bugzilla.samba.org/show_bug.cgi?id=11026 > > Please note that I tested compilation only, for a runtime test I need more > time. Even if building with nss.h is fixed you still need $ORIGIN support which uClibc lacks in the current releases. So you'll have runtime issues. In the past (samba 4.1.x) i moved libraries to /usr/lib as a workaround, but for 4.2.x this didn't seem enough/there's a lot of new libraries to move. Regards. PD: next time CC me otherwise you leave my answer to the chance i don't miss the mail on the list.
Hi, Gustavo Zacarias wrote, > On 04/09/2015 07:33 AM, Bernd Kuhls wrote: > > > Hi, > > > > is this really necessary? Building samba4 with uclibc worked here and I guess > > the problem you saw with nss.h was fixed in 4.2.0rc3: > > https://bugzilla.samba.org/show_bug.cgi?id=11026 > > > > Please note that I tested compilation only, for a runtime test I need more > > time. > > Even if building with nss.h is fixed you still need $ORIGIN support > which uClibc lacks in the current releases. > So you'll have runtime issues. > In the past (samba 4.1.x) i moved libraries to /usr/lib as a workaround, > but for 4.2.x this didn't seem enough/there's a lot of new libraries to > move. uClibc-ng has $ORIGIN support. Can you test it with samba4? best regards Waldemar
On 04/09/2015 05:20 PM, Waldemar Brodkorb wrote:
> uClibc-ng has $ORIGIN support. Can you test it with samba4?
Yes, and it fails to work, snip:
-----
# /etc/init.d/S91smb start
Starting SMB services: /usr/sbin/smbd: can't load library 'libtalloc.so.2'
FAIL
Starting NMB services: /usr/sbin/nmbd: can't load library 'libtalloc.so.2'
FAIL
# ls -l /lib/*uClibc*
-rwxr-xr-x 1 root root 25304 Apr 9 2015
/lib/ld-uClibc-1.0.1.so
lrwxrwxrwx 1 root root 14 Apr 9 2015
/lib/ld-uClibc.so.0 -> ld-uClibc.so.1
lrwxrwxrwx 1 root root 18 Apr 9 2015
/lib/ld-uClibc.so.1 -> ld-uClibc-1.0.1.so
-rwxr-xr-x 1 root root 367544 Apr 9 2015
/lib/libuClibc-1.0.1.so
# ls -l /usr/lib/samba/libtalloc*
lrwxrwxrwx 1 root root 18 Apr 9 2015
/usr/lib/samba/libtalloc.so.2 -> libtalloc.so.2.1.1
-rwxr-xr-x 1 root root 19396 Apr 9 2015
/usr/lib/samba/libtalloc.so.2.1.1
-----
On the build machine:
$ readelf -d ?mbd|grep RPATH
0x0000000f (RPATH) Library rpath: [/usr/lib/samba]
0x0000000f (RPATH) Library rpath: [/usr/lib/samba]
So, it's not up to it yet.
Regards.
Hi, Gustavo Zacarias wrote, > On 04/09/2015 05:20 PM, Waldemar Brodkorb wrote: > > > uClibc-ng has $ORIGIN support. Can you test it with samba4? > > Yes, and it fails to work, snip: > > ----- > # /etc/init.d/S91smb start > Starting SMB services: /usr/sbin/smbd: can't load library 'libtalloc.so.2' > FAIL > Starting NMB services: /usr/sbin/nmbd: can't load library 'libtalloc.so.2' > FAIL > # ls -l /lib/*uClibc* > -rwxr-xr-x 1 root root 25304 Apr 9 2015 > /lib/ld-uClibc-1.0.1.so > lrwxrwxrwx 1 root root 14 Apr 9 2015 > /lib/ld-uClibc.so.0 -> ld-uClibc.so.1 > lrwxrwxrwx 1 root root 18 Apr 9 2015 > /lib/ld-uClibc.so.1 -> ld-uClibc-1.0.1.so > -rwxr-xr-x 1 root root 367544 Apr 9 2015 > /lib/libuClibc-1.0.1.so > # ls -l /usr/lib/samba/libtalloc* > lrwxrwxrwx 1 root root 18 Apr 9 2015 > /usr/lib/samba/libtalloc.so.2 -> libtalloc.so.2.1.1 > -rwxr-xr-x 1 root root 19396 Apr 9 2015 > /usr/lib/samba/libtalloc.so.2.1.1 > ----- > > On the build machine: > $ readelf -d ?mbd|grep RPATH > 0x0000000f (RPATH) Library rpath: [/usr/lib/samba] > 0x0000000f (RPATH) Library rpath: [/usr/lib/samba] > > So, it's not up to it yet. It is not a missing or broken $ORIGIN support. As you posted, there is no $ORIGIN used in RPATH. I am really sure it is this commit and option which is solving the runtime problem: http://git.uclibc.org/uClibc/commit/?id=409f14d9b5e47513d5c939120a33965997c8ceb2 Will be part of uClibc-ng 1.0.2. best regards Waldemar
On 04/16/2015 04:55 PM, Waldemar Brodkorb wrote: > It is not a missing or broken $ORIGIN support. As you posted, there > is no $ORIGIN used in RPATH. > I am really sure it is this commit and option which is solving the > runtime problem: > http://git.uclibc.org/uClibc/commit/?id=409f14d9b5e47513d5c939120a33965997c8ceb2 > > Will be part of uClibc-ng 1.0.2. In any case it's just the comment that's wrong but the conditions are the same, current releases are not up to snuff. We can revisit that when there are newer releases, even though i think samba is a big enough package that any uclibc* space savings are pointless, after all it needs to share some storage besides the obvious firmware size and RAM requirements. Regards.
Hi, Gustavo Zacarias wrote, > On 04/16/2015 04:55 PM, Waldemar Brodkorb wrote: > > > It is not a missing or broken $ORIGIN support. As you posted, there > > is no $ORIGIN used in RPATH. > > I am really sure it is this commit and option which is solving the > > runtime problem: > > http://git.uclibc.org/uClibc/commit/?id=409f14d9b5e47513d5c939120a33965997c8ceb2 > > > > Will be part of uClibc-ng 1.0.2. > > In any case it's just the comment that's wrong but the conditions are > the same, current releases are not up to snuff. > We can revisit that when there are newer releases, even though i think > samba is a big enough package that any uclibc* space savings are > pointless, after all it needs to share some storage besides the obvious > firmware size and RAM requirements. But you still have uClibc as default when using internal toolchain. So it would be nice if more packages are working out of the box. And you have users using uClibc for Kodi, which is even bigger than samba ;) best regards Waldemar
On 04/16/2015 05:09 PM, Waldemar Brodkorb wrote: > But you still have uClibc as default when using internal toolchain. > So it would be nice if more packages are working out of the box. > And you have users using uClibc for Kodi, which is even bigger than > samba ;) I didn't say no ;) I said that i don't think it makes sense, there's a difference :P Regards.
Waldemar Brodkorb <wbx@openadk.org> wrote in news:20150416200943.GM27057@waldemar-brodkorb.de: > And you have users using uClibc for Kodi, which is even bigger than > samba ;) Hi, I am using Samba and Kodi on the same machine, so it will be nice to have a Samba 4.x :) I´ll try to find some time to test Samba4 with LDSO_RUNPATH_OF_EXECUTABLE enabled in uClibc. Thx for the hint! Regards, Bernd
diff --git a/package/samba4/0001-build-find-FILE_OFFSET_BITS-via-array.patch b/package/samba4/0001-build-find-FILE_OFFSET_BITS-via-array.patch deleted file mode 100644 index 8dae44d..0000000 --- a/package/samba4/0001-build-find-FILE_OFFSET_BITS-via-array.patch +++ /dev/null @@ -1,56 +0,0 @@ -From 16d88e7813a7739c070a7a1cf6388fd4f236fd99 Mon Sep 17 00:00:00 2001 -From: Gustavo Zacarias <gustavo@zacarias.com.ar> -Date: Fri, 31 Jan 2014 06:45:18 -0300 -Subject: [PATCHv2] build: find FILE_OFFSET_BITS via array - -This makes cross-compiling happy, use a trick similar to autoconf's -AC_CHECK_SIZEOF macro. -Basically we make an array: - -static int array[1 - 2 * !(((long int)(sizeof(off_t))) < 8)]; - -This gives -1 multiplied by the negation of the condition -(sizeof(off_t) < 8) cast to a long int. -So if the condition is true it gives array[(-1 * 0)] (remember the -condition is cast and negated) thus passing a build test with a 0-sized -array. -If it's false it gives array[(-1 * 1)] thus failing with a -negative-sized array. - -Status: Upstream. - -Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> ---- - lib/ccan/wscript | 11 +++++++---- - 1 file changed, 7 insertions(+), 4 deletions(-) - -diff --git a/lib/ccan/wscript b/lib/ccan/wscript -index 59b8205..81039d0 100644 ---- a/lib/ccan/wscript -+++ b/lib/ccan/wscript -@@ -127,15 +127,18 @@ def configure(conf): - # Only check for FILE_OFFSET_BITS=64 if off_t is normally small: - # use raw routines because wrappers include previous _GNU_SOURCE - # or _FILE_OFFSET_BITS defines. -+ # The math for these tests is: -+ # array[-1 * !((int)(condition)) ] (condition is true) = array[0] = builds -+ # array[-1 * !((int)(condition)) ] (condition is false) = array[-1] = fails - conf.check(fragment="""#include <sys/types.h> -- int main(void) { return !(sizeof(off_t) < 8); }""", -- execute=True, msg='Checking for small off_t', -+ int main(void) { static int test_array[1 - 2 * !(((long int)(sizeof(off_t))) < 8)]; }""", -+ msg='Checking for small off_t', - define_name='SMALL_OFF_T') - # Unreliable return value above, hence use define. - if conf.CONFIG_SET('SMALL_OFF_T'): - conf.check(fragment="""#include <sys/types.h> -- int main(void) { return !(sizeof(off_t) >= 8); }""", -- execute=True, msg='Checking for -D_FILE_OFFSET_BITS=64', -+ int main(void) { static int test_array[1 - 2 * !(((long int)(sizeof(off_t))) >= 8)]; }""", -+ msg='Checking for -D_FILE_OFFSET_BITS=64', - ccflags='-D_FILE_OFFSET_BITS=64', - define_name='HAVE_FILE_OFFSET_BITS') - --- -1.8.3.2 - diff --git a/package/samba4/0007-disable-libbsd.patch b/package/samba4/0001-disable-libbsd.patch similarity index 66% rename from package/samba4/0007-disable-libbsd.patch rename to package/samba4/0001-disable-libbsd.patch index b29a812..67f79d0 100644 --- a/package/samba4/0007-disable-libbsd.patch +++ b/package/samba4/0001-disable-libbsd.patch @@ -5,10 +5,10 @@ and bsd/unistd.h get included. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> -diff -Nura samba-4.1.7.orig/lib/replace/wscript samba-4.1.7/lib/replace/wscript ---- samba-4.1.7.orig/lib/replace/wscript 2014-04-17 04:59:14.000000000 -0300 -+++ samba-4.1.7/lib/replace/wscript 2014-05-19 09:17:25.561947774 -0300 -@@ -253,15 +253,6 @@ +diff -Nura samba-4.2.0rc1.orig/lib/replace/wscript samba-4.2.0rc1/lib/replace/wscript +--- samba-4.2.0rc1.orig/lib/replace/wscript 2014-10-01 06:17:32.000000000 -0300 ++++ samba-4.2.0rc1/lib/replace/wscript 2014-10-01 07:21:13.559498987 -0300 +@@ -282,15 +282,6 @@ conf.CHECK_FUNCS('strtouq strtoll __strtoll strtoq memalign posix_memalign') conf.CHECK_FUNCS('prctl') @@ -18,8 +18,8 @@ diff -Nura samba-4.1.7.orig/lib/replace/wscript samba-4.1.7/lib/replace/wscript - checklibc=True) - if not conf.CHECK_FUNCS('getpeereid'): - conf.CHECK_FUNCS_IN('getpeereid', 'bsd', headers='sys/types.h bsd/unistd.h') -- if not conf.CHECK_FUNCS_IN('setproctitle', 'bsd', headers='sys/types.h bsd/unistd.h'): -- conf.CHECK_FUNCS_IN('setproctitle', 'setproctitle', headers='setproctitle.h') +- if not conf.CHECK_FUNCS_IN('setproctitle', 'setproctitle', headers='setproctitle.h'): +- conf.CHECK_FUNCS_IN('setproctitle', 'bsd', headers='sys/types.h bsd/unistd.h') - conf.CHECK_CODE(''' struct ucred cred; diff --git a/package/samba4/0002-build-allow-some-python-variable-overrides.patch b/package/samba4/0002-build-allow-some-python-variable-overrides.patch deleted file mode 100644 index 91634b9..0000000 --- a/package/samba4/0002-build-allow-some-python-variable-overrides.patch +++ /dev/null @@ -1,47 +0,0 @@ -From fdbdf04a9ab3f3a204e95106c4f8f6729d0bab1a Mon Sep 17 00:00:00 2001 -From: Gustavo Zacarias <gustavo@zacarias.com.ar> -Date: Tue, 4 Feb 2014 14:11:52 -0300 -Subject: [PATCH] build: allow some python variable overrides - -The python variables (settings) are fetched from a running python -interpreter which usually isn't the target one when cross compiling, -hence libraries and flags aren't the same and can pollute the target -build. -Allow some of these variables to be redefined via environment variables -in order to aid cross-compiling. -According to testing python_LDFLAGS and python_LIBDIR should be enough. - -Status: Upstream. - -Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> ---- - buildtools/wafadmin/Tools/python.py | 13 +++++++++++++ - 1 file changed, 13 insertions(+) - -diff --git a/buildtools/wafadmin/Tools/python.py b/buildtools/wafadmin/Tools/python.py -index ab1e817..35c61c2 100644 ---- a/buildtools/wafadmin/Tools/python.py -+++ b/buildtools/wafadmin/Tools/python.py -@@ -193,6 +193,19 @@ MACOSX_DEPLOYMENT_TARGET = %r - """ % (python, python_prefix, python_SO, python_SYSLIBS, python_LDFLAGS, python_SHLIBS, - python_LIBDIR, python_LIBPL, INCLUDEPY, Py_ENABLE_SHARED, python_MACOSX_DEPLOYMENT_TARGET)) - -+ # Allow some python overrides from env vars for cross-compiling -+ os_env = dict(os.environ) -+ -+ override_python_LDFLAGS = os_env.get('python_LDFLAGS', None) -+ if override_python_LDFLAGS is not None: -+ conf.log.write("python_LDFLAGS override from environment = %r\n" % (override_python_LDFLAGS)) -+ python_LDFLAGS = override_python_LDFLAGS -+ -+ override_python_LIBDIR = os_env.get('python_LIBDIR', None) -+ if override_python_LIBDIR is not None: -+ conf.log.write("python_LIBDIR override from environment = %r\n" % (override_python_LIBDIR)) -+ python_LIBDIR = override_python_LIBDIR -+ - if python_MACOSX_DEPLOYMENT_TARGET: - conf.env['MACOSX_DEPLOYMENT_TARGET'] = python_MACOSX_DEPLOYMENT_TARGET - conf.environ['MACOSX_DEPLOYMENT_TARGET'] = python_MACOSX_DEPLOYMENT_TARGET --- -1.8.3.2 - diff --git a/package/samba4/0003-build-find-blkcnt_t-size-via-array.patch b/package/samba4/0003-build-find-blkcnt_t-size-via-array.patch deleted file mode 100644 index f6e4d03..0000000 --- a/package/samba4/0003-build-find-blkcnt_t-size-via-array.patch +++ /dev/null @@ -1,54 +0,0 @@ -From 934f8c8e9439de4f15b2e61016d5d29233d8d5fa Mon Sep 17 00:00:00 2001 -From: Gustavo Zacarias <gustavo@zacarias.com.ar> -Date: Wed, 16 Apr 2014 08:01:36 -0300 -Subject: [PATCH 5/5] build: find blkcnt_t size via array - -Using the same trick as commit 0d9bb86293c9d39298786df095c73a6251b08b7e -find blkcnt_t size via an array so that it can be determined via build -rather than running it. - -Status: Upstream. - -Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> ---- - source3/wscript | 22 ++++++++++++---------- - 1 file changed, 12 insertions(+), 10 deletions(-) - -diff --git a/source3/wscript b/source3/wscript -index aade503..6a5728f 100644 ---- a/source3/wscript -+++ b/source3/wscript -@@ -277,18 +277,20 @@ int main(int argc, char **argv) - headers='sys/types.h sys/stat.h unistd.h') - - if "HAVE_BLKCNT_T" in conf.env: -- conf.CHECK_CODE(''' -- return sizeof(blkcnt_t) == 4 ? 0 : 1''', -- 'SIZEOF_BLKCNT_T_4', execute=True, -- headers='replace.h sys/types.h sys/stat.h unistd.h', -- msg="Checking whether blkcnt_t is 32 bit") -+ conf.CHECK_CODE(''' -+ static int test_array[1 - 2 * !(((long int)(sizeof(blkcnt_t))) <= 4)];''', -+ 'SIZEOF_BLKCNT_T_4', -+ headers='replace.h sys/types.h sys/stat.h unistd.h', -+ msg="Checking whether blkcnt_t is 32 bit") - -+ # If sizeof is 4 it can't be 8 - if "HAVE_BLKCNT_T" in conf.env: -- conf.CHECK_CODE(''' -- return sizeof(blkcnt_t) == 8 ? 0 : 1''', -- 'SIZEOF_BLKCNT_T_8', execute=True, -- headers='replace.h sys/types.h sys/stat.h unistd.h', -- msg="Checking whether blkcnt_t is 64 bit") -+ if not conf.CONFIG_SET('SIZEOF_BLKCNT_T_4'): -+ conf.CHECK_CODE(''' -+ static int test_array[1 - 2 * !(((long int)(sizeof(blkcnt_t))) <= 8)];''', -+ 'SIZEOF_BLKCNT_T_8', -+ headers='replace.h sys/types.h sys/stat.h unistd.h', -+ msg="Checking whether blkcnt_t is 64 bit") - - # Check for POSIX capability support - conf.CHECK_FUNCS_IN('cap_get_proc', 'cap', headers='sys/capability.h') --- -1.8.3.2 - diff --git a/package/samba4/0004-build-unify-and-fix-endian-tests.patch b/package/samba4/0004-build-unify-and-fix-endian-tests.patch deleted file mode 100644 index 3fdfe6e..0000000 --- a/package/samba4/0004-build-unify-and-fix-endian-tests.patch +++ /dev/null @@ -1,165 +0,0 @@ -From ee4e06b7223fb2925bc887c89216a66029d44862 Mon Sep 17 00:00:00 2001 -From: Gustavo Zacarias <gustavo@zacarias.com.ar> -Date: Tue, 1 Apr 2014 06:41:47 -0300 -Subject: [PATCH 2/5] build: unify and fix endian tests - -Unify the endian tests out of lib/ccan/wscript into wafsamba since -they're almost cross-compile friendly. -While at it fix them to be so by moving the preprocessor directives out -of main scope since that will fail. -And keep the WORDS_BIGENDIAN, HAVE_LITTLE_ENDIAN and HAVE_BIG_ENDIAN -defines separate because of different codebases. - -Status: Upstream. - -Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> ---- - buildtools/wafsamba/wscript | 65 ++++++++++++++++++++++++++++++++++++++++++--- - lib/ccan/wscript | 55 -------------------------------------- - 2 files changed, 62 insertions(+), 58 deletions(-) - -diff --git a/buildtools/wafsamba/wscript b/buildtools/wafsamba/wscript -index 7984227..1a2cfe6 100755 ---- a/buildtools/wafsamba/wscript -+++ b/buildtools/wafsamba/wscript -@@ -390,9 +390,68 @@ def configure(conf): - else: - conf.define('SHLIBEXT', "so", quote=True) - -- conf.CHECK_CODE('long one = 1; return ((char *)(&one))[0]', -- execute=True, -- define='WORDS_BIGENDIAN') -+ # First try a header check for cross-compile friendlyness -+ conf.CHECK_CODE(code = """#ifdef __BYTE_ORDER -+ #define B __BYTE_ORDER -+ #elif defined(BYTE_ORDER) -+ #define B BYTE_ORDER -+ #endif -+ -+ #ifdef __LITTLE_ENDIAN -+ #define LITTLE __LITTLE_ENDIAN -+ #elif defined(LITTLE_ENDIAN) -+ #define LITTLE LITTLE_ENDIAN -+ #endif -+ -+ #if !defined(LITTLE) || !defined(B) || LITTLE != B -+ #error Not little endian. -+ #endif -+ int main(void) { return 0; }""", -+ addmain=False, -+ headers="endian.h sys/endian.h", -+ define="HAVE_LITTLE_ENDIAN") -+ conf.CHECK_CODE(code = """#ifdef __BYTE_ORDER -+ #define B __BYTE_ORDER -+ #elif defined(BYTE_ORDER) -+ #define B BYTE_ORDER -+ #endif -+ -+ #ifdef __BIG_ENDIAN -+ #define BIG __BIG_ENDIAN -+ #elif defined(BIG_ENDIAN) -+ #define BIG BIG_ENDIAN -+ #endif -+ -+ #if !defined(BIG) || !defined(B) || BIG != B -+ #error Not big endian. -+ #endif -+ int main(void) { return 0; }""", -+ addmain=False, -+ headers="endian.h sys/endian.h", -+ define="HAVE_BIG_ENDIAN") -+ -+ if not conf.CONFIG_SET("HAVE_BIG_ENDIAN") and not conf.CONFIG_SET("HAVE_LITTLE_ENDIAN"): -+ # That didn't work! Do runtime test. -+ conf.CHECK_CODE("""union { int i; char c[sizeof(int)]; } u; -+ u.i = 0x01020304; -+ return u.c[0] == 0x04 && u.c[1] == 0x03 && u.c[2] == 0x02 && u.c[3] == 0x01 ? 0 : 1;""", -+ addmain=True, execute=True, -+ define='HAVE_LITTLE_ENDIAN', -+ msg="Checking for HAVE_LITTLE_ENDIAN - runtime") -+ conf.CHECK_CODE("""union { int i; char c[sizeof(int)]; } u; -+ u.i = 0x01020304; -+ return u.c[0] == 0x01 && u.c[1] == 0x02 && u.c[2] == 0x03 && u.c[3] == 0x04 ? 0 : 1;""", -+ addmain=True, execute=True, -+ define='HAVE_BIG_ENDIAN', -+ msg="Checking for HAVE_BIG_ENDIAN - runtime") -+ -+ # Extra sanity check. -+ if conf.CONFIG_SET("HAVE_BIG_ENDIAN") == conf.CONFIG_SET("HAVE_LITTLE_ENDIAN"): -+ Logs.error("Failed endian determination. The PDP-11 is back?") -+ sys.exit(1) -+ else: -+ if conf.CONFIG_SET("HAVE_BIG_ENDIAN"): -+ conf.DEFINE('WORDS_BIGENDIAN', 1) - - # check if signal() takes a void function - if conf.CHECK_CODE('return *(signal (0, 0)) (0) == 1', -diff --git a/lib/ccan/wscript b/lib/ccan/wscript -index 1c5f337..0e540db 100644 ---- a/lib/ccan/wscript -+++ b/lib/ccan/wscript -@@ -25,61 +25,6 @@ def configure(conf): - conf.CHECK_CODE('int __attribute__((used)) func(int x) { return x; }', - addmain=False, link=False, cflags=conf.env['WERROR_CFLAGS'], - define='HAVE_ATTRIBUTE_USED') -- # We try to use headers for a compile-time test. -- conf.CHECK_CODE(code = """#ifdef __BYTE_ORDER -- #define B __BYTE_ORDER -- #elif defined(BYTE_ORDER) -- #define B BYTE_ORDER -- #endif -- -- #ifdef __LITTLE_ENDIAN -- #define LITTLE __LITTLE_ENDIAN -- #elif defined(LITTLE_ENDIAN) -- #define LITTLE LITTLE_ENDIAN -- #endif -- -- #if !defined(LITTLE) || !defined(B) || LITTLE != B -- #error Not little endian. -- #endif""", -- headers="endian.h sys/endian.h", -- define="HAVE_LITTLE_ENDIAN") -- conf.CHECK_CODE(code = """#ifdef __BYTE_ORDER -- #define B __BYTE_ORDER -- #elif defined(BYTE_ORDER) -- #define B BYTE_ORDER -- #endif -- -- #ifdef __BIG_ENDIAN -- #define BIG __BIG_ENDIAN -- #elif defined(BIG_ENDIAN) -- #define BIG BIG_ENDIAN -- #endif -- -- #if !defined(BIG) || !defined(B) || BIG != B -- #error Not big endian. -- #endif""", -- headers="endian.h sys/endian.h", -- define="HAVE_BIG_ENDIAN") -- -- if not conf.CONFIG_SET("HAVE_BIG_ENDIAN") and not conf.CONFIG_SET("HAVE_LITTLE_ENDIAN"): -- # That didn't work! Do runtime test. -- conf.CHECK_CODE("""union { int i; char c[sizeof(int)]; } u; -- u.i = 0x01020304; -- return u.c[0] == 0x04 && u.c[1] == 0x03 && u.c[2] == 0x02 && u.c[3] == 0x01 ? 0 : 1;""", -- addmain=True, execute=True, -- define='HAVE_LITTLE_ENDIAN', -- msg="Checking for HAVE_LITTLE_ENDIAN - runtime") -- conf.CHECK_CODE("""union { int i; char c[sizeof(int)]; } u; -- u.i = 0x01020304; -- return u.c[0] == 0x01 && u.c[1] == 0x02 && u.c[2] == 0x03 && u.c[3] == 0x04 ? 0 : 1;""", -- addmain=True, execute=True, -- define='HAVE_BIG_ENDIAN', -- msg="Checking for HAVE_BIG_ENDIAN - runtime") -- -- # Extra sanity check. -- if conf.CONFIG_SET("HAVE_BIG_ENDIAN") == conf.CONFIG_SET("HAVE_LITTLE_ENDIAN"): -- Logs.error("Failed endian determination. The PDP-11 is back?") -- sys.exit(1) - - conf.CHECK_CODE('return __builtin_choose_expr(1, 0, "garbage");', - link=True, --- -1.8.3.2 - diff --git a/package/samba4/0005-build-make-wafsamba-CHECK_SIZEOF-cross-compile-friendl.patch b/package/samba4/0005-build-make-wafsamba-CHECK_SIZEOF-cross-compile-friendl.patch deleted file mode 100644 index 72176cb..0000000 --- a/package/samba4/0005-build-make-wafsamba-CHECK_SIZEOF-cross-compile-friendl.patch +++ /dev/null @@ -1,68 +0,0 @@ -From fd3eb1e9f712e4c96c0b55d4203745afb2bcc8c2 Mon Sep 17 00:00:00 2001 -From: Gustavo Zacarias <gustavo@zacarias.com.ar> -Date: Wed, 9 Apr 2014 10:21:59 -0300 -Subject: [PATCH 3/5] build: make wafsamba CHECK_SIZEOF cross-compile friendly - -Use the same trick as commit 0d9bb86293c9d39298786df095c73a6251b08b7e -We do the same array trick iteratively starting from 1 (byte) by powers -of 2 up to 32. - -The new 'critical' option is used to make the invocation die or not -according to each test. -The default is True since normally it's expected to find a proper -result and should error out if not. - -Status: Upstream. - -Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> ---- - buildtools/wafsamba/samba_autoconf.py | 28 ++++++++++++++++------------ - 1 file changed, 16 insertions(+), 12 deletions(-) - -diff --git a/buildtools/wafsamba/samba_autoconf.py b/buildtools/wafsamba/samba_autoconf.py -index 59d9e79..f60ce9d 100644 ---- a/buildtools/wafsamba/samba_autoconf.py -+++ b/buildtools/wafsamba/samba_autoconf.py -@@ -304,23 +304,27 @@ def CHECK_FUNCS(conf, list, link=True, lib=None, headers=None): - - - @conf --def CHECK_SIZEOF(conf, vars, headers=None, define=None): -+def CHECK_SIZEOF(conf, vars, headers=None, define=None, critical=True): - '''check the size of a type''' -- ret = True - for v in TO_LIST(vars): - v_define = define -+ ret = False - if v_define is None: - v_define = 'SIZEOF_%s' % v.upper().replace(' ', '_') -- if not CHECK_CODE(conf, -- 'printf("%%u", (unsigned)sizeof(%s))' % v, -- define=v_define, -- execute=True, -- define_ret=True, -- quote=False, -- headers=headers, -- local_include=False, -- msg="Checking size of %s" % v): -- ret = False -+ for size in list((1, 2, 4, 8, 16, 32)): -+ if CHECK_CODE(conf, -+ 'static int test_array[1 - 2 * !(((long int)(sizeof(%s))) <= %d)];' % (v, size), -+ define=v_define, -+ quote=False, -+ headers=headers, -+ local_include=False, -+ msg="Checking if size of %s == %d" % (v, size)): -+ conf.DEFINE(v_define, size) -+ ret = True -+ break -+ if not ret and critical: -+ Logs.error("Couldn't determine size of '%s'" % v) -+ sys.exit(1) - return ret - - @conf --- -1.8.3.2 - diff --git a/package/samba4/0006-build-tweak-SIZEOF-utmp-ut_line.patch b/package/samba4/0006-build-tweak-SIZEOF-utmp-ut_line.patch deleted file mode 100644 index 28f5f10..0000000 --- a/package/samba4/0006-build-tweak-SIZEOF-utmp-ut_line.patch +++ /dev/null @@ -1,33 +0,0 @@ -From 1a7f4f5e3fbbe83e147fffdfe00d7f37181a8ec1 Mon Sep 17 00:00:00 2001 -From: Gustavo Zacarias <gustavo@zacarias.com.ar> -Date: Wed, 9 Apr 2014 10:39:06 -0300 -Subject: [PATCH 4/5] build: tweak SIZEOF utmp->ut_line - -Set the critical parameter of CHECK_SIZEOF utmp->ut_line to False since -it's used to find out if utmp support should be enabled. -This is necessary with the introduction of the cross-compile aware -CHECK_SIZEOF. - -Status: Upstream. - -Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> ---- - source3/wscript | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/source3/wscript b/source3/wscript -index e81a47b..aade503 100644 ---- a/source3/wscript -+++ b/source3/wscript -@@ -812,7 +812,7 @@ msg.msg_acctrightslen = sizeof(fd); - 'PUTUTLINE_RETURNS_UTMP', headers='utmp.h', - msg="Checking whether pututline returns pointer") - conf.CHECK_SIZEOF(['((struct utmp *)NULL)->ut_line'], headers='utmp.h', -- define='SIZEOF_UTMP_UT_LINE') -+ define='SIZEOF_UTMP_UT_LINE', critical=False) - if not conf.CONFIG_SET('SIZEOF_UTMP_UT_LINE'): - conf.env.with_utmp = False - elif int(conf.env.SIZEOF_UTMP_UT_LINE) < 15: --- -1.8.3.2 - diff --git a/package/samba4/Config.in b/package/samba4/Config.in index b841f42..5a83ab8 100644 --- a/package/samba4/Config.in +++ b/package/samba4/Config.in @@ -1,11 +1,10 @@ +comment "samba4 needs an (e)glibc toolchain" + depends on !BR2_TOOLCHAIN_USES_GLIBC + config BR2_PACKAGE_SAMBA4 bool "samba4" depends on !BR2_PACKAGE_SAMBA - depends on BR2_INET_IPV6 - depends on BR2_USE_MMU # fork() - depends on BR2_USE_WCHAR # e2fsprogs - depends on BR2_LARGEFILE - depends on BR2_TOOLCHAIN_HAS_THREADS # talloc python threads + depends on BR2_TOOLCHAIN_USES_GLIBC # needs nss.h, $ORIGIN support depends on !BR2_nios2 # binary too large, relocations don't fit select BR2_PACKAGE_E2FSPROGS select BR2_PACKAGE_POPT @@ -18,7 +17,25 @@ config BR2_PACKAGE_SAMBA4 http://www.samba.org/ -comment "samba4 needs a toolchain w/ IPv6, wchar, largfile, threads" - depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_LARGEFILE || \ - !BR2_USE_WCHAR || !BR2_INET_IPV6 - depends on BR2_USE_MMU +if BR2_PACKAGE_SAMBA4 + +config BR2_PACKAGE_SAMBA4_AD_DC + bool "AD DC" + select BR2_PACKAGE_GNUTLS + help + Enable Active Directory Domain Controller functionality. + +config BR2_PACKAGE_SAMBA4_ADS + bool "ADS" + select BR2_PACKAGE_OPENLDAP + help + Enable Active Directory member Server functionality. + +config BR2_PACKAGE_SAMBA4_SMBTORTURE + bool "smbtorture" + help + Install the smbtorture test suite. + It's normally used for validation and stress testing. + Approximately +5 MB of stripped uncompressed target space. + +endif diff --git a/package/samba4/samba4.hash b/package/samba4/samba4.hash index 721c3dc..3dbea5a 100644 --- a/package/samba4/samba4.hash +++ b/package/samba4/samba4.hash @@ -1,2 +1,2 @@ # Locally calculated after checking pgp signature -sha256 7aeb5d09e9c84bbeeb4b98d33404e9dbc4d99c54e64a447cc9c4d57e9255cb1d samba-4.1.17.tar.gz +sha256 66a6057815a971fee64fbe936ff6cbad542421a4bd52cba8d8d41afc9abc490f samba-4.2.0.tar.gz diff --git a/package/samba4/samba4.mk b/package/samba4/samba4.mk index bd8ed12..cb6ff0a 100644 --- a/package/samba4/samba4.mk +++ b/package/samba4/samba4.mk @@ -4,8 +4,8 @@ # ################################################################################ -SAMBA4_VERSION = 4.1.17 -SAMBA4_SITE = http://ftp.samba.org/pub/samba/stable +SAMBA4_VERSION = 4.2.0 +SAMBA4_SITE = http://ftp.samba.org/pub/samba SAMBA4_SOURCE = samba-$(SAMBA4_VERSION).tar.gz SAMBA4_LICENSE = GPLv3+ SAMBA4_LICENSE_FILES = COPYING @@ -14,61 +14,63 @@ SAMBA4_DEPENDENCIES = host-e2fsprogs host-heimdal e2fsprogs popt python zlib \ $(if $(BR2_PACKAGE_READLINE),readline) ifeq ($(BR2_PACKAGE_ACL),y) - SAMBA4_CONF_OPTS += --with-acl-support - SAMBA4_DEPENDENCIES += acl +SAMBA4_CONF_OPTS += --with-acl-support +SAMBA4_DEPENDENCIES += acl else - SAMBA4_CONF_OPTS += --without-acl-support +SAMBA4_CONF_OPTS += --without-acl-support endif ifeq ($(BR2_PACKAGE_CUPS),y) - SAMBA4_CONF_ENV += CUPS_CONFIG="$(STAGING_DIR)/usr/bin/cups-config" - SAMBA4_CONF_OPTS += --enable-cups - SAMBA4_DEPENDENCIES += cups +SAMBA4_CONF_ENV += CUPS_CONFIG="$(STAGING_DIR)/usr/bin/cups-config" +SAMBA4_CONF_OPTS += --enable-cups +SAMBA4_DEPENDENCIES += cups else - SAMBA4_CONF_OPTS += --disable-cups +SAMBA4_CONF_OPTS += --disable-cups endif ifeq ($(BR2_PACKAGE_LIBAIO),y) - SAMBA4_CONF_OPTS += --with-aio-support - SAMBA4_DEPENDENCIES += libaio +SAMBA4_CONF_OPTS += --with-aio-support +SAMBA4_DEPENDENCIES += libaio else - SAMBA4_CONF_OPTS += --without-aio-support +SAMBA4_CONF_OPTS += --without-aio-support endif ifeq ($(BR2_PACKAGE_DBUS)$(BR2_PACKAGE_AVAHI_DAEMON),yy) - SAMBA4_CONF_OPTS += --enable-avahi - SAMBA4_DEPENDENCIES += avahi +SAMBA4_CONF_OPTS += --enable-avahi +SAMBA4_DEPENDENCIES += avahi else - SAMBA4_CONF_OPTS += --disable-avahi +SAMBA4_CONF_OPTS += --disable-avahi endif ifeq ($(BR2_PACKAGE_GAMIN),y) - SAMBA4_CONF_OPTS += --with-fam - SAMBA4_DEPENDENCIES += gamin +SAMBA4_CONF_OPTS += --with-fam +SAMBA4_DEPENDENCIES += gamin else - SAMBA4_CONF_OPTS += --without-fam +SAMBA4_CONF_OPTS += --without-fam endif ifeq ($(BR2_PACKAGE_GETTEXT),y) - SAMBA4_CONF_OPTS += --with-gettext=$(STAGING_DIR)/usr - SAMBA4_DEPENDENCIES += gettext +SAMBA4_CONF_OPTS += --with-gettext=$(STAGING_DIR)/usr +SAMBA4_DEPENDENCIES += gettext else - SAMBA4_CONF_OPTS += --without-gettext -endif - -ifeq ($(BR2_PACKAGE_GNUTLS),y) - SAMBA4_CONF_OPTS += --enable-gnutls - SAMBA4_DEPENDENCIES += gnutls -else - SAMBA4_CONF_OPTS += --disable-gnutls +SAMBA4_CONF_OPTS += --without-gettext endif ifeq ($(BR2_PACKAGE_NCURSES_TARGET_FORM)$(BR2_PACKAGE_NCURSES_TARGET_MENU)$(BR2_PACKAGE_NCURSES_TARGET_PANEL),yyy) - SAMBA4_DEPENDENCIES += ncurses +SAMBA4_DEPENDENCIES += ncurses else - SAMBA4_CONF_OPTS += --without-regedit +SAMBA4_CONF_OPTS += --without-regedit endif +# The ctdb tests (cluster) need bash and take up some space +# They're normally intended for debugging so remove them +define SAMBA4_REMOVE_CTDB_TESTS + rm -rf $(TARGET_DIR)/usr/lib/ctdb-tests + rm -rf $(TARGET_DIR)/usr/share/ctdb-tests + rm -f $(TARGET_DIR)/usr/bin/ctdb_run_*tests +endef +SAMBA4_POST_INSTALL_TARGET_HOOKS += SAMBA4_REMOVE_CTDB_TESTS + define SAMBA4_CONFIGURE_CMDS cp package/samba4/samba4-cache.txt $(@D)/cache.txt; echo 'Checking uname machine type: $(BR2_ARCH)' >>$(@D)/cache.txt; @@ -93,9 +95,7 @@ define SAMBA4_CONFIGURE_CMDS --without-pam \ --without-dmapi \ --disable-glusterfs \ - --without-ldap \ - --without-cluster-support \ - --without-ads \ + --with-cluster-support \ --bundled-libraries='!asn1_compile,!compile_et' \ $(SAMBA4_CONF_OPTS) \ ) @@ -119,18 +119,34 @@ endef SAMBA4_POST_INSTALL_TARGET_HOOKS += SAMBA4_BUILD_PYC_FILES endif +ifeq ($(BR2_PACKAGE_SAMBA4_AD_DC),) +SAMBA4_CONF_OPTS += --without-ad-dc +endif + +ifeq ($(BR2_PACKAGE_GNUTLS),y) +SAMBA4_CONF_OPTS += --enable-gnutls +SAMBA4_DEPENDENCIES += gnutls +else +SAMBA4_CONF_OPTS += --disable-gnutls +endif + +ifeq ($(BR2_PACKAGE_SAMBA4_ADS),y) +SAMBA4_CONF_OPTS += --with-ads --with-ldap --with-shared-modules=idmap_ad +SAMBA4_DEPENDENCIES += openldap +else +SAMBA4_CONF_OPTS += --without-ads --without-ldap +endif + +ifeq ($(BR2_PACKAGE_SAMBA4_SMBTORTURE),) +define SAMBA4_REMOVE_SMBTORTURE + rm -f $(TARGET_DIR)/usr/bin/smbtorture +endef +SAMBA4_POST_INSTALL_TARGET_HOOKS += SAMBA4_REMOVE_SMBTORTURE +endif + define SAMBA4_INSTALL_INIT_SYSV $(INSTALL) -m 0755 -D package/samba4/S91smb \ $(TARGET_DIR)/etc/init.d/S91smb endef -# uClibc doesn't honor $ORIGIN so we need to move a few libs -ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y) -define SAMBA4_MOVE_LIBS - mv -f $(TARGET_DIR)/usr/lib/samba/libreplace* $(TARGET_DIR)/usr/lib - mv -f $(TARGET_DIR)/usr/lib/samba/libtalloc* $(TARGET_DIR)/usr/lib -endef -SAMBA4_POST_INSTALL_TARGET_HOOKS += SAMBA4_MOVE_LIBS -endif - $(eval $(generic-package))
Now with support for AD DC, ADS and clustering features. All dropped patches are upstream. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> --- ...001-build-find-FILE_OFFSET_BITS-via-array.patch | 56 ------- ...able-libbsd.patch => 0001-disable-libbsd.patch} | 12 +- ...uild-allow-some-python-variable-overrides.patch | 47 ------ .../0003-build-find-blkcnt_t-size-via-array.patch | 54 ------- .../0004-build-unify-and-fix-endian-tests.patch | 165 --------------------- ...fsamba-CHECK_SIZEOF-cross-compile-friendl.patch | 68 --------- .../0006-build-tweak-SIZEOF-utmp-ut_line.patch | 33 ----- package/samba4/Config.in | 35 +++-- package/samba4/samba4.hash | 2 +- package/samba4/samba4.mk | 100 +++++++------ 10 files changed, 91 insertions(+), 481 deletions(-) delete mode 100644 package/samba4/0001-build-find-FILE_OFFSET_BITS-via-array.patch rename package/samba4/{0007-disable-libbsd.patch => 0001-disable-libbsd.patch} (66%) delete mode 100644 package/samba4/0002-build-allow-some-python-variable-overrides.patch delete mode 100644 package/samba4/0003-build-find-blkcnt_t-size-via-array.patch delete mode 100644 package/samba4/0004-build-unify-and-fix-endian-tests.patch delete mode 100644 package/samba4/0005-build-make-wafsamba-CHECK_SIZEOF-cross-compile-friendl.patch delete mode 100644 package/samba4/0006-build-tweak-SIZEOF-utmp-ut_line.patch