I am building linux kernel, if my kernel under git, then kernel version every time is:
Image Name: Linux-2.6.39+
If I am not using git, then everything is OK without any plus at the end.
I know that this done by scripts/setlocalversion script:
if test "$CONFIG_LOCALVERSION_AUTO" = "y"; then
# full scm version string
res="$res$(scm_version)"
else
# append a plus sign if the repository is not in a clean
# annotated or signed tagged state (as git describe only
# looks at signed or annotated tags - git tag -a/-s) and
# LOCALVERSION= is not specified
if test "${LOCALVERSION+set}" != "set"; then
scm=$(scm_version --short)
res="$res${scm:++}"
fi
fi
So, it is possible without code changes say to build system that no need to add "+" at the end of version line?
The plus sign at the end of your version string is there as an indicator that the kernel was built from modified sources (that is, there were non-committed changes). This is also indicated by the comments in scripts/setlocalversion.
To avoid the '+' being appended despite having a dirty working directory, simply set LOCALVERSION explicityly when running make:
make LOCALVERSION=
You may also have to change the configuration option CONFIG_LOCALVERSION_AUTO to n in your kernel config (.config) before building:
sed -i "s|CONFIG_LOCALVERSION_AUTO=.*|CONFIG_LOCALVERSION_AUTO=n|" .config
To prevent the script scripts/setlocalversion to append the + to the end of the kernel local version, create an empty .scmversion file in the root of the kernel sources.
touch .scmversion
this way, you'll be able to leave LOCALVERSION as is in the kernel configuration file, in case you want to append a local signature to the kernel name.
Manipulating scripts/setlocalversion seems to be the only way for me.
Force return in scm_version():
scm_version()
{
local short
short=false
**return**
Add this line to your local.conf if you're using yocto and imx soc
SCMVERSION_pn-linux-imx = ""
Tested on imx-4.9.88-2.0.0_ga release
Just comment the line as a workaround/quickfix in scripts/setlocalversion. Then the kernel version should be same as "make kernelversion".
# Check for git and a git repo.
if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
head=$(git rev-parse --verify HEAD 2>/dev/null); then
# If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
# it, because this version is defined in the top level Makefile.
if [ -z "$(git describe --exact-match 2>/dev/null)" ]; then
# If only the short version is requested, don't bother
# running further git commands
if $short; then
#echo "+" #comment this line
return
fi
Related
Please help, who know between /lib/modules/version and /lib/modules/version+ (plus sign)
e.g. /lib/modules/3.4.61 and /lib/modules/3.4.61+.
Sorry my weak English and weak Linux (I am newbie).
First, you need to understand the difference between version and release.
Version is a three fields value, like v5.0.1. We can have alternatives for the same version, especially on development.
As real example: Linus is now working to publish Linux v6.0.0. Before pushing it, he is making many 6.0.0 testing versions, we call it release candidates.
He releases each release candidate as v6.0.0rc2, then v6.0.0rc3, and it keeps increasing. The version prefix keeps the same, it only changes the release suffix (rcN). When its good enough, we releases the 'official' v6.0.0.
So, release is kind of 'version of a version'. Its a very specific moment/commit.
We can check version and release strings using make -s kernelversion and make -s kernelrelease.
kernelrelease is just kernelversion concatenated with a release suffix.
Kernelversion is extracted from the file ./Makefile, from its first lines:
# SPDX-License-Identifier: GPL-2.0
VERSION = 6
PATCHLEVEL = 0
SUBLEVEL = 0
EXTRAVERSION =
Kernelversion is just these three first values separated by '.'.
Lets see ./scripts/setlocalversion algorithm, he is the guy who tells its release suffix:
if [ -z "$(git describe --exact-match 2>/dev/null)" ]; then
...
if $short; then
echo "+"
return
fi
...
fi
Note that he checks git describe, if it doesn't return an annoted tag, it will return "+". That means, if the version is '6.0.0', it will become '6.0.0+'.
TUTORIAL
First thing we need, is to asure we have a git annoted tag, to avoid the '+'.
Use
git tag -a mytag -m 'Commenting about this tag'
Now ./scripts/setlocalversion may return nothing (empty).
Enable auto complement on .config.
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
Make a file .scmversion with the suffix you want (if you want any).
echo 'mysuffix' > .scmversion
Now check it again with make -s kernelrelease. Its expected to be solved :)
I have the following content inside my p4aliases.txt.
diff-cl $(target-cl) = diff -dl //...#$(EQ)$(target-cl)
Basically it diffs against your files in current workspace toward the target shelved files of changelist.
It is fine. I can execute it. But when I compare the result coming from above aliased command against the direct raw (non-aliased) command as follows
p4 diff -dl //...#=<target-cl>
the output lines of text from aliased command is in wrong order e.g. changes according to a certain file shows up first before a line of file shown, line orders are messed up. This is not the case if you execute with a non-aliased command.
Example
Expected result
==== //depot/common.h#none - x:\mydir\project\src\common.h ====
==== //depot/file.cpp#none - x:\mydir\project\src\file.cpp ====
3a4
> added line 1
==== //depot/file.h#none - x:\mydir\project\src\file.h ====
Actual result
3a4
> added line 1
==== //depot/common.h#none - x:\mydir\project\src\common.h ====
==== //depot/file.cpp#none - x:\mydir\project\src\file.cpp ====
==== //depot/file.h#none - x:\mydir\project\src\file.h ====
I have p4 version as of Rev. P4/NTX64/2021.1/2126753 (2021/05/12).
Perforce server version (got from p4 info) is Server version: P4D/LINUX26X86_64/2017.1/1574018 (2017/10/02).
How can I solve this issue?
Could this be a version too far away between client and server
Update
I have tested p4 client all the way down from 2016-2020 version by downloading old binaries from ftp.perforce.com (in directory perforce). No luck. Output still messed the same. So it's not the problem about version mismatch.
This looks like a bug in the p4 client. When the client does a diff, it's written by the ClientUser::Diff() method, which defaults to writing to stdout (i.e. it does not route the output through ClientUser::OutputText()):
https://workshop.perforce.com/projects/perforce_software-p4/files/2018-2/client/clientuser.cc#436
https://workshop.perforce.com/projects/perforce_software-p4/files/2018-2/client/clientuser.cc#573
Output from commands run as part of an alias go through the ClientUserStrBuf subclass, which buffers all of its output. The file headers, for example, are buffered by ClientUserStrBuf::OutputInfo():
https://workshop.perforce.com/projects/perforce_software-p4/files/2018-2/client/clientaliases.cc#1647
There isn't a ClientUserStrBuf::Diff() implementation, though, so that diff output goes straight to stdout while the headers are buffered and printed at the end (presumably after some post-processing) -- hence the diff output showing up first in the console.
The fix I'd make would be to have the base ClientUser::Diff() implementation route the output through OutputText() when no output file is provided, which seems like the least-surprise behavior; that'd fix the aliases behavior and might even make life a little easier for other client developers who would otherwise hit the same issue. If you have a support contract with Perforce you can file this as a bug report, or since the client is open source you can take a crack at fixing and building it yourself. I don't think there's a workaround that doesn't involve modifying the client source code.
Samwise has the correct approach to truly fix the problem at hands although it might take some effort to understand the code, and conduct the fix itself.
At any rate, if we took such approach we won't be able to take benefits of bug fixes and future updates as we will be stuck with 2018-2 version of p4 as it's the latest as it can be in which we can grab the source.
I would recommend to use WSL then interact with p4.exe (yes, a Windows-based binary) for Windows-based project, and p4 for Linux-based binary. If you didn't use WSL, please find the .bash_aliases-like solution as I have below to seamlessly solve aliases diff operation.
Put the following code into your ~/.bash_aliases
# p4 - fix of aliases diff operation
# platform independent, it will choose a correct binary path to execute properly
p4() { cmd="p4.exe" # default is Windows-based
# get the last argument value, if "-lx" passed in then we know it's linux
if [[ "${#: -1}" == "-lx" ]]; then
cmd="/usr/local/bin/p4"
fi
if [[ $1 == "diff-cl" ]]; then
if [ -z "$2" ]; then
echo "usage: p4 diff-cl <CL>"
return 1
fi
$cmd diff -dl //...#=$2 | diffp4 | less -r
elif [[ $1 == "diff-cl-fonly" ]]; then
if [ -z "$2" ]; then
echo "usage: p4 diff-cl-fonly <CL>"
return 1
fi
$cmd diff -Od -dl -ds //...#=$2 | diffp4 | grep ==== | less -r
else
$cmd "$#"
fi
}
then source ~/.bash_aliases.
What it does is to allow you to still use p4 with all of its original commands & arguments normally with exceptions of diff-cl (which is the same name of alias I've put into p4aliases.txt for Windows or ~/.p4aliases for Linux). You can safely remove diff-cl entry from p4's alias file, or just leave it there. What we have in ~/.bash_aliases file will intercept whenever such argument matches then execute the raw command, just that we don't have to type long command ourselves.
We can later remove such section in our ~/.bash_aliases file when upstream p4 has been fixed.
In else section, we just relay the the whole arguments, and it will be performed just as normally done.
Extra: diff-cl-fonly to list out only files (its depot path, and local workspace path) which have changes.
I used to be able to install and use Sass with NetBeans 8 as described in the top answer on How to use SASS with Netbeans 8.0.1
Now, with the current version of Sass (1.14.1), installing is different. Basically just download and untar. That's done and I've pointed NetBeans to the correct location. But this current version of Sass won't run correctly from NetBeans:
"/opt/dart-sass/sass" "--cache-location"
"/home/jasper/.cache/netbeans/8.2/sass-compiler"
"path_to_my.scss" "path_to_my.css"
Could not find an option named "cache-location".
This error is also covered by Sass output error in Netbeans 8.2 where they are using Windows.
I tried to add the cache location parameter (similar to the solution for Windows) to this line in the sass file:
exec "$path/src/dart" --no-preview-dart-2 "-Dversion=1.14.1" "$path/src/sass.dart.snapshot" "$#"
but I could not get it working (same error keeps appearing).
Anybody any ideas on how to get Sass 1.14.1 working from NetBeans 8.2 on Linux (Ubuntu)?
The issue is that --cache-location is no longer supported and should be removed. All of the original parameters are used by "$#". To remove the first two parameters, you should be able to use "${#:3}" (see Process all arguments except the first one (in a bash script)), but somehow that resulted into a "Bad substitution" error for me. So I opted to use shift 2 to remove them:
#!/bin/sh
# Copyright 2016 Google Inc. Use of this source code is governed by an MIT-style
# license that can be found in the LICENSE file or at
# https://opensource.org/licenses/MIT.
# This script drives the standalone Sass package, which bundles together a Dart
# executable and a snapshot of Sass. It can be created with `pub run grinder
# package`.
follow_links() {
file="$1"
while [ -h "$file" ]; do
# On Mac OS, readlink -f doesn't work.
file="$(readlink "$file")"
done
echo "$file"
}
# Unlike $0, $BASH_SOURCE points to the absolute path of this file.
path=`dirname "$(follow_links "$0")"`
shift 2
exec "$path/src/dart" --no-preview-dart-2 "-Dversion=1.14.1" "$path/src/sass.dart.snapshot" "${#}"
Make sure to keep the original file and create a copy to only be used with NetBeans and make the change there.
macOS (Home Brew)
If you are looking for the Dart Sass install location (after installing it with Home Brew), it is located here:
/usr/local/Cellar/sass/{version}/bin
macOS (node.js)
When using node.js, you will run into the "env: node: No such file or directory" issue.
To work around that I created (make sure you make it executable (chmod a+x)):
/usr/local/lib/node_modules/sass/sass_nb.sh
and added:
#!/bin/zsh
export PATH="$PATH:"/usr/local/bin/
shift 3
sass ${#}
NetBeans 11+
On NetBeans 11 and 12 I had to use shift 3 instead of shift 2.
My response is based heavily on Jasper de Vries'one:
It seems that Netbeans simply adds some additional parameters that are no longer supported by sass compiler.
In my case the complete command issued by Netbeans was:
"/home/alex/tools/dart-sass/sass" "--cache-location" "/home/alex/snap/netbeans/common/cache/12.0/sass-compiler" "--debug-info" "/home/alex/projects/alexgheorghiu.com/web/aaa.scss" "/home/alex/projects/alexgheorghiu.com/web/aaa.css"
So the first 3 parameters
"--cache-location" "/home/alex/snap/netbeans/common/cache/12.0/sass-compiler" "--debug-info"
must be "deleted" or ignored.
So you need to either alter the sass file or make a copy of it (safest way)
and add
shift 3
instruction.
So if you start from original version like:
#!/bin/sh
# This script drives the standalone dart-sass package, which bundles together a
# Dart executable and a snapshot of dart-sass.
follow_links() {
file="$1"
while [ -h "$file" ]; do
# On Mac OS, readlink -f doesn't work.
file="$(readlink "$file")"
done
echo "$file"
}
# Unlike $0, $BASH_SOURCE points to the absolute path of this file.
path=`dirname "$(follow_links "$0")"`
exec "$path/src/dart" "$path/src/sass.snapshot" "$#"
You need to end up with something like:
#!/bin/sh
# This script drives the standalone dart-sass package, which bundles together a
# Dart executable and a snapshot of dart-sass.
follow_links() {
file="$1"
while [ -h "$file" ]; do
# On Mac OS, readlink -f doesn't work.
file="$(readlink "$file")"
done
echo "$file"
}
# Unlike $0, $BASH_SOURCE points to the absolute path of this file.
path=`dirname "$(follow_links "$0")"`
shift 3
exec "$path/src/dart" "$path/src/sass.snapshot" "$#"
An interesting aspect is that this bug is known by Netbeans developers (See: Could not find an option named "cache-location") but I was not able to achieve that because under my Xubuntu 18 the Netbeans is a "snap" and therefore it's netbeans.conf file is read only.
But in case you CAN modify that file it might be a cleaner solution.
We develop in a mixed environment - some people work on Macs and some work on Linux. This has proven to be a bit of a challenge at times, as those people who work on Linux are used to having their filesystems be case sensitive, so there's no issue committing (accidentally or otherwise) multiple files differing just by case. (e.g. FileName.ext versus filename.ext)
However, when the people on Macs go to check out the repository, having a case-insensitive filesystem means that the two files - differing only in case - overwrite each other and cause general havoc.
I know that there are various git settings to help people on case-insensitive filesystems work better with case changes (e.g. core.ignorecase), but these don't solve the issue where there's two different files in the repository, only differing by case.
I realize that the only way to fix it is to make sure the Linux people don't commit the two files differing only in case in the first place. -- Is there some setting in git which will pop up a warning or error if a user on a case-sensitive filesystem attempts to commit file(s) which would be confused with each other on a case-insensitive filesystem?
There's nothing built in (although there should be, no doubt). What you can do is provide a pre-commit hook that verifies that all names are OK and prevents the commit if not.
This hook only needs to be run on the Linux box (although making it work on Linux and Mac is easy, it's just Windows with its default impoverished toolbox that is problematic). You might want to add it to a side branch and give the Linux folks instructions on setting it up.
You may want to check branch names as well, as in git pre-commit or update hook for stopping commit with branch names having Case Insensitive match. (Interesting: the answer on this question is my own; I had forgotten it.)
First, let's write a "check for case conflict" function. This is just a matter of sorting with case-folding (so that "helloworld" and "helloWorld" are placed adjacent to each other), then using uniq -di to print any duplicate (after case-folding) strings, but no non-duplicates:
sort -f | uniq -di
If this produces any output, these are the "bad names". Let's capture the output in a temporary file and check its size, so we can print them to standard output as well:
#! /bin/sh
TF=$(mktemp)
trap "rm -f $TF" 0 1 2 3 15
checkstdin() {
sort -f | uniq -di > $TF
test -s $TF || return 0 # if $TF is empty, we are good
echo "non-unique (after case folding) names found!" 1>&2
cat $TF 1>&2
return 1
}
Now we just need to use it on files that will be committed, and perhaps on branch names as well. The former are listed with git ls-files, so:
git ls-files | checkstdin || {
echo "ERROR - file name collision, stopping commit" 1>&2
exit 1
}
You can fancy this up to use git diff-index --cached -r --name-only --diff-filter=A HEAD to check only added files, allowing existing case collisions to continue, and/or try to check things across many branches and/or commits, but that gets difficult.
Combine the above two fragments into one script (and test) and then simply copy it to an executable file named .git/hooks/pre-commit.
Checking branch names is a bit trickier. This really should happen when you create the branch name, rather than when you commit to it, and it's impossible to do a really good job on the client—it has to be done on a centralized server that has a proper global view.
Here is a way to do it on the server in a pre-receive script, in shell script rather than in Python (as in the linked answer). We still need the checkstdin function though, and you might want to do it in an update hook rather than a pre-receive hook, since you don't need to reject the entire push, just the one branch name.
NULLSHA=0000000000000000000000000000000000000000 # 40 0s
# Verify that the given branch name $1 is unique,
# even IF we fold all existing branch names' cases.
# To be used on any proposed branch creation (we won't
# look at existing branches).
check_new_branch_name() {
(echo "$1"; git for-each-ref --format='%(refname:short)' refs/heads) |
checkstdin || {
echo "ERROR: new branch name $1 is not unique after case-folding" 1>&2
exit 1 # or set overall failure status
}
}
while read oldsha newsha refname; do
... any other checks ...
case $oldsha,$refname in
$NULLSHA,refs/heads/*) check_new_branch_name ${refname#refs/heads/};;
esac
... continue with any other checks ...
done
I have many different repositories setup on my server. I need to have an identical post-commit hook file in every one of those repos. Simple enough for existing, but is there a way to have calls to svnadmin create automatically copy a post-commit stub file to the new hooks directory? Essentially I'm looking for a post-svnadmin-create hook. Thanks!
I think your best bet would be to wrap the call to svnadmin create in a script that creates the hooks after the repo.
Agreed as long as there is not some built-in way, which there seems not to be. I would have expected subversion to sport something like the customizable skeleton directory for new Linux users. Too bad.
Here is my wrapper with comments if anyone can find it useful - should be fairly extendable. If anyone notices any glaring gotchas in it, don't hesitate - I'm neither a bash nor Linux expert but I think I got most of it covered, and it works :)
# -----------------------------------------------------------------------
# A wrapper for svnadmin to allow post operations following repo creation - copying custom
# hook files into repo in this case. This should be run as root.
# capture input args; note that args[0] == $#[1] (this script name is not captured here)
args=("$#");
# redirect args to svnadmin in all cases - this script should not modify the behavior of svnadmin.
# note: the original binary "/binary_path/svnadmin" has been renamed "/binary_path/svnadmin-wrapped" and
# this script was then named "/binary_path/svnadmin" and given identical user:group & permissions as
# the original.
sudo -u svnuser svnadmin-wrapped ${args[#]};
# capture return code so we can return on exit; svnadmin returns 0 for success
eCode=$?;
# find out if sub-command to svnadmin was "create" and, if so, note the index of the directory arg,
# which is not necessarily going to be in the same position each time (options may be specified
# before the sub-command).
path_idx=0;
found=0;
for i in ${args[#]}
do
# track index; pre-incerement
((path_idx++));
if [ $i == "create" ]
then
# found repo path
((found++));
break;
fi
done
# we now know if the subcommand was create and where the repo path is - finish up as needed.
# note that this block assumes that our hook file stubs are /stub_path/ (owned by root)
# and that there exists a custom log file at /stub_path/cust-log (also owned by root).
d=`date`;
if [ $found != 0 ]
then
# check that the command succeeded
if [ $eCode == 0 ]
then
# check that the directory exists
if [ -d "${args[$path_idx]}/hooks" ]
then
# copy our custom hooks into place
sudo -u svnuser cp "/stub_path/post-commit" "${args[$path_idx]}/hooks/post-commit";
sudo -u svnuser cp "/stub_path/post-revprop-change" "${args[$path_idx]}/hooks/post-revprop-change";
else
# unlikey failure; set custom error code here; log issue
echo "$d svnadmin wrapper error: svnadmin 'create' succeeded but the 'hooks' directory was not found! Params: ${args[#]}" >> "/stub_path/cust-log";
let "eCode=1325";
fi
else
# tried to create but svnadmin failed; log issue
echo "$d svnadmin wrapper error: svnadmin 'create' was called but failed! Params: ${args[#]}" >> "/stub_path/cust-log";
fi
fi
exit $eCode;
-Thanks to all who host and post!