I am trying to patch a custom qt virtual keyboard from Yocto.
First of all I cloned the git repo of that keyboard, changed one file (just replace an old version of .otf by new one), committed the changes and created the patch file executing:
git format-patch -1 <COMMIT_ID> -o patches
In result I have an commit file inside /patches/ folder.
I have checked it by reverting the changes and git apply <File.patch> again. Everything looks fine.
The next step.
I have necessary qtvirtualkeyboard_%.bbappend file in /sources/meta-yogurt/recipes-qt/qt5/.
I created new folder qtvirtualkeyboard and copied the file.patch there.
Than I modified qtvirtualkeyboard_%.bbappend and not it looks like:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += \
"file://0001-Update-font-file.patch;striplevel=0"
PATCHTOOL = "git"
PACKAGECONFIG = " lang-de_DE lang-en_GB lang-ru_RU lang-zh_CN \
lang-it_IT lang-ja_JP"
I tried to modify it with and without PATCHTOOL var and striplevel - it did not make any result.
And in the end when I build the image I receive the next error:
ERROR: qtvirtualkeyboard-5.9.8+gitAUTOINC+dc18b608b5-r0 do_patch: Applying '0001-Update-font-file.patch' failed:
can't find file to patch at input line 12
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From 5defffb3a8afaa8e254cd2cf551d6126ead74014 Mon Sep 17 00:00:00 2001
|From: Savchenko Serhii <s.savchenko#smissltd.com>
|Date: Mon, 21 Sep 2020 11:41:37 +0300
|Subject: [PATCH] Update font file
|
|---
| FontAwesome.otf | Bin 85908 -> 465076 bytes
| 1 file changed, 0 insertions(+), 0 deletions(-)
|
|diff --git a/FontAwesome.otf b/FontAwesome.otf
|index 81c9ad949b47f64afeca5642ee2494b6e3147f44..7720e3739b64143d0a1dcb28fda78ac209afbcb8 100644
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
Does anyone have any idea how to fix it?
Related
rule all:
input:
"../data/A_checkm/{genome}"
rule A_checkm:
input:
"../data/genomesFna/{genome}_genomic.fna.gz"
output:
directory("../data/A_checkm/{genome}")
threads:
16
resources:
mem_mb = 40000
shell:
"""
# setup a tmp working dir
tmp=$(mktemp -d)
mkdir $tmp/ref
cp {input} $tmp/ref/genome.fna.gz
cd $tmp/ref
gunzip -c genome.fna.gz > genome.fna
cd $tmp
# run checking
checkm lineage_wf -t {threads} -x fna ref out > stdout
# prepare output folder
cd {config[project_root]}
mkdir -p {output}
# copy results over
cp -r $tmp/out/* {output}/
cp $tmp/stdout {output}/checkm.txt
# cleanup
rm -rf $tmp
"""
Thank you in advance for your help!
I would like to run checkm on a list of ~600 downloaded genome files having the extension '.fna.gz'. Each downloaded file is saved in a separate folder having the same name as the genome. I would like also to have all the results in a separate folder for each genome and that's why my output is a directory.
When I run this code with 'snakemake -s Snakefile --cores 10 A_checkm', I get the following error:
WorkflowError: Target rules may not contain wildcards. Please specify concrete files or a rule without wildcards at the command line, or have a rule without wildcards at the very top of your workflow (e.g. the typical "rule all" which just collects all results you want to generate in the end).
Anyone could help me identifying the error, please?
You need to provide snakemake with concrete values for the {genome} wildcard. You cannot just leave it open and expect snakemake to work on all the files in some folder of your project just like that.
Determine the filenames/genome values of the files which you want to work on, using glob_wildcards(...). See the documentation for further details.
Now you can use these values to specify in rule all to create all the folders (using your other rule) with those {genome} values:
# Determine the {genome} for all downloaded files
(GENOMES,) = glob_wildcards("../data/genomesFna/{genome}_genomic.fna.gz")
rule all:
input:
expand("../data/A_checkm/{genome}", genome=GENOMES),
rule A_checkm:
input:
"../data/genomesFna/{genome}_genomic.fna.gz",
output:
directory("../data/A_checkm/{genome}"),
threads: 16
resources:
mem_mb=40000,
shell:
# Your magic goes here
If the download is supposed to happen inside snakemake, add a checkpoint for that. Have a look at this answer then.
I'm trying to setup a local pre-commit hook. It should check if any edited files are styled according to the tidyverse styleguide (using styler). Because my company does not allow for direct access to github, I cannot use precommit, and have to setup the hook by editing the .git/hooks/pre-commit file.
Setup
This is what I tried: My .git/hooks/pre-commit
#!/bin/bash
set -eo pipefail
CHANGED_FILES=$(git diff --name-only --cached --diff-filter=ACMR)
get_pattern_files() {
pattern=$(echo "$*" | sed "s/ /\$\\\|/g")
echo "$CHANGED_FILES" | { grep "$pattern$" || true; }
}
R_FILES=$(get_pattern_files .R)
# if R_FILES is not empty, run Rscript
if [[ -n "$R_FILES" ]]
then
Rscript ./style.R $R_FILES
fi
# exit with 1, if Rscript failed
if [ $? -eq 0 ]; then
exit 0
else
exit 1
fi
and my ./style.R
#!/usr/bin/env Rscript
args <- commandArgs(trailingOnly = TRUE)
output <- styler::style_file(path = args)
if (any(output$changed) == TRUE) {quit(status = 1)}
Problem
When I edit a file, I can see it in the diff.
user#machine:~/r_template$ git diff
diff --git a/src/main.R b/src/main.R
index 8d2f097..dd1272d 100644
--- a/src/main.R
+++ b/src/main.R
## -1 +1 ##
-1 + 1
+1 +1 <-- this is what I have changed in the file
I add it with git add -u and then git commit. The hook gets called, and aborts the commit (because the Rscript exits with status 1) as expected.
user#machine:~/r_template$ git commit
Styling 1 files:
src/main.R ℹ
────────────────────────────────────────
Status Count Legend
✓ 0 File unchanged.
ℹ 1 File changed.
x 0 Styling threw an error.
────────────────────────────────────────
Please review the changes carefully!
and can see an (expected) edited file
user#machine:~/r_template$ git status
On branch feature/precommit-hooks
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: src/main.R
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: src/main.R
with the intended changes done by styler::style_file()
user#machine:~/r_template$ git diff
diff --git a/src/main.R b/src/main.R
index dd1272d..8d2f097 100644
--- a/src/main.R
+++ b/src/main.R
## -1 +1 ##
-1 +1
+1 + 1 <-- this is done by styler::style_file()
Ok, so next I want to stage this edit, so I git add -u. But then something happens I cannot understand
utxkanal#vlx00950:~/r_template$ git status
On branch feature/precommit-hooks
nothing added to commit but untracked files present (use "git add" to track)
The staging area is completely empty. And still, the change in src/main.R is in effect.
What is happening here?
The trick to understanding what's going on is this: The staging area is never empty, and never contains any changes. To which the obvious reply is what the f—, you obviously don't know what you're talking about because git status shows an empty staging area and git diff shows changes. And yes, they do. The trick is that these are strategically developed lies.
As Emily Dickinson's poem Tell all the Truth but tell it slant points out, trying to instantly see the whole picture all at once is overwhelming. The whole truth of Git's index / staging-area is that it contains a full copy of every file, ready to be committed. That is, there are at all times three copies of the current commit:
There's the frozen-for-all-time one in the current commit itself. This is what you started with.
There's an "in between" version, which I put here because it's "between", but don't describe yet.
There's a usable (edit-able, view-able, and generally useful for doing work) copy, in your working tree. This is how you get stuff done.
The "in-between" version is simply a full copy of every file in Git's staging area, which Git also calls the index.
When git diff or git diff --cached shows changes, what Git is doing is playing the Spot the Difference game with two snapshots. There are two full pictures, but the two have some differences. Git omits, from a diff output, all the stuff that is the same, because that stuff is boring! We want to know what's different.
The same thing happens with git status, except that instead of showing us what's different, it tells us which file names have one or more differences. So this:
user#machine:~/r_template$ git status
On branch feature/precommit-hooks
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: src/main.R
means that when Git compares the full snapshot of every file in the HEAD (current) commit to the full snapshot of every file in the staging area, one file is different: src/main.R. Meanwhile, this second part:
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: src/main.R
means that when Git (separately) compares the full snapshot in the staging area to the full snapshot in your working tree, one file is different: src/main.R (again).
If we now change the index (aka staging) copy of src/main.R—we're allowed to replace it wholesale at any time, and formatting hooks do that sort of trick—then the difference from HEAD-to-index changes. Perhaps it even disappears entirely! And, separately, the difference from index-to-working-tree changes as well.
In this particular case, what happened is that the frozen, archived, HEAD copy and the working tree copy already matched. Only the index/staging-area copy was different. Running git add src/main.R told Git: replace the index copy with the working tree copy. It did that, and now all three copies matched again.
Footnote: "The staging area is never empty, and never contains any changes" is obviously an overstatement. It's also wrong because it is possible to have a completely-empty staging area, by removing every file from it. It's just not normal to do that. The only time you normally have that is in a fresh, new, totally-empty repository, when you're working on your first commit. But it's still a good way to remember that the index / staging-area has a full snapshot of every file. In fact, the point of this is that the full snapshot in the index area is, in effect, the snapshot you're proposing to put into your next commit.
(There's also the much trickier case of multiple index / staging-areas.)
I've inherited a JS code base with Jasmine unit tests. The testing framework uses karma and instanbul-combine to get code coverage. It seems istanbul-combine isn't working with present node modules, and besides is no longer maintained: the recommended replacement is nyc. I'm having trouble replacing istanbul-combine with nyc in the Makefile.
I succeeded in merging my separate coverage results (json) files into a single coverage-final.json file (this SO question), but now I need to generate the summary report.
How do I generate a summary report from a coverage.json file?
One problem here, I think, is that I have no .nyc_output directory with intermediate results, since I'm not using nyc to generate coverage data. All my coverage data is in a coverage directory and its child directories.
I've tried specifying a filename:
npx nyc report --include coverage-final.json
Also tried specifying the directory:
npx nyc report --include coverage
Neither works.
----------|---------|----------|---------|---------|-------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files | 0 | 0 | 0 | 0 |
----------|---------|----------|---------|---------|-------------------
The CLI help documentation says
--temp-dir, -t directory to read raw coverage information from
But when I use that point to coverage directory (viz., npx nyc report -t coverage), I get the same unsatisfactory result. NYC is apparently fairly rigid in the formats it will accept this data.
Here's the original Makefile line that I'm replacing:
PATH=$(PROJECT_HOME)/bin:$$PATH node_modules/istanbul-combine/cli.js \
-d coverage/summary -r html \
coverage/*/coverage-final.json
Using this line in my Makefile worked:
npx nyc report --reporter html --reporter text -t coverage --report-dir coverage/summary
It grabs the JSON files from the coverage directory and puts them altogether into an HTML report in the coverage/summary subdirectory. (Didn't need the nyc merge command from my previous question/answer.)
I'm not sure why the -t option didn't work before. It may be I was using the wrong version of nyc (15.0.0 instead of 14.1.1, fwiw).
After trying multiple nyc commands to produce the report from JSON with no luck, I found an interesting behavior of nyc: You have to be in the parent directory of the instrumented code when you are generating a report. For example:
If the code I instrumented is in /usr/share/node/**, and the merged coverage.json result is in /tmp directory. If I run nyc report --temp-dir=/tmp --reporter=text under /tmp, I won't get anything.
----------|---------|----------|---------|---------|-------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files | 0 | 0 | 0 | 0 |
----------|---------|----------|---------|---------|-------------------
But if I run the same command under /usr/share/node or /, I'm able to get the correct output with coverage numbers.
Not sure if it's a weird permission issue in nyc. If it's an expected behavior of nyc
I have a tarball src.tar.gz whose contents are unpacked into src/ and a patch of this sources generated with this command:
$ diff -Nurp src/ src_mod/ > my.patch
The patch header starts with this three lines:
diff -Nurp src/path/to/file src_PATCHED/path/to/file
--- src/path/to/file 2012-10-22 05:52:59.000000000 +0200
+++ src_PATCHED/path/to/file 2016-03-14 12:27:52.892802283 +0100
My bitbake recipe references both path and tarball files using this SRC_URI:
SRC_URI = " \
file://my.patch \
file://src.tar.gz \
"
do_fetch and do_unpack tasks work as expected, leaving my.patch and src/ inside ${S} directory, that is:
${S}/my.path
${S}/src.tar.gz
But do_patch task is failing with this ERROR message:
ERROR: Command Error: exit status: 1 Output:
Applying patch my.patch
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
I have tested different alternatives, for example setting "patchdir" attribute like showed below:
SRC_URI = " \
file://my.patch;patchdir=${S}/src \
file://src.tar.gz \
"
I expected "patchdir" being the same as using "patch -d dir". But it doesn't work as expected, it always returns the same ERROR message.
What I am doing wrong?
My variable ${S} was re-defined inside my recipe with this content:
S = "${WORKDIR}/${PN}-${PV}"
But the fetchers downloads my.patch and src/ inside ${WORKDIR}, not inside ${S} directory, so:
${WORKDIR}/my.path
${WORKDIR}/src.tar.gz
And tarball was also extracted inside ${WORKDIR}
${WORKDIR}/src/
The fix was setting "patchdir" attribute properly, replacing ${S} by ${WORKDIR}
SRC_URI = " \
file://my.patch;patchdir=${WORKDIR}/src \
file://src.tar.gz \
"
That is already working!
Though the author provided their own solution to their distinct problem, this question is the first result that comes up when searching for solutions to the "can't find file to patch" error in Yocto builds, so I want to share a solution for a different situation that produces the same error output.
In my case, I was trying to use a .bbappend file to apply an override controlled patch to a pre-existing recipe, and was receiving the "can't find file to patch" error. The thread at https://community.nxp.com/thread/474138 identified the solution: using the '_append' syntax instead of the '+=' syntax. That is, use:
SRC_URI_append_machineoverride = " file://my.patch"
Instead of
SRC_URI_machineoverride += "file://my.patch"
Note that the use of '_append' requires a leading space (contra the trailing space noted in the thread linked above). I have not yet investigated this enough to explain why this syntax is necessary, but I thought this would still be a valuable addition to the record for this question.
I am using Shoestrap, a WordPress theme based on Roots that uses Bootstrap and less. I added the Bootswatch Yeti theme variables.less to assets/less/bootstrap as as a replacement of the existing one and also added bootswatch.less. Then I added bootswatch.less to bootstrap.less. To recompile I ran grunt. The grunt file content I have added here.
I ran into two issues though. One error I do not know how to fix and one major issue that is that grunt seems to keep on removing assets/css/main.min.css all the time and then tells me the file or directory is missing. Here are the errors I had with --force activated:
grunt --force
Running "clean:dist" (clean) task
Running "less:dist" (less) task
>> NameError: variable #gutter is undefined in assets/less/app.less on line 5, column 13:
>> 4 .gallery-row {
>> 5 padding: (#gutter / 2) 0;
>> 6 }
Warning: Error compiling assets/less/app.less Used --force, continuing.
Running "uglify:dist" (uglify) task
File "assets/js/scripts.min.js" created.
Running "version" task
Warning: ENOENT, no such file or directory 'assets/css/main.min.css' Used --force, continuing.
Done, but with warnings.
It was the Byte Order Mark (BOM) signature that was an issue as I linked to before in the question. But both TextWrangler and Dreamweaver did not remove it. I found one command that did help here: Using awk to remove the Byte-order mark And I ran
awk '{if(NR==1)sub(/^\xef\xbb\xbf/,"");print}' app.less > app.less
which worked like a charm! Only the theme still has not changed in styling. That is rather odd.
Update I
The awk command emptied my app.less. I ran another command found here as well: Using awk to remove the Byte-order mark and that command:
sed -i .bak '1 s/^\xef\xbb\xbf//' *.less
did work without removing all data from app.less, but then I got the same error again:
Reading assets/less/app.less...OK
>> NameError: variable #gutter is undefined in assets/less/app.less on line 5, column 13:
>> 4 .gallery-row {
>> 5 padding: (#gutter / 2) 0;
>> 6 }
Did see TextMate added attributes and removed those using xattr -d com.macromates.caret file.less, but that did not do the trick either.
Update II
Seems that the variable #gutter does not exist. There seems to be a variable #grid-gutter-width. Thanks to at Roots Discourse I was notified - http://discourse.roots.io/t/grunt-hits-a-snag-compiling-gutter-not-defined/940/3 . Making an adjustment does not help though as other variables pop-up as issues. Will see if I can get some feedback from the Shoestrap team.
There was a bug in the shoestrap, theme, I believe we managed to fix it with this commit: https://github.com/shoestrap/shoestrap/commit/ff75cf73cf778e4b80c5e11544c0a67717fbcc10
Please let me know if that works for you...