fix fedora44 #23
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,6 +23,12 @@ RUN wget "https://github.com/Kitware/CMake/releases/download/v${CMAKE_VERSION}/c | |
| ./cmake.sh --skip-license --prefix=/usr/local && \ | ||
| rm ./cmake.sh | ||
|
|
||
| # Necessary to remove numctl-libs, so msquic works | ||
| RUN dnf -y update && \ | ||
| dnf -y remove \ | ||
| wget \ | ||
| numactl-libs | ||
|
Comment on lines
+26
to
+30
There was a problem hiding this comment. 🧩 Analysis chain🌐 Web query:
💡 Result: No clear evidence that msquic conflicts with numactl or numactl-libs on Fedora Linux. What we do see in msquic’s Fedora-related issues is dependency/build completeness around NUMA, not package-level “conflicts”: - msquic’s early Linux packages had issues around locating the NUMA header (numa.h). The report explicitly notes the packages “don’t actually have the libnuma dependency” (and the build found libnuma.so but not numa.h), and that this was fixed via a follow-up change/pull request [1]. - Other Fedora packaging issues mentioned by msquic’s maintainers/issue reporters are about missing publication for specific Fedora releases, and unrelated missing dependencies (e.g., lttng-ust), not conflicts with numactl/numactl-libs [2][3][4]. So, based on the available Fedora-focused msquic evidence, the relevant risk is whether the system has the required NUMA development/runtime libraries at build/install time (e.g., libnuma/numa.h), rather than a conflict between msquic and numactl/numactl-libs. If you’re troubleshooting Fedora specifically, the practical check is to ensure the needed NUMA pieces are present (libnuma runtime and headers/devel if building from source). Citations:
🌐 Web query:
💡 Result: You generally should NOT remove numactl-libs just because you installed msquic; whether you must keep it depends on your msquic build/package and distro. What the evidence shows: - MsQuic’s Linux shared library can load libnuma at runtime (e.g., ldd output shows libnuma.so.1 linked by libmsquic.so). In other words, if your msquic package is linked against libnuma, removing numactl-libs (which provides the runtime libnuma.so.1 on many distros) would break msquic at load time. [1] - MsQuic maintainers have discussed packaging/build pipeline issues where a libnuma runtime dependency may or may not be correctly declared in the package metadata (e.g., “No libnuma dependency because it wasn’t fully available at build time”, later fixed). That means some installations may appear to work until you actually run into a missing libnuma.so.1. [1] Practical guidance (safe approach): 1) Check whether your installed msquic library currently depends on libnuma: - Debian/Ubuntu/RPM systems: - ldd $(readlink -f /usr/lib*/libmsquic.so.* 2>/dev/null | head -n1) | grep -i numa - If you see “libnuma.so.1 => …”, keep numactl-libs installed. 2) If you do not see any libnuma dependency for your particular libmsquic build, then removing numactl-libs may be safe for runtime—but you should validate by starting whatever process uses msquic. If you tell me your distro (e.g., Ubuntu 22.04, Debian 12, RHEL/Rocky 9) and which msquic package/version you installed, I can suggest the exact dpkg/rpm commands to remove it safely and how to verify msquic still loads. Citations: 🌐 Web query:
💡 Result: On Fedora, the “libnuma” dependency that MsQuic may need is provided by the Fedora package “numactl-libs” (it “provides libnuma” and contains libnuma.so.1). [1] Evidence: - Fedora’s package page for numactl-libs explicitly states it provides “libnuma libraries” and “libnuma, a library to do allocations with NUMA policy”. [1] - MsQuic maintainers discussed/confirmed that MsQuic links to libnuma.so.1 on Linux (and that missing package metadata depended on build-time availability, but the library is runtime-linked when present). [2][3] Practical Fedora packaging/install guidance: - If you’re running MsQuic’s shared library and it reports libnuma.so.1 missing, install numactl-libs. [1][3] Example: - sudo dnf install numactl-libs Citations:
🌐 Web query:
💡 Result: MsQuic’s NUMA support uses libnuma headers, specifically numa.h, and on Fedora you should ensure the development package that provides numa.h is installed (not just the runtime library). 1) What numa.h/libnuma are for - The libnuma library provides the programming interface for NUMA policy and its API is exposed via headers that include <numa.h> (e.g., the Linux man page shows how to compile with -lnuma and that source includes <numa.h>) [1]. 2) What happened in MsQuic builds/packages - MsQuic maintainers reported that at one point the build pipeline could find libnuma.so but failed to find numa.h at build time, noting the build log: “-- Found libnuma … -- numa.h not found. If build fails, install libnuma-dev” [2]. - This was addressed by a fix that corrects how numa.h is located; maintainers also showed that after the fix, libmsquic links against libnuma.so.1 at runtime (ldd output includes libnuma.so.1) [2]. - Separately, maintainers discussed that MsQuic depends on libnuma but packages may not have declared the dependency consistently (discussion of “libnuma is missing” vs later versions) [3]. 3) Fedora-specific dependency to install - On Fedora/RHEL-family systems, the runtime library package (often named something like libnuma) may be insufficient for building from source because <numa.h> is in the development package (the analogous issue for other distros shows the pattern: installing libs alone is not enough; you need the devel package that provides numa.h) [4]. Action (Fedora) - Install the libnuma development package that provides numa.h before building MsQuic from source or building dependent components: - sudo dnf install libnuma-devel Evidence: MsQuic’s build explicitly checks for numa.h and recommends installing the “libnuma-dev” package when numa.h is missing [2], which corresponds to the devel package on Debian/Ubuntu; the general symptom “numa.h: No such file or directory even when libnuma runtime is installed” is fixed by installing the devel package (numactl-devel/libnuma-devel depending on distro) [4]. If you tell me the exact Fedora version and whether you’re building msquic from source or installing the prebuilt libmsquic RPM, I can tailor the exact dnf command and verify what the package dependency list should look like for that release. Citations:
Fix the claim about removing
🧰 Tools🪛 Trivy (0.69.3)[error] 27-30: 'RUN update' instruction alone The instruction 'RUN update' should always be followed by ' install' in the same RUN statement. Rule: DS-0017 (IaC/Dockerfile) 🤖 Prompt for AI Agents |
||
|
|
||
| ARG CMLIB_VERSION=1.3.5 | ||
| RUN git clone --branch v${CMLIB_VERSION} --depth 1 https://github.com/cmakelib/cmakelib.git /cmakelib | ||
| RUN echo "export CMLIB_DIR=/cmakelib" >> /root/.bashrc | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix typo in comment.
The comment says "numctl-libs" but should be "numactl-libs" (missing 'a').
📝 Proposed fix
📝 Committable suggestion
🤖 Prompt for AI Agents