I am trying to build LineageOS 17.1 bacon based on the steps here: https://wiki.lineageos.org/devices/bacon/build
All steps until the below failure have been successful. Everything is the latest leading to LINEAGE_VERSION=17.1-20210324-UNOFFICIAL-bacon
brunch bacon returns the following failure. This is my first android build, web search did not yield anything useful on how to fix this. Currently, I am clueless, any help/suggestions on how to fix this are very welcome.
[ 75% 372/496] including system/sepolicy/Android.mk ...
system/sepolicy/Android.mk:89: warning: Be careful when using the SELINUX_IGNORE_NEVERALLOWS flag. It does not work in user builds and using it will not stop you from failing CTS.
[100% 496/496] writing build rules ...
build/make/core/Makefile:28: warning: overriding commands for target `out/target/product/bacon/system/vendor/lib/hw/android.hardware.nfc#1.0-impl.so'
build/make/core/base_rules.mk:510: warning: ignoring old commands for target `out/target/product/bacon/system/vendor/lib/hw/android.hardware.nfc#1.0-impl.so'
FAILED: ninja: 'vendor/oppo/msm8974-common/proprietary/vendor/bin/hci_qcomm_init', needed by 'out/target/product/bacon/system/vendor/bin/hci_qcomm_init', missing and no known rule to make it
18:51:33 ninja failed with: exit status 1
Could the above error be due to the missing source?:
$ ./extract-files.sh
Cleaning output directory (./../../oppo/msm8974-common/../../../vendor/oppo/msm8974-common/proprietary)..
Extracting 115 files in ./../../oppo/msm8974-common/proprietary-files.txt from adb:
- vendor/bin/adsprpcd
- vendor/bin/hci_qcomm_init
!! vendor/bin/hci_qcomm_init: file not found in source
Edit: Answering my own question, one has to run adb root on the terminal that guides you want needs to be done on the phone. This can be closed. #lineageos-dev is the place to ask such a question.
Answering my own question, one has to run adb root on the terminal that guides you to do what needs to be done on the phone. This can be closed. #lineageos-dev is the place to ask such a question.
I can't seem to understand why this just wouldn't install, it keeps failing and I have no idea how to proceed. Does anyone have any ideas as to why the installer would behave this way ?
Here is the bug filed at Google's Issue Tracker - https://issuetracker.google.com/issues/37366016
Greatly appreciate any help :)
As noted in the comments on this Q&A, the issue derives from a line in the installer which needs to be removed. The original comment by user "Valentin":
In your case, I think you can use the versioned archive method at
cloud.google.com/sdk/downloads#versioned Once you download it, instead
of running .\google-cloud-sdk\install.bat, open the file in an editor
and remove the line "echo %CmdCmdLine% | find /i "%~0" >nul". Then you
can run install.bat and finish the installation. Please still file a
bug so we can keep track of this.
OP noted that they filed an issue, so this is the appropriate resolution for anyone who sees this. I'd only request that OP update this thread with a link to their issue so other users can find it and watch for progress if they're interested.
May be I am missing something but I have not found a dedicated place in WebStorm where I can see (and navigate) all errors reported by TSLint.
In the best case I can find the errors while opening a file and pressing F2 (to go to Next Highlighted Error) which not always working as well.
PS. There is a dedicated TypeScript Pane/l in WebStorm but it doesn't show any TSLint errors, neither these reported in Event Log Pane/l.
Select npm tab from the bottom left side.
Run linting script (you must have it in package.json).
See screenshot below for example:
List of tslint errors/warnings
I am having problems with Teamcity, where it is proceeding to run build steps even if the previous ones were unsuccessful.
The final step of my Build configuration deploys my site, which I do not want it to do if any of my tests fail.
Each build step is set to only execute if all previous steps were successful.
In the Build Failure Conditions tab, I have checked the following options under Fail build if:
-build process exit code is not zero
-at least one test failed
-an out-of-memory or crash is detected (Java only)
This doesn't work - even when tests fail TeamCity deploys my site, why?
I even tried to add an additional build failure condition that will look for specific text in the build log (namely "Test Run Failed.")
When viewing a completed test in the overview page, you can see the error message against the latest build:
"Test Run Failed." text appeared in build log
But it still deploys it anyway.
Does anyone know how to fix this? It appears that the issue has been running for a long time, here.
Apparently there is a workaround:
So far we do not consider this feature as very important as there is
an obvious workaround: the script can check the necessary condition
and do not produce the artifacts as configured in TeamCity.
e.g. a script can move the artifacts from a temporary directory to the
directory specified in the TeamCity as publish artifacts from just
before the finish and in case the build operations were successful.
But that is not clear to me on exactly how to do that, and doesn't sound like the best solution either. Any help appreciated.
Edit: I was also able to workaround the problem with a snapshot dependency, where I would have a separate 'deploy' build that was dependent on the test build, and now it doesn't run if tests fail.
This was useful for setting the dependency up.
This is a known problem as of TeamCity 7.1 (cf. http://youtrack.jetbrains.com/issue/TW-17002) which has been fixed in TeamCity 8.x+ (see this answer).
TeamCity distinguishes between a failed build and a failed build step. While a failing unit test will fail the build as a whole, unfortunately TeamCity still considers the test step itself successful because it did not return a non-zero error code. As a result, subsequent steps will continue running.
A variety of workarounds have been proposed, but I've found they either require non-trivial setup or compromise on the testing experience in TeamCity.
However, after reviewing a suggestion from #arex1337, we found an easy way to get TeamCity to do what we want. Just add an extra Powershell build step after your existing test step that contains the following inline script (replacing YOUR_TEAMCITY_HOSTNAME with your actual TeamCity host/domain):
$request = [System.Net.WebRequest]::Create("http://YOUR_TEAMCITY_HOSTNAME/guestAuth/app/rest/builds/%teamcity.build.id%")
$xml = [xml](new-object System.IO.StreamReader $request.GetResponse().GetResponseStream()).ReadToEnd()
Microsoft.PowerShell.Utility\Select-Xml $xml -XPath "/build" | % { $status = $_.Node.status }
if ($status -eq "FAILURE") {
throw "Failing this step because the build itself is considered failed. This is our way to workaround the fact that TeamCity incorrectly considers a test step to be successful even if there are test failures. See http://youtrack.jetbrains.com/issue/TW-17002"
}
This inline PowerShell script is just using the TeamCity REST API to ask whether or not the build itself, as a whole, is considered failed (the variable %teamcity.build.id%" will be replaced by TeamCity with the actual build id when the step is executed). If the build as a whole is considered failed (say, due to a test failure), then this PowerShell script throws an error, causing the process to return a non-zero error code which results in the individual build step itself to be considered unsuccessful. At that point, subsequent steps can be prevented from running.
Note that this script uses guestAuth, which requires the TeamCity guest account to be enabled. Alternately, you can use httpAuth instead, but you'll need to update the script to include a TeamCity username and password (e.g. http://USERNAME:PASSWORD#YOUR_TEAMCITY_HOSTNAME/httpAuth/app/rest/builds/%teamcity.build.id%).
So, with this additional step in place, all subsequent steps set to execute "Only if all previous steps were successful" will be skipped if there are any previous unit test failures. We're using this to prevent automated deployment if any of our NUnit tests are not successful until JetBrains fixes the problem.
Thanks to #arex1337 for the idea.
Just to prevent confusion, this issue is fixed in Team City v8.x, We don't need those workarounds now.
You can specify the step execution policy via the Execute step option:
Only if build status is successful - before starting the step, the build agent requests the build status from the server, and skips the step if the status is failed.
https://confluence.jetbrains.com/display/TCD8/Configuring+Build+Steps
Of course you need to fail the build if at least one unit test failed:
https://confluence.jetbrains.com/display/TCD8/Build+Failure+Conditions
On the Build Failure Conditions page, the Fail build if area, specify when TeamCity will fail builds:
at least one test failed: Check this option to mark the build as failed if the build fails at least one test.
This is (as you have found) a known issue with TeamCity, there are a set of linked issues in their Issue Tracker. This issue is hopefully scheduled to be resolved in the next release of TeamCity (version 8.x)
In the mean time, the way we identified to resolve the issue (for version 6.5.5) was to download the test results file as part of the later steps. This was then parsed to check for any test failures, returning an error code and hence breaking the build properly (performing any cleanup we needed as part of that failure) which would probably work for you.
TeamCity build failure does not mean that it will stop the build and it will publish the artifacts if your build is providing the the build output files as required by TeamCity. It will only update the build status properly.
But, you can very well stop the build process by modification to your build script to stop the build on test case failure. If you are using MSBuild, then ContinueOnError="false" will do that.
In the end, I was able to solve the problem with a snapshot dependency, where I would have a separate 'deploy' build that was dependent on the test build, and now it doesn't run if tests fail.
This was useful for setting the dependency up.
I've build a msi installer using a VS2010 setup project.
Now the project does not deinstall because of a "1001 Exception: Invalid format for argument machineName" (see below) inside a custom action.
I am unsucessful at uninstalling the application using the remove from the system control or msiexec /uninstall.
Is there a way to force uninstallation?
Details:
As part of a custom action I register a custom event source which my app uses for event loging into the windows log:
public override void Install(IDictionary stateSaver) {
base.Install(stateSaver);
EventLog.CreateEventSource("VeodinRecorder","Application");
}
inside of the "Uninstall" I try to remove this Eventsource with
if (!EventLog.SourceExists("VeodinRecorder"))
EventLog.Delete("VeodinRecorder"); `
The EventLog.Delete also takes machinename as second argument
So I tried to overwrite the msi used for uninstallation with msiexec /fv and changed the uninstall action:
EventLog.Delete("VeodinRecorder",".");
EventLog.Delete("VeodinRecorder","Application");
I even left the whole "uninstall action" blank.
But nothing seemed to work.
Any Hints?
The full log:
Error 1001. Error 1001. An exception occurred while uninstalling. This exception will be ignored and the uninstall will continue. However, the application might not be fully uninstalled after the uninstall is complete. --> Invalid format for argument machineName.
MSI (s) (60!68) [22:49:00:101]:
DEBUG: Error 2769: Custom Action _3C1D0358_8969_4B01_B8FA_B6B43F4E9E4C.uninstall did not close 1 MSIHANDLEs.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: _3C1D0358_8969_4B01_B8FA_B6B43F4E9E4C.uninstall, 1,
CustomAction _3C1D0358_8969_4B01_B8FA_B6B43F4E9E4C.uninstall returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 22:49:00: InstallExecute. Return value 3.
Action ended 22:49:00: INSTALL. Return value 3.
It seems that the CustomAction.dll was not updated when I update the installation with msiexec /fv.
I now manually placed the newly build CustomAction.dll (with an empty uninstall override) into the installation folder and was able to uninstall.
Update: (Credits to #pcans) use ORCA to edit the currently installed msi and manually disable the uninstall custom action.
Just for reference I want to add that you can also patch the installed product with a minor upgrade to remove any faulty actions in the uninstall sequence before it gets called. This works because a minor upgrade is a reinstall of the same product, and not an uninstall and a reinstall of a new version (which is a major upgrade). You hence replace the uninstall sequence with a correct one before the erronous one gets run.
Creating the patch is quite complicated though, even with professional tools such as Wise or Installshield, but in certain cases this is the only fix that works to get the package properly uninstalled. A package "in the wild" in a company should be fixed this way.
Finally you can use msizap.exe from Microsoft to unregister a whole faulty package from the Windows Installer database, but this is not good since changes to the system are not rolled back at all and lots of junk is left everywhere. The tool itself also seems a bit shaky at times, sometimes creating new errors that are really difficult to fix. Preferably use it for debugging only.
One further note in this already long reply: a special case is when you run a custom action only during the uninstall sequence, and it then returns a faulty return code - sometimes even if it performed its operations ok. These actions can trigger a very annonying "uninstall only rollback situation". Effectively your uninstall is rolled back when it hits the custom action that was never run during install. This will rollback the uninstall and hence work as an installation - your product is left on the machine. Quite strange.
The bottom line: skip return codes for custom actions that are run during uninstall, use other verification mechanisms to ensure the action succeeded.