devel/goreleaser: update to 1.15.2 Approved by: eduardo, flo (mentors) Changelog: https://github.com/goreleaser/goreleaser/releases/tag/v1.15.2 Changelog: https://github.com/goreleaser/goreleaser/releases/tag/v1.15.1 Changelog: https://github.com/goreleaser/goreleaser/releases/tag/v1.15.0 Differential Review: https://reviews.freebsd.org/D38434
Details
Details
- Reviewers
flo eduardo - Commits
- R11:9967311797a9: devel/goreleaser: Update to 1.15.2
Tested with Poudriere on i386 amd64 FreeBSD 12.4, 13.1.
http://fuz.su/~fuz/freebsd/goreleaser-1.15.2
Diff Detail
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Summary should include all info as commit msg so we can check style and order of mesg:
<category>/<portname>: Update to x.y.z (optional steps inside port) While I'm here, change this or that ChangeLog: [1] PR: [2] Approved by: [2] Differential Review: [2] ...
[1] ChangeLog
Theres no problem using several links in here but when multiple versions were released by upstream we can use:
- one link to changelog that includes all versions: https://github.com/goreleaser/goreleaser/releases or a changelog file when available: https://github.com/gopasspw/gopass/blob/master/CHANGELOG.md
- the same as above with diff between versions: https://github.com/goreleaser/goreleaser/compare/v1.14.1...v1.15.2
[2] fields available on .hooks/prepare-commit-msg (it must be executable) and it can be added with
git config --add core.hooksPath .hooks so each commit will show bellow your commit msg:
# Uncomment and complete these metadata fields, as appropriate: # # PR: <If and which Problem Report is related.> # Reported by: <If someone else reported the issue.> # Reviewed by: <If someone else reviewed your modification.> # Tested by: <If someone else tested the change.> # Approved by: <If you needed approval for this commit.> # Obtained from: <If the change is from a third party.> # Fixes: <Short hash and title line of commit fixed by this change> # MFH: <Ports tree branch name you plan to merge to.> # Relnotes: <Set to 'yes' for mention in release notes.> # Security: <Vulnerability reference (one per line) or description.> # Sponsored by: <If the change was sponsored by an organization.> # Pull Request: <https://github.com/freebsd/freebsd-ports/pull/###> # Differential Revision: <https://reviews.freebsd.org/D###>
Comment Actions
Thank you. I did not know about the hooks. Have installed them now.
This project in particular posts frequent updates, so pointing to the releases page is not useful, especially as it is not clear which releases were skipped. I usually wait until at least X.X.1 is released, which usually takes place less than a day after X.X.0.
The summary plus title of this review is already exactly what I intend to use for the commit message. I can repeat the title and put things into a pre-formatted block if this makes it easier to read.
Comment Actions
(...)
Test Plan:
Committer have the responsability of doing build tests on official releases and optionally but recomended, in current too.
Tier 1 archs should be tested.
You can upload poudriere testport logs to your freefall html space:
140amd64, 131amd64, 124{amd64,i386}
aarch64 when possible since not all hace access to this arch
here an example: https://reviews.freebsd.org/D30591
Comment Actions
How up to date is the ports tree supposed to be for these tests? I can perform all of them, though it'll take days for all dependencies (especially llvm) to build on my ARM64 setup. Usually I have a ports tree that is a few weeks out of date so I can immediately draw from already built dependencies.
Is it okay if I produce a bunch more changes and then bulk-test them all? This will save a significant amount of time.
Comment Actions
The point of uploading testport logs is to demonstrate that committer knows for sure that his update will build on most recent up to date ports tree.
Most important tests will be amd64 on official releases since it's widely used.
Less important is i386 on 12.x since it will be EOLed when that branch is over.
Optionaly test aarch64 when possible.
Regarding big dependencies, you can use poudriere-devel with -b latest|quarterly switch to download build deps packages.
You need to find the best way to that job with the machine that you have.
Some examples on how to speed builds will be like:
- use a script to build only big deps one at a time with full core support and depends on how much ram you have you can need some adjustments like:
etc/poudriere.conf: ALLOW_MAKE_JOBS_PACKAGES="llvm* gcc* qt6*"
etc/poudriere.d/make.conf:
.if ${.CURDIR:M*/devel/llvm13}
MAKE_JOBS_NUMBER=4
.endif
.if ${.CURDIR:M*/devel/llvm15}
MAKE_JOBS_NUMBER=2
.endif
.if ${.CURDIR:M*/lang/gcc12}
MAKE_JOBS_NUMBER=4
.endif- poudriere -b latest for main tree
- poudriere -b quarterly for 2023Qn tree (when testing cherry-picks from head)
Comment Actions
I understand. In this case, it will take a few days and I'll submit build logs for all my pending patches at once. Otherwise it's just going to take too long.
Regarding big dependencies, you can use poudriere-devel with -b latest|quarterly switch to download build deps packages.
I strongly prefer not doing that, but will consider it.
Comment Actions
(...)
In this specific update the only big dep is lang/go:
ALLOW_MAKE_JOBS_PACKAGES="go"
#list="lang/rust lang/go lang/gcc12 devel/llvm15 devel/llvm13"
list="lang/go"
for jail in 140amd64 131amd64 124amd64 124i386
do
for port in ${list}
do
doas poudriere bulk -b latest -j ${jail} -p main ${port}
done
doneComment Actions
"Tested with Poudriere on i386 amd64 FreeBSD 13.1."
You can start to upload those logs.
Comment Actions
>> Regarding big dependencies, you can use poudriere-devel with -b latest|quarterly switch to download build deps packages.
I strongly prefer not doing that, but will consider it.
It makes all the sense to prevent user to re-build again and again those big deps. Also, -b switch is being worked upstream for better results and some plans to build big deps like gcc and llvm on different tree are being discussed.
The point is that more and more ram is being needed and not every one are capable of buying "beefy" machines to do this job.
Comment Actions
some plans to build big deps like gcc and llvm on different tree are being discussed.
Looking forwards to that.
You can start to upload those logs.
The reason I want to do all builds at once is that I do not have an automated setup to upload logs and doing that manually from multiple machines is tedious work, so I would prefer to do all test runs in one go.
I'll go ahead and upload these anyway; will do so in a few hours.
Comment Actions
Just chiming in on this a bit late.
I never requested buildlogs from my mentees previously. I trust them to send diffs for stuff that was buildtested. However if Nuno likes to see those that will be our modus operandi. Shouldn't make a huge difference as you built those patches anyway and the logs are there. I think it might be enough to just post the links here, if the poudriere web server is reachable.
I do however think that it's good practice to build test with an up to date ports tree, otherwise I see the possibility to miss infrastructure work that changed in the meantime and the possibility that the committed patches may not build on the current ports tree.
I usually build all the diffs I commit from submitters on my own poudriere. I currently test on these releases/archs, but i have a very fast machine for pouriere. rust, llvm and others are still a PITA though. :)
JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
12amd64 12.4-RELEASE amd64 http 2023-02-02 22:33:33 /usr/local/poudriere/jails/12amd64
13amd64 13.1-RELEASE-p5 amd64 http 2023-02-02 22:33:45 /usr/local/poudriere/jails/13amd64
13i386 13.1-RELEASE-p5 i386 http 2023-02-02 22:13:44 /usr/local/poudriere/jails/13i386
head 14.0-CURRENT 1400078 ab926ba4c3 amd64 git 2023-02-02 22:55:35 /usr/local/poudriere/jails/head
Comment Actions
You can find the requested build logs here: http://fuz.su/~fuz/freebsd/goreleaser-1.15.2/
For the next few changes, I'll go ahead and submit them in bulk, making it significantly easier for me to upload the log files.
Comment Actions
ChangeLog and other user tags should not be mixed with official metadata fields:
category/port: Subject (additional steps) user metadata (ChangeLog, etc) metadata fields list (described in .hooks/prepare-commit-msg)
Remember to use "tabs" instead of "spaces":
<field> TAB <value>
PR: TAB TAB <value>
Aprroved by: TAB <value>
to achieve a good looking formatting
Comment Actions
(...)
And devel/goreleaser: update to 1.15.2 -> devel/goreleaser: Update to 1.15.2 looks better.
It's good to follow a commit style at the beginning as a closed/fixed one so we can have a fixed pattern on next commits.
With time and after released from mentorship, you will adquire your own style.
Comment Actions
I have checked the commit log and capitalisation after the colon seems to be a 50/50 sort of thing. I know it's a rule to do it this way in e.g. German, but it's a lot less common in English. Is there a policy on this?
As for tabs, I have of course used them in the commit message. However, you cannot enter tabs into the web UI, so I had to use spaces there. Will change the order as such:
devel/goreleaser: Update to 1.15.2 Changelog: https://github.com/goreleaser/goreleaser/releases/tag/v1.15.2 Changelog: https://github.com/goreleaser/goreleaser/releases/tag/v1.15.1 Changelog: https://github.com/goreleaser/goreleaser/releases/tag/v1.15.0 Approved by: eduardo, flo (mentors) Differential Revision: https://reviews.freebsd.org/D38434
Is this ok?
Comment Actions
Awesome! Beutifull commit msg.
Some tips that you already maybe know:
git showto show your last commit, git show <tag> same for other commit tag.
git --amend to do some later changes needed to be edited in latest commit msg.
git commitwhen youŕe the author
git commit --author="Name <e-mail>" from diff author
git rebase -i freebsd/main main that gives options to delete, change multiples commits that you working on
Also keep in mind that commit message lines do not exceed 72 columns (max 80) because bugzilla will ruin commit msg when preocessing PRs
So, for example, if
ChangeLog: TAB <url> is longer than 80 cols, IMO it better to use:
ChangeLog: <url>
Nice work!
Comment Actions
git commit --author="Name <e-mail>" from diff author
Yupp, have been doing a bunch of
git commit --amend --reset-author
the last hour to propagate my email address change to my pending patches. My usual workflow is that I branch a development branch off the main branch and hack on it. Every once in a while (about once a month) I synchronise this branch with the main branch. This is mainly because my RPi 4B development machine is slow and takes days to rebuild dependencies after a synchronisation. I'm going to switch to a Windows ARM dev kit in March, which will hopefully improve things.
As an additional step, I now build my changes in bulk for all tier 1 architectures before I send them over to you for approval. This will take a while, so I do it in bulk. I currently have about 10 patches pending this way.