Closed Bug 1024140 Opened 10 years ago Closed 10 years ago

Do open264 builds

Categories

(Release Engineering :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: catlee, Assigned: Callek)

References

(Blocks 1 open bug)

Details

(Whiteboard: [rollup status in c#18] [known next-steps in c#19])

Attachments

(1 file)

We need some kind of automation around doing openh264 builds. First pass of this should be a set of mozharness scripts/configs to generate the builds. If required, we can hook this up into CI (task cluster perhaps). Repo is here: https://github.com/cisco/openh264 We'll need win32, osx, linux32, linux64 to start with. win64 is nice bonus. android and b2g are likely to be required at some point as well.
Per mtg with coop, taking this bug. Unclear of requirements/steps atm, so I'll start by gathering those and dumping state here as I go.
Assignee: nobody → bugspam.Callek
Hi Chris, We now have the GMP plugin build landed on github.com/cisco/openh264. Here's how to build: For Linux and OSX 32bit - 'make ENABLE64BIT=No plugin' 64bit - 'make ENABLE64BIT=Yes plugin' By default these will make release builds. Adding 'BUILDTYPE=Debug' will make debug builds. The output of this will be libgmpopenh264.so/dylib. This combined with the gmpopenh264.info file is what we will be distributing as the GMP plugin. They will need to end up in a directory named gmp-gmpopenh264 in the interenet plugins directory which is '/usr/lib/mozilla/plugins' on Linux and '~/Libarary/Internet Plug-Ins' on OSX. For Windows there is build info in the README. It is essentially the deveoper shell with msys. I'm assuming we will want to build with msvc instead of gcc so the command would be: 'make OS=msvc plugin' Its output is gmpopenh264.dll and where it goes on disk involves the registry. The code that looks for it can be found in the moz source here - http://mxr.mozilla.org/mozilla-central/source/content/media/gmp/GMPService.cpp#324
Ok, so had a chat with catlee, for some additional info: He wrote a quick mozharness script to test this with: http://hg.mozilla.org/users/catlee_mozilla.com/mozharness/file/4554900be7d1/scripts/openh264_build.py Which mostly just worked "on his laptop". Linux builds need (at least): nasm, gtest, svn Mac is one of the preferred starting platforms for exploratory testing (although all of mac, windows, linux are important) There is no requirement on us to provide installer/update mechanics with the openh264 pieces itself (all of that will be part of Firefox) We will not be hosting these files for our users, cisco will. However they do not need to be private and can be on ftp, or s3, etc. I theorized that windows might be slightly problematic with regard to which MSVC version we choose (I expected that we'd need the same MSVC version as the Firefox version we ship, unless we want to additionally ship extra MSVC runtime dll's. Catlee is not so sure, but at a first-go its not necessarily the most important piece to find out) Desire to have this built and fully tested by end of week, preferably "yesterday"
I'm testing mac builds ~now with the loaner I stole in Bug 1036254
Depends on: 1036254
Touchpoint, with default mozharness script as catlee provided: 22:07:59 INFO - nasm -DUNIX64 -DPREFIX -f macho64 -Icodec/common/x86/ -o codec/encoder/core/x86/coeff.o codec/encoder/core /x86/coeff.asm 22:07:59 INFO - nasm: fatal: unrecognised output format `macho64' - use -hf for a list 22:07:59 INFO - type `nasm -h' for help 22:07:59 INFO - make: *** [codec/encoder/core/x86/coeff.o] Error 1 22:07:59 ERROR - Return code: 2 22:07:59 FATAL - couldn't build plugin 22:07:59 FATAL - Running post_fatal callback... 22:07:59 FATAL - Exiting -1 [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com openh264]$ nasm -hf usage: nasm [-@ response file] [-o outfile] [-f format] [-l listfile] [options...] [--] filename or nasm -r for version info (obsolete) or nasm -v for version info (preferred) -t assemble in SciTech TASM compatible mode -g generate debug information in selected format. -e preprocess only (writes output to stdout by default) -a don't preprocess (assemble only) -M generate Makefile dependencies on stdout -E<file> redirect error messages to file -s redirect error messages to stdout -F format select a debugging format -I<path> adds a pathname to the include file path -O<digit> optimize branch offsets (-O0 disables, default) -P<file> pre-includes a file -D<macro>[=<value>] pre-defines a macro -U<macro> undefines a macro -X<format> specifies error reporting format (gnu or vc) -w+foo enables warnings about foo; -w-foo disables them where foo can be: macro-params macro calls with wrong no. of params (default off) macro-selfref cyclic macro self-references (default off) orphan-labels labels alone on lines without trailing `:' (default off) number-overflow numeric constants greater than 0xFFFFFFFF (default on) gnu-elf-extensions using 8- or 16-bit relocation in ELF, a GNU extension (default off) response files should contain command line parameters, one per line. valid output formats for -f are (`*' denotes default): * bin flat-form binary files (e.g. DOS .COM, .SYS) aout Linux a.out object files aoutb NetBSD/FreeBSD a.out object files coff COFF (i386) object files (e.g. DJGPP for DOS) elf ELF32 (i386) object files (e.g. Linux) as86 Linux as86 (bin86 version 0.3) object files obj MS-DOS 16-bit/32-bit OMF object files win32 Microsoft Win32 (i386) object files rdf Relocatable Dynamic Object File Format v2.0 ieee IEEE-695 (LADsoft variant) object file format macho NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X object files [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com openh264]$
Also failed with --32 per README.md from repo: NASM needed to be installed for assembly code: workable version 2.07 or above, nasm can downloaded from http://www.nasm.us/ [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com openh264]$ nasm -v NASM version 0.98.40 (Apple Computer, Inc. build 11) compiled on May 16 2011 updated nasm ... [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com ~]$ wget http://www.nasm.us/pub/nasm/releasebuilds/2.11.05/macosx/nasm-2.1 1.05-macosx.zip --2014-07-08 22:14:37-- http://www.nasm.us/pub/nasm/releasebuilds/2.11.05/macosx/nasm-2.11.05-macosx.zip Resolving www.nasm.us... 198.137.202.10, 2001:1868:205::10 Connecting to www.nasm.us|198.137.202.10|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1250711 (1.2M) [application/zip] Saving to: `nasm-2.11.05-macosx.zip' 100%[=======================================================================================>] 1,250,711 --.-K/s in 0.06s 2014-07-08 22:14:37 (19.5 MB/s) - `nasm-2.11.05-macosx.zip' saved [1250711/1250711] [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com ~]$ unzip nasm-2.11.05-macosx.zip Archive: nasm-2.11.05-macosx.zip inflating: nasm-2.11.05/ldrdf inflating: nasm-2.11.05/README inflating: nasm-2.11.05/nasm inflating: nasm-2.11.05/rdfdump inflating: nasm-2.11.05/LICENSE inflating: nasm-2.11.05/rdf2ihx inflating: nasm-2.11.05/ndisasm inflating: nasm-2.11.05/nasmdoc.pdf inflating: nasm-2.11.05/rdflib inflating: nasm-2.11.05/rdf2bin inflating: nasm-2.11.05/rdf2ith inflating: nasm-2.11.05/man1/rdf2bin.1 extracting: nasm-2.11.05/man1/rdf2srec.1 extracting: nasm-2.11.05/man1/rdf2ihx.1 extracting: nasm-2.11.05/man1/rdf2ith.1 inflating: nasm-2.11.05/man1/ldrdf.1 inflating: nasm-2.11.05/man1/rdflib.1 extracting: nasm-2.11.05/man1/rdf2com.1 inflating: nasm-2.11.05/man1/rdfdump.1 inflating: nasm-2.11.05/man1/ndisasm.1 inflating: nasm-2.11.05/man1/nasm.1 inflating: nasm-2.11.05/man1/rdx.1 inflating: nasm-2.11.05/rdf2srec inflating: nasm-2.11.05/rdx inflating: nasm-2.11.05/rdf2com [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com ~]$ ls Desktop Downloads Movies Pictures nasm-2.11.05 Documents Library Music Public nasm-2.11.05-macosx.zip [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com ~]$ rm -rf nasm-2.11.05-macosx.zip [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com ~]$ popd /builds/slave/openh264 [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com openh264]$ export PATH=~/nasm-2.11.05/ LICENSE ldrdf nasm ndisasm rdf2com rdf2ith rdfdump rdx README man1/ nasmdoc.pdf rdf2bin rdf2ihx rdf2srec rdflib [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com openh264]$ export PATH=~/nasm-2.11.05/:$PATH [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com openh264]$ echo $PATH /Users/cltbld/nasm-2.11.05/:/tools/python/bin:/tools/buildbot/bin:/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/us r/X11/bin ..... and things just worked with default script
Running gtest from mozharness failed due to the following: [cltbld@bld-lion-r5-013.build.releng.scl3.mozilla.com openh264]$ svn co https://googletest.googlecode.com/svn/trunk/ gtest Error validating server certificate for 'https://googletest.googlecode.com:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: *.googlecode.com - Valid: from Wed, 04 Jun 2014 08:37:35 GMT until Tue, 02 Sep 2014 00:00:00 GMT - Issuer: Google Inc, US - Fingerprint: 98:19:0d:20:e0:da:1f:e8:ff:c4:06:f2:7d:13:2f:83:dc:7b:d5:eb (R)eject, accept (t)emporarily or accept (p)ermanently? p I permanently accepted it, and then was able to run from mozharness without issue. All tests pass. Repeating with --32 now....
--32 bit OSX built fine, however gtest failed with the mozharness script as exists. (I suspect the issue is that we need to pass the ENABLE64BIT=no to the other make calls as well) 22:28:04 INFO - ld: symbol(s) not found for architecture x86_64 22:28:04 INFO - collect2: ld returned 1 exit status 22:28:04 INFO - make: *** [codec_unittest] Error 1 ------- As a touchpoint I uploaded the referenced (needed) files to people.m.c for anyone who wants to play with them in any way. Since I'm told they are not private. STATUS: OS | Arch | Build | Tests | People.m.c URL ====================================================================== OSX | 64 | GOOD | PASS | http://tinyurl.com/mm2dh9t ---------------------------------------------------------------------- OSX | 32 | GOOD | FAIL | http://tinyurl.com/m5mevf5 ---------------------------------------------------------------------- .....TODO....
Whiteboard: [status in c#8]
Thanks Callek! I've uploaded linux builds here: Linux32: http://people.mozilla.org/~catlee/openh264/linux32/ Linux64: http://people.mozilla.org/~catlee/openh264/linux64/ You're right re: the test failures with 32-bit. I've fixed up the script to set the ENABLE64BIT=no variable properly for 32-bit tests, and now they also work properly for me.
Depends on: 1036768
Per c#9 the new script is http://hg.mozilla.org/users/catlee_mozilla.com/mozharness/file/4554900be7d1/scripts/openh264_build.py Windows is having problems (I'll detail at end of this comment) PRIOR STATUS: OS | Arch | Build | Tests | People.m.c URL ====================================================================== OSX | 64 | GOOD | PASS | http://tinyurl.com/mm2dh9t ---------------------------------------------------------------------- OSX | 32 | GOOD | PASS | http://tinyurl.com/m5mevf5 ---------------------------------------------------------------------- DEBUG: OS | Arch | Build | Tests | People.m.c URL ====================================================================== OSX | 64 | GOOD | PASS | <not uploaded, but I can> ---------------------------------------------------------------------- OSX | 32 | GOOD | PASS | <not uploaded, but I can> ---------------------------------------------------------------------- =============================================================================== Windows: So, I had lots of trouble connecting properly to windows (ironically since I use windows locally). Eventually I was able to connect as administrator (root) on my loaner... I had to install Git as in Bug 963617 Following that, running this mozharness on windows is giving me mozharness gittool.py complete and utter failure.... ((( 23:55:44 ERROR - caught OS error 2: The system cannot find the file specified while running [' tool.py', '-r', 'master', 'https://github.com/cisco/openh264.git', 'c:\\builds\\moz2_slave\\openh \\build\\src'] 23:55:44 INFO - rmtree: c:\builds\moz2_slave\openh264\build\src 23:55:44 INFO - Using _rmtree_windows ... 23:55:44 INFO - retry: Calling <bound method OpenH264Build._rmtree_windows of <__main__.OpenH Build object at 0x028BEB50>> with args: ('c:\\builds\\moz2_slave\\openh264\\build\\src',), kwargs }, attempt #1 23:55:44 INFO - retry: Failed, sleeping 60 seconds before retrying ))) This was done after launching start-msvc10.bat from /c/mozilla-build And the following history: $ history 1 cd /c/builds/moz2_slave/ 2 cd openh264/ 3 export PATH=/C/mozilla-build/nsis-2.46u:/C/mozilla-build/python27:/C/mozilla-build/buildbotve /scripts:/C/mozilla-build/msys/local/bin:/c/mozilla-build/wget:/c/mozilla-build/7zip:/c/mozilla-buil d/blat261/full:/c/mozilla-build/python:/c/mozilla-build/svn-win32-1.6.3/bin:/c/mozilla-build/upx203w :/c/mozilla-build/emacs-22.3/bin:/c/mozilla-build/info-zip:/c/mozilla-build/nsis-2.22:/c/mozilla-bui ld/nsis-2.33u:/c/mozilla-build/nsis-2.46u:/c/mozilla-build/wix-351728:/c/mozilla-build/hg:/c/mozilla -build/python/Scripts:/c/mozilla-build/kdiff3:/c/mozilla-build/yasm:.:/C/mozilla-build/msys/local/bi n:/C/mozilla-build/msys/mingw/bin:/C/mozilla-build/msys/bin:/c/windows/system32:/c/windows:/c/window s/System32/Wbem:/c/windows/System32/WindowsPowerShell/v1.0/:/c/mozilla-build:/c/mozilla-build/python 27:/c/mozilla-build/python27/Scripts:/C/mozilla-build/msys/bin:/c/mozilla-build/vim/vim72:/c/mozilla -build/wget:/c/mozilla-build/info-zip:/c/CoreUtils/bin:/c/mozilla-build/buildbotve/scripts:/c/Progra m\ Files\ \(x86\)/Microsoft\ SQL\ Server/100/Tools/Binn/:/c/Program\ Files/Microsoft\ SQL\ Server/10 0/Tools/Binn/:/c/Program\ Files/Microsoft\ SQL\ Server/100/DTS/Binn/:/c/Program\ Files\ \(x86\)/Wind ows\ Kits/8.0/Windows\ Performance\ Toolkit/:/c/mozilla-build/moztools-x64/bin:/c/mozilla-build/vim/ vim72:${PATH}:/c/mozilla-build/Git/bin/ 4 ls 5 rm -rf build 6 ls 7 python scripts/scripts/openh264_build.py --os msvc 8 wget -O /c/mozilla-build/Git/gittool.py http://mxr.mozilla.org/build/source/puppet/modules/pa ckages/files/gittool.py\?raw=1 9 mv /c/mozilla-build/Git/{,bin/}gittool.py 10 python scripts/scripts/openh264_build.py --os msvc 11 mv /c/mozilla-build/Git/bin/{,real_}gittool.py 12 echo "python ./gittool.py %*" > /c/mozilla-build/Git/bin/gittool.py.bat 13 cat /c/mozilla-build/Git/bin/gittool.py.bat 14 python scripts/scripts/openh264_build.py --os msvc 15 python scripts/scripts/openh264_build.py --os msvc 16 python scripts/scripts/openh264_build.py --os msvc 17 history Apologies for the delay here, but I'm gonna need :catlee, or :aki's help deciphering how to fix this Git issue with mozharness (first thing tomorrow)
Whiteboard: [status in c#8] → [status in c#10]
Changing Requirement (Based on My Understandings thus far): The two files should be shipped in a .zip instead of flat. \- unspecified is compression amount, /me will choose default |- unspecified is required structure/layout of the zip internals. Per bsmedberg in https://bugzilla.mozilla.org/show_bug.cgi?id=1009816#c53 === Ben, is there any requirement around zip file layout? If not I will be doing -foo.zip |- ./ \- ./{libprefix}gmpopenh264.{libsuffix} |- ./gmpopenh264.info
Flags: needinfo?(benjamin)
Just the two files in the toplevel of the ZIP. I presume we should use the best compression.
Flags: needinfo?(benjamin)
Per :catlee, proxying legal. I've restricted my people directory of these files: SSLRequireSSL On AuthType Persona Require persona-idp login.mozilla.org tl;dr is you need to load via https:// and its restricted to login via persona.
touchpoint: Windows [non-debug] bulds success! Did not yet try debug Notes: * Had to explicitly pass --32, (ENABLE64BIT=Yes failed at linker step) * Had to manually install Git on our systems \- needed to be last in PATH, to not conflict MSYS libs/binaries with our mozilla-build * Had to manually grab nasm (http://www.nasm.us/pub/nasm/releasebuilds/2.11.05/win32/) and add to path \- used the zip, and simply unzipped * Test failed, (gtest checked out, then promptly tries to invoke g++, which fails) * Had to manually checkout the git sources, instead of relying on mozharness
*** [Current] Commands for [re-]Building on Windows *** current builds used b-2008-ix-0108.build.mozilla.org, which has all prerequisites installed (pre-requisites) * Git installed to C:\mozilla-build\Git\ per Bug 963617 * nasm-2.11.05 installed [currently] to C:/builds/moz2_slave/openh264/nasm-2.11.05 * mozharness scripts checked out at C:/builds/moz2_slave/openh264/scripts \- from http://hg.mozilla.org/users/catlee_mozilla.com/mozharness/rev/9020372db38c --> launch start-msvc10.bat from C:\mozilla-build * cd /c/builds/moz2_slave/openh264 * export PATH=/C/mozilla-build/nsis-2.46u:/C/mozilla-build/python27:/C/mozilla-build/buildbotve/scripts:/C/mozilla-build/msys/local/bin:/c/mozilla-build/wget:/c/mozilla-build/7zip:/c/mozilla-build/blat261/full:/c/mozilla-build/python:/c/mozilla-build/svn-win32-1.6.3/bin:/c/mozilla-build/upx203w:/c/mozilla-build/emacs-22.3/bin:/c/mozilla-build/info-zip:/c/mozilla-build/nsis-2.22:/c/mozilla-build/nsis-2.33u:/c/mozilla-build/nsis-2.46u:/c/mozilla-build/wix-351728:/c/mozilla-build/hg:/c/mozilla-build/python/Scripts:/c/mozilla-build/kdiff3:/c/mozilla-build/yasm:.:/C/mozilla-build/msys/local/bin:/C/mozilla-build/msys/mingw/bin:/C/mozilla-build/msys/bin:/c/windows/system32:/c/windows:/c/windows/System32/Wbem:/c/windows/System32/WindowsPowerShell/v1.0/:/c/mozilla-build:/c/mozilla-build/python27:/c/mozilla-build/python27/Scripts:/C/mozilla-build/msys/bin:/c/mozilla-build/vim/vim72:/c/mozilla-build/wget:/c/mozilla-build/info-zip:/c/CoreUtils/bin:/c/mozilla-build/buildbotve/scripts:/c/Program\ Files\ \(x86\)/Microsoft\ SQL\ Server/100/Tools/Binn/:/c/Program\ Files/Microsoft\ SQL\ Server/100/Tools/Binn/:/c/Program\ Files/Microsoft\ SQL\ Server/100/DTS/Binn/:/c/Program\ Files\ \(x86\)/Windows\ Kits/8.0/Windows\ Performance\ Toolkit/:/c/mozilla-build/moztools-x64/bin:/c/mozilla-build/vim/vim72:${PATH}:/c/mozilla-build/Git/bin/ * rm -rf output * mkdir -p output/win32 * rm -rf build * python scripts/scripts/openh264_build.py --os msvc --no-checkout-sources --no-build * git clone https://github.com/cisco/openh264.git build/src * pushd build/src/; git show > /c/builds/moz2_slave/openh264/output/win32/git_show.txt; popd * python scripts/scripts/openh264_build.py --os msvc --32 --no-checkout-sources * cp build/src/gmpopenh264.{dll,info} output/win32/ * pushd output/win32; zip ./gmpopenh264.zip gmpopenh264.{dll,info}; popd ---> from a local computer: * sftp cltbld@B-2008-IX-0108.winbuild.releng.scl3.mozilla.com:/C$/builds/moz2_slave/openh264/output/win32/* ./ Then you can transfer those files around per normal
*** [Current] Commands for [re-]Building on OSX *** current builds used bld-lion-r5-013.build.mozilla.org, which has all prerequisites installed (pre-requisites) * nasm-2.11.05 installed [currently] to ~cltbld/nasm-2.11.05 * mozharness scripts checked out at /builds/slave/openh264/scripts \- from http://hg.mozilla.org/users/catlee_mozilla.com/mozharness/rev/9020372db38c --> ssh/launch terminal * cd /builds/slave/openh264/ * svn co https://googletest.googlecode.com/svn/trunk/ gtest \- <press "p"> |- # This is explicitly to accept the googlecode cert fingerprint so the script will run fine * export PATH=/tools/python/bin:/tools/buildbot/bin:/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin * export VERSIONER_PYTHON_PREFER_32_BIT=no * export VERSIONER_PYTHON_VERSION=2.7 * export HG_SHARE_BASE_DIR=/builds/hg-shared * export CCACHE_COMPRESS=1 * export CCACHE_DIR=/builds/ccache * export CCACHE_UMASK=002 * export PATH=~/nasm-2.11.05/:$PATH * rm -rf output * rm -rf build * mkdir -p output/macosx64 * ./scripts/scripts/openh264_build.py --64 * pushd build/src/; git show > /builds/slave/openh264/output/macosx64/git_show.txt; popd * cp build/src/libgmpopenh264.dylib output/macosx64/ * cp build/src/gmpopenh264.info output/macosx64/ * rm -rf build/ * mkdir -p output/macosx32 * ./scripts/scripts/openh264_build.py --32 * pushd build/src/; git show > /builds/slave/openh264/output/macosx32/git_show.txt; popd * cp build/src/gmpopenh264.info output/macosx32/ * cp build/src/libgmpopenh264.dylib output/macosx32/ * cd output/macosx64/ * zip gmpopenh264.zip gmpopenh264.info libgmpopenh264.dylib * cd ../macosx32/ * zip gmpopenh264.zip gmpopenh264.info libgmpopenh264.dylib ---> from a local computer: use scp to get these files to where they need to be
Commands for generating shasums/md5sums on people: ssh jwood@people.mozilla.com * cd openh264 * echo "# 5th column is size" > filelist.txt; * find . -mindepth 2 -type f -exec ls -la {} \; >> filelist.txt * md5sum filelist.txt > MD5SUMS * find . -mindepth 2 -type f -exec md5sum {} \; >> MD5SUMS * sha1sum filelist.txt > SHA1SUMS * find . -mindepth 2 -type f -exec sha1sum {} \; >> SHA1SUMS MUCH REJOICE
Ok Status Rollup! OSX and Windows Built by me, see following table. Windows Build Instructions in: c#15 OSX Build Instructions in: c#16 Instructions for SHA/MD5 Sum generations in: c#17 Linux Builds were by :catlee, I did not reproduce myself yet, so not part of my SUMS/etc on people.m.c Windows Tests won't run, due to attempts to compile with g++ STATUS: OS | Arch | Build | Tests | People.m.c URL (1) ====================================================================== OSX | 64 | GOOD | PASS | http://tinyurl.com/nb2qv7e ---------------------------------------------------------------------- OSX | 32 | GOOD | PASS | http://tinyurl.com/nstqe7j ---------------------------------------------------------------------- WIN | 32 | GOOD | <NOT_RUN> | http://tinyurl.com/ky4ngb7 ---------------------------------------------------------------------- LIN | 64 | GOOD | PASS? | http://tinyurl.com/mb2yrwj ---------------------------------------------------------------------- LIN | 32 | GOOD | PASS? | http://tinyurl.com/lwjkjfk ====================================================================== MD5SUMS | http://tinyurl.com/mvlpzp4 ---------------------------------------------------------------------- SHA1SUMS | http://tinyurl.com/pyanuoy ---------------------------------------------------------------------- File List (includes file size) | http://tinyurl.com/odc9jqb ---------------------------------------------------------------------- 1 --- people url protected by persona. per :catlee/legal DEBUG: OS | Arch | Build | Tests | People.m.c URL ====================================================================== OSX | 64 | GOOD | PASS | <not uploaded, but I can> ---------------------------------------------------------------------- OSX | 32 | GOOD | PASS | <not uploaded, but I can> ---------------------------------------------------------------------- WIN | 32 | GOOD | <NOT_RUN> | <not uploaded, but I can> ---------------------------------------------------------------------- LIN | 64 | GOOD | PASS? | <not uploaded, but I can> ---------------------------------------------------------------------- LIN | 32 | GOOD | PASS? | <not uploaded, but I can> ----------------------------------------------------------------------
Whiteboard: [status in c#10] → [rollup status in c#18]
ToDo's: * possibly rebuild the binaries per :catlee telling me theres an incomming API change. * Integrate Linux Builds/Binaries to my own People publish, to include sha1sums/etc * Update Mozharness to either checkout using git binary on windows, or coerce gittool to work on windows [and install it] * Update mozharness script to upload these binaries somewhere other than people.m.c * Get mozharness script reviewed and checked in. * Make official mozharness script configs to correspond to paths/etc our machines need. * Get Git properly deployed across windows [Bug 963617] Maybe: * CI to to the above * Convince <others> how its not a good idea to svn checkout from tip of a repo (e.g. google) for testing * mirror openh264 to inhouse (git.mozilla.org) and use that from the mozharness script * Get [newer, on OSX] nasm deployed across our infra. \- only maybe due to the fact that as a .zip we could theoretically just have the mozharness grab it as a script pre-req and add to path
Whiteboard: [rollup status in c#18] → [rollup status in c#18] [known next-steps in c#19]
I have windows builds based on the v1.1 branch: https://people.mozilla.org/~jwood/openh264/branches/v1.1-Firefox32/win32/ I did not gen shasum's for that yet, but will do so once I unblock the builds for osx and get linux builds out in general. I'm also told the "rebuild request" for the master branch hasn't come in yet, so those are still as they sat from yesterday.
Blocks: 1038108
No longer blocks: 1038108
Depends on: 1038108
(In reply to Justin Wood (:Callek) from comment #19) > ToDo's: > > * possibly rebuild the binaries per :catlee telling me theres an incomming > API change. :bhearsum told me over the weekend that we are "ready" for new binaries. They exist for windows/mac now, Linux maybe later this evening https://people.mozilla.org/~jwood/openh264/2014-07-14.0/ (SHA1SUMS, SHA512SUMS, filelist, etc all up a level)
to restate here, I have mac and win builds for firefox33 at https://people.mozilla.org/~jwood/openh264/branches/v1.1-Firefox33/ feel free to reach out if I have anything missing. (catlee sent his firefox33 builds along to cisco, so afaik I'm not blocking anything atm)
We should get this landed. Did you have any extra changes from what I had?
Attachment #8481293 - Flags: review?(bugspam.Callek)
Comment on attachment 8481293 [details] [diff] [review] mozharnes script for builds Review of attachment 8481293 [details] [diff] [review]: ----------------------------------------------------------------- no extras yet, I've been doing all steps outside of this manually
Attachment #8481293 - Flags: review?(bugspam.Callek) → review+
Attachment #8481293 - Flags: checked-in+
Merged to production, and deployed.
What's the status here?
We have tools written to reliably build the openh264 bits. Still TODO: - Hook up to automation if desired - Implement uploading logic
Catlee, I'm thinking I should give up these loaners that were established to do these builds, given the infrequency of them. Do you agree the above steps should be enough to allow me to give them all up, rather than force their indefinite hold?
Flags: needinfo?(catlee)
Definitely, no need to keep hold of the loaners.
Flags: needinfo?(catlee)
we've since done followup builds in new bugs, and catlee has updated the script. r/f
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: