I have installed SwiftLint using SwiftLint.pkg in my system. Now I want to customize the rules so I have added .swiftlint.yml file in my root directory. I have added the script. I have followed the steps that are mentioned in the documentation, But somehow it's not working.
Script:
if which swiftlint >/dev/null; then
swiftlint --config "$SRCROOT/.swiftlint.yml"
else
echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi
Rule in .switlint.yml file :
custom_rules:
comma_space_rule:
regex: ",[ ]{2,}"
message: "Expected only one space after ',"
Your rule is fine! 🎉
I tried it and it is working. You just need to indent properly:
custom_rules:
comma_space_rule:
regex: ",[ ]{2,}"
message: "Expected only one space after ',"
Related
I'm working with this Yocto/ Bitbake recipe for wpa_supplicant (v2.9) which is a bbappend for this recipe. I had significant difficulties getting the associated library (libwpa_client.so) included in the install process during my Yocto/ Poky build. Eventually I created my own bbappend which contained:
# Force build of library libwpa_client.so
do_configure_append() {
echo 'CONFIG_BUILD_WPA_CLIENT_SO=y' >> wpa_supplicant/.config
}
# Avoid QA errors:
INSANE_SKIP_${PN} += " ldflags"
INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_SYSROOT_STRIP = "1"
SOLIBS = ".so"
FILES_SOLIBSDEV = ""
# Force install of libwpa_client.so
do_install_append(){
install -d ${D}${libdir}
install -m 0644 ${S}/wpa_supplicant/libwpa_client.so ${D}${libdir}
}
Using the config option CONFIG_BUILD_WPA_CLIENT_SO=y failed to install the library so thats why I went with the do_install_append() method. I find it hard to believe this hasn't come up before for others so I think I'm missing something, I can't find similar hacks/ patches.
Can't someone point out if I'm missing something obvious?? There's a patch file for v2.10 which may be associated with this issue, but I think it's more an issue with the Makefile as the library file was successfully built for v2.9, just not populated to the final image.
If this isn't a waste of half a day perhaps this will help others.
Regards,
I am attempting to install DevStack on a CentOS system. I have performed the necessary setup for running stack.sh, but when I run it I am getting the following failure:
Installing collected packages: PyYAML, zipp, importlib-metadata, stevedore, colorama, pyperclip, cmd2, pyparsing, cliff, future, stestr, os-testr
Attempting uninstall: PyYAML
Found existing installation: PyYAML 5.3
ERROR: Cannot uninstall 'PyYAML'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
+inc/python:pip_install:1 exit_trap
+./stack.sh:exit_trap:489 local r=1
++./stack.sh:exit_trap:490 jobs -p
+./stack.sh:exit_trap:490 jobs=
+./stack.sh:exit_trap:493 [[ -n '' ]]
+./stack.sh:exit_trap:499 '[' -f '' ']'
+./stack.sh:exit_trap:504 kill_spinner
+./stack.sh:kill_spinner:399 '[' '!' -z '' ']'
+./stack.sh:exit_trap:506 [[ 1 -ne 0 ]]
+./stack.sh:exit_trap:507 echo 'Error on exit'
Error on exit
+./stack.sh:exit_trap:509 type -p generate-subunit
+./stack.sh:exit_trap:512 [[ -z /opt/stack/logs ]]
+./stack.sh:exit_trap:515 /usr/bin/python3.6 /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs
ebtables v1.8.4 (nf_tables): table `broute' is incompatible, use 'nft' tool.
+./stack.sh:exit_trap:524 exit 1
Researching this on the Internet, I have learned that this failure apparently occurs when python's pip3 commamd attempts to uninstall something that was installed using distutils (including, apparently, PyYAML). I also see that somewhere in stack.sh PyYAML gets installed, then later an attempt is made to uninstall it which fails!
I have also looked at the setup.py script that comes with Devstack, but that script apparently does not use distutils. It is used elsewhere during the PyYAML install, but cannot find where it is.
Worse, there are workarounds (including using the --ignore-installed option for PIP), but I am not seeing where to place that option in stack.sh or any of the other files I have seen.
As things stand, stack.sh looks to be unusable. It is incapable of installing Devstack because of this problem.
Has anyone found a way to install Devstack and get around this problem? Is there an alternative to stack.sh? To devstack?
I have found a solution to my problem:
Do not use Devstack. Use Packstack.
I have even posted a bug report on this problem for Devstack. It doesn't appear that it is going to be fixed in the near future. Consequently, those seeking to create a development installation should use Packstack. I was able to install and run Openstack with Packstack using the instructions provided in:
https://www.linuxtechi.com/install-openstack-centos-8-with-packstack/
In the book "Embedded Linux Systems with the Yocto Project", Chapter 4 contains a sample called "HelloWorld - BitBake style". I encountered a bunch of problems trying to get the old example working against the "Sumo" release 2.5.
If you're like me, the first error you encountered following the book's instructions was that you copied across bitbake.conf and got:
ERROR: ParseError at /tmp/bbhello/conf/bitbake.conf:749: Could not include required file conf/abi_version.conf
And after copying over abi_version.conf as well, you kept finding more and more cross-connected files that needed to be moved, and then some relative-path errors after that... Is there a better way?
Here's a series of steps which can allow you to bitbake nano based on the book's instructions.
Unless otherwise specified, these samples and instructions are all based on the online copy of the book's code-samples. While convenient for copy-pasting, the online resource is not totally consistent with the printed copy, and contains at least one extra bug.
Initial workspace setup
This guide assumes that you're working with Yocto release 2.5 ("sumo"), installed into /tmp/poky, and that the build environment will go into /tmp/bbhello. If you don't the Poky tools+libraries already, the easiest way is to clone it with:
$ git clone -b sumo git://git.yoctoproject.org/poky.git /tmp/poky
Then you can initialize the workspace with:
$ source /tmp/poky/oe-init-build-env /tmp/bbhello/
If you start a new terminal window, you'll need to repeat the previous command which will get get your shell environment set up again, but it should not replace any of the files created inside the workspace from the first time.
Wiring up the defaults
The oe-init-build-env script should have just created these files for you:
bbhello/conf/local.conf
bbhello/conf/templateconf.cfg
bbhello/conf/bblayers.conf
Keep these, they supersede some of the book-instructions, meaning that you should not create or have the files:
bbhello/classes/base.bbclass
bbhello/conf/bitbake.conf
Similarly, do not overwrite bbhello/conf/bblayers.conf with the book's sample. Instead, edit it to add a single line pointing to your own meta-hello folder, ex:
BBLAYERS ?= " \
${TOPDIR}/meta-hello \
/tmp/poky/meta \
/tmp/poky/meta-poky \
/tmp/poky/meta-yocto-bsp \
"
Creating the layer and recipe
Go ahead and create the following files from the book-samples:
meta-hello/conf/layer.conf
meta-hello/recipes-editor/nano/nano.bb
We'll edit these files gradually as we hit errors.
Can't find recipe error
The error:
ERROR: BBFILE_PATTERN_hello not defined
It is caused by the book-website's bbhello/meta-hello/conf/layer.conf being internally inconsistent. It uses the collection-name "hello" but on the next two lines uses _test suffixes. Just change them to _hello to match:
# Set layer search pattern and priority
BBFILE_COLLECTIONS += "hello"
BBFILE_PATTERN_hello := "^${LAYERDIR}/"
BBFILE_PRIORITY_hello = "5"
Interestingly, this error is not present in the printed copy of the book.
No license error
The error:
ERROR: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb: This recipe does not have the LICENSE field set (nano)
ERROR: Failed to parse recipe: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
Can be fixed by adding a license setting with one of the values that bitbake recognizes. In this case, add a line onto nano.bb of:
LICENSE="GPLv3"
Recipe parse error
ERROR: ExpansionError during parsing /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
[...]
bb.data_smart.ExpansionError: Failure expanding variable PV_MAJOR, expression was ${#bb.data.getVar('PV',d,1).split('.')[0]} which triggered exception AttributeError: module 'bb.data' has no attribute 'getVar'
This is fixed by updating the special python commands being used in the recipe, because #bb.data was deprecated and is now removed. Instead, replace it with #d, ex:
PV_MAJOR = "${#d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${#d.getVar('PV',d,1).split('.')[1]}"
License checksum failure
ERROR: nano-2.2.6-r0 do_populate_lic: QA Issue: nano: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]
This can be fixed by adding a directive to the recipe telling it what license-info-containing file to grab, and what checksum we expect it to have.
We can follow the way the recipe generates the SRC_URI, and modify it slightly to point at the COPYING file in the same web-directory. Add this line to nano.bb:
LIC_FILES_CHKSUM = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
The MD5 checksum in this case came from manually downloading and inspecting the matching file.
Done!
Now bitbake nano ought to work, and when it is complete you should see it built nano:
/tmp/bbhello $ find ./tmp/deploy/ -name "*nano*.rpm*"
./tmp/deploy/rpm/i586/nano-dbg-2.2.6-r0.i586.rpm
./tmp/deploy/rpm/i586/nano-dev-2.2.6-r0.i586.rpm
I have recently worked on that hands-on hello world project. As far as I am concerned, I think that the source code in the book contains some bugs. Below there is a list of suggested fixes:
Inheriting native class
In fact, when you build with bitbake that you got from poky, it builds only for the target, unless you mention in your recipe that you are building for the host machine (native). You can do the latter by adding this line at the end of your recipe:
inherit native
Adding license information
It is worth mentioning that the variable LICENSE is important to be set in any recipe, otherwise bitbake rises an error. In our case, we try to build the version 2.2.6 of the nano editor, its current license is GPLv3, hence it should be mentioned as follow:
LICENSE = "GPLv3"
Using os.system calls
As the book states, you cannot dereference metadata directly from a python function. Which means it is mandatory to access metadata through the d dictionary. Bellow, there is a suggestion for the do_unpack python function, you can use its concept to code the next tasks (do_configure, do_compile):
python do_unpack() {
workdir = d.getVar("WORKDIR", True)
dl_dir = d.getVar("DL_DIR", True)
p = d.getVar("P", True)
tarball_name = os.path.join(dl_dir, p+".tar.gz")
bb.plain("Unpacking tarball")
os.system("tar -x -C " + workdir + " -f " + tarball_name)
bb.plain("tarball unpacked successfully")
}
Launching the nano editor
After successfully building your nano editor package, you can find your nano executable in the following directory in case you are using Ubuntu (arch x86_64):
./tmp/work/x86_64-linux/nano/2.2.6-r0/src/nano
Should you have any comments or questions, Don't hesitate !
In a configure file (#!/bin/sh/) generated by autoconf, there is a paragraph inside like the following:
if ac_fn_cxx_try_compile "$LINENO"; then :
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
$as_echo "yes" >&6; }
succeeded=yes
found_system=yes
else
fi
And when I execute ./configure it tells me "syntax error near unexpected token `fi'" at that line. It is not the end of the file.
In line with the comment:
if ac_fn_cxx_try_compile "$LINENO"; then
$as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
$as_echo "yes" >&6;
succeeded=yes
found_system=yes
else
## look nothing here !!
## at least put a ':'
## or delete else altogether
fi
In addition, I have found why autoconf generates such configure file. I copied the configure.ac from Windows and it has ^M as return. Autoconf thinks ^M is something and add it into else...
I ran into this error when compiling libtorrent with minGW.
The problem was a m4 macro saved as a DOS file. Converting "ax_boost_base.m4" to linux file endings did the trick.
I am almost sure I have misconfigured GIT on my windows: It converts all files to DOS which is no good idea.
we have a build environ which sources a script for few environment settings as follows
if test -f build_env
then
# Source the config file
. build_env
but some how this seems to be failing in RHEL6
sh-4.1$ . build_env
sh: .: build_env: file not found
while in RHEL4 it works
sh-3.00$ . buildenv
sh-3.00$
what could be the issue ?
Try . ./build_env (notice './').
Also, your if syntax is doubtful, though I can't be sure until you fix formatting in the question. I would write it like this:
if test -f build_env; then . ./build_env; fi