Package Details: salome-meca-bin 2020.0.1-1

Git Clone URL: https://aur.archlinux.org/salome-meca-bin.git (read-only, click to copy)
Package Base: salome-meca-bin
Description: Integration of the Code_Aster solver in the Salome platform
Upstream URL: https://www.code-aster.org/spip.php?article303
Licenses: LGPL
Provides: salome-meca
Submitter: m-pilia
Maintainer: m-pilia
Last Packager: m-pilia
Votes: 3
Popularity: 0.018429
First Submitted: 2017-12-01 13:56
Last Updated: 2021-03-20 21:39

Latest Comments

1 2 3 4 Next › Last »

tiaschaer commented on 2021-01-17 20:18

The previously mentioned error "undefined symbol: MEDlibraryNumVersion" (see my posty on 2020-12-28) has been solved by downgrading the med package (community repository) to version 4.0.0-8. Newer versions (current version is 4.1.0-3) brake the execution of CodeAster computations.

tiaschaer commented on 2020-12-28 15:43

After my last Arch update the Shaper, Geometry, Mesh and AsterStudy modules work... till I try to run the simulation. No matter which study I run, I always get the same error in the log file: ...
/opt/salome_meca/V2019.0.3_universal/tools/Code_aster_stable-v144_smeca/bin/aster: symbol lookup error: /opt/salome_meca/V2019.0.3_universal/tools/Code_aster_stable-v144_smeca/bin/aster: undefined symbol: MEDlibraryNumVersion EXECUTION_CODE_ASTER_EXIT_335693-0001-arch-tia=127 <INFO> Code_Aster run ended, diagnostic : <F>_ABNORMAL_ABORT ... To me, this has to do with changes in some library due to the update. Anyone having the same issue?

tiaschaer commented on 2020-12-04 15:04

As for blixawillbargeld, I had to install libffi6 from AUR in order to be able to run the module AsterStudy within Salome_Meca. Otherwise, the package allows for a very easy installation of Salome_Meca, good job!

blixawillbargeld commented on 2020-04-16 06:42

The recent libfft update breaks Aster-Study for me. Workaround is to install libffi6 from AUR. Any other (better) solutions?

m-pilia commented on 2020-03-13 13:44

@franksmaia: You're welcome! Those warnings that you see should be ok. There is a grep command in the PKGBUILD that fixes all symlinks pointing to the temporary build directory, making them point to the final installation directory. Since there are loops in the folder structure, grep warns about it, but it is ok. I have not suppressed that output to avoid masking actual errors, in case there was any.

franksmaia commented on 2020-03-13 01:20

@m-pilla: Thanks for updating the package! Indeed I have gconf installed. I am installing now and got some errors/warnings while fixing references:

-> Fixing references... grep: ~/.cache/yay/salome-meca-bin/src/salome_meca/V2019.0.3_universal/prerequisites/Python-365/lib/python3.6/config: No such file or directory grep: warning: ~/.cache/yay/salome-meca-bin/src/salome_meca/V2019.0.3_universal/modules/ASTERSTUDY_201903/lib/salome: recursive directory loop grep: warning: ~/.cache/yay/salome-meca-bin/src/salome_meca/appli_V2019.0.3_universal/lib/salome/lib/salome/lib: recursive directory loop

I presume that everything is fine as there was not complains about referencing the building directory.

m-pilia commented on 2020-03-10 20:29

@franksmaia: Sorry again for the late reply. For the references to $srcdir, the virtual_salome.pyc contains the bytecode for one of the scripts used during the installation, and I think it should be fine to remove it from the final package, since it should be used only to install salome. For the DBUS error, it looks like an error caused by gconftool-2 (I assume you have the gconf package installed). I noticed in the install script there were some gconftool-2 calls to set configuration variables, and I removed them since I think they should not be in a PKGBUILD in the first place.

m-pilia commented on 2020-03-01 11:21

@franksmaia: Sorry for the late reply, unfortunately I have been rather busy over the last few weeks. In the incoming week I will be looking to the issues you reported!

franksmaia commented on 2020-02-29 16:45

==> Starting package()... -> Building virtual application... Error setting value: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Error setting value: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Setting for help already set Adjusting the file : ~/.cache/yay/salome-meca-bin/src/salome_meca/appli_V2019.0.3_universal/SalomeApp.xml `

franksmaia commented on 2020-01-19 21:04

Hi m-pilia. Thank you for updating the package!

I have gotten warnings regarding references to the source directory. The binary virtual_salome.pyc is referencing ~/.cache/yay/salome-meca-bin/... instead of /opt/...

==> WARNING: Package contains reference to $srcdir opt/salome_meca/V2019.0.3_universal/modules/KERNEL_V9_3_0/bin/salome/virtual_salome.pyc

Is it something easy to fix? Please let me know if I can help somehow.