Our current apitrace version can't detect the host-python version
correctly, so if both host-python and host-python3 where installed, it
will take the last one and it will fail with an "invalid syntax" error.
The latest apitrace version has this problem solved and it detects the
host-python version correctly.
Fixes:
http://autobuild.buildroot.net/results/22a/22a73b4ba0adcc874ecc153917ae6edcfd4d37af/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The daemon binary is tftpd, not in.tftpd. While we are at it, drop the
unneeded /usr/local from the PATH.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Both of CONFIG_NF_CONNTRACK and CONFIG_NF_CONNTRACK_MARK are needed by
xtables-addons.
Although the current code does enable them in the linux' .config file,
the former is protected behind CONFIG_NETFILTER_ADVANCED, which may be
missing from a user-supplied (def)config file, and is missing from some
of the bundled defconfigs as well.
For example, the following defconfig fails to build:
BR2_TOOLCHAIN_EXTERNAL=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_DEFCONFIG="i386"
BR2_PACKAGE_XTABLES_ADDONS=y
So, also force-enable CONFIG_NETFILTER_ADVANCED.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Too often the question is raised, that ipkg, opkg and rpm do not work,
and users complain they can not install packages.
Even though we do have a clear and clearly explained section in our
manual, people do not read it (when will users read manuals? sigh...).
So, add a big fat comment about ipkg/opkg/rpm, that Buildroot does not
generate binary packages and does not provide any package database for
any of those package manager.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libselinux causes some build problems due to the toolchain on ARC,
which haven't been solved so far. As a temporary solution for Buildroot
2015.08, this commit makes libselinux (and its reverse dependencies)
unavailable on ARC. Of course, once the toolchain problem is
addressed, this commit can be reverted to re-enable libselinux on ARC.
Fixes:
http://autobuild.buildroot.org/results/220/2207f6aad44a6988bf07b02b583b6418ad930dc8/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds a patch to Boost to make it use the eventfd()
function provided by the C library when uClibc is used, rather than
falling back to using directly the __NR_eventfd system call. This
fixes the build on ARC, which doesn't define __NR_eventfd.
The original problem is that uClibc pretends to be glibc 2.2, which
didn't had eventfd(), so Boost makes the system call
manually. uClibc-ng, in its next release, will pretend to be glibc
2.10 (see
http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=4ff3a6c8eb91db71d6dc3d2932b66e848bd20ac3),
which will also fix the problem, but requires bumping the uClibc
version, rebuilding the external toolchains, and so on.
Ideally, Boost should be doing a compile test to detect if eventfd()
is available or not, but the Boost build system is so brain-damaged
that doing so would require way too much effort.
Fixes:
http://autobuild.buildroot.org/results/22b/22b710346d2cd78b7b51cdccd18d670bb6ac5d24/
and many similar build failures
[Peter: minor tweaks to description]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The mono source code includes <dlfcn.h>, which is only available when
shared library support is available. While it might be possible to do
a fully static installation of Mono, it probably isn't very useful.
While we're at it, this commit also makes sure that the Config.in
comment is not visible when the architecture doesn't support Mono.
Fixes:
http://autobuild.buildroot.net/results/5d99bdf77f1942fa403081267c362aa1f8fd0dab/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When the XCB backend is selected, the libqxcb.so plugin is installed,
and is linked against libQt5XcbQpa.so. However, until, Buildroot was
not installing this library. This commit fixes this.
[Thomas: tweak commit log.]
Signed-off-by: Matthew Shyu <matthew.shyu@amlogic.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libpthsem has been affected since quite a while by build issues, but
occuring only on Nathaniel Roach's autobuilder. The failure message
is:
error: #error "Unsupported Linux (g)libc version and/or platform"
This message comes from pth_mctx.c file, which implements five methods
for machine context initialization:
VARIANT 1: THE STANDARDIZED SVR4/SUSv2 APPROACH
VARIANT 2: THE SIGNAL STACK TRICK
VARIANT 3: LINUX SPECIFIC JMP_BUF FIDDLING
VARIANT 4: INTERACTIVE SPECIFIC JMP_BUF FIDDLING
VARIANT 5: WIN32 SPECIFIC JMP_BUF FIDDLING
The "Unsupported (g)libc version and/or platform" only appears when
"VARIANT 4" is used, since VARIANT 4 only supports a very limited
number of platforms. So when building with Nathaniel's autobuilder,
VARIANT 4 is chosen.
However, when you build libpthsem on some other machine than
Nathaniel's autobuilder, VARIANT 2 is chosen, and works regardless of
the glibc version or architecture.
VARIANT 2 is chosen when:
!PTH_MCTX_DSP(sjljlx) &&\
!PTH_MCTX_DSP(sjljisc) &&\
!PTH_MCTX_DSP(sjljw32)
On both Nathaniel's autobuilder, and on a different machine, the
PTH_MCTX_MTH macro gives sjlj:
#define PTH_MCTX_MTH_use PTH_MCTX_MTH_sjlj
However, on a "normal" machine, the PTH_MCTX_DSP macro gives ssjlj:
#define PTH_MCTX_DSP_use PTH_MCTX_DSP_ssjlj
While on Nathaniel's autobuilder, it gives:
#define PTH_MCTX_DSP_use PTH_MCTX_DSP_sjljlx
This explains why VARIANT 4 is being used on Nathaniel's autobuilder,
while VARIANT 2 is used when building on other platforms.
The decision of the value for PTH_MCTX_DSP is derived as follows in
configure.ac:
AC_CHECK_SJLJ(sjlj=yes, sjlj=no, sjlj_type)
[...]
elif test ".$sjlj" = .yes; then
mctx_mth=sjlj
mctx_dsp=$sjlj_type
[...]
AC_DEFINE_UNQUOTED(PTH_MCTX_DSP_use, [PTH_MCTX_DSP_$mctx_dsp], [define for machine context dispatching])
So basically, the value of PTH_MCTX_DSP is $sjlj_type, as returned by
the AC_CHECK_SJLJ autoconf macro, implemented in
acinclude.m4. However, reading this macro is quite informative: it
does a number of tests that are not cross-compile
friendly. Especially, it looks at the kernel version with 'uname -r'
to decide whether the Linux system is braindead or not. If the system
runs a 2.2.x kernel or newer 2.x, or a 3.x kernel, everything is fine,
the system is not braindead, and sjlj_type is set to ssjlj. However,
if the build system runs a 4.x kernel, then it is considered as
braindead, and sjlj_type is set to sjljlx.
And indeed, Nathaniel's autobuilder is running a 4.x kernel, while all
other autobuilders run 2.x or 3.x kernels.
Since for all sane Linux systems, this AC_CHECK_SJLJ macro concludes
that the setjmp/longtmp type is ssjlj, this commit takes the simplest
route of forcing this value, skipping the broken detection.
Note that we're overriding ac_cv_check_sjlj instead of using the
--with-mctx-* options, since the latter do not work properly in the
context of Nathaniel's autobuilder, as the broken cross-compilation
tests continue to cause problems.
Fixes:
http://autobuild.buildroot.org/results/3dd/3dd66d70c2e36f2d9fb0a0fe01bbdec009d55067/
and many similar build failures
This patch has been tested by Nathaniel Roach in the context of his
autobuilder instance which was causing the original problem.
Tested-by: Nathaniel Roach <nroach44@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Eventhough it should be theoretically possible to build protobuf in
static-only, configure.ac includes an m4 macro, ACX_PTHREAD defined in
m4/acx_pthread.m4, which forcibly checks for threads *with* shared libs,
and is completely broken for static-only (as it forces -shared whatever
the user selection), ending up with these configure results:
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking whether to check for GCC pthread/shared inconsistencies... yes
checking whether -pthread is sufficient with -shared... no
checking whether -lpthread fixes that... no
checking whether -lc_r fixes that... no
configure: WARNING: Impossible to determine how to use pthreads with shared libraries
checking whether what we have so far is sufficient with -nostdlib... no
checking whether -lpthread saves the day... no
configure: WARNING: Impossible to determine how to use pthreads with shared libraries and -nostdlib
Fixing this macro is far from trivial; protobuf in a static-only
scenario is probably not too common. So, just disable protobuf for
static-only builds.
Fixes:
http://autobuild.buildroot.org/results/3ef/3efb86c7e8ec2db5d953d634470cafae79bd34cf/http://autobuild.buildroot.org/results/96a/96ae1108fc3193df2a93a779057130b774379655/http://autobuild.buildroot.org/results/00c/00c29795980319d38823eec1301e9ebd860ebd2a/
...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Nimai Mahajan <nimaim@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, protobuf-c's dependency on threads is labelled as being
inherited from protobuf.
This is wrong, as protobuf-c does not depend on protobuf, and such
dependency was removed in e16865a (protobuf-c: Don't require protobuf on
target), but forgot to remove the corresponding comment.
Remove it now.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch fixes this autobuild failure:
http://autobuild.buildroot.net/results/e14/e14e1700d4fe359c56be57587bdb509e002e5753/build-end.log
The problem is caused by the -fvisibility-inlines-hidden switch.
Removing the switch is probably the least intrusive way we can make the
problem go away. The first solution that was considered was to move the
definition of the offending method to the .cpp file. However, with
other combinations of compilers and platforms, I suppose it could happen
with other methods as well. Removing the switch ensures we catch them
all.
Built-tested with the config from the build bot, as well as with all OLA
options/plugins enabled.
Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, when a preconfigured prebuilt toolchain forgets to specify
its gcc version, the error message is a bit misleading, like:
Incorrect selection of gcc version: expected .x, got 4.9.2
Add a an explicit check for the gcc version being set, that reports a
better error message.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
C++ support unconditionally needs shared libraries; it uses
dlopen/dlsym.
Also, fix the conditions under which the comment is shown.
Finally, explicitly require C++ support when configuring.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Test the configuration of the kernel to see if loadable module support
is enabled, and error out otherwise. This makes build failures of
external kernel modules less confusing.
[Thomas: tweak the commit log.]
Signed-off-by: Noé Rubinstein <nrubinstein@aldebaran.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The common filesystem infrastructure already supports a
<fs>_PRE_GEN_HOOKS variable, which allows filesystem makefiles to
register some actions to be done before the root filesystem image is
generated.
This commit adds a similiar <fs>_POST_GEN_HOOKS variable, which will
allow filesystem makefiles to do some actions after the filesystem
image has been generated. It will initially be used by the iso9660
filesystem to delete the temporary directory it creates.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Noé Rubinstein <nrubinstein@aldebaran.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gcc will always report a three-digit version sting, like 4.9.3 or 5.1.0.
For gcc before 5, we want to check the first two digits, while starting
with gcc 5, we are only concerned about the first digit.
So, change our matching code to test for the leading part of the version
string, up to the first dot after as-many version digit we're interested
in.
Note: we're adding the dot in the .mk code rather than in the Kconfig
symbol, because it seemed cleaner to do so.
Reported-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The project seems not maintained anymore since there
is no commit since 2011:
https://github.com/wlach/wvstreams
After fixing the first build issue by adding a missing limit.h header...
xplc/modulemgr.cc:90:14: error: ‘PATH_MAX’ was not declared in this scope
char fname[PATH_MAX];
and fixing a basename() conflict between the gnu and posix version,
the build fail due to missing __libc_stack_end.
wvtask.cc:(.test+0xb08): undefined reference to `__libc_stack_end'
There is a configure test for __libc_stack_end support but it
doesn't work properly with a musl toolchain.
Since we already have several fixes for uClibc, let's mark wvstreams
as not available for musl toolchains, until someone interested
enough fixes it.
[Thomas: replace uClibc-ng by just uClibc in the Config.in comments.]
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As Thomas puts it:
The comment can only be visible when a toolchain that is *not*
uclibc and *not* glibc is used. I.e, the comment is now only visible
when musl is used. Which is not what we want.
Indeed, I completely borked the conditions. When a glibc or uClibc
toolchain is selected, the comment is entirely hidden, and we don;t get
the extra requirements (wchar, !static).
Fix that with the solution proposed by Thomas.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
According to Nicolas Cavallari and confirmed by testing, std::strtoll
is indeed available in gcc 4.6, so the dawgdic package can be enabled
on gcc >= 4.6 instead of gcc >= 4.7.
Reported-by: Nicolas Cavallari <Nicolas.Cavallari@green-communications.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When gcc 4.9.x was bumped from 4.9.2 to 4.9.3 in commit
2fed00ea1e, patch
920-libgcc-remove-unistd-header.patch was removed with the argument
that it had been applied upstream.
However, it is not the case, and the patch continues to apply fine on
gcc 4.9.3, and is actually needed to make gcc build properly on
NIOS-II.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As found via autobuilders and discussed on the list, the
ifdef is wrong, as empty uses SysV semaphores and not POSIX
semaphores.
Tested with glibc/uclibc-ng builds. And with uclibc-ng without
threads.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
SourceForge is working again, and Peter has copied the file to
fan-ctrl.c on sources.buildroot.org so that it gets found if
SourceForge breaks again. Therefore this commit re-enables the
fan-ctrl package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since argp-standalone is only available for uClibc-ng
and musl toolchains, it's safe to link with it when
the package is selected.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since argp-standalone is only available for uClibc-ng
and musl toolchains, add the dependendy only if it's
selected.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since argp-standalone is only available for uClibc-ng
and musl toolchains, it's safe to link with it when
the package is selected.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
lrzsz could technically build in a static-only environment, but it
unconditionally redefines the error() and error_at_line() functions,
which clashes with the definition from uClibc. Since the autotools
packaging dates back from 1998, lots of work is needed to fix it, and
do some proper tests on the availability of such functions.
So, let's mark it as not available for static builds, until someone
interested enough fixes it.
Fixes:
http://autobuild.buildroot.net/results/8106ab057f538d1408d736736fdbe50b99ae709d/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: applying for 2015.08, because it fixes a regression
introduced in dnsmasq 2.74, as reported by Gustavo.]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
According to the doc file from <uclibc-src>/docs/
Glibc_vs_uClibc_Differences.txt, the uclibc library read the
TZ environment variable, or the /etc/TZ file; the /etc/TZ file
should be a single line, ending with a newline, containing the
TZ setting. For example: echo CST6CDT > /etc/TZ
Whereas the tzdump cmd would output two lines like this:
# Asia/Shanghai
CST-8
This make the uclibc could not read the correct TZ setting, therefore
e.g. the 'busybox date' cmd always show the UTC timezone.
This fix remove the redundant first line from the tzdump output.
Signed-off-by: Scott Fan <fancp2007@gmail.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add a patch to disable mallinfo statistics with musl toolchains
which doesn't have struct mallinfo.
Fixes:
selinux-util.c: In function ‘mac_selinux_init’:
selinux-util.c:70:25: error: storage size of ‘before_mallinfo’ isn’t known
struct mallinfo before_mallinfo, after_mallinfo;
Add a second patch for strndupa() which is a GNU extension.
Fixes:
./.libs/libudev-core.a(selinux-util.o): In function `mac_selinux_bind':
selinux-util.c:(.text+0xd94): undefined reference to `strndupa'
collect2: error: ld returned 1 exit status
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Clayton Shotwell <clshotwe@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The musl C library does not understand the feature test macro __USE_MISC and so
libuv (built-in dependency of nodejs) does not use the correct struct stat
definition for musl:
error: ‘uv_statbuf_t’ has no member named ‘st_ctimensec’
error: ‘uv_statbuf_t’ has no member named ‘st_mtimensec’
The macro __USE_MISC is defined by glibc if _BSD_SOURCE or _SVID_SOURCE is
defined.
The libuv build system enables the feature test macro _GNU_SOURCE for linux
builds.
Since glibc 2.19, defining _GNU_SOURCE also has the effect of implicitly
defining _DEFAULT_SOURCE - the replacement for _BSD_SOURCE and _SVID_SOURCE.
In glibc versions before 2.20, defining _GNU_SOURCE also had the effect of
implicitly defining _BSD_SOURCE and _SVID_SOURCE. This is also true for uClibc.
Alltogether, we can safely replace __USE_MISC by _GNU_SOURCE to support building
nodejs 0.10.x with the musl C library.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add a patch from the Alpine Linux project [1] to fix a musl build issue with
gcc 5:
```
error: temporary of non-literal type ‘pthread_mutex_t’ in a constant expression
constexpr PosixMutex():mutex(PTHREAD_MUTEX_INITIALIZER) {}
```
Problem has been reported by the Alpine team upstream and was closed by the MPD
maintainer with WONTFIX:
http://bugs.musicpd.org/view.php?id=4387http://bugs.musicpd.org/view.php?id=4110
However...
POSIX does not permit using PTHREAD_COND_INITIALIZER except for static
initialization, and certainly does not permit using it as a value.
Also POSIX does not specify the type of the object (it's opaque) so if
there are any types for which their code would be invalid C++, then their
code is invalid.
Also, volatile in the type is necessary. without that, LTO can break the code.
[1]
http://git.alpinelinux.org/cgit/aports/log/main/mpd/musl-gcc5-fixes.patch
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Angelo is the author of the upstream patch, so it is safe to add his
SoB. This commit also adds the upstream status of the patch.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Webkit 2.4.x depends on gcc being >= 4.8.x so use the new
BR2_TOOLCHAIN_GCC_AT_LEAST_X_Y knob and drop the manual x86* external
toolchain exclusions.
Follow up in the midori package as well.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
depends on BR2_arm || BR2_i386 || BR2_mipsel || BR2_x86_64
# host-protobuf only builds on certain architectures
depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
depends on !BR2_STATIC_LIBS
help
Protocol buffers are Google's language-neutral, platform-neutral,
extensible mechanism for serializing structured data.
https://developers.google.com/protocol-buffers
comment "protobuf needs a toolchain w/ C++, threads"
depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS
comment "protobuf needs a toolchain w/ C++, threads, dynamic library"
depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS \
|| BR2_STATIC_LIBS
depends on BR2_arm || BR2_i386 || BR2_mipsel || BR2_x86_64
depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Thomas Petazzoni