Bug 182209
| Summary: | [new port] emulators/hyperv-ic: Ports containing Hyper-V integration components for FreeBSD | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | BSD Integration Components for Hyper-V <bsdic> |
| Component: | Individual Port(s) | Assignee: | John Marino <marino> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | kyliel, marino, timp87 |
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| Attachments: | |||
|
Description
BSD Integration Components for Hyper-V
2013-09-18 18:40:00 UTC
State Changed From-To: open->feedback Fix synosis. Note to submitter: I have substituted 'misc' as the category. 'kld' is a virtual category and cannot be used for a primary category (e.g. there is no ports/kld/ directory.) Is there another physical category you think might be better? Hi, Please change the category from "misc" to "emulators". Do let us know if there is anything else that needs to be done. Thanks, Sainath. From: Abhishek Gupta (LIS) Sent: 01 October 2013 02:40 To: Aryeh Friedman; linimon@freebsd.org<mailto:linimon@freebsd.org> Cc: BSD Integration Components for Hyper-V; freebsd-ports-bugs@freebsd.org<mailto:freebsd-ports-bugs@freebsd.org> Subject: RE: ports/182209: [new port] misc/hyperv-ic: Ports containing Hyper-V integration components for FreeBSD Hi, Apologies for the mistake. Ideally I like Aryeh's suggestion of creating a category for virtualization integration components. However given that it would require a lot more work, I believe emulators is the right category. Please change from misc to emulators. Thanks, Abhishek From: Aryeh Friedman [mailto:aryeh.friedman@gmail.com] Sent: Sunday, September 29, 2013 5:09 PM To: linimon@freebsd.org<mailto:linimon@freebsd.org> Cc: BSD Integration Components for Hyper-V; freebsd-ports-bugs@freebsd.org<mailto:freebsd-ports-bugs@freebsd.org> Subject: Re: ports/182209: [new port] misc/hyperv-ic: Ports containing Hyper-V integration components for FreeBSD General question on the category: There are a significant number of virtualization ports in emulators. Emulators seems to be more about emulating hardware that is not present instead of virtualizing the existing hardware. Given that why not create a category for virtualization? On Sun, Sep 29, 2013 at 7:16 PM, <linimon@freebsd.org<mailto:linimon@freebsd.org>> wrote: Old Synopsis: Ports containing Hyper-V integration components for FreeBSD New Synopsis: [new port] misc/hyperv-ic: Ports containing Hyper-V integration components for FreeBSD State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Sun Sep 29 23:15:12 UTC 2013 State-Changed-Why: Fix synosis. Note to submitter: I have substituted 'misc' as the category. 'kld' is a virtual category and cannot be used for a primary category (e.g. there is no ports/kld/ directory.) Is there another physical category you think might be better? http://www.freebsd.org/cgi/query-pr.cgi?pr=182209 _______________________________________________ freebsd-ports-bugs@freebsd.org<mailto:freebsd-ports-bugs@freebsd.org> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports-bugs To unsubscribe, send any mail to "freebsd-ports-bugs-unsubscribe@freebsd.org<mailto:freebsd-ports-bugs-unsubscribe@freebsd.org>" State Changed From-To: feedback->open feedback received. Hi FreeBSD Team, Any update on the hyperv-ic port progress please let us know. Thanks, Sainath. Hi, if you are still interested in having this port in FreeBSD, it may (or may not) need to be reworked to support stage, and it may need updating to other newer conventions such as "USES" which is expanding all time. For staging, see http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-May/000080.html Additionally, you need to provide some sort of quality assurance. In order of preference, we are looking for: 1) "poudriere testport" or "poudriere bulk -t" logs 2) Redports or tinderbox logs 3) at least this: https://www.freebsd.org/doc/en/books/porters-handbook/porting-testing.html Please provide an updated shar file and attach a test log. Alternatively, please indicate if you are no longer interested in having this software in the Ports Collection and that we can close the PR. Thanks! Hi John, We definitely have interest in having this port in FreeBSD. Thanks for guidance. I will follow up. Stay tuned. Thanks, Kylie Try to get something in before 30 september because there's going to be a mass-closing of all dormant new port PRs. This isn't dormant but don't risk getting caught in the sweep! Yes. We will submit ports of 9.1 and 9.2 this week. And then we will work on 8.4 and 9.3, and try to submit them before 9/30. Thanks for reminder. Created attachment 146366 [details]
shar file for Hyper-v Integration Service on FreeBSD 9.1
Created attachment 146367 [details]
shar file for Hyper-v Integration Service on FreeBSD 9.2
Created attachment 146369 [details]
test log for FreeBSD 9.1 64 bit
Created attachment 146370 [details]
test log for FreeBSD 9.1 32 bit
Created attachment 146371 [details]
test log for FreeBSD 9.2 64 bit
Created attachment 146372 [details]
test log for FreeBSd 9.2 32 bit
Additional steps to use poudriere:
• fstab issue:
Follow the steps of change fstab to the new format that hyper-v requests. Then reboot
cp /etc/fstab ${poudrieredir}/jails/xxx/etc/fstab
• Use poudriere on FreeBSD9.1
1. FreeBSD9.1 just supports poudriere 2.x version which must uses zpool as the rootfs.
2. Mount a disk less than 30GB disk
3. Create a zpool by typing 'zpool create myzpool /dev/${zpooldisk}(you new disk's name)
4. Check if it's successful by typing 'df'
5. Configure the poudriere.conf in /usr/local/etc/poudriere.conf where the 'zpool' shows.
• Poudriere does not support "make stage"
1. Should add "NO_STAGE="YES"" in poudriere/ports/default/emulators/hyperv-is/Makefile
Because poudriere can't create package in packages/All
this isn't patch-ready. There's one shar per FreeBSD release. Ports doesn't support that. We need to discuss these multiple shars - there can be only one, so the shar has to handle each release (e.g. it handles 4 cases instead of 1 shar per case) Hi John, Thanks for feedback. Yes, currently we used one shar file for FreeBSD 9.1 and the other shar file for FreeBSD 9.2. To avoid confusion, you see 4 test logs because we tested both 32 bit and 64 bits for each FreeBSD release. So we will generate "ONE" shar file for FreeBSD 9.1 and 9.2 and upload it. In future, if we get ports for FreeBSD 8.4, 9.3 and 10 ready, we will update shar file. Is that right approach? Thank you. Thanks, Kylie If the port already exists in the future, then you update it with a compound patch. A shar is only used when the port doesn't already exist. Created attachment 147366 [details]
shar file for ports of FreeBSD 8.4, 9.1, 9.2, 9.3 and 10.0
Mark share file and test logs submitted before as obsoletes.
Attach share file for Hyper-v Integration Service Ports of FreeBSD 8.4, 9.1, 9.2, 9.3 and 10.0.
Created attachment 147367 [details]
Test log for ports of FreeBSD 8.4, 9.1, 9.2, 9.3 and 10.0 (64 bit).
Created attachment 147368 [details]
Test log for ports of FreeBSD 8.4, 9.1, 9.2, 9.3 and 10.0 (32 bit).
Hi John, Resubmit shar file for Hyper-v Integration Service ports of FreeBSD 8.4, 9,1, 9.2, 9.3 and 10.0 with test logs. Could you please have a review? If any question for upstream, please let me know. Thank you. Thanks, Kylie Liang I'm sorry, but what about 10.1? (In reply to timp87 from comment #23) > I'm sorry, but what about 10.1? Thanks for asking. As I got, FreeBSD 10.1 is in Beta phase and will be released next month. From FreeBSD 10, all Hyper-v integration service drivers/daemons are built-in except KVP. Now we got KVP upstreamed to head. But we don't have enough time to upstream them to FreeBSD 10 branch to catch upcoming 10.x releases. Then once 10.1 is released, we could see whether we will provide ports for 10.1 per customer request. http://svnweb.freebsd.org/base/head/contrib/hyperv/tools/ http://svnweb.freebsd.org/base/head/sys/dev/hyperv/utilities/ Hmmm, there are a number of questions I have: XPORTNAME= hyperv-ic XPORTVERSION= 1.0 XCATEGORIES= kld XMASTER_SITES= https://github.com/FreeBSDonHyper-V/Hyperv-Ports/raw/packages/hyperv-ic/ X XMAINTAINER= bsdic@microsoft.com XCOMMENT= Hyper-V Integration Components X XFETCH_ARGS= -Fpr ^^^^ What is the purpose of redefining FETCH_ARGS? I suspect this is unneed XCC?=clang XCXX?=clang++ XCPP?=clang-cpp ^^^^ This looks very suspicious. For one, it won't work on FreeBSD 9 and below Secondly, you probably should be using "USES+=compiler:<option>" (see Mk/Uses/compiler.mk for details). Is clang truely required and GCC absolutely cannot be used? XONLY_FOR_ARCHS= amd64 i386 X X.include <bsd.port.pre.mk> X X.if ${OSVERSION} != 901000 XBROKEN= Only for FreeBSD 9.1 Release X.endif ^^^^ Am I looking at the wrong shar? This is limited to FreeBSD 9.1 (And I kind of doubt the OSVERSION for 9.1 is exactly 901000 too) Xpre-install: X @PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL remove "@" X Xpost-install: X @PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL X remove "@" Xpost-deinstall: X @PKG_PREFIX=${PREFIX} ${SH} ${PKGDEINSTALL} ${PKGNAME} POST-DEINSTALL remove this completely -- it's not necessary anymore (it's don't automatically) (In reply to John Marino from comment #25) > Xpre-install: > X @PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL > > remove "@" > > X > Xpost-install: > X @PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL > X > > remove "@" > > > Xpost-deinstall: > X @PKG_PREFIX=${PREFIX} ${SH} ${PKGDEINSTALL} ${PKGNAME} POST-DEINSTALL > > remove this completely -- it's not necessary anymore (it's don't > automatically) I misspoke. Remove all 3 of these targets. All are handled automatically now. Thank you for feedbacks. New shar file is "shar file for ports of FreeBSD 8.4, 9.1, 9.2, 9.3 and 10.0". There is no below line.
X.if ${OSVERSION} != 901000
XBROKEN= Only for FreeBSD 9.1 Release
I will follow up other 3 feedbacks. Could you please review new share file to see any other feedback? Thank you.
This is the type of confusion that occurs when you leave an old shar visible instead of moving it to obsolete. I looked at the wrong file. And the correct file had such a long title that it looks similar to the test log files. additional comments then:
XFILE_84= ${PORTNAME}-8.4.${PORTVERSION}${EXTRACT_SUFX}
Don't use ${PORTNAME}, use hardcoded text. If I change the PORTNAME, the port breaks unnecessarily. (People commonly use ${PORTNAME} when any value of ${PORTNAME} other than the current value is outright wrong, and I don't understand why. I guess it's a pet peeve with me at this point)
Also, in your validity check, check ${OPSYS} == FreeBSD. If it does not, IGNORE should be set.
(In reply to John Marino from comment #28) > This is the type of confusion that occurs when you leave an old shar visible > instead of moving it to obsolete. I looked at the wrong file. And the > correct file had such a long title that it looks similar to the test log > files. Apologize. The first file was not uploaded by me. I could not mark it as obsolete. Sorry for confusion. Created attachment 147463 [details]
shar file
Submit new shar file to address 3 feedbacks.
(In reply to John Marino from comment #25) > Hmmm, there are a number of questions I have: > > > XPORTNAME= hyperv-ic > XPORTVERSION= 1.0 > XCATEGORIES= kld > XMASTER_SITES= > https://github.com/FreeBSDonHyper-V/Hyperv-Ports/raw/packages/hyperv-ic/ > X > XMAINTAINER= bsdic@microsoft.com > XCOMMENT= Hyper-V Integration Components > X > XFETCH_ARGS= -Fpr > > > ^^^^ > What is the purpose of redefining FETCH_ARGS? I suspect this is unneed If we use default FETCH_ARGS, sometimes fetch will fail in our test environment. From this discussion http://lists.freebsd.org/pipermail/freebsd-ports/2013-December/088717.html, it seems default value for FETCH_ARGS is "-AFpr" and "-A" is to limit fetch redirection. Then could we redefine it to ensure fetch operation successfully? Thanks. > > XCC?=clang > XCXX?=clang++ > XCPP?=clang-cpp > > > ^^^^ > This looks very suspicious. > For one, it won't work on FreeBSD 9 and below > Secondly, you probably should be using "USES+=compiler:<option>" (see > Mk/Uses/compiler.mk for details). > Is clang truely required and GCC absolutely cannot be used? > CLANG works for our FreeBSD 9.x and 8.x ports. However if we change compiler to GCC, our KVP daemon ports on FreeBSD10 will have some issue which we need to investigate. From this wiki https://wiki.freebsd.org/PortsAndClang, it seems Clang is default compiler on FreeBSD 10. Could we keep CLANG as compiler since functions on 10, 9.x and 8.4 are verified successfully. > > XONLY_FOR_ARCHS= amd64 i386 > X > X.include <bsd.port.pre.mk> > X > X.if ${OSVERSION} != 901000 > XBROKEN= Only for FreeBSD 9.1 Release > X.endif > > ^^^^ > Am I looking at the wrong shar? This is limited to FreeBSD 9.1 (And I kind > of doubt the OSVERSION for 9.1 is exactly 901000 too) > > > > Xpre-install: > X @PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL > > remove "@" > > X > Xpost-install: > X @PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL > X > > remove "@" > > > Xpost-deinstall: > X @PKG_PREFIX=${PREFIX} ${SH} ${PKGDEINSTALL} ${PKGNAME} POST-DEINSTALL > > remove this completely -- it's not necessary anymore (it's don't > automatically) I just uploaded "shar file" which adopted these feedbacks. Thanks for valuable feedbacks again. Okay, let's go through this methodically then: X# $FreeBSD$ XUSES+=uidfix Why is this on line #2? This is normally much lower in the makefile XPORTNAME= hyperv-is XPORTVERSION= 1.1 XCATEGORIES= kld XMASTER_SITES= https://github.com/FreeBSDonHyper-V/Hyperv-Ports/raw/hyperv-is-master/BIS-${PORTVERSION}/FreeBSD-${OSREL}/ports/ XMAINTAINER= bsdic@microsoft.com XCOMMENT= FreeBSD Integration Service on Hyper-v X XONLY_FOR_ARCHS= amd64 i386 X.include <bsd.port.pre.mk> XFILE_84= hyperv-is-8.4.${PORTVERSION}${EXTRACT_SUFX} XFILE_91= hyperv-is-9.1.${PORTVERSION}${EXTRACT_SUFX} XFILE_92= hyperv-is-9.2.${PORTVERSION}${EXTRACT_SUFX} XFILE_93= hyperv-is-9.3.${PORTVERSION}${EXTRACT_SUFX} XFILE_100= hv-kvp-${PORTVERSION}${EXTRACT_SUFX} XFETCH_ARGS+= -Fpr The FETCH_ARGS line didn't change. This is the default value, so this line has no reason to exist. XCC=clang XCXX=clang++ XCPP=clang-cpp So this wasn't addressed either. How is this even working on FreeBSD 8.4 that doesn't have clang? Did you look into USES+= compiler:<option> as I suggested? If nothing else, explain why you are overriding CC/CXX/CPP... Xpost-extract: X @${MKDIR} ${STAGEDIR}/boot X @${MKDIR} ${STAGEDIR}/boot/kernel X @${MKDIR} ${STAGEDIR}/etc/ && ${MKDIR} ${STAGEDIR}/etc/rc.d X @${MKDIR} ${STAGEDIR}/usr/share && ${MKDIR} ${STAGEDIR}/usr/share/man X @${MKDIR} ${STAGEDIR}/usr/share/man/man1 && ${MKDIR} ${STAGEDIR}/usr/share/man/man4 && ${MKDIR} ${STAGEDIR}/usr/share/man/man8 X @${MKDIR} ${STAGEDIR}/usr/local/hyperv && ${MKDIR} ${STAGEDIR}/usr/local/hyperv/scripts X @${MKDIR} ${STAGEDIR}/usr/sbin X.if exists(/boot/loader.conf) X @${CP} /boot/loader.conf ${STAGEDIR}/boot/loader.conf.bak X.else This line violates filesystem checks. A port is not supposed to touch /boot X @${TOUCH} ${STAGEDIR}/boot/loader.conf.bak Here as well X.endif X.if exists(/etc/rc.conf) X @${CP} /etc/rc.conf ${STAGEDIR}/etc/rc.conf.bak ditto. This is also not normal. sysadmins are suppose to hand-edit rc.conf The post-(de)install scripts are also touching these files. This needs to be justified and frankly I need to get more opinions on what this port is trying to do to system conf files. (In reply to Kylie from comment #32) cross-posted > > What is the purpose of redefining FETCH_ARGS? I suspect this is unneed > If we use default FETCH_ARGS, sometimes fetch will fail in our test > environment. From this discussion > http://lists.freebsd.org/pipermail/freebsd-ports/2013-December/088717.html, > it seems default value for FETCH_ARGS is "-AFpr" and "-A" is to limit fetch > redirection. Then could we redefine it to ensure fetch operation > successfully? Thanks. No, "FETCH_ARGS" is defined as "-Fpr". Your information is obsolete. > CLANG works for our FreeBSD 9.x and 8.x ports. However if we change compiler > to GCC, our KVP daemon ports on FreeBSD10 will have some issue which we need > to investigate. Where is clang coming from on FreeBSD 8? You didn't specify it as a dependency. > From this wiki https://wiki.freebsd.org/PortsAndClang, it seems Clang is > default compiler on FreeBSD 10. > Could we keep CLANG as compiler since functions on 10, 9.x and 8.4 are > verified successfully. Hardcoding clang is frowned upon. USES+= compiler: is the proper way. Created attachment 147681 [details]
hyperv.shar
Per feedbacks, update shar file.
Thank you John for valuable feedbacks. We addressed your feedbacks about "FETCH" arg, compiler and touch. Could you please have a review? Thank you very much. it looks good with a quick glance ; I'll take it. Okay, I'm going to paste a running log of issues I see and am fixing on the spot.
First: ${MKDIR} equates to "mkdir -p", so you only need to specify the lowest level directory and all the others above it will be created automatically. Secondly, you'd create STAGEDIR directories at pre-install target, not post-extract.
The pkg-descr is not appropriate. It appears to be a copy of the man page. It's supposed to be a synopsis, usually < 10 lines, definitely less than 24 lines. It was my fault to not ask for "portlint" check because portlint would have told you. There are lot of other issues portlint is catching now, like whitespace at the end of lines. I don't think this redefinition of PORTNAME and PORTVERSION on FreeBSD 10.0 is kosher. The best I can do is change the PKGNAME suffix but I don't understand the purpose of having a completely different PORTNAME based on OSREL is ... Maybe to adjust the MASTER_SITES? at least the portversion... This "do-patch" target is horribly wrong. It's changing the ports tree itself!!! e.g. touch $PATCHDIR/havepatched That adds a file to the ports tree -- completely illegal. I don't even want to mention patching the ports tree. What were you planning that would happen on the 2nd run after the ports tree had been permanently changed? of course it would fail when you try to patch it again. I am going to fix this a better, more maintainable way. For the record, never, never, never generate non-unified patches. (e.g. use "diff -u", not plain "diff") I had to make some updates to pkg-install script. 1) check existence of /etc/fstab before trying to use it 2) exit 1 instead of exit -1 which is illegal. A commit references this bug: Author: marino Date: Mon Oct 6 22:58:52 UTC 2014 New revision: 370242 URL: https://svnweb.freebsd.org/changeset/ports/370242 Log: Add new port emulators/hyperv-is (FreeBSD 8.4, 9.1, 9.2, 9.3, 10.0) PR: 182209 Submitted by: kylie (bsdic @ microsoft) The hyperv-is provision a collection of kernel mode drivers as well as user-space daemons to facilitate integration with Hyper-v to provide a feature rich and high performance FreeBSD guest experience. The FreeBSD Integration Service on Hyper-v includes a collection of kernel mode drivers as well as user-space daemons to interact with the drivers that are required to run Hyper-V-specific devices known as FreeBSD Integration Services (BIS). It is to facilitate integration with Hyper-v to provide a feature rich and high performance FreeBSD guest experience. See the man page for a list of binaries and their functions. FreeBSD support for hyperv-is was first added by Microsoft BSD Integration Services Team <bsdic@microsoft.com>. Changes: head/emulators/Makefile head/emulators/hyperv-is/ head/emulators/hyperv-is/Makefile head/emulators/hyperv-is/distinfo head/emulators/hyperv-is/files/ head/emulators/hyperv-is/files/pkg-message.A.in head/emulators/hyperv-is/files/pkg-message.B.in head/emulators/hyperv-is/pkg-descr head/emulators/hyperv-is/pkg-install head/emulators/hyperv-is/pkg-plist Okay, as you can infer, I made lots of changes but hopefully you will agree it simplifies the port and makes it easier to maintain. You might want to review the pkg-descr. I notice you tried to have a different pkg-descr depending on the OSREL, but you need just to have one to cover all releases. poudriere is happy other than the fact the PRE-INSTALL check fails but I guess that's to be expected. Thanks for persevering for over a year! Thanks John very much to update and upstream them. Sorry for late response due to holiday. Thanks again. When you get back, you should also review the changes since documented at http://www.freshports.org/emulators/hyperv-is/ We had to patch to support PREFIX != /usr/local and other stuff. So the current version even looks a bit different from my initial commit. |
