-
-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
gdbm: --enable-libgdbm-compat #56834
Conversation
Two targets are provided, "macos" and "macos-gdbm". "macos" will successfully compile, but it appears macOS's default POSIX ndbm implementation is completely broken (db.dptr void pointer to garbage data). "macos-gdbm" uses gdbm_compat (same as the "linux" target), but that requires a Homebrew patch which is not yet accepted[0]. [0] Homebrew/homebrew-core#56834
Looks like it installed and tested all children dependencies (which are effectively all formulae). None of the failures were regressions due to this request.
|
Two targets are provided, "macos" and "macos-gdbm". "macos" will successfully compile, but it appears macOS's default POSIX ndbm implementation is completely broken (db.dptr void pointer to garbage data). "macos-gdbm" uses gdbm_compat (same as the "linux" target), but that requires a Homebrew patch which is not yet accepted[0]. [0] Homebrew/homebrew-core#56834
Hi, any update on this? It passes CI (dependent formulae failed for unrelated reasons, see above) and is ready to be reviewed. |
Does anyone else ship this option enabled by default? And would this be useful to the majority of homebrew users? |
@SMillerDev Yes, it's enabled for every distro I know of (Debian and derivatives, Fedora and derivatives, Arch, etc). And it's a library, so it's of use for people who need to compile software against gdbm's ndbm variant. |
Rebased due to conflicts since this was originally opened. @SMillerDev (or anyone other reviewers), please see reply above, this is still ready to be reviewed. |
Anybody? |
I'm not sure what to do here. @SMillerDev hasn't replied to my response to the questions, this ticket is so far down the list that nobody looks at it (or is hesitant to look at it because if it's so far down the list, it's not low hanging fruit), and per https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request the only recourse is:
|
The build is failing, so that needs to be resolved before we can merge. |
@SMillerDev Please see above, those are reverse dependencies which are failing unrelated to this change. The build is not failing, nor is the change causing any reverse dependencies to fail. |
I have updated the main description of the summary of the replies I've made in this PR within the last month. |
If you had the interest and inclination, the easiest way to get this PR merged would be to open PRs that fix these ten tests. That's not expected of you at all, but CI passing with a happy ✅ would make this PR way easier to merge. In the mean time, we're discussing this PR and how to deal with these CI failure. |
I'm in favour of this PR, CI issues aside. |
Some have already been fixed (opentsdb from a quick check, #58076), one had apparently been failing for a long time and was easy to fix (yafc, #58717 filed), but it seems many of them are simply transient failures, usually because of external dependencies. bzt was particularly interesting; looks like in the 20 hours between when these tests started and ended, it was updated and the old bottle disappeared. As is, it appears any formula with a significant number of reverse dependencies currently need to be manually merged since at least one transient failure is going to happen (and that will start covering up serial problems like yafc -- see e.g. #58302). |
CI takes 20.5 hours. 😬 |
@Homebrew/core Any objections to merging this PR, ignoring the CI failures? |
As-is: yes. The last CI run was 18 days ago. I'd like to see CI rerun and some evidence that at least some of these failures aren't due to this PR. I'd also like to see (as is usual/should be standard practise) the maintainer that merges this create an TODO issue to confirm that these failures are unrelated and work on fixing them. |
Changing |
And with extra work, they were all determined to be unrelated to the change. I've noticed the same thing is going on in #58683 for gettext, with pushback for getting it merged because of unrelated reverse dependency failures. While testing reverse dependencies for regressions would be a good idea, and something like an occasional full rebuild test would be good, this current system is not helping. |
I agree. |
--enable-libgdbm-compat for dbm.h / gdbm-ndbm.h compatibility: https://www.gnu.org.ua/software/gdbm/manual/html_chapter/gdbm_19.html
Rebased, see you in 24 hours. |
As for the rm -rf, no idea, something to do with go_mod_cache: https://github.com/Homebrew/homebrew-core/pull/56834/checks?check_run_id=919824030#step:6:12728
As before, none of the failures are related to the change. Please go ahead and merge, thanks. |
Thanks so much for your contribution (and patience)! Without people like you submitting PRs we couldn't run this project. You rock, @rfinnie! |
This PR is not blocked or waiting on submitter feedback. Summary of replies and comments made within the last month:
--enable-libgdbm-compat for dbm.h / gdbm-ndbm.h compatibility:
https://www.gnu.org.ua/software/gdbm/manual/html_chapter/gdbm_19.html
("compat" in this sense means compatibility with gdbm's older dbm / ndbm implementations, which have differences to POSIX ndbm, if you're wondering "why not just use macOS's ndbm.h?"
brew install --build-from-source <formula>
, where<formula>
is the name of the formula you're submitting?brew test <formula>
, where<formula>
is the name of the formula you're submitting?brew audit --strict <formula>
(after doingbrew install <formula>
)?