A single rpm spec file has to support multiple locale of Linux [EN & JA].
Suppose it checks Java is existing, if not throws exception, "Error: Java not installed". On Japanese machine the Japanese message should be shown. In the spec file java_err_msg is declared as macro. I want to know how to localize below 'java_err_msg' to behave as Summary, Group, Description, etc.
%define java_err_msg "Error: Java not installed"
So, that spec file picks corresponding message based on locale of PC.
I am looking for solution like in the Summary, Group, description case where based on system locale rpm will display the appropriate message. As below;
Summary: AppName
Summary(ja): AppName[in Japanese]
Group: XYZ Group
Group(ja): XYZ Group[in Japanese]
Please let me know for any better solution.
I assume you are testing for java existence in an rpm %pre script let.
If you have only a single message in 2 locales, then you can
test the LC_ALL envvar and hardcode both the EN and JA messages emitting
as appropriate.
Slightly better is to write a program with proper locale handling
that is invoked in the %pre script, and emits a localized message
to stderr as appropriate.
There are no means to include an i18n error message in an rpm header
from a rpm.spec file: the only i18n tags are Summary:, Group:, and %description.
I'm not sure how to throw an exception if java does not exist. RPM is
a C, not a C++, program, and there are no exceptions in C.
Related
I really hope that someone could help me out with my problem.
I want to start an exe File (VSeeFace - see https://www.vseeface.icu for more information) on my Mac with wineskin. VseeFace is an application for Vtubing.
The application starts normally via Wineskin, but as soon as I try to open my avatar (a .vrm file), the software stops and I don't know why. I have searched everywhere and found nothing about my problem, but perhaps that is also due to my limited knowledge of development skills.
Can anyone help me please?
My Mac:
MacOS Monterey Version 12.4
Radeon Pro 575X 4 GB
My Wineskin Setup:
Wrapper Version Wineskin 2.9.1.5
Engine WS11WineCX64Bit22.0.1-1
Config Utility - Windows-Version 8
VseeFace Software – https://www.vseeface.icu/#download
They also describe how it will work on Linux or maybe Mac,
https://www.vseeface.icu/#running-on-linux-and-maybe-mac
For the Facetracking I run OpenSeeFace (but that seemed to work, I could see the green light of the iMac camera, but I couldn't test it because of my software problem).
I mean I could run the application but on the most important Screen it stops working.
In the debug.log file I noticed the following messages:
0024:err:shell:HCR_GetFolderAttributes should be called for simple PIDL's only!
0024:fixme:exec:SHELL_execute flags ignored: 0x0000000c
0118:err:module:import_dll Library dsound.dll (which is needed by L"C:\windows\system32\devenum.dll") not found
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\msdmo.dll" at 000000034ABC0000: builtin
0118:err:ole:apartment_add_dll couldn't load in-process dll L"C:\windows\system32\devenum.dll"
0118:err:ole:com_get_class_object no class object {62be5d10-60eb-11d0-bd3b-00a0c911ce86} could be created for context 0x1
0118:err:module:import_dll Library dsound.dll (which is needed by L"C:\windows\system32\devenum.dll") not found
0118:err:ole:apartment_add_dll couldn't load in-process dll L"C:\windows\system32\devenum.dll"
0118:err:ole:com_get_class_object no class object {62be5d10-60eb-11d0-bd3b-00a0c911ce86} could be created for context 0x1
0118:err:ole:apartment_add_dll couldn't find function DllGetClassObject in L"C:\windows\system32\devenum.dll"
0118:err:ole:com_get_class_object no class object {62be5d10-60eb-11d0-bd3b-00a0c911ce86} could be created for context 0x1
0118:err:ole:com_get_class_object no class object {62be5d10-60eb-11d0-bd3b-00a0c911ce86} could be created for context 0x1
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\Avrt.dll" at 00000002F2930000: builtin
0118:trace:loaddll:build_module Loaded L"C:\VSeeFace\VSeeFace_Data\Plugins\x86_64\LeapCV4.dll" at 000000010A220000: native
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\VCRUNTIME140_1.dll" at 00000002F7F20000: builtin
0118:err:module:import_dll Loading library MSVCP140_2.dll (which is needed by L"C:\VSeeFace\VSeeFace_Data\Plugins\x86_64\LeapCV5.dll") failed (error c000007b).
0118:trace:loaddll:build_module Loaded L"C:\VSeeFace\VSeeFace_Data\Plugins\x86_64\CONCRT140.dll" at 0000000104CA0000: native
0118:err:module:import_dll Loading library MSVCP140_2.dll (which is needed by L"C:\VSeeFace\VSeeFace_Data\Plugins\x86_64\LeapCV5.dll") failed (error c000007b).
[mvk-info] Created 2 swapchain images with initial size (1280, 720) and contents scale 1.0 for screen Integriertes Retina-Display.
[mvk-error] VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (Error code 2):
Vertex attribute v4(4) of type int4 cannot be read using MTLAttributeFormatUInt4.
0118:trace:loaddll:build_module Loaded L"C:\VSeeFace\UnityPlayer.dll" at 0000000180000000: native
0118:fixme:thread:get_thread_times not implemented on this platform
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\mmdevapi.dll" at 0000000336850000: builtin
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\winecoreaudio.drv" at 00000001C92D0000: builtin
0118:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel 0xffffffff
0
01b0:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFFFFFFFFFA, 0000000066D6FE10
01b0:trace:loaddll:build_module Loaded L"C:\windows\system32\avrt.dll" at 00000002F2930000: builtin
01b0:fixme:avrt:AvSetMmThreadCharacteristicsW (L"Audio",0000000066D6FDB8): stub
01b0:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\avrt.dll" : builtin
***If needed I could post the complete log file. ***
I have installed the dlls and they are in all the folders. I have also tried the installation via Winetricks, where it displays the following message:
Executing mkdir -p /Applications/Wineskin/VSeeFace.app/Contents/SharedSupport
warning: You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
Using winetricks 20220411-next - sha256sum: 846f79cac49697fd818f06a6aebf36ca408661f89b97633e9872025b33bc0e7b with wine-7.7 (WineskinCX 22.0.1) and WINEARCH=win64
Unknown arg UnityPlayer.dll
Usage: Applications/Wineskin/VSeeFace.app/Wineskin.app/Contents/Resources/winetricks [options] [command|verb|path-to-verb] ...
Executes given verbs. Each verb installs an application or changes a setting.
Options:
--country=CC Set country code to CC and don't detect your IP address
-f, --force Don't check whether packages were already installed
--gui Show gui diagnostics even when driven by commandline
--gui=OPT Set OPT to kdialog or zenity to override GUI engine
--isolate Install each app or game in its own bottle (WINEPREFIX)
--self-update Update this application to the last version
--update-rollback Rollback the last self update
-k, --keep_isos Cache isos (allows later installation without disc)
--no-clean Don't delete temp directories (useful during debugging)
-q, --unattended Don't ask any questions, just install automatically
-r, --ddrescue Retry hard when caching scratched discs
-t --torify Run downloads under torify, if available
--verify Run (automated) GUI tests for verbs, if available
-v, --verbose Echo all commands as they are executed
-h, --help Display this message and exit
-V, --version Display version and exit
Commands:
list list categories
list-all list all categories and their verbs
apps list list verbs in category 'applications'
benchmarks list list verbs in category 'benchmarks'
dlls list list verbs in category 'dlls'
fonts list list verbs in category 'fonts'
games list list verbs in category 'games'
settings list list verbs in category 'settings'
list-cached list cached-and-ready-to-install verbs
list-download list verbs which download automatically
list-manual-download list verbs which download with some help from the user
list-installed list already-installed verbs
arch=32|64 create wineprefix with 32 or 64 bit, this option must be
given before prefix=foobar and will not work in case of
the default wineprefix.
prefix=foobar select WINEPREFIX=/Users/myusername/.local/share/wineprefixes/foobar
annihilate Delete ALL DATA AND APPLICATIONS INSIDE THIS WINEPREFIX
Winetricks Commands Finished!!
When trying to use octeract with pyomo, I uncounter the following error.
2022-06-22 15:48:44,451 [ WARNING][pyomo.opt] Failed to create solver with name 'octeract-engine':
Failed to set executable for solver asl. File with name=octeract-engine either does not exist or it is not executable. To skip this validation, call set_executable with validate=False.
[...]
The SolverFactory was unable to create the solver "octeract-engine"
and returned an UnknownSolver object. This error is raised at the point
where the UnknownSolver object was used as if it were valid (by calling
method "solve").
The original solver was created with the following parameters:
executable: octeract-engine
type: octeract-engine
_args: ()
options: {}
I've tried following both octerat doc and this doc unsuccessfully.
This is the classic Pyomo message when the binary it's told to invoke (in this case octeract-engine) is not in the system PATH.
You can fix this by adding the engine to the PATH. The way to verify that this was done correctly is to start up the terminal that you use to invoke Pyomo (e.g. linux terminal or powershell), and type octeract-engine (linux) or octeract-engine.exe (windows). If the engine is in the PATH, this will print the engine's help menu, otherwise the system will complain that the binary was not found.
What's actually happening here is that Octeract Engine connects to Pyomo through an ASL interface. Pyomo simply looks for a binary in the system PATH with the "name" specified in the command. As long as that binary has an ASL interface, it will just work, however Pyomo leaves it up to the user to ensure that the binary is visible in the PATH.
Our installers actually add the binary to the PATH on all platforms by default for this reason, so try a clean reinstall and see if that fixes your issue. Otherwise, it's likely that you don't have the right permissions set up on your machine i.e., the Python version that runs Pyomo doesn't see the right PATH (e.g. if you use octeract-engine.exe on powershell but run Pyomo from cmd.exe).
I've installed GnuCOBOL 2.2 on my Ubuntu 17.04 system. I've written a basic hello world program to test the compiler.
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. HELLO-WORLD.
3 *---------------------------
4 DATA DIVISION.
5 *---------------------------
6 PROCEDURE DIVISION.
7 DISPLAY 'Hello, world!'.
8 STOP RUN.
This program is entitled HelloWorld.cbl. When I compile the program with the command
cobc HelloWorld.cbl
HelloWorld.so is produced. When I attempt to run the compiled program using
cobcrun HelloWorld
I receive the following error:
libcob: entry point 'HelloWorld' not found
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
According to the official manual of GNUCOBOL, you should compile your code with:
cobc -x HelloWorld.cbl
then run it with
./HelloWorld
You can also read GNUCOBOL wiki page which contains some exmaples for further information.
P.S. As Simon Sobisch said, If you change your file name to HELLO-WORLD.cbl to match the program ID, the same commands that you have used will be ok:
cobc HELLO-WORLD.cbl
cobcrun HELLO-WORLD
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
An entry point is a point where you may enter a shared object (this is actually more C then COBOL).
GnuCOBOL generates entry points for each PROGRAM-ID, FUNCTION-ID and ENTRY. Therefore your entry point is HELLO-WORLD (which likely gets a conversion as - is no valid identifier in ANSI C - you won't have to think about this when CALLing a program as the conversion will be done internal).
Using cobcrun internally does:
search for a shared object (in your case HelloWord), as this is found (because you've generated it) it will be loaded
search for an entry point in all loaded modules - which isn't found
There are three possible options to get this working:
As mentioned in Ho1's answer: use cobc -x, the reason that this works is because you don't generate a shared object at all but a C main which is called directly (= the entry point doesn't apply at all)
preload the shared object and calling the program by its PROGRAM-ID (entry point), either manually with COB_PRE_LOAD=HelloWorld cobcrun HELLO-WORLD or through cobcrun (option available since GnuCOBOL 2.x) cobcrun -M HelloWorld HELLO-WORLD
change the PROGRAM-ID to match the source name (either rename or change the source, I'd do the second: PROGRAM-ID. HelloWorld.)
I'm trying to resurrect an old (1999 or earlier) project written in Scheme (PLT-Scheme, using the mzscheme interpreter (?) commandline tool). To make the matters worse, I don't know Scheme, or Lisp (in fact, I want to learn, but that's another story).
I have the source code of the project at:
github.com/akavel/sherman
Now, when running the code, it bails out with an error message like below:
Sherman runtime version 0.5
Hosted on MzScheme version 52, Copyright (c) 1995-98 PLT (Matthew Flatt)
reference to undefined identifier: list->block
(I've tried PLT-Scheme versions 52, 53, 103, 103p1. Earlier versions don't allow mzscheme -L option, which is referenced in the sherman.bat script used in the project. Later versions also have some more serious problems with the code or options.)
The difficulty is, that from what I see, list->block actually is defined - see: collects/sherman/BLOCK.SS line 48. So, what is wrong?
To run the code, I perform the following steps:
Download PLT-Scheme v. 103p1 (from the old versions download page - first closing the "PLT Scheme is now Racket" banner) - for Windows, use: mz-103p1-bin-i386-win32.zip.
Unzip (e.g. to directory c:\PLT).
Copy c:\sherman\collects\sherman directory with contents to: c:\PLT\collects\sherman (where c:\sherman contains the contents of the github repository).
Run cmd.exe, then cd c:\sherman.
set PATH=c:\PLT;%PATH%
sherman.bat run trivial.s
this command is in fact, from what I understand, equivalent to:
(require-library "runtime.ss" "sherman")
(parameterize ((current-namespace sherman-namespace)) (load "trivial.s"))
(current-namespace sherman-namespace)
After that, I get the error as described above (MzScheme version would be reported as 103p1 or whatever).
Could you help me solve the problem?
EDIT 2: SOLVED!
To whom it may concern, I've added a fully fledged "How to use this project" instruction on the project page, detailing the solution to the problem thanks to soegaard's help.
In short:
copy trivial.s trivial.rs
rem (the above is workaround for problems with 'r2s.exe < trivial.r > trivial.rs')
sherman.bat compile trivial.rs
sherman.bat run trivial.zo
rem (or: sherman.bat run trivial.ss)
Not an answer, but a few notes too big for a comment.
1. Sanity Check
The error message says list->block is undefined.
Make sure that the code in block.ss is run, by
inserting (display "block.ss is loaded!") in block.ss
just to make sure, the code is run.
2. Random Thoughts
The file blocks.ss begins with:
(require-library "functios.ss")
(require-library "synrule.ss")
(require-library "stream.ss" "sherman")
The file "sherman/stream.ss" is in the repository,
but where is "synrule.ss" and "functios.ss" ?
Ah... This code is old! Here is a description of
how require-library worked. It lists functios.ss
and synrule.ss as part of MzLib.
http://www.informatik.uni-kiel.de/~scheme/doc/mzscheme/node158.htm
Let's check out how require-library worked:
When require-library is used to load a file, the library name and the
resulting value(s) are recored in a table associated with the current
namespace. If require-library is evaluated for a library that is
already registered in the current namespace's load table, then the
library is not loaded again; the result(s) recorded in the load table
is returned, instead.
So when the code in block.ss is run, the names are stored in a namespace. If the current namespace is the wrong one, when the code in block.ss is evaluated, it would explain you error message of list->block being undefined.
I'm using ant.bat (in Ant 1.7.1) to build the all target in a build.xml file, on Windows 2003 Server. (I've substituted "xxx" in the error message for the project name in that file.)
It builds successfully, but then ends with:
2009-06-10 17:26:03 | all:
2009-06-10 17:26:03 |
2009-06-10 17:26:03 | BUILD FAILED
2009-06-10 17:26:03 | Target "1" does not exist in the project "xxx".
...and returns with a non-zero error code.
I've searched build.xml unsuccessfully for anything that might lead to this error. (There is no target "1", of course, nor any dependencies that might resolve "1".)
I'm hoping someone out there might recall seeing this. I don't expect anyone to debug the XML for me, but a Google search turned up http://simile.mit.edu/mail/ReadMsg?listId=9&msgId=2735, which contains "I found an email thread on this problem and will
retry.". I wish I could find that thread.
Update - here's the command-line:
D:/build/toolchain/noarch/ant-1.7.1/bin/ant.bat all -DBRANCH_NAME="main" -DBUILD_NUMBER="66675" -DCHANGE_NUMBER="1061789" -DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1 -DGOBUILD_VICLIB_ROOT=d:/build/ob/bora-66675/compcache//viclib/ob-65655/windows -DGOBUILD_VIMBASE_ROOT=d:/build/ob/bora-66675/compcache//vimbase/ob-64494/windows -DOBJDIR="beta" -DPRODUCT_BUILD_NUMBER="82" -DPUBLISH_DIR="d:/build/ob/bora-66675/publish" -DRELTYPE="beta" -DREMOTE_COPY_SCRIPT="D:/build/toolchain/win32/python-2.5/python.exe D:/build/gobuild/script/gobuildc.py bora-66675"'
Hopefully it's of some help.
Do you have any targets that depend on "1"? Perhaps due to a typo?
<target name="SomeTarget" depends="1">
....
</target>
Update: You explained (paraphrased) that the error message was a result of the (partial) command-line
-DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1
Although there's a space between those two define statements, it's being treated like this:
-DGOBUILD_AUTO_COMPONENTS=-DGOBUILD_OFFICIAL_BUILD=1
because something is expected to follow '='. And it appears that the second '=' is being treated as a whitespace, perhaps because ANT is confused. I would not expect that. The correct way to do what you want to do is:
-DGOBUILD_AUTO_COMPONENTS="" -DGOBUILD_OFFICIAL_BUILD=1
That way, something follows the equals sign and ANT won't get confused.
could you add the commandline you are using. it could be that ant agrees with you that there is no target '1' but that it believes you are passing one in.
This posting helped me resolve this error and wanted to share my version of the problem.
Target "listener" does not exist in the project "null".
ANT will use an environment variable ANT_ARGS if it is set. I was using the -listener option and set this option in my Windows envvar, ANT_ARGS. When I pasted the options into the Env Var:
-listener org.apache.tools.ant.listener.Log4jListener -lib D:\apache-ant-1.7.1\lib
I was missing the 'minus' sign in front of the 'listener' option.
This is similar to the problem above, but was hidden by the fact that I used the envvar ANT_ARGS.
Ya goose :-) You changed the project to "xxx" in the heading but left it as "vireporting" in the error output.
So the cat's out of the bag. You may as well make our life easier and post the XML since our ability to help you (psychic debugging) is greatly limited. If you want, sanitize the XML you post (better than you sanitized the original, hopefully).
And your comment ('There is no target "1"') makes sense since that's what ant is telling you. What you may have done is inadvertently created a dependency on that non-existent target.
It turns out this error message is the result of "-DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1" in the command-line. I guess having nothing after the '=' in that -D option confuses Ant. (As an experiment, I changed "-DGOBUILD_OFFICIAL_BUILD=1" to "-DGOBUILD_OFFICIAL_BUILD=2" in this programmatically-generated command-line and the error message changed to "Target "2" does not exist in the project "xxx".")
Removing "-DGOBUILD_AUTO_COMPONENTS=" eliminated the build failure.
If someone can clearly explain why Ant emits such a strange error message in this case (or perhaps why it's not strange if one looks at it correctly), I'll accept your answer.