Created attachment 144848 [details] devel/tianocore-udk2010 UEFI Development Kit 2010 Ports of the UEFI Development Kit 2010 and 2014 and UEFI firmware images for QEMU.
Created attachment 144849 [details] devel/tianocore-udk2014 UEFI Development Kit 2014
Created attachment 144850 [details] emulators/tianocore-ovmf-ia32 OVMF image for UEFI firmware emulation with QEMU
Created attachment 144851 [details] emulators/tianocore-ovmf-x64 OVMF image for UEFI firmware emulation with QEMU
Note that the UDK2010 and UDK2014 ports do not (yet) support building DuetPkg. Further work and patching is required. Support on GNU/Linux for DuetPkg is limited anyway so I would not recommend delaying the ports' release for this.
Hmmm, I don't know why I moved this to patch-ready status without build test logs. It must have been before I started requiring them.
Plus, all the ports are submitted as application/gzip. Submitter, please resubmit with a shar, and include poudriere or redports build logs.
The ports are attached as gzipped shars; the UDK2010 and UDK2014 shars were rather large. I was following instructions from the handbook - https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/contrib-how.html#CONTRIB-GENERAL. Would you like me to reattach them without compression? I am happy to generate poudriere build logs and attach them. It appears that the current port submission procedures aren't yet documented in the porter's handbook. I would be happy to draft an update. Feel free to send me an email outlining what you would like.
(In reply to Ross McKelvie from comment #7) > The ports are attached as gzipped shars; the UDK2010 and UDK2014 shars were > rather large. I was following instructions from the handbook - > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/contrib- > how.html#CONTRIB-GENERAL. I apologize, that info is obsolete, the bugzilla limit is 1Mb per attachment. > Would you like me to reattach them without compression? Please do, 4 attaches, 4 shars would be nice > I am happy to generate poudriere build logs and attach them. > It appears that the current port submission procedures aren't yet documented > in the porter's handbook. I would be happy to draft an update. Feel free to > send me an email outlining what you would like. No, it's not documented. We just decided that we had so many PRs that we only wanted to deal with tested ones. Those that provide logs get bumped to the front of the line.
Tested the two -ovmf ones, the other ones need some more testing.
Created attachment 147431 [details] Updated devel/tianocore-udk2010 UEFI Development Kit 2010
Created attachment 147432 [details] Updated devel/tianocore-udk2014 UEFI Development Kit 2014
Created attachment 147433 [details] Updated emulators/tianocore-ovmf-ia32 OVMF image for UEFI firmware emulation with QEMU
Created attachment 147434 [details] Updated emulators/tianocore-ovmf-x64 OVMF image for UEFI firmware emulation with QEMU
Created attachment 147435 [details] Poudriere testport logs for devel/tianocore-udk2010
Created attachment 147436 [details] Poudriere testport logs for devel/tianocore-udk2014
Created attachment 147437 [details] Poudriere testport logs for emulators/tianocore-ovmf-ia32
Created attachment 147438 [details] Poudriere testport logs for emulators/tianocore-ovmf-x64
I have updated all submitted ports, enhancing (including writing some man pages), fixing and catering for changes in lang/gcc* and lang/python* ports. The UDK shar files exceeded the 1000k size limit and so I have compressed them with gzip. I hope this is acceptable. Poudriere testport logs for each port with default options are attached for all currently supported releases on amd64 and i386, except for 9.3 i386, on which ports-mgmt/pkg failed to build and testing could not be completed. The Portlint warnings relating to the UDK ports' options are expected due to the way I have used port options to modify and configuration file. Warnings of use of /usr/local in the OVMF ports relate only to pkg-message, which can't be dynamically modified. The OVMF ports are affected by bug 187315, where the native unzip utility fails with some zip archives. For these, I have implemented a work-around, requiring archivers/unzip for FreeBSD 10.0 and later. UDK2014 comes bundled with the source for OpenSSL 0.9.8w and it is included in UDK2010 as a default port option. I am mindful of the vulnerabilities in this bundled library. However, it is this (and only this) version of OpenSSL that is supported by the UDK releases and I was reluctant to unpick the integration only for the port to FreeBSD. The use of this library does not introduce vulnerabilities into FreeBSD systems with the ports installed, though could potentially result in vulnerabilities in UEFI applications compiled with the kit. I have added a security consideration note to the man pages. The sensible place for the current version of OpenSSL to be integrated with UDK is in the upstream project (the development version is EDKII, which I have not yet ported) . I'm happy to discuss any of the above in more detail.
(In reply to Ross McKelvie from comment #18) > I have updated all submitted ports Thanks, testing right now. It will take a while.
poudriere build logs for 10a, 91a, 84i available at https://people.freebsd.org/~pi/logs/tianocore-10a/ https://people.freebsd.org/~pi/logs/tianocore-91a/ https://people.freebsd.org/~pi/logs/tianocore-84i/ All looks fine.
Kurt, were you planning on assigning this PR to yourself given that you've already done a lot of work on it?
- reduced pkg-plist after @dirrm stuff is no longer needed - reduced pkg-plist with PORTDOCS=* in the Makefile Open issue: The 8.4i386 poudriere run for tianocore-udk2010 and -2014 finds this issue: ====>> Error: Files or directories left over: /readelf.core Any ideas ?
> /readelf.core Hmm. Do you know if this is from base system binutils' readelf, or from the binutils port?
(In reply to Ed Maste from comment #23) > > /readelf.core > > Hmm. Do you know if this is from base system binutils' readelf, or from the > binutils port? the poudriere logs are not showing this level of detail. binutils is being installed. see http://people.freebsd.org/~pi/logs/devel__tianocore-udk2010-84i-1412659371.txt http://people.freebsd.org/~pi/logs/devel__tianocore-udk2014-84i-1412632411.txt
(In reply to Kurt Jaeger from comment #24) > (In reply to Ed Maste from comment #23) > > > /readelf.core > > > > Hmm. Do you know if this is from base system binutils' readelf, or from the > > binutils port? > > the poudriere logs are not showing this level of detail. binutils is being > installed. arg. At least is says in the MAKE_ENV: READELF="/usr/local/bin/readelf" So it looks like the binutils readelf is used.
(In reply to Kurt Jaeger from comment #22) > - reduced pkg-plist after @dirrm stuff is no longer needed > - reduced pkg-plist with PORTDOCS=* in the Makefile Great! The packing list was really long. I wasn't aware of this functionality in the ports infrastructure. Will it also play well with the DOCS_CHM option, which can be selected independently of the DOCS option? Could you send me patches? > The 8.4i386 poudriere run for tianocore-udk2010 and -2014 finds this issue: > ====>> Error: Files or directories left over: > /readelf.core I haven't seen that in my poudriere runs. A core dump would also suggest that the build of the UDK base tools has failed somewhere but not caused the build to stop, which is a little worrying. Both UDK versions have a frustrating Makefile structure that calls (GNU) make recursively and it's possible a return code is being ignored somewhere. I couldn't see the /readelf.core line in the logs you posted in comment 20. Could you see other build errors? Taking a pragmatic view, how many developers will be building UEFI applications that are only really useful for 64-bit systems on a 32-bit version of an older version of FreeBSD?
(In reply to Ross McKelvie from comment #26) > (In reply to Kurt Jaeger from comment #22) > > - reduced pkg-plist after @dirrm stuff is no longer needed > > - reduced pkg-plist with PORTDOCS=* in the Makefile > Great! The packing list was really long. I wasn't aware of this > functionality in the ports infrastructure. The dir stuff was made obsolete at 20140922 or so. > Will it also play well with the > DOCS_CHM option, which can be selected independently of the DOCS option? > Could you send me patches? http://people.freebsd.org/~pi/misc/tiano.tgz has my current state of affairs. > > The 8.4i386 poudriere run for tianocore-udk2010 and -2014 finds this issue: > > ====>> Error: Files or directories left over: > > /readelf.core > I haven't seen that in my poudriere runs. Maybe this is because of DEVELOPER=yes in my /etc/make.conf ? > Taking a pragmatic view, how many developers will be building > UEFI applications that are only really useful for 64-bit systems on a 32-bit > version of an older version of FreeBSD? I agree, but somehow I picked quite a few PRs where stuff did not work on 8.4 and never failed to achieve a BROKEN that only triggers on that 8.4 8-( I'm still searching for a solution.
(In reply to Kurt Jaeger from comment #27) > (In reply to Ross McKelvie from comment #26) > > Taking a pragmatic view, how many developers will be building > > UEFI applications that are only really useful for 64-bit systems on a 32-bit > > version of an older version of FreeBSD? > > I agree, but somehow I picked quite a few PRs where stuff did not work > on 8.4 and never failed to achieve a BROKEN that only triggers on that 8.4 > 8-( > > I'm still searching for a solution. Why not just limit the port to ARCH == amd64? If it really is not useful on i386, don't even bother with that platform.
It is somewhat useful for i386, and we'll have a growing interest in UEFI on i386, but is certainly a lower priority.
Kurt, if it only breaks on 8.4 i386, then I suggest putting a check for OPSYS==FreeBSD and OSREL==8.4 and just setting IGNORE if those are true. If that's the only thing holding these up, that seems prudent to me. Somebody can submit a fix for 8.4 i386 later if it's really desired.
(In reply to John Marino from comment #30) > Kurt, if it only breaks on 8.4 i386, then I suggest putting a check for > OPSYS==FreeBSD and OSREL==8.4 and just setting IGNORE if those are true. > If that's the only thing holding these up, that seems prudent to me. > Somebody can submit a fix for 8.4 i386 later if it's really desired. and ARCH == i386 of course.
(In reply to John Marino from comment #31) > (In reply to John Marino from comment #30) > > Kurt, if it only breaks on 8.4 i386, then I suggest putting a check for > > OPSYS==FreeBSD and OSREL==8.4 and just setting IGNORE if those are true. I tried this: .if ${OPSYS} == "FreeBSD" && ${OSVERSION} < 900000 BROKEN= does not build on 8.x .endif and ran it in poudriere: http://people.freebsd.org/~pi/logs/devel__tianocore-udk2010-84i and it build and failed and did not trigger the BROKEN. I'm still trying to find the right syntax to really trigger the BROKEN or IGNORE.
it has to be below the ".include <bsd.port.options.mk>" or ".include <bsd.port.pre.mk>" lines, of course. If it is, it should work. Now your line will also prevent it from building on freebsd 8.4 amd64 too, is that what you want? You can do testing without building with something like "make -VIGNORE -VBROKEN OSVERSION=804000" and you should see the expected ignore values.
(In reply to John Marino from comment #33) > it has to be below the ".include <bsd.port.options.mk>" or ".include > <bsd.port.pre.mk>" lines, of course. See for yourself: http://people.freebsd.org/~pi/misc/tianocore-udk2010-Makefile > If it is, it should work. Now your > line will also prevent it from building on freebsd 8.4 amd64 too, is that > what you want? I will test it with poudriere and 8.4-amd64 and as far as I understand, readelf does dump core there as well. > You can do testing without building with something like "make -VIGNORE > -VBROKEN OSVERSION=804000" and you should see the expected ignore values. Ok, I'll investigate further.
is it possible your poudriere setup is reporting the wrong OSVERSION? You could put a pre-extract target like: pre-extract: @${ECHO} "This is ${OPSYS} version ${OSVERSION}" and look in the log to see what the makefile is seeing. It does look okay to me.
Actually, it's in the log already: Poudriere version: 3.1-pre Host OSVERSION: 1000510 Jail OSVERSION: 804000
as a side note, all those install commands with "@" masks have to be unmasked, except for the MKDIR command (which can be condensed into a single command instead of 5 separate invocations)
another side note: I see no legitimate reason to have MANPAGES options. Unless dependencies have to be pulled in to build man pages (which doesn't seem to be the case here) then man pages have to be unconditionally installed.
another side note: I see pre-install, do-install, and post-install targets which are run one after the other. Normally in the case that do-install is overridden, you would include the pre-install and post-install tasks with it. So they should all be combined to do-install, and no pre-install or post-install should be defined.
> > If it is, it should work. Now your > > line will also prevent it from building on freebsd 8.4 amd64 too, is that > > what you want? > > I will test it with poudriere and 8.4-amd64 and as far as I understand, > readelf does dump core there as well. Tested, yes, it also has it's readelf coredump at the end of the build.
(In reply to John Marino from comment #36) > Actually, it's in the log already: > > Poudriere version: 3.1-pre > Host OSVERSION: 1000510 > Jail OSVERSION: 804000 Testing shows that the readelf coredump happens in the /usr/ports/Mk/bsd.port.mk:lib-depends target. This ugly hack can cirumvent the poudriere fail, in the Makefile: # yes, it's an ugly hack .if ${OPSYS} == "FreeBSD" && ${OSVERSION} < 900000 PKGPREDEINSTALL?= ${PKGDIR}/pkg-84-hack .endif and the script: #!/bin/sh if [ -f /readelf.core ] then echo "removing /readelf.core in 84-hack" ls -l /readelf.core /bin/rm -f /readelf.core else echo "nothing to remove in 84-hack" fi I'll investigate whether I can catch ARGV from readelf.
i don't think you should be putting something in the makefile to clean up core files if they show up. Just break build on 8.4 and put in a comment whatever information you have about it.
(In reply to John Marino from comment #42) > i don't think you should be putting something in the makefile to clean up > core files if they show up. I agree, this is to debug the cause of the coredump. > Just break build on 8.4 and put in a comment whatever information you have > about it. Well, BROKEN inside the OPSYS comparision did not work, for whatever reason. IGNORE did not work, either. I have no idea why BROKEN etc is not working in that case. At least the pkg-*-hacks work 8-}
well, does make -V BROKEN -V IGNORE show anything? It did for me in my quick tests on other ports. It was setting these variables. The only explanation I can think of is something is hitting .unset BROKEN ! I've never seen a set BROKEN not work, and that's what I'd like to understand.
So a while ago I noticed some issues (37-39) that would require updates to the makefile to address (aside from the strange issue Kurt seems to have). Is anyone going to update the ports? I hesitate to help troubleshoot when these easy things are still outstanding. I'm also motivated because this PR shows up in my "interest" list, but I'm tired of seeing it there (it's been months, guys) and I can just de-CC myself to fix that.
I'm happy to make whatever changes are needed. This is my first set of ports so I've relied on the Porter's Handbook and portlint output to guide me. I don't want to step on Kurt's toes though; he has already started making changes relating to the GNU binutils core dump (which I've not successfully replicated).
I suggest for at least one port, Kurt adds his stuff, addresses my comments, uploads it, and then you can do the same for the remaining. I am slightly worried about Kurt's setup because the OPSYS / OSREL checks should just work and if they don't, there's a bigger issue. (e.g. don't hack it, figure out why something that should work doesn't)
(In reply to Kurt Jaeger from comment #43) > Well, BROKEN inside the OPSYS comparision did not work, for whatever > reason. IGNORE did not work, either. I have no idea why BROKEN etc > is not working in that case. At least the pkg-*-hacks work 8-} Now I found the reason why BROKEN did not work. poudriere testport sets TRYBROKEN=yes. So poudriere builds it even if it is marked BROKEN. Now I have to find a way to unset TRYBROKEN to test BROKEN...
(In reply to Kurt Jaeger from comment #48) > Now I have to find a way to unset TRYBROKEN to test BROKEN... By editing: /usr/local/share/poudriere/testport.sh the TRYBROKEN can be avoided. Tests running with all the ports. If those are sucessful, I'll commit the ports. The changes from comments 37-39 are already integrated.
I'm sorry for the long delay; life has gotten in the way. There are new versions of both UDK2010 and UDK2014 that have been released for which I will need to adjust the ports. Unfortunately, I'm not going to have time to do this until early April 2015.
(In reply to Ross McKelvie from comment #50) Any chance you'll be able to look at the new versions soon?
(In reply to Ed Maste from comment #51) I still have good intentions for this, including trying to push some of my FreeBSD patches upstream to encourage official support in EDK2. A combination of work and personal commitments have kept me from it until now. I expect to have a brief window of opportunity to spend some time on it in two weeks' time. However, if you're in a rush and thinking about taking on the task yourself I would be more than happy to talk you through what I've done so far.
(In reply to Ross McKelvie from comment #52) Thanks - as it happens I'm largely unavailable until July 22, and hopefully can help look into it then. I'm happy to help trying to push changes upstream.
Excellent! I was actually looking for the OVMF port. One question: do we need to make them depend on QEMU? I'd like to use them with the Xen port, which bundles Qemu already.
We might want to make sure we're using UDK2014.SP1 instead of the original UDK2014? And also consider including UDK2015 since it has now been released too.
Any advance here?
Too much time passed and too many changes happened, this is unfortunatly no longer relevant. But the question is: What would be a suitable replacement ?
https://github.com/tianocore/tianocore.github.io/wiki/UDK2017 is the most recent version.
and there's the https://github.com/tianocore/tianocore.github.io/wiki/UDK2017-How-to-Build
Apologies, all, this totally fell off my radar. If someone in the future wishes to port the latest UDK versions I'd be happy to talk them through the work I did back in 2014.