-
-
Notifications
You must be signed in to change notification settings - Fork 12.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix afsctool for High Sierra #20898
fix afsctool for High Sierra #20898
Conversation
patch file type to allow file type 24 as well ref: diimdeep/afsctool#3 original diff: https://github.com/gingerbeardman/afsctool/commit/1fab0d87546f36e24e89a9f73f187b3ff639b920.diff?full_index=1 modified path in patch to afsctool_34/afsctool.c
It doesn't work natively on 10.12 and 10.13, there has been no sign since 2014 that the original author intends to maintain it. |
@brkirch can we get this upstreamed in a new release? |
With my patch (in OP) it works on 10.12 Sierra and 10.13 High Sierra there's also this currently maintained version: https://github.com/RJVB/afsctool |
@gingerbeardman either @brkirch would need to bless one of the forks, or a fork would need its own project name and need to meet the |
@gingerbeardman that rjvb fork is really nice! I'll update the formula to use that version soon. it's clearly superior to your branch and also looks to be regularly maintained |
I still have yet to try the @RJVB version out, however, I did notice the f_type is not even checked. I'm assuming that file compression is attempted and then when errors occur, the changes are rolled back. EDIT: turns out the f_type check is changed to:
in this commit: RJVB/afsctool@4d3272d |
Closing this out until we hear from upstream. Thanks @heavyk |
ok I updated the formula here if you want to pull it in: |
Great. I only found the RJVB version after seeing this issue. So thanks! Much better than my old fork. |
Thanks, I had already sent him a message. Though I doubt we will get a response. Fingers crossed 🤞 |
I've been using the RJVB version here locally for the last 4 months just fine... I hope that's the one that makes it into brew finally |
I suggest you host your own tap https://github.com/Homebrew/brew/blob/master/docs/How-to-Create-and-Maintain-a-Tap.md#how-to-create-and-maintain-a-tap |
@ilovezfs that's a nice alternative, thanks. With regards to the "dead" formula, it's kind of worrying this can happen. For how long do such formula stick around before being retired? What happens if an author dies or ceases being interested? I also think it's odd that the author's permission was not sought for the formula to be added, but it is needed for this worthwhile change that will benefit all. Had the initial permission been sought you'd have realised the author is totally incommunicado. |
Formulae are typically retained until they break and fixes cannot be upstreamed. If an upstream becomes completely unavailable, then a fork may be able to take its place depending on circumstances. In this case, based on the responses on RJVB/afsctool#1 I don't have the requisite confidence in that fork. |
Ah, all is now clear - you're holding a grudge. You've not got your way so you're creating obstacles. Hopefully we can get somebody else involved who doesn't have a vendetta. Any thoughts @MikeMcQuaid @fxcoudert @JCount @mistydemeo @tschoonj ? |
@gingerbeardman please read or re-read our Code of Conduct and adjust your future communications accordingly. |
I've read it, understood. Any thoughts on my points above? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks okay, this can be merged in.
@brkirch if you could post a 10.13 compatible version, that would be great. |
Any fork with major changes can have a formula submitted under a different program name, and I don't mind at all if "afsctool" is included in the name so long as it isn't the full name. Originally I created afsctool just as a way to identify compressed files and accurately determine the disk space such files used. The other features were quite frankly an afterthought and as such what afsctool really needs is a complete rewrite. I started on such a rewrite a long while back but have never completed it. Even though it has been a long time I still wish to finish it eventually. @ilovezfs Although I don't know how much time I'll have to spend on it, I'll see if I can look into that within the next few days. |
Thanks, @brkirch. That would be much appreciated. |
5b5d8af
to
6bd9cd2
Compare
@ilovezfs Thanks, I actually didn't notice the other commit there when I was looking before. @heavyk The enhancements in https://github.com/RJVB/afsctool do look nice so if @RJVB doesn't mind then it doesn't seem like a bad idea to submit a formula for it under a different name. Like I said in my above comment, it would be fine if "afsctool" is included in the name (e.g. afsctool_rjvb). |
Thanks for your first contribution to Homebrew, @heavyk! Without people like you submitting PRs we couldn't run this project. You rock! |
@gingerbeardman Thanks for pointing that out, I've corrected my comment. |
@brkirch for now, I've shipped this as-is with the patch inlined in the formula, but we look forward to a new upstream release tarball when you have a chance so that we can remove the patches. In terms of enhancements from the fork(s), my suggestion would be to have a https://github.com/brkirch/afsctool repository on GitHub so that people can open pull requests and get those upstreamed into your version if you'll accept them. The forks are unlikely to qualify on their own as new formulae in terms of the notability threshhold. Of course, as I mentioned above, they could also offer the alternative versions in their own tap. |
@gingerbeardman My thoughts are the following:
This is exactly why this policy exists (and validates @ilovezfs's decision). We're not willing to have either major patches or move formulae to point to forks when either of them may have major issues which unfairly damage the reputation of the original author/software. In future, @gingerbeardman, if you don't like or understand our policies I suggest asking for explanations and creating your own tap rather than criticising how we run this project. With no disrespect intended: unless you've run your own package manager for many years it's unlikely you'll have encountered or fully thought through all the edge cases we've had to. That all said: thanks for your contributions to Homebrew and hopefully this can be seen as a minor request for course correction as we'd love you to continue to contribute in future. |
That's all fair enough, thanks for the reply. In hindsight I should have read the notability requirements when they were initially mentioned. Lesson learned. I've only ever had one other unpleasant experience across all of the years and OSS projects I have participated in on GitHub, so I hope you'll understand that I feel I must stand my ground on this. unfair accusation
"Sometimes we can make an exception"
"But the fork owner didn't do what I wanted, the way I sugggested, so there's no chance" That sort of snide remark is petty, seems arrogant, and is not really in the spirit of OSS I have come to expect. I wanted to call that out for the greater good. I also see that a comment by the fork owner was deleted (before I had a chance to read it, no idea what it said). I took it as validation of my initial remark. So: accusation - yes; unfair - depends on your point of view. escalation brkirch decision |
@gingerbeardman I'm going to assume good intentions here and hopefully explain to you why this is unacceptable. At this point you have accused @ilovezfs of the following:
That's simply not an acceptable way to speak to anyone on our issue tracker. It's a violation of our Code of Conduct (which you've been warned about before) and I'm formally warning you about again. Please keep your discussions technical and completely eliminate the name calling. Personally, I think it would also be polite to apologise to @ilovezfs but that's up to you. To be clear on all of the above (with the exception of the recommendation to apologise): this is not a negotiation or discussion. I'm telling you your behaviour is unacceptable and you need to either adjust it or you will no longer be welcome in our community. This pains me to have to point out because you've previously contributed to Homebrew (which we genuinely appreciate) but I will sooner lose your future contributions than see you continue to speak to our about @ilovezfs in this way. |
Consider my future behaviour adjusted and in accordance with the Code of Conduct. 🕊 I'd be happy to apologise to @ilovezfs if he is happy to apologise to @RJVB for the remark which resulted in my unacceptable behaviour? 🤝
That said, I look forward to contributing further to homebrew in future. 🍻 |
@gingerbeardman A conditional apology is not an apology so just to clarify for your own benefit: you're not willing to apologise. That's fine but I just think it's worth being explicit about.
Thanks ❤️ |
There was nothing negative in my previous reply, so please don't imply that there was. I did not mean to offer a conditional apology, I just meant that I feel there is more than one person here that is due an apology and neither of them are me. So let me take a leaf out of your book @MikeMcQuaid: To @ilovezfs - I am sorry for any offence you may have taken. Personally, I think it would also be polite to apologise to @RJVB but that's up to you. |
@gingerbeardman Thank you ❤️ |
patch file type to allow file type 24 as well
ref: diimdeep/afsctool#3
original diff: https://github.com/gingerbeardman/afsctool/commit/1fab0d87546f36e24e89a9f73f187b3ff639b920.diff?full_index=1
modified path in patch to afsctool_34/afsctool.c
brew install --build-from-source <formula>
, where<formula>
is the name of the formula you're submitting?brew audit --strict <formula>
(after doingbrew install <formula>
)?