- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 24 2023
Apr 16 2023
Apr 15 2023
Mar 30 2023
Mar 24 2023
Mar 16 2023
Mar 3 2023
In D38863#884950, @fuz wrote:Packages exist for other architectures and this bump changes the versions of dependencies used in them, hence I believe a PORTREVISION bump is appropriate.
Feb 27 2023
Approved. Thanks for adding the UPDATING entry.
Feb 26 2023
Approved.
I think this looks fine. What @diizzy notes comes down to personal preference I guess. Approved, with or without changes to the do-install target.
I left a comment in the PR, i think we should add an UPDATING entry. Other than that I think this looks good.
Feb 23 2023
Approved. I realize that this is one more of those not documented but usually we do it this way things. When we use blanket approval it's often noted as such. i.e. portmgr (blanket, build fix), otherwise it looks like portmgr actively approved this commit, which I *think* the did not?
Approved
This is kind of redundant information, i would leave it out
- make makesum
- new plist entries
Feb 20 2023
In D38683#880657, @diizzy wrote:Consider asking maintainer for a new patch as 1.3.5 is out
https://github.com/open62541/open62541/releases
In D38681#880651, @fuz wrote:If you approve, please set the appropriate flag. I've seen various other maintainers write something to the effect of “first time maintainer” or “already maintainer of other ports” when committing new ports by third party contributors.
Yeah, forgot the tag. Ok, apparently I never noticed.
In D38684#880648, @fuz wrote:@flo This is a Go port, which always links its dependencies statically. As per Porter's Handbook, Go dependencies are never packaged on their own, simply because it cannot be done in a reasonable way. This project in particular *vendors* its dependencies, meaning copies of them are part of the upstream repository. A part of go.mk is the target gomod-vendor which automatically generates a set of GH_TUPLE entries to do this vendoring locally, permitting a build without network access at build time. This target did not detect that upstream had already vendored the dependencies, leading to useless duplicate code fetches. With more knowledge of how this works, I can now safely remove these extraneous distfiles, keeping only the one we override with a different version. They were never used anyway as the presence of the directories they were supposed to be unpacked to in the main distfile led them to be unpacked into the wrong places.
In D38687#880643, @fuz wrote:The maintainer has disclaimed maintainership (D38635). I had generated this batch of patches from a branch right before I had committed the previous batch, so that change is not in there yet.
Are the bundled libraries always used? I.e. the ones that the port depended on were unused? Otherwise we should keep the dependencies.
Was this discussed with the maintainer? I'm 50:50 whether this is infrastructure works that we as committers are expected to correct, or if this should be run by the maintainer. For sysutils/rundeck2 it's clear as it has been unmaintained upstream for a long time.
Approved. This looks like something that might be MFH'ed?
Approved. You can put something like (maintainer, via private mail). That's how it's done from time to time.
Approved.
Approved. I was going to comment on the commit message, that it should describe why something is done and not what is done, but I see it was also submitted by the maintainer.
"Submitter is first time maintainer." I've never seen this mentioned. I don't think it's necessary to mention this, but it doesn't hurt of course. Personally I would leave it out.
Looks good. Approved
Feb 19 2023
Approved
In D38629#879848, @eduardo wrote:
Approved.
Feb 17 2023
In D38635#879630, @fuz wrote:Is it ok if I add the deprecation to the next batch or do you want me to revise this one?
In D38635#879603, @diizzy wrote:As mentioned in PR deprecate 2.x and set EXPIRATION_DATE appropriately. Please don't just dump old unmaintained versions in ports.
In D38636#879592, @eduardo wrote:Isn't Security: tag a vid or cve?
27c822a0-addc-11ed-a9ee-dca632b19f10
or
CVE-2021-44832 ?
Feb 16 2023
Approved
I see you add a Reported by: tag on all maintainer submitted patches. That is relatively uncommon. I see that fernape seems to do this. Usually ever since switching to git we just set the author on the commit. Reported by: is usually for when someone just reported something but did not provide a patch.
In D38628#879480, @fuz wrote:I have submitted the patch as I received it from the maintainer. I can change it to DISTVERSION for the commit if you want.
Approved. The PR states that it should be MFH'ed. I don't see this in the commit message template, but if you want to that's approved too, as a simple build fix.
Feb 14 2023
In D38511#877881, @fuz_fuz.su wrote:As a general question, do you want me to obtain separate approval for the MFH commits or is this approval here also applicable to the commit to the quarterly branch?
In D38518#878077, @fuz_fuz.su wrote:Is approval from @grahamperrin required to proceed or is mentor approval sufficient?
Feb 12 2023
Approved. FWIW, the sentence "A patch release" didn't immediately make sense to me. I'd use a couple of more words, like "fixes a couple of bugs in the 0.10 branch". I guess you want do describe why this will be MFH'ed?
Minor comments. Otherwise approved.
Hmm, I'm not sure replacing a couple of REINPLACE_CMD with loads of patch files is a good idea. It would follow the policy, but also add a lot of churn. I'm unsure, @eduardo what do you think?
Approved. Crash fix should be ok to MFH.