I am currently building a project in a (Singularity) container, and one of the dependencies is the FBX SDK (for building Qt static).
The problem is that the installer of FBX reads the licence conditions and then asks to confirm those, and as the installation by recipe don't allow me answer manually, it produces an endless repetition of the lines
To continue installing the software, you must agree
to the terms of the software license agreement.
Type "yes" to agree and continue the installation. Agree [yes/no] ?
Now I did some research into how to auto confirm such things and found How do I script a "yes" response for installing programs?.
Given the answers there, I tried the following lines:
yes | ./fbx20190_fbxsdk_linux
yes Y | ./fbx20190_fbxsdk_linux
echo yes | ./fbx20190_fbxsdk_linux
(Second line just in case, as the installer clearly wants a "yes".)
None of those worked. Is there some other trick I could try? Or another way to install FBX?
(Note: the lines above do at least something, that is they automatically confirm File(s) will be extracted to: . Please confirm [y/n] ?)
...as the installer clearly wants a "yes"
In that case, try this:
yes yes | ./fbx20190_fbxsdk_linux
By default, the yes command does not send "yes" to the subsequent process, only y. You can override this behavior by giving a command line parameter as you did in your second attempt above. However, there you inokved it as yes Y which does not send a "yes" either, it sends Y.
The parameter to yes must be the string that you want to send to ./fbx20190_fbxsdk_linux, hence yes yes.
Related
I install DAHDI on Debian stable (Buster) via module-assistant like this:
apt-get install dahdi dahdi-source module-assistant
module-assistant auto-install dahdi
I also create /etc/dahdi/system.conf and /etc/dahdi/assigned-spans.conf.
I cannot figure out who calls dahdi_cfg during system boot. I can confirm that it does get called by something, because if I remove dahdi_cfg and reboot, echo and dahdi_echocan_oslec modules are missing from lsmod (echo cancellation is specified in system.conf).
I found /usr/share/dahdi/span_config.d/10-dahdi-cfg, but I have no idea what may run this.
So, where is dahdi_cfg called from during system boot?
UPDATE
I found out that if system.conf is missing, echo cancellation modules are loaded anyways. Mandatory conditions are:
presence of dahdi_cfg
/etc/dahdi/assigned-spans.conf
UPDATE2
One more observation: if /etc/dahdi/assigned-spans.conf is removed and options dahdi auto_assign_spans=1 is added to /etc/modprobe.d/dahdi.conf, echo cancellation modules are not loaded (system.conf is still removed). So it seems auto_assign_spans=1 is not working.
Can anybody answer new questions in my answer?
First of all, let's deal with auto_assign_spans=1:
Remove auto_assign_spans=1. Result: /proc/dahdi/ is empty.
Use auto_assign_spans=1. Result: /proc/dahdi/ is not empty.
So, this is the way how to check the effect of auto_assign_spans=1.
This is the example:
Span 1: WCTDM/0 "Wildcard TDM410P" (MASTER)
1 WCTDM/0/0 RED
2 WCTDM/0/1
3 WCTDM/0/2
4 WCTDM/0/3
Now run dahdi_genconf system and check /proc/dahdi/1 again:
Span 1: WCTDM/0 "Wildcard TDM410P" (MASTER)
1 WCTDM/0/0 FXSKS RED
2 WCTDM/0/1 FXOKS
3 WCTDM/0/2 FXOKS
4 WCTDM/0/3 FXOKS
We have seen that dahdi_genconf messes with the span. Is this a bug?
Then run dahdi_cfg and check /proc/dahdi/1 again:
Span 1: WCTDM/0 "Wildcard TDM410P" (MASTER)
1 WCTDM/0/0 FXSKS RED (EC: OSLEC - INACTIVE)
2 WCTDM/0/1 FXOKS (EC: OSLEC - INACTIVE)
3 WCTDM/0/2 FXOKS (EC: OSLEC - INACTIVE)
4 WCTDM/0/3 FXOKS (EC: OSLEC - INACTIVE)
Now we see that everything is properly configured.
Next, dahdi_handle_device is called by udev. It does nothing (because auto_assign_spans=1 is used).
Then dahdi_span_config is called by udev. It does nothing also for the same reason.
And this is the interesting part: dahdi_cfg is not called if auto_assign_spans=1 is used. Is this a bug?
------------------------------
On the contrary, if auto_assign_spans=1 is not used, dahdi_cfg is called by dahdi_span_config.
This is a bit confusing. Why is it prohibited to run dahdi_cfg if auto_assign_spans=1 is used? If we have only one card, this is perfectly acceptable. auto_assign_spans=1 is even documented in dahdi-tools README as the use case for such scenario:
Normally (with auto_assign_spans=1 in the module
dahdi, which is the default), when a device is discovered and loaded,
it registers with the DAHDI core and its spans automatically become
available. However if you have more than one device, you may be
interested to set explicit spans and channels numbers for them.
Is it safe to add dahdi_cfg to dahdi_span_config manually?
BTW, system.conf need not even be created - it is generated dynamically if it does not exist, but again, only if auto_assign_spans=1 is not used.
If this deficiency is corrected somehow, the only thing needed to configure DAHDI would be just
echo options dahdi auto_assign_spans=1 >/etc/modprobe.d/dahdi.conf
Use the following patch for /lib/udev/rules.d/60-dahdi.rules:
+SUBSYSTEM=="dahdi_spans", RUN+="/usr/sbin/dahdi_cfg"
LABEL="dahdi_add_end"
I would like to execute a command that takes a specific file in the project (building it as necessary) and sends it somewhere externally. For example, it may be a command that uploads a web page, or sends an e-mail. It may even write some additional files, such as a log, but that is not the point of calling it.
In other words, this action is evoked by naming its source, rather than the target — either because there is no tangible target, or it is insignificant and the action is primarily wanted for its side effect.
I see it that an extra command line argument will have to be provided, like this:
% BuildSystem send pizza.box
The command above should be equivalent to the following:
% BuildSystem pizza.box
% send pizza.box
Can (and "should") this be performed with the shake build system?
P.S. As Daniel suggests in an answer, I can extend shake's argument parser. But I am not sure if this is the best practice for a case like this. It seems a little at odds with the way shake behaves, treating every single command line argument as a self-contained goal. It is also a whole new logic for the operator to design, so much overhead for such a menial task.
It might be more intuitive to request a receipt file for each box that is sent. For instance:
% BuildSystem pizza.receipt
— would then be equivalent to:
% BuildSystem pizza.box
% send pizza.box >pizza.receipt
On the downside, as I understand from an official answer to a question nearby,we cannot have a pseudo-target like pizza.send that does not actually result in a file pizza.send being created. So I am not sure, again, if this is the right way.
P.S. 2 It would be even better if we could replace the default "file exists" success verifier with a custom code. For instance, instead of verifying that a file pizza.receipt (that we otherwise have no need for) was indeed created, we may telephone the customer and ask them if they enjoyed the lunch. If we can arrange that, we can then invoke the corresponding rule with a "pseudo-file" target pizza.send. In general, build artifacts need not reside on the local file system at all, insofar as the code that can verify and retrieve them is given.
The answer depends on whether you want to send the email once, or repeatedly, even if pizza.box doesn't change. In both cases let's imagine you want to write BuildSystem send.pizza.box to cause the email to be sent.
Send every time
If you want to send a copy of pizza.box every time you can use a phony rule:
phony "send.pizza.box" $ do
need ["pizza.box"]
cmd_ "send-email" "pizza.box"
If you want that to work for all files, you can generalise to:
phonys $ \s -> case stripPrefix "send." s of
Nothing -> Nothing
Just file -> Just $ do
need [file]
cmd_ "send-email" [file]
Send once
If you only want one copy of each changed pizza.box to be sent then you need to record evidence of that locally, to stop sending successive copies. The easiest way to do that is actually create a file send.pizza.box:
"send.*" %> \out -> do
let src = drop 5 out
need [src]
cmd_ "send-email" [src]
writeFile' out ""
If you strongly want to avoid writing the send.pizza.box file you can use the phony technique from above combined with addOracle (but it's unlikely to be worth the additional hassle).
Yes, shake supports this via phony.
I note that when cygwin's setup.exe installs packages now, it looks for a file named "setup.zst.sig" first. What's the content and format of this binary file? How to produce a valid "setup.zst.sig"?
This must have been a recent change. Previously it looked for "setup.exe.sig" first. I use the feature (to detect whether "setup.exe.sig" changed) to decide whether my cygwin installation needs to be updated. See also this for an application example.
EDIT: #matzeri:
setup.zst.sig is not yet used.
The "zst" functionality was introduced in the program to eventually replace the
previous compression methods of setup.ini and the packages
const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
For checking the update of setup-ARCH.exe you need to use the standard signature.
https://cygwin.com/setup-x86.exe.sig
https://cygwin.com/setup-x86_64.exe.sig
The pop up you shows seems to happen only on FTP mirror server, the HTTP servers
do not produce it.
It is clearly a bug in setup
https://cygwin.com/ml/cygwin/2019-02/msg00153.html
According to the documentation, the .sig files carry a SHA-512 hash of the respective file without that extension, signed with the private key available only to Cygwin the company.
https://www.cygwin.com/faq.html#faq.setup.install-security
I have created an RPM and that installs successfully. After installing, when I tried to verify the RPM with --verify command I am getting an error on executable file X it returns as
...P /location/to/file/X
I don't know what is mean P. The file has a special capability to listen the ports set by setcap. Can you please tell me what is mean by P? I have searched through Google but did't get any luck. Thanks in advance
As explained (albeit briefly) in the rpm man page:
rpm {-V|--verify} [select-options] [verify-options]
Verifying a package compares information about the installed files in the package with information about the files taken from the package metadata stored in the rpm database. Among other things, verifying compares the size, digest, permissions, type, owner and group of each file. Any discrepancies are displayed. Files that were not installed from the package, for example, documentation files excluded on installation using the "--excludedocs" option, will be silently ignored.
The format of the output is a string of 8 characters, a possible attribute marker:
....
from the package header, followed by the file name. Each of the 8 characters denotes the result of a comparison of attribute(s) of the file to the value of those attribute(s) recorded in the database. A single "." (period) means the test passed, while a single "?" (question mark) indicates the test could not be performed (e.g. file permissions prevent reading). Otherwise, the (mnemonically emBoldened) character denotes failure of the corresponding --verify test:
....
P caPabilities differ
So the capability of the file in question differs on disk from the capabilities of the file as listed in the rpm files section. How it differs is up to you to find out (and possibly fix).
I am using following command to sync B vob files from A vob
clearfsimport -master -follow -nsetevent -comment $2 /vobs/A/xxx/*.h /vobs/B/xxx/
It works fine. But it will check in all the changes automatically. Is there a way to do the same task but leave the update files in a check out status?
I want to update the file for B from A. Build my programme, and then re-cover the branch. So if the updated files is an check out status, I can do unco later. Well with my command before, everything is checked in. I cann't re-cover my branch then.
Thanks.
As VonC said, it's impossible to prevent "clearfsimport" to do the check in. And he suggested to use a label to recover back.
For me, the branch where I did "clearfsimport" is branched from a label.Let's call it LABEL_01. So I guess I can use that label for recovery. Is there an easy way (one command) to recover the files under /vobs/B/xxx/ to label LABEL_01 ? I want to do it in my bash script, so the less/easy the command is, the better.
Thanks.
After having a look at the man page for clearfsimport, no, it isn't possible to prevent the checkins.
I would set a label before the clearfsimport, and modify the config spec for the new version to be created in a branch (similar to this config spec).
That way, "re-cover" the initial branch would be easy: none of the new version would have been created in it.