Ok, please open reviews for both of go and go-devel, we should commit the vuxml and both ports together, not mandatory, but nice to do.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 26 2019
Will we update go and go-devel ports? Do you need to sync anything with @jlaffaye?
Sep 25 2019
Sep 24 2019
Is it worth do an exp-run on this one too?
LGTM, same thing as the other reviews, wait for the exp-run and also for the portmgr approval.
LGTM, same thing, wait for the exp-run and portmgr approval.
It looks good to me, but you need to wait for the exp-run and also portmgr approval.
Thanks to work on this.
Sep 23 2019
This is cool, I didn't know it would be possible set version via ldflags.
In D21730#475087, @dmgk wrote:In D21730#474823, @tobik wrote:IIUC this potentially changes all Go binaries, so all USES=go ports that do not set ldflags themselves probably need a PORTREVISION bump afterwards to relink them?
A quick search
for f in $(find /usr/ports -name Makefile | xargs grep -l 'USES=.*\bgo\b'); do grep -q '\bldflags\b' $f || echo $f; done | wc -lshows that it would require bumping PORTREVISION of 198 ports. Recompiling will make binaries about 25% smaller on average but there are no other functional changes. I can prepare a separate review if we're OK with this.
Sep 22 2019
Sep 20 2019
In D21721#474028, @dmgk wrote:In D21721#473929, @araujo wrote:As you are working on this already for a while, how about ports that you are not a maintainer? Maybe an exp-run following with a portmgr@ approval would be interesting to clean up the rest of the ports.
That was my plan actually, I was just not sure what would be the best way to get something like that reviewed/committed. The complete diff is about 250KB, I was thinking about maybe breaking it to 3-4 parts for easier review. Would that make sense or it would be better to post it in a single review?
In D21721#473887, @dmgk wrote:In D21721#473870, @tz wrote:Since i am very unfamiliar with the go ports, i have problems to understand this diff.
In devel/awless only do-build and do-install is removed, but i do not see any usage of GO_TARGET. Same for some other ports.r505321 converted all ports to USES=go which already provides do-build and do-install targets. During that conversion, ports that were defining their own build/install targets were left alone to be cleaned up later. This commit does this cleanup for the ports that I maintain.
Sep 19 2019
You should do two commits for this review, first commit security/botan2 and then commit the BUMP for the other ports that depends of security/botan2.
Sep 18 2019
Sep 17 2019
Sep 16 2019
Sep 11 2019
It builds fine at my side with poudriere: build of sysutils/uefi-edk2-qemu | uefi-edk2-qemu-x86_64-g20190307_1 ended at Wed Sep 11 09:26:10 CST 2019
Sep 10 2019
In D21580#470256, @bcran wrote:In D21580#470252, @araujo wrote:You have my approve to commit it! Thank you!
Committed. But I just realized, should I also bump PORTREVISION?
In D21580#470251, @bcran wrote:In D21580#470248, @araujo wrote:USE_GCC will set build-time and run-time dependency, if we need only build-time dependency the patch looks good to me.
Thanks! Since I'm not a ports committer, could you commit the change please?
USE_GCC will set build-time and run-time dependency, if we need only build-time dependency the patch looks good to me.
Sep 9 2019
Sep 2 2019
Aug 28 2019
Aug 27 2019
Aug 2 2019
In D21053#459032, @markj wrote:In D21053#458959, @jhb wrote:I worry this might be a bit premature. New features for bhyve are often developed without capsicum because capsicum is a pain to work with. The debug server didn't use it at first, save/restore currently disables it as does the 9p patch. Removing WITHOUT_CAPSICUM makes coordinating that existing work harder. It also adds a pretty good barrier to entry when trying to add new things that add new ioctls, etc.
It's not much more work to add a new right in a driver that already works under capsicum than it is to add -DWITHOUT_CAPSICUM to the build flags.
Aug 1 2019
In D19400#458961, @rob.fx907_gmail.com wrote:@araujo, sounds like you are taking over this review?
In D19400#458949, @jhb wrote:I wonder if it makes more sense to do this in vmrun.sh? OTOH, it's probably fine to do this. We should also probably do it in bhyverun.c since bhyveload isn't used in the UEFI case. Another option would be to do this in the vm_create() wrapper in libvmmapi in which case that would fix bhyveload, grub2-bhyve, and bhyve all in one place.
Jul 30 2019
Committed already at r349335
I'm commandeer this revision because this patch were committed already by @scottl: https://svnweb.freebsd.org/base?view=revision&sortby=date&revision=349335
@jhb Perhaps do the same with bhyverun.c?
Jul 28 2019
Ok, I'm gonna do it tomorrow!!!
Jul 25 2019
Jul 24 2019
@jhb Any objection if I proceed to commit this patch? I just hit the same situation "forgot to load vmm" and this patch does fix it.
ping!!!
In D21053#456794, @oshogbo wrote:The problem here is that you will not be able to build this code on other platforms like Solaris.
I'm not sure if this is applicaple for bhyve, if not then the change looks good to me.
Remove CASPER from Makefile as we don't use any service.
Jul 16 2019
Lgtm!
Jul 3 2019
Jun 25 2019
Jun 22 2019
Jun 17 2019
May 23 2019
Apr 28 2019
Apr 24 2019
LGTM! Thank you!
Apr 19 2019
double accept this revision!
Apr 15 2019
Any news about this patch?
I'm fine with that too! We can have it as it is and later evolve it.
Apr 14 2019
- Also remove SHEBANGFIX not needed.
- Update ONLY_FOR_ARCHS that was replaced wrong.
Address @bcran suggestions!
Apr 10 2019
I did only smoke tests!! Do you mind do additional tests with different guests?
In D19869#426696, @bcran wrote:
- Rename the port and files to include a -x86_64 suffix
Apr 3 2019
It looks good! Thanks again @chuck
Mar 26 2019
In D19042#422183, @jhixson wrote:Sooooooooo. Is anybody going to help me fix this or approve this? ;-) I am still waiting.