- User Since
- May 22 2014, 10:41 AM (348 w, 6 d)
Mon, Jan 25
Nice work @loader!
Thu, Jan 14
Sun, Jan 3
In the absence of poudriere (one should set it up), you can run the set of commands outlined here:
Dec 28 2020
Dec 27 2020
For future reference sake: Ports compliance/recommendations require ports to 'unbundle' any bundled libraries (in this case slirp) except in cases where that is creates an unnecessary or inappropriate support or maintenance burden (such as go / node modules). We'll land this change in the short term until a slirp port can be produced
Also Question: do any of the other qemu-* ports need to have this change made too, or do they all inherit/child port off the main one (I haven't looked)
@adrian Can you confirm QA passes (portlint/poudriere, filling out TEST PLAN section) and add MFH: value <branch|no> <reason> in commit log message
Dec 4 2020
Nov 30 2020
- Add <reason> to MFH: line regardless of value
- Any reason for not renaming the port per the upstream rename, or is the product name still the same with only the repo name changing?
Nov 12 2020
Oct 12 2020
Sep 28 2020
Sep 22 2020
Sep 21 2020
Sep 20 2020
Sep 12 2020
Already accepted @loader nice work :)
Sep 8 2020
I'd include the motivating issue description in the commit log message:
Aug 30 2020
Aug 24 2020
Aug 14 2020
Aug 12 2020
Looks good Dan!
Aug 10 2020
Aug 9 2020
Aug 8 2020
Jul 31 2020
Jul 24 2020
@If you accept this review + maintainer-approval + the patch in bugzilla, @wulf is clear to self-assign and commit+merge with my ports approval (already added).
@imp I've approved (ports) the updated patch in the bugzilla issue
Is -werror now disabled /overridden in upstream sources?
Jul 23 2020
Jul 22 2020
bsd.options.desc.mk changes are not blocked by anyone, the file is explicitly available for anyone to commit to. update reviewers accordingly
@kevans is assisting me with my mentorship duties, to otherwise unblock this review/change, because I am super occupied for at least a week
MFH candidates are not 'explicitly' or only in the domain of the maintainer
Jul 14 2020
Jul 3 2020
Jun 29 2020
Jun 24 2020
How awesome are you, thank you so much :D
Missing MFH: <branch|No> <reason> and Approved by:
Jun 23 2020
Might there be ways to make this run-time tunable, or is it fundamentally not possible even in principle?
Jun 22 2020
Congratulations Kyle, you've been an excellent mentee (I'm not surprised) and its been my pleasure!
Thanks for this!
Jun 21 2020
Jun 16 2020
Jun 15 2020
Should separate out the maintainer such from the rest such that it can be MFH'd to quarterly so that MAINTAINER is consistent between branches