I tried to update nix-env but it is not showing latest packages:
a_user[~]$ nix-channel --update
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US",
LC_ALL = "en_US",
LC_COLLATE = "C",
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
downloading Nix expressions from âhttps://nixos.org/releases/nixpkgs/nixpkgs-16.03pre71923.3087ef3//nixexprs.tar.xzâ...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US",
LC_ALL = "en_US",
LC_COLLATE = "C",
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
unpacking channels...
a_user[~]$
a_user[~]$
a_user[~]$ nix-env -qa | grep baobab
baobab-3.16.1
a_user[~]$
a_user[~]$
a_user[~]$ nix-env -qa | grep dicom
a_user[~]$
a_user[~]$
a_user[~]$ nix-env -qa | grep grassroot
a_user[~]$
a_user[~]$
grassroot-dicom is available: https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93&q=dicom
Also, baobab version 3.18 is available: https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93&q=baobab
Why this discrepancy and how can I resolve this?
Also, how to correct locale settings in Slackware? Thanks.
Your search result for "dicom" found that string in the description of a package, alright, but that package is not called "dicom": it's called gdcm. You can do a similar search with nix-env as follows:
nix-env -qaP --description | grep -i dicom
gdcm gdcm-2.4.4 The grassroots cross-platform DICOM implementation
The output has three columns. The first one is the attribute path to the package, which you can use to install the package with nix-env -iA. The second column shows the package's name, which you can use to install it with nix-env -i. The third column is the short description of the package, which has no relevant inside of Nix; it's intended just for humans.
Now, to install the package, run nix-env -i gdcm or nix-env -iA gdcm. Both commands will work, but the latter one (the one using the attribute path) is usually faster.
The package baobab-3.18.0 is available in the master branch of the Nixpkgs git repository, but it's not yet available in the nixos-unstable channel. The channel hasn't advanced to the latest version of master yet, because there are regression test failures that need to be fixed before the channel is updated. The new version of baobab will show up in the channel in a couple of days (state of 2015-11-26). Simply put, the channel updates every time an entire column in the build set https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents is green, and this hasn't happened in a while: https://github.com/NixOS/nixpkgs/issues/11097 has more details.
Related
I compiled harfbuzz 7.0.0 on Ubuntu 22.04 ok.
I want to install latest kitty terminal (0.27.1) where harfbuzz >= 1.5 is required.
Kitty did not find harfbuzz 7.0.0
When I typed "make" for Kitty, i get a system exit telling me that harfbuzz >= 1.5 is required and that the version is not found.
I typed "export PKG_CONFIG_PATH=/home/user/harfbuzz/harfbuzz-7.0.0/src" since that is where 'harfbuzz.pc' resides.
harbuzz is still not found when typing 'make' in the kitty directory.
Alternative solution implemented (worked ok): "curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin"
I am Arch GNU/Linux user who usually manages almost every package with pacman; I manage TeX and LaTeX-related things with tlmgr. I installed tlmgr from source.
I am writing paper. I would like to use bibliography.
When I tried latexmk -pdflua main.ltx:
Rc files read:
latexmkrc
Latexmk: This is Latexmk, John Collins, 20 November 2021, version: 4.76.
Latexmk: applying rule 'biber main'...
Rule 'biber main': The following rules & subrules became out-of-date:
'biber main'
------------
Run number 1 of rule 'biber main'
------------
------------
Running 'biber "main.bcf"'
------------
biber: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
Latexmk: Errors, so I did not complete making targets
Collected error summary (may duplicate other messages):
biber main: Could not open biber log file for 'main'
Latexmk: Use the -f option to force complete processing,
unless error was exceeding maximum runs, or warnings treated as errors.
libcrypt.so* on my environment
$ pacman -Qo /usr/lib/libcrypt*
/usr/lib/libcrypto.so is owned by openssl 1.1.1.m-1
/usr/lib/libcrypto.so.1.1 is owned by openssl 1.1.1.m-1
/usr/lib/libcryptsetup.so is owned by cryptsetup 2.4.3-2
/usr/lib/libcryptsetup.so.12 is owned by cryptsetup 2.4.3-2
/usr/lib/libcryptsetup.so.12.7.0 is owned by cryptsetup 2.4.3-2
/usr/lib/libcrypt.so is owned by libxcrypt 4.4.28-1
/usr/lib/libcrypt.so.2 is owned by libxcrypt 4.4.28-1
/usr/lib/libcrypt.so.2.0.0 is owned by libxcrypt 4.4.28-1
What I tried else
I uninstalled and re-installed biber on tlmgr but did not work.
# ln -s /usr/lib/libcrypt.so /usr/lib/libcrypt.so.1
$ latexmkrc -pdflua main.ltx
Rc files read:
latexmkrc
Latexmk: This is Latexmk, John Collins, 20 November 2021, version: 4.76.
Latexmk: applying rule 'biber main'...
Rule 'biber main': The following rules & subrules became out-of-date:
'biber main'
------------
Run number 1 of rule 'biber main'
------------
------------
Running 'biber "main.bcf"'
------------
/tmp/par-716861/cache-0e6aa298f0c2e7a775de99938825b2d56bd2027f/biber: /usr/lib/libcrypt.so.1: version `GLIBC_2.2.5' not found (required by /tmp/par-716861/cache-0e6aa298f0c2e7a775de99938825b2d56bd2027f/biber)
Latexmk: Errors, so I did not complete making targets
Collected error summary (may duplicate other messages):
biber main: Could not open biber log file for 'main'
Latexmk: Use the -f option to force complete processing,
unless error was exceeding maximum runs, or warnings treated as errors.
File source
latexmkrc:
$latex='lualatex %O -synctex=1 -interaction=nonstopmode %S';
#$bibtex='upbibtex %O %B';
$bibtex='biber %O %B';
$makeindex='upmendex %O -o %D %S';
$pdf_mode=3;
Install libxcrypt-compat from the Core (1) repository, as suggest in this answer.
This made my biber from TeX Live 2020 work again. The interesting question is if newer TeX distributions will require this package, too.
(1) Thanks to #samueldy for the hint that the package was moved from the AUR to Core.
Adding on to #Christoph90's answer, as of 25 May 2022 the libxcrypt-compat package is still required in TeX Live 2022 in order for biber to function on Manjaro 21.2.6. However, the package has moved to core/libxcrypt-compat, so install by doing
sudo pacman -S libxcrypt-compat
The asterisk or star tells the engine to attempt to match the preceding token zero or more times. The plus tells the engine to attempt to match the preceding token once or more.
Based on the definition, I was wondering why the plus sign returns more matches than the asterisk sign.
echo "ABC ddd kkk DDD" | grep -Eo "[A-Z]+"
returns
ABC DDD
echo "ABC ddd kkk DDD" | grep -Eo "[A-Z]*"
returns
ABC
As far as I can tell, it doesn't. With GNU grep versions 2.5.3, 2.6.3, 2.10, and 2.12, I get:
$ echo "ABC ddd kkk DDD" | grep -Eo "[A-Z]+"
ABC
DDD
$ echo "ABC ddd kkk DDD" | grep -Eo "[A-Z]*"
ABC
DDD
Please double-check your second example. If you can confirm that you get only one line of output, it might be a bug in your grep. If you're using GNU grep, what's the output of grep --version? If not, what OS are you using, and (if you know) what grep implementation?
UPDATE :
I just built and installed GNU grep 2.5.1 (the version you're using) from source, and I confirm your output. It appears to be a bug in that version of grep, apparently corrected between 2.5.1a and 2.5.3. GNU grep 2.5.1 is about 12 years old; can you install a newer version? Looking through the ChangeLog for 2.5.3, I suspect this may have been the fix:
2005-08-24 Charles Levert <charles_levert#gna.org>
* src/grep.c (print_line_middle): In case of an empty match,
make minimal progress and continue instead of aborting process
of the remainder of the line, in case there's still an upcoming
non-empty match.
* tests/foad1.sh: Add two tests for this.
* doc/grep.texi, doc/grep.1: Document this behavior, since
--only-matching and --color are GNU extensions which are
otherwise unspecified by POSIX or other standards.
Even if you don't have full access on the machine you're using, you should still be able to download the source tarball from ftp://ftp.gnu.org/gnu/grep/ and install it under your home directory (assuming your system has a working compiler and associated tools).
I'm using lcov to generate coverage reports. I have a tracefile (broker.info) with this content (relevant fragment shown):
$ lcov -r broker.info
...
[/var/lib/jenkins/jobs/ContextBroker-PreBuild-UnitTest/workspace/test/unittests/orionTypes/]
EntityTypeResponse_test.cpp | 100% 11| 100% 6| - 0
...
[/var/lib/jenkins/jobs/ContextBroker-PreBuild-UnitTest/workspace/test/unittests/parse/]
CompoundValueNode_test.cpp | 100% 82| 100% 18| - 0
...
[/var/lib/jenkins/jobs/ContextBroker-PreBuild-UnitTest/workspace/test/unittests/rest/]
OrionError_test.cpp |92.1% 38| 100% 6| - 0
...
[/var/lib/jenkins/jobs/ContextBroker-PreBuild-UnitTest/workspace/test/unittests/serviceRoutines/]
badVerbAllFour_test.cpp | 100% 24| 100% 7| - 0
...
I want to remove all the info corresponding to test/unittest files.
I have attemped to use the -r option which, according to man page is:
-r tracefile pattern
--remove tracefile pattern
Remove data from tracefile.
Use this switch if you want to remove coverage data for a particular set of files from a tracefile. Additional command line parameters will be interpreted as
shell wildcard patterns (note that they may need to be escaped accordingly to prevent the shell from expanding them first). Every file entry in tracefile
which matches at least one of those patterns will be removed.
The result of the remove operation will be written to stdout or the tracefile specified with -o.
Only one of -z, -c, -a, -e, -r, -l, --diff or --summary may be specified at a time.
Thus, I'm using
$ lcov -r broker.info 'test/unittests/*' -o broker.info2
As far as I understand test/unittest/* matches the files under test/unittest. However, it's not working (note Deleted 0 files below):
Reading tracefile broker.info
Deleted 0 files
Writing data to broker.info2
Summary coverage rate:
lines......: 92.6% (58313 of 62978 lines)
functions..: 96.0% (6451 of 6718 functions)
branches...: no data found
I have tried also this variants (same result):
$ lcov -r broker.info "test/unittests/*" -o broker.info2
$ lcov -r broker.info "test/unittests/\*" -o broker.info2
$ lcov -r broker.info "test/unittests" -o broker.info2
So, maybe I'm doing something wrong?
I'm using lcov version 1.13 (just in case the data is relevant)
Thanks!
I have been testing another options and the following one seems to work, using the wildcard in the prefix also:
$ lcov -r broker.info "*/test/unittests/*" -o broker.info2
Maybe it is something new in version 1.13 because in version 1.11 it seems it works without wildcard in the prefix...
The below mentioned lcov command is working fine, even with wild characters (lcov 1.14):
lcov --remove meson-logs/coverage.info '/home/builduser/external/*' '/home/builduser/unittest/*' -o meson-logs/sourcecoverage.info
ack (the grep tool written in Perl) does not find a file that grep -r finds, and I cannot find the right options to get it to work. The following shows ack did not find the target string, which is in a regular file in a sub-directory. It's on Bash shell (Ubuntu 11.04):
100 $ grep -r imbue *
hel/find: the fact that some shells including Bash imbue braces
## Note: grep find it as shown in the above.
101 $ ./ack-standalone imbue
## Note: ack didn't find it as shown in the above.
102 $ ./ack-standalone --version
ack 1.96
Running under Perl 5.10.1 at /usr/bin/perl
Copyright 2005-2011 Andy Lester.
This program is free software. You may modify or distribute it
under the terms of the Artistic License v2.0.
## This is the testing folder structure:
103 $ tree
.
ack-standalone
hel
|- dot
|- find
|- grep
|- jobs
perlman
perlre
perlrequick
perlrun
perlvar
xargs
1 directory, 11 files
Version 2 of ack, from apt-get package installation, got same results. In the stand-alone version (version 1) shown above. ack -f shows nothing, and I tried the -r and * options, all with the same results.
On another machine, Ubuntu 10.04, it works like a charm.
It works for me if I select to operate in all files regardless of its type, using -a switch (my version is same that yours):
ack -a imbue *