Created attachment 235670 [details] Patch for pstree Update MASTER_SITES to unbreak port Add LICENSE definitions Remove USES alias definition as DragonflyBSD is defined in source Poudriere testport OK 12.3-RELEASE (amd64) Poudriere testport OK 13.0-RELEASE (i386) References: https://github.com/FredHucht/pstree/blob/main/pstree.c#L69
I've just seen this patch and can work on validation, however can you please address mastersite change? Are you originator of code and project? If so, can you please validate this information in some way? Thanks! -jgh
Hi, Not more than same person is listed as author https://fossies.org/dox/pstree-2.39/pstree_8c_source.html And that Alpine, MacPorts and OpenIndiana uses the same repo https://pkgs.alpinelinux.org/package/edge/main/x86/pstree https://ports.macports.org/port/pstree/details/ https://github.com/OpenIndiana/oi-userland/search?q=pstree+filename%3AMakefile&type=Code Best regards, Daniel
Friendly ping
Good to go?
I didn't see these updates, sorry... I'll take a look at this soon.
Why is this pointing to a specific file? Is this a commit? https://github.com/FredHucht/${PORTNAME}/files/9119465/ Thanks! -jgh
"If the distribution file comes from a specific commit or tag on GitHub for which there is no officially released file, there is..." https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github https://github.com/FredHucht/pstree/releases/tag/v2.40 --> https://github.com/FredHucht/pstree/files/9119465/pstree-v2.40.zip ("Source code" archives are generated on the fly so not suitable). Not sure how upstream ended up with that path but that's the link. Best regards, Daniel
Ok, thanks. I haven't run into this specific situation, yet, as I've always at least pulled on content hash when release hasn't been made, and use a patchfile tied to a commit, if appropriate, over pulling a specific file. I will work this out, but encourage you open up an issue to have owner properly tag release if these changes aren't in release, yet it was updated. It does become more difficult to follow updates going forward, and I've found maintainer of software does become more aware of release-based actions. Thanks! -jgh
Ok, thanks. I haven't run into this specific situation, yet, as I've always at least pulled on content hash when release hasn't been made, and use a patchfile tied to a commit, if appropriate, over pulling a specific file. I will work this out, but encourage you open up an issue to have owner properly tag release if these changes aren't in release, yet it was updated. It does become more difficult to follow updates going forward, and I've found maintainer of software does become more aware of release-based actions. Thanks! -jgh (In reply to Daniel Engberg from comment #7) After re-reading this comment, I looked into it more and have attached a patch to address this issue. Please let me know what you think.
Created attachment 236956 [details] patch to use tag
I'm not sure I follow you, what changes and what isn't tagged properly? If you are to follow Porters Handbook (which we should unless there's a very good reason not to) you should use upstream distfile if available which in this case is the file despite where it's being hosted. Pulling individual changes from GitHub as patches is fine. Best regards, Daniel
I'm pulling based off of github tag, https://github.com/FredHucht/pstree/releases/tag/v2.40 , as you noted. I am using upstream distfile from github. From bsd.sites.mk: # GH_TAGNAME - name of the tag to download (2.0.1, hash, ...) # Using the name of a branch here is incorrect. It is # possible to do GH_TAGNAME= GIT_HASH to do a snapshot. # default: ${DISTVERSIONFULL}
This blurb is also cited in Porter's Handbook
GitHub tag is not a "static" distfile provided by upstream, it's generated on the fly (codeload). See https://cgit.freebsd.org/ports/tree/Mk/bsd.sites.mk#n289 for more information about that glue. See also https://github.com/isamert/scli/issues/143 for example so it's "last resort" which Porters Handbook tells you not to use if there's a static distfile/tarball available.
(In reply to Daniel Engberg from comment #14) Ok, fair point. The only thing holding me and trying to understand what is going on here is that how can I say that v2.40 equals this zip, and how to do track when a new version is available? Is there a particular commit bit to base off of? To me, this seems to be more of something that can be technically chased. Thanks! -jgh
I see how this is working now.. Not my preference, but it is what it is... I'll work on getting this through, and thank you for any patience you extended to me during this back-n-forth ;) -jgh
I don't think portscout works that well with GitHub in general but I can't say I've looked at it closely. Looking at commits logs many seem to rely on GitHub's own watch feature including myself. Thanks for looking into this! Best regards, Daniel
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=4899be1e6323086b95823cff3a486f240c73eb4a commit 4899be1e6323086b95823cff3a486f240c73eb4a Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2022-09-30 23:08:51 +0000 Commit: Jason Helfman <jgh@FreeBSD.org> CommitDate: 2022-09-30 23:08:51 +0000 sysutils/pstree: update to v2.40, shift to github upstream PR: 265619 sysutils/pstree/Makefile | 12 +++++++----- sysutils/pstree/distinfo | 5 +++-- 2 files changed, 10 insertions(+), 7 deletions(-)
Committed! Thanks :) -jgh
Shift to closed.