Closed Dunedubby closed 4 weeks ago
Just wanted to point out that this seems somewhat relevant: https://aur.archlinux.org/packages/edencommon (the comments).
i'm not surprised others are having issues. these package don't follow any versioniong, other than weekly releases, whether or not they're stable, and the versions are all tightly-coupled.
Fine to do in a single branch, but the rebuilds won't be available since they're done in parallel.
Hmm it's so weird... from the errors it's like the edencommon package wants an old version of folly (<2024.09.16, not even just 2024.09.23), but obviously the edencommon source itself only references the most recent version of folly. My hunch is that there's some weird dependency daisy chain where one of the facebook packages has a dependency on the previous version, which in turn has a package that depends on the previous version...
I'm starting to strongly suspect the problem may be wangle... https://github.com/pkgxdev/pantry/actions/runs/11218670141/job/31182979376
the fact that the watchman releases hadn't built a distributable binary on their GitHub since May the last I checked suggests that it releases pro-forma on Monday like the others, but isn't really in a 'release' state.
i think after moving everything to gcc
on linux, i finally got it. merging #6389
Oh that's awesome!!! Yeah I was getting stuck on linking Python, so I'm really impressed that you figured it out! Does that build fix the state directory not in userspace problem?
Oh that's awesome!!! Yeah I was getting stuck on linking Python, so I'm really impressed that you figured it out! Does that build fix the state directory not in userspace problem?
If I didn't that part should be easy, I hope. Let me know.
ah, it builds. does that fix the issue for you?
After you fixed everything (thank you so much) the state directory started pointing to the original, backup state directory location in /tmp. This PR now would just put the state directory in .pkgx instead of /tmp ... but I don't know if it's worth the rather hacky/manual script edit. Maybe it's better just to close without merging
no, i think patching is the right solution. we do it for other packages for relocatability. if this solves your problem, just mark it ready and I'll merge it.
Thanks for closing this! Sorry, got pulled into some tight deadlines at work 😅
Created a new pull request because my older one was bogged down by a lot of commits to externally fix a problem (CMake prefix) which hopefully is now fixed in the pkgx framework. This pull request has a different scope: getting the WATCHMAN_STATE_DIR variable to be relocatable.