Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [4diac-dev] Providing RPMs for 4DIAC Forte
I definitely understand that ... I just had hopes to get this done quicker ;-) It is quite exciting!

I am happy to create a PR for open62541. The final spec file for Fedora will be hosted in the Fedora repositories anyway. And I think it doesn't make much sense hosting this in open62541 anyway. But adding a CI and local RPM build to open62541 and 4diac-forte would definitely make sense. As does adding things like the systemd units, … and I will definitely create PRs for that!

It is really great to see that there is at least one person working on both sides. And while it still might take a bit longer, I would really like to get open62541 and forte into Fedora at some point.

Btw ... if you are located in Munich and have some free time around 18:00 at the 14th of September (Thursday next week), I would like to invite you to the IoT & Beer meetup [1], so we can discuss all the details ;-)

Cheers

Jens

On Tue, Sep 5, 2017 at 2:00 PM, Stefan Profanter <profanter@xxxxxxxxxxx> wrote:
Hi Jens,
I'm one of the core developers of open62541 and currently we do not have a release schedule for 0.3. I would expect it to be a few months until 0.3 is released, since there are currently still some important Pull Requests open (e.g. nodeset compiler, encryption, ...)

I am also one of the main contributors for OPC UA support in 4diac. We had support for 0.2 and master of open62541 in 4diac.

Unfortunately, in the last month there were some necessary changes in the API between 0.2 and master which would have lead to some very ugly #ifdefs in 4diac, that's why we dropped the support of the 0.2 version. I know that this is not the best option to rely on a actively developing master, but until 0.3 is out, it will probably stay like this, due to many features which are missing in 0.2.
Additionally, OPC UA support in 4diac is currently also only available in the development branch.

Therefore I would suggest to wait until the next version of 4diac is released, which includes OPC UA, and there we will then decide which open62541 version we will support for that specific release.

Btw. thanks for your efforts in creating the RPMs!
As Julius already answered here (https://groups.google.com/forum/#!topic/open62541/RuMANJIkdkU) we are always happy to integrate such features in our nightly build process. Thus a Pull Request on github would be really nice.

Does that sound like a solution for you?
Stefan

-----Original Message-----
From: Jens Reimann <jreimann@xxxxxxxxxx>
Reply-to: 4diac developer discussions <4diac-dev@xxxxxxxxxxx>
To: 4diac developer discussions <4diac-dev@xxxxxxxxxxx>
Subject: Re: [4diac-dev] Providing RPMs for 4DIAC Forte
Date: Tue, 5 Sep 2017 09:01:25 +0000

That is too bad. I had hoped to get 4diac into Fedora as well, but going with a master branch version for both doesn't seem like a good idea.

Do you know of any plan when 0.3 of open62541 will be out? Or could there be a way to have a forte version with less features but compatible with 0.2?

Jens

On Tue, Sep 5, 2017 at 10:55 AM, Alois Z. <alois.zoitl@xxxxxx> wrote:
Hi,
 
unfortunately to get all the new open62541 features we had to skip 0.2 support. In order to get it working you need to use the open62541's master branch.
 
Alois
 
Gesendet: Dienstag, 05. September 2017 um 10:17 Uhr

Von: "Jens Reimann" <jreimann@xxxxxxxxxx>
An: "4diac developer discussions" <4diac-dev@xxxxxxxxxxx>
Betreff: Re: [4diac-dev] Providing RPMs for 4DIAC Forte
This is great news. I already work on adding "opcua" as a conditional build flag.
 
However now I do run into the following issue:

---
[ 50%] Building CXX object src/CMakeFiles/forte.dir/modules/opc_ua/opcua_layer.cpp.o
/home/jreimann/git/org.eclipse.4diac.forte/src/modules/opc_ua/opcua_layer.cpp: In member function ‘forte::com_infra::EComResponse COPC_UA_Layer::createMethodNode()’:
/home/jreimann/git/org.eclipse.4diac.forte/src/modules/opc_ua/opcua_layer.cpp:414:89: error: invalid conversion from ‘UA_StatusCode (*)(UA_Server*, const UA_NodeId*, void*, const UA_NodeId*, void*, const UA_NodeId*, void*, size_t, const UA_Variant*, size_t, UA_Variant*) {aka unsigned int (*)(UA_Server*, const UA_NodeId*, void*, const UA_NodeId*, void*, const UA_NodeId*, void*, long unsigned int, const UA_Variant*, long unsigned int, UA_Variant*)}’ to ‘UA_MethodCallback {aka unsigned int (*)(void*, UA_NodeId, long unsigned int, const UA_Variant*, long unsigned int, UA_Variant*)}’ [-fpermissive]
                   inputArguments, getCommFB()->getNumSD(), outputArguments, methodNodeId)) !=
                                                                                         ^
In file included from /home/jreimann/git/org.eclipse.4diac.forte/src/modules/opc_ua/opcua_layer.cpp:20:0:
/home/jreimann/git/org.eclipse.4diac.forte/src/modules/opc_ua/opcua_handler.h:89:16: error:   initializing argument 4 of ‘UA_StatusCode COPC_UA_Handler::createMethodNode(const UA_NodeId*, UA_UInt16, const char*, UA_MethodCallback, void*, unsigned int, const UA_Argument*, unsigned int, const UA_Argument*, UA_NodeId*)’ [-fpermissive]
  UA_StatusCode createMethodNode(const UA_NodeId *parentNode, UA_UInt16 namespaceIdx, const char *methodName, UA_MethodCallback callback,
                ^
make[2]: *** [src/CMakeFiles/forte.dir/modules/opc_ua/opcua_layer.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/forte.dir/all] Error 2
make: *** [all] Error 2
---
 
My C/C++ is a bit rusty ... unfortunately not in that way :-D ... so any help figuring out what is wrong is appreciated.
 
I am building with open62541 version 0.2.
 
Thanks
 
Jens
 
On Mon, Sep 4, 2017 at 10:37 PM, Alois Z. <alois.zoitl@xxxxxx> wrote:
Hi,
 
just a quick answer to your last question which seams for now for me the most important part. All OPC UA development is already in the development branch and also maintained and further developed there. The problem is that as commiter I'm currently not allowed to delete/close feature branches. I hope I can sort this out soon.
 
Cheers,
Alois
 
Gesendet: Montag, 04. September 2017 um 18:10 Uhr
Von: "Jens Reimann" <jreimann@xxxxxxxxxx>
An: "4diac developer discussions" <4diac-dev@xxxxxxxxxxx>
Betreff: Re: [4diac-dev] Providing RPMs for 4DIAC Forte
Hi Alois,
 
this is great to hear. I am currently working on getting open62541 into Fedora. Currently this looks good, the review is accepted and maybe forte could also become a port of Fedora in the future. Doing a simple 'dnf install 4diac-forte" to install forte would be great ;-)
 
I did come up with a relatively painless way of building an RPM out of forte: https://git.eclipse.org/r/#/c/104294/
 
Two allows to do a local RPM build by executing "tito build --test --rpm", or "tito build --test --srpm". This will use the content of the local git repository with the last commit (so local modifications won't be present in the build). The --rpm option will build locally. The --srpm option only creates a source RPM which can then be build e.g. on a Raspberry Pi with "rpmbuild --rebuild src.rpm". It will also apply the git commit ref to the version, indicating a snapshot build.
 
This works fine in local setup. Bringing forte to a Raspberry Pi is rather painless and involves no cross-compiling that way.
 
You can then also drop in the git repository into "copr" [1], and let copr do a CI build, much like Travis does it, but only for RPMs.
 
I would like to continue adding OPC UA support as a next step, because this is my actual interest ;) Is there any chance to see the OPC_UA branch merged soon? Or should I continue working on a branch for that?
 
Thanks for your help
 
Cheers
 
Jens
 
On Sun, Sep 3, 2017 at 8:49 PM, Alois Z. <alois.zoitl@xxxxxx> wrote:

Hi Jens,

 

until recently I would have said that it is not so interesting for 4diac. The main reason would have been that a typical 4diac users would need to compile its own FORTE with her own Fbs anyhow. However a few things happened which changed my mind a bit. First of all in an internal project we noticed how cumbersome it is to build your FORTE for different platforms, deploy it and start it. Especially in a cross compilation scenario with different compilers and target operating systems. There my colleagues are experimenting with Docker images and Gitlab CI. I haven’t seen results yet but I can keep you updated.

 

The second thing is that with the first version of integrating Lua into FORTE the need for recompiling FORTE is gone. This increases the need for providing standard prebuilt FORTEs for different platforms.

 

Therefore I think the answer is yes even if I currently don’t know how it impacts us.

 

Regarding your question 2 I must confess that I don’t know enough about rpm packages to give here an answer. The only thing that I can see is that in addition to source directories also the Cmake configuration should be adjustable. Don’t know if parameters can be given to a spec file.

 

And finally to your question 3: FORTE does not distinguish the startups. Normally in the default configuration FORTE looks on start-up if it finds in the directory it was started from (or a location specified in an environment variable) a boot file. If it finds one it tries to load it if not this step is ignored. Even if a boot-file is loaded a user can connect with the ide and remove the loaded content from a FORTE. The only thing that is currently not possible is that you connect your ide to a running forte and explore what is currently running inside. BTW this could be a nice goog le summer or code project for next year.

 

As now more and more PLCs and PLC like devices are migrating to Linux having such a systemd unit could greatly simplify the deployment of FORTEs.

 

Alois

 

 
 
Gesendet: Freitag, 01. September 2017 um 16:34 Uhr
Von: "Jens Reimann" <jreimann@xxxxxxxxxx>
An: "4diac developer discussions" <4diac-dev@xxxxxxxxxxx>
Betreff: [4diac-dev] Providing RPMs for 4DIAC Forte
Hi,
 
I was playing a bit around, creating RPMs of Forte for Fedora. My goal would be to provide a rather simple way of dropping forte into a Fedora machine.
 
Right now I am building integration builds using "copr" [1], and also for open62541 [2]. as my goal would be to have forte with OPC UA support. The current state is available on GitHub in a fork I created [3].
 
My primary motivation is to get a simple, reproducible setup on a Raspberry Pi with Forte. I already did this 2 times and every time started from scratch as I forgot the different steps. I think some "out-of-the-box" experience would help, at least me ;)
 
The following topics are still unsolved and I would like to get your feedback on that:
 
1) Would the project be interested in adopting this? I am happy to help, but if there is no interest I think it isn't any good.
2) Currently the "spec" file can only be used for CI builds, for a release build it would need to be adopted manually in order to point to a correct source location. I have no good idea here, but I am open for suggestions.
3) Currently forte is not being started. My proposal would be to create a systemd unit for starting this as a system service. From what I remember there are two ways to start forte. a) with a "boot file" and b) empty, deploying the application over the remote socket. Bot ways make sense in different scenarios to me. a) is probably more for production, while b) is more for development. So there could be two systemd unit to reflect that. One could probably start automatic when the boot file is present (copied over by some).
 
Please let me know what you think.
 
Cheers
 
Jens

[1] https://copr.fedorainfracloud.org/coprs/ctron/4diac-forte/
[2] https://copr.fedorainfracloud.org/coprs/ctron/open62541/
[3] https://github.com/ctron/org.eclipse.4diac.forte/
 

--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill
_______________________________________________ 4diac-dev mailing list 4diac-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/4diac-dev

_______________________________________________
4diac-dev mailing list
4diac-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/4diac-dev
 



--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill
_______________________________________________ 4diac-dev mailing list 4diac-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/4diac-dev

_______________________________________________
4diac-dev mailing list
4diac-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/4diac-dev
 



--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill
_______________________________________________ 4diac-dev mailing list 4diac-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/4diac-dev

_______________________________________________
4diac-dev mailing list
4diac-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/4diac-dev





--
fortiss · Landesforschungsinstitut des Freistaats Bayern
An-Institut Technische Universität München
Guerickestraße 25 
80805 München
Germany

Amtsgericht München: HRB: 176633
USt-IdNr.: DE263907002, Steuer-Nr.: 143/237/25900
Rechtsform: gemeinnützige GmbH
Sitz der Gesellschaft: München
Geschäftsführer: Dr. Harald Rueß, Thomas Vallon
Vorsitzender des Aufsichtsrats: Dr. Manfred Wolter

_______________________________________________
4diac-dev mailing list
4diac-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/4diac-dev




--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

Back to the top