Date   

Re: Collaboration Tools

Sebastian Sylwan
 

I think both forms of communication are perfectly fine and have their place, but most importantly I don't think it's the role of the ASWF to dictate the tools to use. It is very much - I believe-- in the purview of the individual projects to decide what works best for them. 

The foundation (the TAC actually) could recommend that if a real time communication channel is used a default one should be preferred (but again not imposed), or provide an infrastructure for it, if enough projects choose the same, to encourage others to join in (for the advantages pointed up above). Same for a mailing list infrastructure.

S

On Wed, Aug 22, 2018, 5:53 PM Ben De Luca, <bdeluca@...> wrote:
Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions. 




On Wed, 22 Aug 2018 at 19:59, Darin Grant <darin.grant@...> wrote:
I believe Larry has it correct.  Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.

On Aug 22, 2018, at 10:50 AM, Sean Cooper <sean@...> wrote:

Am I just a cranky old man for preferring mail lists

Nope. I think its completely fair for the ASWF to just say no to real-time options.

Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.


It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
 
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)

On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



-- 
Larry Gritz
lg@...




--
Darin Grant
Chief Technology Officer

T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...

Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA

  LinkedIn  Facebook  Twitter  Instagram

Animal Logic

www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.


Re: Collaboration Tools

Edward Warnicke
 

Depends a lot on the communities.

While I personally prefer IRC (or did, until it started dying of spam :( ), I also participate in many communities that use slack instead.

Ed

On August 22, 2018 at 9:30:51 PM, Michael Dolan (mdolan@...) wrote:

FWIW, I've seen a number of communities start off by adding everyone's favorite real time service - but then they commonly end up back at email and maybe IRC for real time chat during meetings (with a MeetBot addon). 

-- Mike



On Wed, Aug 22, 2018 at 9:33 PM Larry Gritz <lg@...> wrote:
Not to beat a dead horse, but when somebody says "real time", what I hear is "somebody important on the project, maybe even me, is going to miss it."

As I understand it, ASWF projects are intended to have a very high level of autonomy in what gets developed and how. I can't imagine that each project community wouldn't decide on its own communications style and mode. Though it's possible that for the ones who choose to have a real time (aka people left out 😜) comm channel, there may end up being an org-wide preference for which one.






On August 22, 2018 2:48:01 PM PDT, Ben De Luca <bdeluca@...> wrote:
Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions. 




On Wed, 22 Aug 2018 at 19:59, Darin Grant <darin.grant@...> wrote:
I believe Larry has it correct.  Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.

On Aug 22, 2018, at 10:50 AM, Sean Cooper <sean@...> wrote:

Am I just a cranky old man for preferring mail lists

Nope. I think its completely fair for the ASWF to just say no to real-time options.

Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.


It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
 
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)

On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



-- 
Larry Gritz
lg@...




--
Darin Grant
Chief Technology Officer

T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...

Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA

  LinkedIn  Facebook  Twitter  Instagram

Animal Logic

www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.

--
Larry Gritz
lg@...


Re: Code signing

Nathan Loofbourrow
 

For both Windows and Max OSX, you will need a developer signing certificate which is used to ensure the origin of the compiled code. Similar to GPG, but verified by the OS rather than by a package manager.

Let me know if you need additional details.

n


On Tue, Aug 21, 2018 at 9:24 PM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

For those who don't know me I'm a Release Engineer at the Linux Foundation and am helping the ASWF project get setup. Feel free to direct any CI related questions to me.

I can confirm that signing is very important to many of our projects and we definitely sign both our artifacts (binaries) as well as git tags when we release software for many of our other projects at the Linux Foundation.

Today the signing is done manually via "git tag -s" as well as gpg sign of release artifacts when projects approve a staged release for public release.

We are working on providing some automation in our CI platform to allow projects to have their artifacts signed along with the staging jobs (these jobs prepare releases) but it's not ready just yet.

Cheers,
Thanh

On Tue, Aug 21, 2018 at 7:31 PM Meadhbh Hamrick <ohmeadhbh@...> wrote:
I bet security requirements are going to be all over the map in this group.

I bet people who are trying to push out media to end user devices are
going to be VERY interested in signed code, but other people who are
running binaries they completely compiled from source files they just
downloaded from github are going to be more interested in verifying
the provenance of the tarballs they just downloaded than verifying
signatures on executables they just built.

I'm mostly in the latter camp, except for the tiny bits where i'm in
the former. I really want my developers that are building FLOSS
projects to be able to pick operational security procedures that make
sense for them (but yeah, at the same time I don't want to say
"SIGNING EXECUTABLES IS USELESS!" because I do bump up into that world
from time to time and know it's a requirement for some people.)

I guess what I'm saying is... I bet it's going to be a little more
complicated than people might originally think based on their own
experiences. But I also think we could do a small amount of work
up-front to define a handful of security models that will work for 80%
of people on the list and it'll give the other 20% something to point
at when they're trying to describe how it doesn't work.

Do you have specific requirements, Nathan? Like I said, I'm mostly a
backend server farm guy, but every now and again I bump into the
mobile / app store world where code signing makes a lot more sense.

-cheers
-m
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.hamrick.rocks/ * OhMeadhbh@...
Sent from my TRS-80 Model 102


On Tue, Aug 21, 2018 at 3:29 PM, Nathan Loofbourrow <njloof@...> wrote:
> I know it’s early days, especially for Windows and Mac, but will there be a
> plan for code signing the binaries produced by CI? This will be important
> for security and adoption.


Re: Code signing

Thanh Ha
 

Yep, we'll have to figure out Windows and Mac once we get the infra for those in place and working. I have some experience with signing OSX code from a past life which might be of use. Today our infra is mainly Linux based so our signing services are a lot more mature on the Linux platform, but as we get the non-linux builders up and running we will definitely be interested rolling out tooling to support those platforms as well.

Regards,
Thanh


On Mon, Aug 27, 2018 at 11:19 AM Nathan Loofbourrow <njloof@...> wrote:
For both Windows and Max OSX, you will need a developer signing certificate which is used to ensure the origin of the compiled code. Similar to GPG, but verified by the OS rather than by a package manager.

Let me know if you need additional details.

n


On Tue, Aug 21, 2018 at 9:24 PM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

For those who don't know me I'm a Release Engineer at the Linux Foundation and am helping the ASWF project get setup. Feel free to direct any CI related questions to me.

I can confirm that signing is very important to many of our projects and we definitely sign both our artifacts (binaries) as well as git tags when we release software for many of our other projects at the Linux Foundation.

Today the signing is done manually via "git tag -s" as well as gpg sign of release artifacts when projects approve a staged release for public release.

We are working on providing some automation in our CI platform to allow projects to have their artifacts signed along with the staging jobs (these jobs prepare releases) but it's not ready just yet.

Cheers,
Thanh

On Tue, Aug 21, 2018 at 7:31 PM Meadhbh Hamrick <ohmeadhbh@...> wrote:
I bet security requirements are going to be all over the map in this group.

I bet people who are trying to push out media to end user devices are
going to be VERY interested in signed code, but other people who are
running binaries they completely compiled from source files they just
downloaded from github are going to be more interested in verifying
the provenance of the tarballs they just downloaded than verifying
signatures on executables they just built.

I'm mostly in the latter camp, except for the tiny bits where i'm in
the former. I really want my developers that are building FLOSS
projects to be able to pick operational security procedures that make
sense for them (but yeah, at the same time I don't want to say
"SIGNING EXECUTABLES IS USELESS!" because I do bump up into that world
from time to time and know it's a requirement for some people.)

I guess what I'm saying is... I bet it's going to be a little more
complicated than people might originally think based on their own
experiences. But I also think we could do a small amount of work
up-front to define a handful of security models that will work for 80%
of people on the list and it'll give the other 20% something to point
at when they're trying to describe how it doesn't work.

Do you have specific requirements, Nathan? Like I said, I'm mostly a
backend server farm guy, but every now and again I bump into the
mobile / app store world where code signing makes a lot more sense.

-cheers
-m
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.hamrick.rocks/ * OhMeadhbh@...
Sent from my TRS-80 Model 102


On Tue, Aug 21, 2018 at 3:29 PM, Nathan Loofbourrow <njloof@...> wrote:
> I know it’s early days, especially for Windows and Mac, but will there be a
> plan for code signing the binaries produced by CI? This will be important
> for security and adoption.


introduction

Henk Vanneste <hankbonk2@...>
 

I am a 52 years young programmer from Belgium .  I am learning Linux on an education site called edx.org because I am very interested in it, and also have Lubuntu 16.04 LTS running on my little PC .  It would be an honour to work with a group of Linux programmers, I am not yet familiar with Java or perl or python, but I am planning to learn python .


Re: Missing link in Infra Bootstrap documentation?

Thanh Ha
 

On Tue, Sep 11, 2018 at 3:27 AM Jean-Francois Panisset <panisset@...> wrote:
Hi Thanh,

Hi JF,

I hope you don't mind me cc'ing the mailing lists so that others can benefit from the knowledge from this discussion as well.


I'm starting to configure Jenkins to match the documented config,
looking at the documentation:

https://docs.releng.linuxfoundation.org/en/latest/infra/bootstrap.html

I find:

9. Configure Jenkins security as described in Jenkins Security
<jenkins-security>

which doesn't seem to link to anything. Should it?

Syntax error will be fixed once this is merged https://gerrit.linuxfoundation.org/infra/12532

It's supposed to link to this:


I'll let you know once my project gets to the point of having
reproduced the documented config for Jenkins / Nexus 2 / Nexus 3
servers.

Does the LF have code that creates these servers? There's value for me
in figuring this out on my own, and in particular in creating a local
/ standalone version, but it would be create to have a reference to
compare against.

We do but I've been told we cannot share it because it's tied in with our infra management puppet configuration.

On the other hand I can assure you that there's nothing special about our configuration to create these servers. These docs assume a completely fresh install of these servers with no additional changes in the backend. You could for example even use the official Jenkins docker container and start off from these docs for both Jenkins / Nexus 2 / Nexus 3 even.


Hope this helps,
Thanh


Re: Missing link in Infra Bootstrap documentation?

Jean-Francois Panisset
 

Perfect, thank you for the documentation link. I had been using those official containers as a base so looks like I'm on the right track.

JF Panisset



On Sep 11, 2018, at 08:30, Thanh Ha <thanh.ha@...> wrote:

On Tue, Sep 11, 2018 at 3:27 AM Jean-Francois Panisset <panisset@...> wrote:
Hi Thanh,

Hi JF,

I hope you don't mind me cc'ing the mailing lists so that others can benefit from the knowledge from this discussion as well.


I'm starting to configure Jenkins to match the documented config,
looking at the documentation:

https://docs.releng.linuxfoundation.org/en/latest/infra/bootstrap.html

I find:

9. Configure Jenkins security as described in Jenkins Security
<jenkins-security>

which doesn't seem to link to anything. Should it?

Syntax error will be fixed once this is merged https://gerrit.linuxfoundation.org/infra/12532

It's supposed to link to this:


I'll let you know once my project gets to the point of having
reproduced the documented config for Jenkins / Nexus 2 / Nexus 3
servers.

Does the LF have code that creates these servers? There's value for me
in figuring this out on my own, and in particular in creating a local
/ standalone version, but it would be create to have a reference to
compare against.

We do but I've been told we cannot share it because it's tied in with our infra management puppet configuration.

On the other hand I can assure you that there's nothing special about our configuration to create these servers. These docs assume a completely fresh install of these servers with no additional changes in the backend. You could for example even use the official Jenkins docker container and start off from these docs for both Jenkins / Nexus 2 / Nexus 3 even.


Hope this helps,
Thanh


Re: Missing link in Infra Bootstrap documentation?

Thanh Ha
 

On Tue, Sep 11, 2018 at 11:30 AM Thanh Ha <thanh.ha@...> wrote:
On Tue, Sep 11, 2018 at 3:27 AM Jean-Francois Panisset <panisset@...> wrote:
Hi Thanh,

Hi JF,

I hope you don't mind me cc'ing the mailing lists so that others can benefit from the knowledge from this discussion as well.


I'm starting to configure Jenkins to match the documented config,
looking at the documentation:

https://docs.releng.linuxfoundation.org/en/latest/infra/bootstrap.html

I find:

9. Configure Jenkins security as described in Jenkins Security
<jenkins-security>

which doesn't seem to link to anything. Should it?

Syntax error will be fixed once this is merged https://gerrit.linuxfoundation.org/infra/12532

It's supposed to link to this:


I'll let you know once my project gets to the point of having
reproduced the documented config for Jenkins / Nexus 2 / Nexus 3
servers.

Does the LF have code that creates these servers? There's value for me
in figuring this out on my own, and in particular in creating a local
/ standalone version, but it would be create to have a reference to
compare against.

We do but I've been told we cannot share it because it's tied in with our infra management puppet configuration.

On the other hand I can assure you that there's nothing special about our configuration to create these servers. These docs assume a completely fresh install of these servers with no additional changes in the backend. You could for example even use the official Jenkins docker container and start off from these docs for both Jenkins / Nexus 2 / Nexus 3 even.


Hi JF,

IT gave me the following puppet information in case it's helpful for you but as I suspected we don't have any custom config in place to handle Jenkins and use what's already available out on puppet forge. Here was the response I got:

We use the public puppet module for jenkins @ https://forge.puppet.com/rtyler/jenkins (mod 'rtyler/jenkins', '1.7.0'). Our internal config is essentially:

jenkins::config_hash:
  JENKINS_LISTEN_ADDRESS:
    value: '0.0.0.0'
  JENKINS_AJP_PORT:
    value: '-1'
  JENKINS_ARGS:
    value: '-Dhudson.model.ParametersAction.safeParameters=GERRIT_EVENT_TYPE,GERRIT_EVENT_HASH,GERRIT_BRANCH,GERRIT_TOPIC,GERRIT_CHANGE_NUMBER,GERRIT_CHANGE_ID,GERRIT_PATCHSET_NUMBER,GERRIT_PATCHSET_REVISION,GERRIT_REFSPEC,GERRIT_PROJECT,GERRIT_CHANGE_SUBJECT,GERRIT_CHANGE_COMMIT_MESSAGE,GERRIT_CHANGE_URL,GERRIT_CHANGE_OWNER,GERRIT_CHANGE_OWNER_NAME,GERRIT_CHANGE_OWNER_EMAIL,GERRIT_PATCHSET_UPLOADER,GERRIT_PATCHSET_UPLOADER_NAME'
    # yamllint enable

jenkins::port: '8080'
jenkins::admin: '<projectname>-jenkins'


Building OpenEXR on Windows

Thanh Ha
 

Hi Everyone,

We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"

It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?

The jenkins job I've been tested is here:


Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.

Thanks,
Thanh


& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..

CMake Error at CMakeLists.txt:8 (PROJECT):
  Failed to run MSBuild command:

    C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 4.6.1586.0
    [Microsoft .NET Framework, version 4.0.30319.42000]
    Copyright (C) Microsoft Corporation. All rights reserved.
    
    Build started 9/19/2018 12:45:34 AM.
    Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.
    
    Build FAILED.
    
    "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    
        0 Warning(s)
        1 Error(s)


Re: Building OpenEXR on Windows

Nick Porcino
 

Hi there, the script I see here: https://jenkins.aswf.io/sandbox/job/openexr-win64-master/configure seems to be incorrectly configured to run a very old Visual Studio, Visual Studio 2010.

-G "Visual Studio 10 Win64" ..

The Generator expression for CMake needs to specify version and year. We've tested OpenEXR with Visual Studio 2015 and 2017, and I see you're intending to use 2017. So, update the generator with:

-G "Visual Studio 15 2017 Win64"

HTH!

- Nick




On Wed, Sep 19, 2018 at 11:57 AM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"

It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?

The jenkins job I've been tested is here:


Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.

Thanks,
Thanh


& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..

CMake Error at CMakeLists.txt:8 (PROJECT):
  Failed to run MSBuild command:

    C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 4.6.1586.0
    [Microsoft .NET Framework, version 4.0.30319.42000]
    Copyright (C) Microsoft Corporation. All rights reserved.

    Build started 9/19/2018 12:45:34 AM.
    Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982


Re: Building OpenEXR on Windows

Thanh Ha
 

Oh yeah that makes sense, I should have thought of that. I copied what was in README and didn't think to try changing the value. I got further now with the updated generator. Will report more on progress once I have something working.

Thanks,
Thanh

On Wed, Sep 19, 2018 at 3:40 PM Nick Porcino <nick.porcino@...> wrote:
Hi there, the script I see here: https://jenkins.aswf.io/sandbox/job/openexr-win64-master/configure seems to be incorrectly configured to run a very old Visual Studio, Visual Studio 2010.

-G "Visual Studio 10 Win64" ..

The Generator expression for CMake needs to specify version and year. We've tested OpenEXR with Visual Studio 2015 and 2017, and I see you're intending to use 2017. So, update the generator with:

-G "Visual Studio 15 2017 Win64"

HTH!

- Nick




On Wed, Sep 19, 2018 at 11:57 AM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"

It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?

The jenkins job I've been tested is here:


Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.

Thanks,
Thanh


& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..

CMake Error at CMakeLists.txt:8 (PROJECT):
  Failed to run MSBuild command:

    C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 4.6.1586.0
    [Microsoft .NET Framework, version 4.0.30319.42000]
    Copyright (C) Microsoft Corporation. All rights reserved.

    Build started 9/19/2018 12:45:34 AM.
    Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982


Re: Building OpenEXR on Windows

Cary Phillips
 

I'll update the README.


On Wed, Sep 19, 2018 at 12:57 PM Thanh Ha <thanh.ha@...> wrote:
Oh yeah that makes sense, I should have thought of that. I copied what was in README and didn't think to try changing the value. I got further now with the updated generator. Will report more on progress once I have something working.

Thanks,
Thanh

On Wed, Sep 19, 2018 at 3:40 PM Nick Porcino <nick.porcino@...> wrote:
Hi there, the script I see here: https://jenkins.aswf.io/sandbox/job/openexr-win64-master/configure seems to be incorrectly configured to run a very old Visual Studio, Visual Studio 2010.

-G "Visual Studio 10 Win64" ..

The Generator expression for CMake needs to specify version and year. We've tested OpenEXR with Visual Studio 2015 and 2017, and I see you're intending to use 2017. So, update the generator with:

-G "Visual Studio 15 2017 Win64"

HTH!

- Nick




On Wed, Sep 19, 2018 at 11:57 AM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"

It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?

The jenkins job I've been tested is here:


Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.

Thanks,
Thanh


& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..

CMake Error at CMakeLists.txt:8 (PROJECT):
  Failed to run MSBuild command:

    C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 4.6.1586.0
    [Microsoft .NET Framework, version 4.0.30319.42000]
    Copyright (C) Microsoft Corporation. All rights reserved.

    Build started 9/19/2018 12:45:34 AM.
    Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982



--
Cary Phillips | R&D Supervisor | ILM | San Francisco


Re: Building OpenEXR on Windows

Nick Porcino
 

Thanks! I was still grepping to find the VS2010 reference. The root Readme.md is correct.


On Wed, Sep 19, 2018 at 2:23 PM Cary Phillips <cary@...> wrote:
I'll update the README.

On Wed, Sep 19, 2018 at 12:57 PM Thanh Ha <thanh.ha@...> wrote:
Oh yeah that makes sense, I should have thought of that. I copied what was in README and didn't think to try changing the value. I got further now with the updated generator. Will report more on progress once I have something working.

Thanks,
Thanh

On Wed, Sep 19, 2018 at 3:40 PM Nick Porcino <nick.porcino@...> wrote:
Hi there, the script I see here: https://jenkins.aswf.io/sandbox/job/openexr-win64-master/configure seems to be incorrectly configured to run a very old Visual Studio, Visual Studio 2010.

-G "Visual Studio 10 Win64" ..

The Generator expression for CMake needs to specify version and year. We've tested OpenEXR with Visual Studio 2015 and 2017, and I see you're intending to use 2017. So, update the generator with:

-G "Visual Studio 15 2017 Win64"

HTH!

- Nick




On Wed, Sep 19, 2018 at 11:57 AM Thanh Ha <thanh.ha@...> wrote:
Hi Everyone,

We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"

It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?

The jenkins job I've been tested is here:


Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.

Thanks,
Thanh


& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..

CMake Error at CMakeLists.txt:8 (PROJECT):
  Failed to run MSBuild command:

    C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe

  to get the value of VCTargetsPath:

    Microsoft (R) Build Engine version 4.6.1586.0
    [Microsoft .NET Framework, version 4.0.30319.42000]
    Copyright (C) Microsoft Corporation. All rights reserved.

    Build started 9/19/2018 12:45:34 AM.
    Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982



--
Cary Phillips | R&D Supervisor | ILM | San Francisco



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982


hello

sreenivas
 

I am excited to seen the initiative by the community to push towards open source. Congratulations to all the folks involved in setting up ASWF!

Two questions I have! 
* Going forward, VFX platform(http://www.vfxplatform.com/) will be moved under the umbrella of ASWF ? 
* Are the Wednesday TAC meetings open for all to join ? 

Thanks!  


Re: hello

Rob Bredow
 


Thank you for your interest. Great questions.

1) No, or at least not yet. The VES is doing an excellent job running the VFX Platform and there are a number of other projects that the group has discussed which seem much higher priority to be adopted by the ASWF. Projects like OpenEXR, OpenVDB, OCIO are under active discussion for early adoption. That said, there is a lot of overlap between VES Technology Committee members and ASWF members and the door is open for any collaboration that makes sense for sure. But right now, I personally am just happy both projects are moving forward and staying in close communication with each other. For example, the build infrastructure is based heavily on compatibility with the VFX Platform.

2) Yes. I understand it's an open meeting. Only TAC members can vote, but the calls are open for anyone to join in. Take a look at the list here for meeting announcements.


Thanks--

Rob


On Mon, Sep 24, 2018 at 9:39 AM <sreenivas9alapati@...> wrote:
I am excited to seen the initiative by the community to push towards open source. Congratulations to all the folks involved in setting up ASWF!

Two questions I have! 
* Going forward, VFX platform(http://www.vfxplatform.com/) will be moved under the umbrella of ASWF ? 
* Are the Wednesday TAC meetings open for all to join ? 

Thanks!  


Re: hello

sreenivas
 

Thanks for the answers Rob!
Cheers!


Re: hello

Cary Phillips
 

On Mon, Sep 24, 2018 at 10:55 AM <sreenivas9alapati@...> wrote:
Thanks for the answers Rob!
Cheers!



--
Cary Phillips | R&D Supervisor | ILM | San Francisco


News Today: New Members & OpenVDB

Emily Olin
 

ASWF Community:

Today, the Academy Software Foundation announced four new members: Sony Pictures Entertainment/Sony Pictures Imageworks as a Premier member, Warner Bros. as a General Member, and Blender Foundation and Visual Effects Society (VES) as Associate members.
 
We also announced that OpenVDB, developed and maintained by DreamWorks Animation, has been approved as the Foundation's first hosted project.
 
The press release with additional details is here. Please consider sharing this news via your social channels. Below are some suggested Tweets.

Thanks!
 
.@SonyPictures @WarnerBrosEnt @Blender_Org and @VFXSociety join @AcademySWF! The Foundation also welcomes OpenVDB by @DWAnimation as its first hosted project. Read more here: https://bit.ly/2q8q13Q
Click-to-tweet: https://ctt.ac/jvd0t

.@AcademySWF gains momentum with four new members and approves OpenVDB by @DWAnimation as the Foundation's first open source project. Read more here: https://bit.ly/2q8q13Q

Click-to-Tweet: https://ctt.ac/0I86H

 


ASWF CI Infrastructure: VFX Reference Platform Dependencies

Daniel Heckenberg
 


Hello everyone,

As we start to adopt projects into the ASWF, I would like to turn attention to the CI setup and especially the way that project dependencies are built and managed.

There have been many discussions here and elsewhere which I shall ambitiously summarize as, "We should make the ASWF CI dependencies a practical realization of the VFX Reference Platform."   This would entail establishing build configurations for the relevant packages to be built from source and storage of the results as reusable artifacts.  As all parts of this chain will be open, accessible and reproducible this offers a great opportunity for contributions from the community, and for the configurations and artifacts to be used to facilitate software development and OSS software use.

Of course, there are lots of gaps and questions with this, such as "what do we do for non-Linux builds"?  I'd like to encourage the discussion here as we embark on the effort.

Some links follow with excellent Linux Foundation documentation of the CI infrastructure.

Thanks,
Daniel Heckenberg
ASWF TAC Chair

References: 
ci-management repo here:
CI docs are available here:
     https://docs.releng.linuxfoundation.org/en/latest/

As a background into the current ASWF CI infrastructure, Thanh Ha gave a great overview back in July:

CI Infrastructure Usage Details

Thanh Ha
Jul 31  

Hi Everyone,
 
The infrastructure for ASWF is ready to go and has the following components:
 
 
I will step through each of those components one by one below:
 
GitHub Organization
 
The current organization has 4 repos: ci-management, opencolorio, openexr, and openvdb.
 
The 3 project repos are just forks of their respective upstream projects. The "ci-management" repo contains the code for the CI system, mainly all of the Jenkins build scripts. It contains 3 important directories:
 
1. jenkins-config: contains Jenkins global configuration, usually not too important for contributors and is typically maintained by the releng team
2. jjb: contains the project build scripts, usually maintained by the releng team & projects
3. packer: contains the vm image build scripts, we try to make reproducible CI so that any org can take the same packer scripts and build the same VM Images in their own environments.
 
Projects typically will be most interested in the "JJB" directory and detailed documentation on Jenkins Job Builder (JJB) / Jenkins usage are available at these 2 links:
 
 
Jenkins Job Builder is a tool that allows projects to manage their Jenkins Job configuration using YAML configuration files typically stored in a Git repo so that it can be source controlled the same way as code.
 
When a Pull Request is merged in the ci-management repo a Jenkins job will kick off and automatically update all of the Jenkins jobs in the production system with the updated build configuration.
 
Jenkins / Jenkins Sandbox
 
We provide 2 Jenkins servers for projects to utilize the first is the production Jenkins system located at https://jenkins.aswf.io/ which is where all the production builds are run (the jobs that report back to GitHub). We do not allow developers to login and manage Jenkins in the production system, this is purely managed via the ci-management repo mentioned previously.
 
The 2nd system is the Jenkins Sandbox located at https://jenkins.aswf.io/sandbox is for projects to develop new job types and test their jobs before merging the patch into the ci-management repo and making it live to GitHub.
 
Detailed documentation on how to use the Jenkins Sandbox is available here:
 
 
Nexus
 
Sonatype Nexus located at https://nexus.aswf.io/ is where all of our build artifacts / binaries are released to. Typically a "staging" job will produce a staging repository in Nexus containing a Release Candidate build. Projects can then test this repository and once approved will be released to a "release" repository in Nexus to make it widely available.
 
Jenkins jobs typically manages the staging repository creation and LF Helpdesk will manage the release (we are working on some automation here for the future).
 
Jira
 
Jira located at http://jira.aswf.io/ can be used to track bugs and new feature development. We've created Jira projects for the 4 repo projects already ci-management, opencolorio, openexr, and openvdb.
 
Jenkins Jobs
 
With that said I'd like to discuss some Jenkins jobs we've rolled out already for the projects. For every project we have 2 job types "verify" and "stage".
 
The "verify" jobs are used to verify code contributions from contributors by running test build of the project. Typically it will also run any unit tests etc... as configured by the project for the build. This job also watches GitHub for keywords so if someone leaves a comment "recheck" in a PR comment the job will automatically retrigger for that PR. This is useful for rerunning the verify tests in case of intermittent issues.
 
As an example we've configured the OpenEXR project to run 2 verify builds for incoming PRs. One job runs autoconf build and the other job runs CMake build, this allows us to test both supported build methods simultaneously for all incoming PRs.
 
Example:
 
 
The "stage" job type produces release candidate builds. The idea is that this job can run periodically and a project can decide to release any particular day's "staged release" as the final release. The job stores a commit hash of the build so that the developer can tag the appropriate commit as was built by Jenkins after approving a staged release.
 
For example:
 
 
This job produced a staging repo "opencolorio-1002" here:
 
 
This is a temporary repository containing the artifacts for the release. Once a project decides to release this repo it will be copied to the final release repository here:
 
 
Making the artifacts in that staging repo available generally to the world.
 
This was a quick walkthrough of the current CI infra. It is a lot to cover all at once but please feel free to reach out with any questions about this system.
 



Re: ASWF CI Infrastructure: VFX Reference Platform Dependencies

Dan Bailey
 

Hi Daniel,

Thanks for sending this around, this is a great overview.

I know vendor dependencies were discussed in a past meeting, but skimming the meeting notes, I can't seem to find the outcome of those discussions. Wondering what the plan is to build against libraries for Houdini, Maya, Nuke, etc in terms of EULAs and exactly how this will be exposed in Nexus?

Regarding CI for OpenVDB specifically, I don't see a problem with sticking to using VFX Reference Platform versions of dependencies. I suggest one of the next steps will be to match the existing build matrix used with Travis CI (https://github.com/AcademySoftwareFoundation/openvdb/blob/master/.travis.yml) and the major component missing in ASWF Jenkins currently is building the Houdini plugins. 

Thanks,
Dan

61 - 80 of 188