RE: [EXTERNAL]Re: How should I be running `npm install …`?

[Josh Marshall]

That does help, but it ought to be the default in many ways.

From: Dejan Ranisavljevic
Sent: Wednesday, June 17, 2020 12:10 AM
To: Gary Johnson
Cc: Dmitry Alexandrov; Josh 
Marshall; 
help-guix@gnu.org; Vivien 
Kraus
Subject: [EXTERNAL]Re: How should I be running `npm install …`?

To use different directory for global packages, you have to create ~/.npmrc 
dotfile with:

prefix=~/.npm

Once you have that you should be able to do npm i -g, and package would be 
installed in ~/.npm
Also don't forget to add ~/.npm/bin in your PATH:

export PATH="$HOME/.npm/bin:$PATH"

Hope this helps.

Best,
Dejan

On Tue, 16 Jun 2020 at 17:21, Gary Johnson 
mailto:lambdatro...@disroot.org>> wrote:
In Guix, all system-level packages and configuration files are created
by the package manager under /gnu/store. The /usr directory is empty on
a Guix system.

~Gary

Dmitry Alexandrov <321...@gmail.com> writes:

> Vivien Kraus mailto:viv...@planete-kraus.eu>> wrote:
>> Le jeudi 30 avril 2020 à 14:59 +, Josh Marshall a écrit :
>>> I’m trying to run `npm install -g browserify` with the output below.
>
>>> npm ERR! path 
>>> /gnu/store/39zkw3a8lxkxs7rmx4238959zc368075-node-10.19.0/lib/node_modules
>>
>> I am a mere guix user, so you may want to have another answer.
>
> I am not even a Guix (the SD) user, but this made me curious.
>
>> You cannot install anything globally with NPM in guix because NPM is 
>> installed in a read-only location (/gnu/store/)
>
> So?  /usr/ in traditional GNU distributions might be read-only as well, but 
> it does not impede npm(1) or pip(1) or whatever install things system-wide 
> (given that operator utilize his superuser powers, of course), as there are 
> plenty other hierarchies available.
>
> Why is npm in Guix built with default ‘prefix’¹ (means, for --global actions) 
> set to package directory under /gnu/store/ instead of, say, /usr/local?
>
> ---
> ¹
>   $ npm config get prefix


--
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
===
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary 
attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

---

The information in this email, including attachments, may be confidential and 
is intended solely for the addressee(s). If you believe you received this email 
by mistake, please notify the sender by return email as soon as possible.

Re: BPF in linux-libre

[John Soo]

Hi Mathieu,

Mathieu Othacehe  writes:

> Yes the issue here is that linux-libre-headers is in fact
> linux-libre-headers-5.4.20 which is too old.
>
> I tried to add linux-libre-headers-5.7 to the inputs. Even though it
> comes first in CPLUS_INCLUDE_PATH, GCC is picking the old headers.

I found out that if LIBBPF_INCLUDE_DIR was specified instead of present
as a submodule, the error about missing macros would occur. There is an
open issue upstream regarding it so now bcc builds ok. It was definitely
confusing because kernels since about 4.16 support bpf. Now there is a
new problem building bpftrace:

cd /tmp/guix-build-bpftrace-0.10.0-1.v0.10.0.drv-0/build/src && 
/gnu/store/89rj5fqcg48afgk99639ds602pgf92k4-cmake-minimal-3.16.5/bin/cmake -E 
cmake_link_script CMakeFiles/bpftrace.dir/link.txt --verbose=1
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/c++  -O2 -g -DNDEBUG  
-rdynamic CMakeFiles/bpftrace.dir/attached_probe.cpp.o 
CMakeFiles/bpftrace.dir/bpffeature.cpp.o CMakeFiles/bpftrace.dir/bpftrace.cpp.o 
CMakeFiles/bpftrace.dir/btf.cpp.o CMakeFiles/bpftrace.dir/clang_parser.cpp.o 
CMakeFiles/bpftrace.dir/disasm.cpp.o CMakeFiles/bpftrace.dir/driver.cpp.o 
CMakeFiles/bpftrace.dir/fake_map.cpp.o CMakeFiles/bpftrace.dir/list.cpp.o 
CMakeFiles/bpftrace.dir/lockdown.cpp.o CMakeFiles/bpftrace.dir/main.cpp.o 
CMakeFiles/bpftrace.dir/map.cpp.o CMakeFiles/bpftrace.dir/mapkey.cpp.o 
CMakeFiles/bpftrace.dir/output.cpp.o CMakeFiles/bpftrace.dir/printf.cpp.o 
CMakeFiles/bpftrace.dir/resolve_cgroupid.cpp.o 
CMakeFiles/bpftrace.dir/signal.cpp.o CMakeFiles/bpftrace.dir/struct.cpp.o 
CMakeFiles/bpftrace.dir/tracepoint_format_parser.cpp.o 
CMakeFiles/bpftrace.dir/types.cpp.o CMakeFiles/bpftrace.dir/utils.cpp.o 
CMakeFiles/bpftrace.dir/bfd-disasm.cpp.o  -o bpftrace  
-Wl,-rpath,:
 -Wl,-Bstatic -lbfd -lopcodes arch/libarch.a ast/libast.a ../libparser.a 
../resources/libresources.a -Wl,-Bdynamic -lbcc -lelf arch/libarch.a 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMOrcJIT.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMJITLink.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMMCJIT.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMExecutionEngine.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMRuntimeDyld.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libclang.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMXCoreDisassembler.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMXCoreCodeGen.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMXCoreDesc.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMXCoreInfo.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMX86Disassembler.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMX86AsmParser.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMX86CodeGen.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMX86Desc.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMX86Utils.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMX86Info.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMWebAssemblyDisassembler.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMWebAssemblyAsmParser.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMWebAssemblyCodeGen.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMWebAssemblyDesc.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMWebAssemblyInfo.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMSystemZDisassembler.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMSystemZAsmParser.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMSystemZCodeGen.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMSystemZDesc.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMSystemZInfo.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMSparcDisassembler.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMSparcAsmParser.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMSparcCodeGen.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libLLVMSparcDesc.so.9
 
/gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.

Re: How should I be running `npm install …`?

[Dejan Ranisavljevic]

To use different directory for global packages, you have to create ~/.npmrc
dotfile with:

prefix=~/.npm

Once you have that you should be able to do npm i -g, and package would be
installed in ~/.npm
Also don't forget to add ~/.npm/bin in your PATH:

export PATH="$HOME/.npm/bin:$PATH"

Hope this helps.

Best,
Dejan

On Tue, 16 Jun 2020 at 17:21, Gary Johnson  wrote:

> In Guix, all system-level packages and configuration files are created
> by the package manager under /gnu/store. The /usr directory is empty on
> a Guix system.
>
> ~Gary
>
> Dmitry Alexandrov <321...@gmail.com> writes:
>
> > Vivien Kraus  wrote:
> >> Le jeudi 30 avril 2020 à 14:59 +, Josh Marshall a écrit :
> >>> I’m trying to run `npm install -g browserify` with the output below.
> >
> >>> npm ERR! path
> /gnu/store/39zkw3a8lxkxs7rmx4238959zc368075-node-10.19.0/lib/node_modules
> >>
> >> I am a mere guix user, so you may want to have another answer.
> >
> > I am not even a Guix (the SD) user, but this made me curious.
> >
> >> You cannot install anything globally with NPM in guix because NPM is
> installed in a read-only location (/gnu/store/)
> >
> > So?  /usr/ in traditional GNU distributions might be read-only as well,
> but it does not impede npm(1) or pip(1) or whatever install things
> system-wide (given that operator utilize his superuser powers, of course),
> as there are plenty other hierarchies available.
> >
> > Why is npm in Guix built with default ‘prefix’¹ (means, for --global
> actions) set to package directory under /gnu/store/ instead of, say,
> /usr/local?
> >
> > ---
> > ¹
> >   $ npm config get prefix
>
>
> --
> GPG Key ID: 7BC158ED
> Use `gpg --search-keys lambdatronic' to find me
> Protect yourself from surveillance: https://emailselfdefense.fsf.org
> ===
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>
> Please avoid sending me MS-Office attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
>
>

Re: BPF in linux-libre

[Mathieu Othacehe]

Hello John,

> /tmp/guix-build-bcc-0.14.0.drv-0/source/src/cc/libbpf.c:694:58: error: 
> ‘BPF_PROG_TYPE_EXT’ undeclared (first use in this function); did you mean 
> ‘BPF_PROG_TYPE_XDP’?
>if (prog_type != BPF_PROG_TYPE_TRACING && prog_type != BPF_PROG_TYPE_EXT)
>   ^
>   BPF_PROG_TYPE_XDP
>
> The bcc github releases seem to indicate that bcc supports kernels up to
> 5.6.

Yes the issue here is that linux-libre-headers is in fact
linux-libre-headers-5.4.20 which is too old.

I tried to add linux-libre-headers-5.7 to the inputs. Even though it
comes first in CPLUS_INCLUDE_PATH, GCC is picking the old headers.

I'll have another look later.

Thanks,

Mathieu