Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 9266ab06e0)
[Peter: drop Makefile change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Drop patches (already in version) and so drop autoreconf
- Update hash of BSD_LICENSE (update in year:
551657bfbf)
https://github.com/hreinecke/sg3_utils/blob/v1.48/ChangeLog
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The 6.4.x series is now EOL upstream, so drop the linux-headers option
and add legacy handling for it.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Drop all patches (already in version)
- Update hash of LICENSE file (year updated with
f035303b8a)
https://github.com/Cyan4973/xxHash/releases/tag/v0.8.2
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Changelog:
http://www.gnuplot.info/ReleaseNotes_5_4_9.html
Signed-off-by: Michael Fischer <mf@go-sys.de>
[Peter: use --without-qt for consistency]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit df2c4a2301)
[Peter: drop Makefile/Vagrantfile changes]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 70638523a7)
[Peter: drop Makefile/Vagrantfile changes]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
PPPD_DROP_INTERNAL_IF_PPOL2TP_H is not needed since bump to version
2.4.6 in commit 49b239ab20 and
c41092dd4c
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When nodejs is build, a qemu wrapper script is used to execute some
programs built for the target in user-mode emulation. However, when the
target and build machines are similar (e.g. x86_74), running those
programs fails, with errors such as:
cd ../../tools/v8_gypfiles; python ../../deps/v8/tools/run.py ../../out/Release/v8-qemu-wrapper ../../out/Release/bytecode_builtins_list_generator ../../out/Release/obj.host/gen/generate-bytecode-output-root/builtins-generated/bytecodes-builtins-list.h
../../out/Release/bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ../../out/Release/bytecode_builtins_list_generator)
../../out/Release/bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ../../out/Release/bytecode_builtins_list_generator)
../../out/Release/bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ../../out/Release/bytecode_builtins_list_generator)
../../out/Release/bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ../../out/Release/bytecode_builtins_list_generator)
Return code is 1
So the question is: why the heck does Qemu use the host C library?
To answer this question, we first have to look at how the -L option of
Qemu is implemented. This option is documented as such:
-L path QEMU_LD_PREFIX set the elf interpreter prefix to 'path'
The v8-qemu-wrapper script makes this option point to $(STAGING_DIR),
so that the ELF interpreter used is the one in $(STAGING_DIR).
However, contrary to what the option documentation says, this option
does much more than setting the ELF interpreter prefix: it is going to
affect how *all* system calls manipulating files (open, etc.) are
going to work.
When this option is passed, the function init_paths() in
https://git.qemu.org/?p=qemu.git;a=blob;f=util/path.c is called at
initialization time, and essentially its sets the global "base"
variable to point to the directory passed as -L argument.
Then, for every single syscall that manipulates a path, this path will
be passed through the path() function in the same file. This function
will first attempt to resolve the path with "base" as a prefix, and if
not, return the unprefixed path.
After adding some traces into this function, I was able to understand
what happens:
(1) -L$(STAGING_DIR) is passed, causing "base" to point to
$(STAGING_DIR)
(2) The target ELF interpreter from $(STAGING_DIR) is properly invoked
(3) When this ELF interpreter then resolves the libc.so.6 library, it
first looks for /etc/ld.so.cache.
(4) Qemu first looks for /etc/ld.so.cache with the -L prefix, i.e
$(STAGING_DIR)/etc/ld.so.cache, but it does not exist. So, the Qemu
system call emulation falls back to /etc/ld.so.cache, which means
the target ELF interpreter reads the /etc/ld.so.cache of the host
system.
(5) This /etc/ld.so.cache of the host system says that libc.so.6 is in
/lib/x86_64-linux-gnu/
(6) The target ELF interpreter therefore tries to use
/lib/x86_64-linux-gnu/libc.so.6. The Qemu system call emulation
first tries $(STAGING_DIR)/lib/x86_64-linux-gnu/libc.so.6, but
this library does not exist (it is in
$(STAGING_DIR)/lib/libc.so.6), so the Qemu system call emulation
falls back to /lib/x86_64-linux-gnu/libc.so.6 of the host system,
which exist... but is too old compared to the target C library.
Indeed, results from ld.so.cache take precedence over the simple
resolution of library paths in /usr/lib and /lib.
We see 3 possible ideas to resolve this problem:
(A) Change the behavior of Qemu to not fallback to unprefixed paths:
when -L is passed, all path-related system calls should see the
paths prefixed by the -L option.
Issue with this is that this change is unlikely to get accepted by
Qemu upstream. And there might be some side effects we have not
really identified.
(B) Create an empty $(STAGING_DIR)/etc/ld.so.cache. We have tested
this solution and it works: it gets used instead of the host
/etc/ld.so.cache. Because $(STAGING_DIR)/etc/ld.so.cache is empty,
there's no libc.so.6 match, so the target ELF interpreter goes
through its normal library location resolution logic, which falls
back to trying in /usr/lib and /lib, which works as those paths
ends up being prefixed with $(STAGING_DIR) by Qemu.
(C) Pass LD_LIBRARY_PATH pointing to $(STAGING_DIR)/lib and
$(STAGING_DIR)/usr/lib in the Qemu wrapper. This works because
LD_LIBRARY_PATH paths have precedence over paths given by
ld.so.cache.
This is the solution already used by the GOI qemu wrapper in
package/gobject-introspection/g-ir-scanner-qemuwrapper.in.
We chose to go with the third option, because it has been proven to work
for the GOI wrapper, and has been reported to solve #14366. Even though
the first option would be the best, it is also the one that has the
least chances to land any time soon (if ever); the second has not been
exercised, and the impact is not fully understood either (e.g what about
non-glibc toolchains?).
Fixes: #14366
Signed-off-by: Jens Maus <mail@jens-maus.de>
[yann.morin.1998@free.fr:
- add whole analsys done by Thomas in:
https://lore.kernel.org/buildroot/20221031213926.50d3c778@windsurf/
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
- Drop patch (already in version)
- Drop license comment and add REAMDE and libopeniscsiusr/COPYING as
license files due to
10d50ed4bchttps://github.com/open-iscsi/open-iscsi/blob/2.1.9/Changelog
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
linux/fsverity.h is only available since kernel 5.4 and
085771ec14
resulting in the following build failure since bump to version 2023.5 in
commit c64a3e9767 and
d3b4b1a259:
composefs/libcomposefs/lcfs-writer-erofs.c:37:10: fatal error: linux/fsverity.h: No such file or directory
37 | #include <linux/fsverity.h>
| ^~~~~~~~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/045987a09cf9061dae80db6ada1f912b2867db26
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Unless told otherwise, ninja will spawn as many jobs as there are CPU
(plus 2). Nodejs is built with ninja, but it is a generic package, so
there is no variable (like with cmake-package) that passes the proper
number of parallel jobs as configured by the user.
As a consequence, the nodejs build will use as many CPU as are
available, possibly overcommitting the rsources the user expected to be
used.
Set the JOBS variableto limit that number.
Signed-off-by: Jens Maus <mail@jens-maus.de>
[yann.morin.1998@free.fr: reword commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fixes the following security vulnerability:
- CVE-2023-27585: Heap buffer overflow when parsing DNS packet
https://github.com/pjsip/pjproject/security/advisories/GHSA-q9cp-8wcq-7pfr
Drop now upstreamed security fixes for CVE-2022-23537 and CVE-2022-23547.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit fixes a problem where the NUT package couldn't be
used as a NUT server due to the fact that the default group for
nobody is "nogroup" and not "nobody" like the internal default
of NUT. Thus, when starting a NUT server daemon the daemon starts
with incorrect group permissions. This commit fixes this
shortcoming by introducing a dedicated 'nut' user and 'nut' group
to drop priviledges to it.
Signed-off-by: Jens Maus <mail@jens-maus.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
For release announce, see:
https://lists.infradead.org/pipermail/kexec/2023-August/027830.html
This new version introduced a usage of memfd_create() in [1]. This
function was introduced in Kernel 3.17. Therefore, this commit adds
this new dependency. This direct use of memfd_create() requires a
glibc >= 2.27. As is, this version would no longer work with uclibc-ng
or musl libc. This commit also adds a patch to allow compilation with
glibc < 2.27, and also uclibc and musl. See the patch commit log for
more details.
[1] https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=714fa11590febc9cf6fd3c6309374a040a05ebb0
Signed-off-by: Julien Olivain <ju.o@free.fr>
[yann.morin.1998@free.fr: add arch dependency to comment]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
According to a collaborator [0] the affected code isn't in 4.3.1
[0]: https://github.com/obgm/libcoap/issues/1117
Signed-off-by: Daniel Lang <dalang@gmx.at>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
