vimer
Debian's people told me the appstream issues are usually minor enough that it isn't worth doing anything except fixing upstream and waiting. Just wait until upstream makes a new release...
Yeah. These icons should be put into `/usr/share/icons/hicolor/scalable/apps/` directory or its subdirectory. That is the fix will be finished by neomutt Debian maintainer?
Great, thank you
Hello, Just post some hits for the issue: --------------------------------------log---------------------------------------- constructs are not supported yet return GEN_BINARY_RMWcc(LOCK_PREFIX __ASM_SIZE(bts), *addr, c, "Ir", nr); ^ /lib/modules/5.0.0-rc7-00177-gcb268d806972/build//arch/x86/include/asm/rmwcc.h:60:32: note: expanded from macro 'GEN_BINARY_RMWcc' #define GEN_BINARY_RMWcc(X...)...
> > I have no idea why it fail to compile in kernel/sample/bpf. > > in kernel, "make" works well. > > This issue clearly states that this project does...
Hi, @DaniAffCH Thanks for working on that. My locally real riscv64 hardware is Unmatched boards. ```bash Linux unmatched 5.18.0-2-riscv64 #1 SMP Debian 5.18.5-1 (2022-06-16) riscv64 GNU/Linux ``` So how can...
More info about Unmatched board is here: https://www.sifive.com/boards/hifive-unmatched The machines from plct is the same
Oops： ```bash vimer@unmatched:~/build/cpu$ gcc -g get_cpuid.c -o test get_cpuid.c: Assembler messages: get_cpuid.c:12: Error: unknown CSR `mcpuid' ```
It can be compiled but fail on runtime: ```bash vimer@unmatched:~/build/cpu$ gcc -g get_cpuid.c -o test vimer@unmatched:~/build/cpu$ ./test Illegal instruction vimer@unmatched:~/build/cpu$ cat get_cpuid.c #include static unsigned long cpuid() { unsigned long...