| Message ID | 20231228152657.488457-2-antoine.coutant@smile.fr |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,1/3] package/{rust, rust-bin}: bump to version 1.74.1 | expand |
Antoine, All, Thanks for this patchset! On 2023-12-28 16:26 +0100, Antoine Coutant spake thusly: > ripgrep previous version hash is no longer valid. > The tarball is modified by rust vendoring so the hash > may change with rust versions. If that's so, then we have a big problem: the hashes for all the cargo-based packages will change, and thus it means we will have to name the generated archive based on the cargo version used to do the vendoring. That would apply to: package/bat/bat.mk package/dust/dust.mk package/eza/eza.mk package/hyperfine/hyperfine.mk package/nushell/nushell.mk package/procs/procs.mk package/ripgrep/ripgrep.mk package/rust-bindgen/rust-bindgen.mk package/sentry-cli/sentry-cli.mk package/tealdeer/tealdeer.mk Can you clarify this point, please? Regards, Yann E. MORIN. > The patch has been rebased to ripgrep 14.0.3. > > Changelog: > https://github.com/BurntSushi/ripgrep/blob/master/CHANGELOG.md > > Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> > --- > > Tested using qemu_aarch64_virt_defconfig and Arm AArch64 13.2.rel1 > toolchain. > > Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> > --- > ...llocator-behind-a-cargo-feature-flag.patch | 52 ++++++++++--------- > package/ripgrep/ripgrep.hash | 2 +- > package/ripgrep/ripgrep.mk | 6 +-- > 3 files changed, 29 insertions(+), 31 deletions(-) > > diff --git a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch > index e2ba68f389..aa073c6e7f 100644 > --- a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch > +++ b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch > @@ -1,4 +1,4 @@ > -From 68c2a4d7a5d9b46f65121958fdb12d5270bfd1b6 Mon Sep 17 00:00:00 2001 > +From e4df6678e3e2d018acccafd47d1e484887d23323 Mon Sep 17 00:00:00 2001 > From: Jonathan Stites <mail@jonstites.com> > Date: Wed, 6 May 2020 12:55:35 +0000 > Subject: [PATCH] puts jemalloc allocator behind a cargo feature flag > @@ -9,6 +9,8 @@ Moves jemalloc behind a feature for musl builds, where it is not > supported by the upstream project, so ripgrep will fail to build. > > Signed-off-by: Sam Voss <sam.voss@gmail.com> > +[Antoine: update for 14.0.3] > +Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> > --- > .github/workflows/ci.yml | 6 ++++++ > .github/workflows/release.yml | 8 +++++++- > @@ -18,10 +20,10 @@ Signed-off-by: Sam Voss <sam.voss@gmail.com> > 5 files changed, 35 insertions(+), 4 deletions(-) > > diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml > -index ab154ec..aa567d9 100644 > +index b37753e..a2cdeee 100644 > --- a/.github/workflows/ci.yml > +++ b/.github/workflows/ci.yml > -@@ -149,6 +149,12 @@ jobs: > +@@ -160,6 +160,12 @@ jobs: > if: matrix.target != '' > run: ${{ env.CARGO }} test --verbose --workspace ${{ env.TARGET_FLAGS }} > > @@ -31,14 +33,14 @@ index ab154ec..aa567d9 100644 > + if: matrix.os == 'nightly-musl' > + run: ${{ env.CARGO }} test --verbose --all --features jemalloc ${{ env.TARGET_FLAGS }} > + > - - name: Test for existence of build artifacts (Windows) > - if: matrix.os == 'windows-2019' > - shell: bash > + - name: Test zsh shell completions (Unix, sans cross) > + # We could test this when using Cross, but we'd have to execute the > + # 'rg' binary (done in test-complete) with qemu, which is a pain and > diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml > -index 7cfb6a4..ad6b82d 100644 > +index b10c076..58a7a12 100644 > --- a/.github/workflows/release.yml > +++ b/.github/workflows/release.yml > -@@ -133,7 +133,13 @@ jobs: > +@@ -153,7 +153,13 @@ jobs: > echo "target flag is: ${{ env.TARGET_FLAGS }}" > echo "target dir is: ${{ env.TARGET_DIR }}" > > @@ -50,25 +52,25 @@ index 7cfb6a4..ad6b82d 100644 > + > + - name: Build release binary (non-linux) > + if: matrix.build != 'linux' > - run: ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} > - > - - name: Strip release binary (linux and macos) > + shell: bash > + run: | > + ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} > diff --git a/Cargo.toml b/Cargo.toml > -index fb78fcb..0d34b1e 100644 > +index f30cc0b..6fe4c79 100644 > --- a/Cargo.toml > +++ b/Cargo.toml > -@@ -56,8 +56,9 @@ version = "2.33.0" > - default-features = false > - features = ["suggestions"] > +@@ -59,8 +59,9 @@ serde_json = "1.0.23" > + termcolor = "1.1.0" > + textwrap = { version = "0.16.0", default-features = false } > > -[target.'cfg(all(target_env = "musl", target_pointer_width = "64"))'.dependencies.jemallocator] > +[dependencies.jemallocator] > - version = "0.3.0" > + version = "0.5.0" > +optional = true > > - [build-dependencies] > - lazy_static = "1.1.0" > -@@ -75,6 +76,11 @@ walkdir = "2" > + [dev-dependencies] > + serde = "1.0.77" > +@@ -70,6 +71,11 @@ walkdir = "2" > [features] > simd-accel = ["grep/simd-accel"] > pcre2 = ["grep/pcre2"] > @@ -81,10 +83,10 @@ index fb78fcb..0d34b1e 100644 > [profile.release] > debug = 1 > diff --git a/README.md b/README.md > -index 46938bc..9917b29 100644 > +index 63c0725..3d35819 100644 > --- a/README.md > +++ b/README.md > -@@ -406,6 +406,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have > +@@ -442,6 +442,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have > `musl-gcc` installed, which might be in a separate package from the actual > MUSL library, depending on your Linux distribution. > > @@ -101,10 +103,10 @@ index 46938bc..9917b29 100644 > ### Running tests > > diff --git a/crates/core/main.rs b/crates/core/main.rs > -index 47385de..c9dae5a 100644 > +index 64f35ce..9aa6663 100644 > --- a/crates/core/main.rs > +++ b/crates/core/main.rs > -@@ -31,7 +31,7 @@ mod subject; > +@@ -27,7 +27,7 @@ mod search; > // have the fastest version of everything. Its goal is to be small and amenable > // to static compilation.) Even though ripgrep isn't particularly allocation > // heavy, musl's allocator appears to slow down ripgrep quite a bit. Therefore, > @@ -113,7 +115,7 @@ index 47385de..c9dae5a 100644 > // > // We don't unconditionally use jemalloc because it can be nice to use the > // system's default allocator by default. Moreover, jemalloc seems to increase > -@@ -39,7 +39,11 @@ mod subject; > +@@ -35,7 +35,11 @@ mod search; > // > // Moreover, we only do this on 64-bit systems since jemalloc doesn't support > // i686. > @@ -127,5 +129,5 @@ index 47385de..c9dae5a 100644 > static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc; > > -- > -2.32.0 > +2.25.1 > > diff --git a/package/ripgrep/ripgrep.hash b/package/ripgrep/ripgrep.hash > index 71e74e1bcf..ff86c12ad5 100644 > --- a/package/ripgrep/ripgrep.hash > +++ b/package/ripgrep/ripgrep.hash > @@ -1,3 +1,3 @@ > # Locally calculated > -sha256 6f1d4a8b653ce48d59ad777288b1257cbda607db29db19d031b7e622c60526f8 ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5.tar.gz > +sha256 2f022889c999ffe00955e586fe24b334d1c79060978fc41b95b52a30946e65d0 ripgrep-14.0.3.tar.gz > sha256 0f96a83840e146e43c0ec96a22ec1f392e0680e6c1226e6f3ba87e0740af850f LICENSE-MIT > diff --git a/package/ripgrep/ripgrep.mk b/package/ripgrep/ripgrep.mk > index d587441cfa..44662749bb 100644 > --- a/package/ripgrep/ripgrep.mk > +++ b/package/ripgrep/ripgrep.mk > @@ -4,11 +4,7 @@ > # > ################################################################################ > > -# Same as 13.0.0, we use a Git commit hash because the hash of this > -# tarball changed when moving to the cargo-package infrastructure, and > -# we can't change the hash of existing tarball. Please switch back to > -# a Git tag at the next version bump. > -RIPGREP_VERSION = af6b6c543b224d348a8876f0c06245d9ea7929c5 > +RIPGREP_VERSION = 14.0.3 > RIPGREP_SITE = $(call github,burntsushi,ripgrep,$(RIPGREP_VERSION)) > RIPGREP_LICENSE = MIT > RIPGREP_LICENSE_FILES = LICENSE-MIT > -- > 2.25.1 > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
On Fri, 29 Dec 2023 23:13:35 +0100 "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > If that's so, then we have a big problem: the hashes for all the > cargo-based packages will change, and thus it means we will have to > name the generated archive based on the cargo version used to do the > vendoring. That would apply to: Note that I also encountered some hash mismatch on some Rust/Cargo package recently, and BR was falling back to sources.buildroot.net. I did not have the time to investigate at the time (I was looking into another issue, and didn't want to enter an infinite recursion of problem solving quest). And now, I don't remember with which package I encountered this. But yes, it seems like we have a reproducibility issue. Best regards, Thomas
Thomas, All, On 2023-12-30 19:00 +0100, Thomas Petazzoni via buildroot spake thusly: > On Fri, 29 Dec 2023 23:13:35 +0100 > "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > > If that's so, then we have a big problem: the hashes for all the > > cargo-based packages will change, and thus it means we will have to > > name the generated archive based on the cargo version used to do the > > vendoring. That would apply to: > Note that I also encountered some hash mismatch on some Rust/Cargo > package recently, and BR was falling back to sources.buildroot.net. I > did not have the time to investigate at the time (I was looking into > another issue, and didn't want to enter an infinite recursion of > problem solving quest). And now, I don't remember with which package I > encountered this. But yes, it seems like we have a reproducibility > issue. So, I tested with commit b7938d2, i.e. before the rust version bump, and ripgrep already has a hash issue: ERROR: ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5.tar.gz has wrong sha256 hash: ERROR: expected: 6f1d4a8b653ce48d59ad777288b1257cbda607db29db19d031b7e622c60526f8 ERROR: got : 9d9769e45ffe6089f58bc19fa39dd6b6299aa0c3ad90508d21dfa27a3d3416d5 In 2023-01-01, it was already failing but the reported hash was different: http://autobuild.buildroot.org/results/43d/43d9b993a019c9c46701924f664476c2ac900b2b/build-end.log ERROR: got : ed72a5ad6592c2c605ed9712e896872fd3858b94895601dbbb9f7d2a94b105af Then on 2023-06-25, a vendoring suceeded (the last ripgrep build failure reported in autobuilder): http://autobuild.buildroot.org/results/15b/15bea8d3bc8765ec9088c5bc380d482caee1b6d5/build-end.log Then, I had hash issues with host-sentry-cli, too: ERROR: sentry-cli-2.20.3.tar.gz has wrong sha256 hash: ERROR: expected: 2188b8eead4f2b6543725b23852427bea164e8dd76bf1ce33f41ca0c03cfeee7 ERROR: got : 4db94489e7c427ff092483529eee56229fa764b619669f9f9e6e663cc4a05abc The other cargo-vendored packages were all OK. Then, with the rust version bump to 1.74.1, the vendoring status is unchanged: - ripgrep fails vendoring, and reports the same hash failure - host-sentry-cli fails vendoring, again with the same reported hash failure - all other cargo-vendored packages are fine and don't need a hash bump because of th rust bump. So, we need to understand why we have two cargo-vendored packages that are not reproducible... More investigations later on... Regards, Yann E. MORIN.
Thomas, Antoine, All, On 2023-12-30 20:44 +0100, Yann E. MORIN spake thusly: > On 2023-12-30 19:00 +0100, Thomas Petazzoni via buildroot spake thusly: > > On Fri, 29 Dec 2023 23:13:35 +0100 > > "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > > > If that's so, then we have a big problem: the hashes for all the > > > cargo-based packages will change, and thus it means we will have to > > > name the generated archive based on the cargo version used to do the > > > vendoring. That would apply to: > > Note that I also encountered some hash mismatch on some Rust/Cargo > > package recently, and BR was falling back to sources.buildroot.net. I > > did not have the time to investigate at the time (I was looking into > > another issue, and didn't want to enter an infinite recursion of > > problem solving quest). And now, I don't remember with which package I > > encountered this. But yes, it seems like we have a reproducibility > > issue. [--SNIP--] > - ripgrep fails vendoring, and reports the same hash failure > - host-sentry-cli fails vendoring, again with the same reported hash > failure diffoscope to the rescue: the only change in either package, is a single file that got its mode bits changed (context elided for brevity): --- ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5.tar +++ ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5-2.tar ├── file list │ @@ -2731,1 +2731,1 @@ │ --rwxr-x--- 0 0 0 10719 2021-06-12 12:12:24.000000 ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5/VENDOR/unicode-width/scripts/unicode.py │ +-rwxr-x--x 0 0 0 10719 2021-06-12 12:12:24.000000 ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5/VENDOR/unicode-width/scripts/unicode.py --- sentry-cli-2.20.3.tar +++ sentry-cli-2.20.3-2.tar ├── file list │ @@ -15292,1 +15292,1 @@ │ --rwx------ 0 0 0 1796 2023-07-31 09:58:46.000000 sentry-cli-2.20.3/VENDOR/username/src/lib.rs │ +-rwx--x--x 0 0 0 1796 2023-07-31 09:58:46.000000 sentry-cli-2.20.3/VENDOR/username/src/lib.rs In either case, a single file had its mode bits changed, and it smells like go+X was applied. It seems that cargo did change its behaviour at some point, as the archive as manually downloaded from crates.io does have the executable bits as we originally expected: $ wget -O unicode-width-0.1.8.tar.gz https://crates.io/api/v1/crates/unicode-width/0.1.8/download $ tar xzf unicode-width-0.1.8.tar.gz $ ls -hl unicode-width-0.1.8/scripts/unicode.py -rwxr-x---. 1 ymorin ymorin 11K Jun 29 2020 unicode-width-0.1.8/scripts/unicode.py* $ wget -O username-0.2.0.tar.gz https://crates.io/api/v1/crates/username/0.2.0/download $ tar xzf username-0.2.0.tar.gz $ ls -hl username-0.2.0/src/lib.rs -rwx------. 1 ymorin ymorin 1.8K Aug 10 2017 username-0.2.0/src/lib.rs I could not find anything relevant in the cargo bug tracker: https://github.com/rust-lang/cargo/issues?q=is%3Aissue+vendor+executable+bit So, I have no clue what the best course of action would be. The short-term workaround is to chop-off one more digit from the ripgrep version and recalculate a new hash for it, and for sentry-cli maybe we can update the version (or switch to a commit hash). Probably we will want at some point to introduce a vendoring version, like we have for the git and svn methods. so that we can update rust (and thus cargo) without requiring a version bump/tweak for all affected packages... As an aside, the situation for sentry-cli is a bit concerning: the 'username' crate only ever had one release, 0.2.0, over 6 years ago now, and the documentation and repository listed on the crates.io page no longer exist: https://crates.io/crates/username http://pijul.org/user/doc/user/index.html => 404 https://pijul.org/darcs/user => 404 Meh?... Regards, Yann E. MORIN.
Thomas, Antoine, All, +James and Eric fr their previous work on the rust side On 2023-12-30 20:44 +0100, Yann E. MORIN spake thusly: > On 2023-12-30 19:00 +0100, Thomas Petazzoni via buildroot spake thusly: > > On Fri, 29 Dec 2023 23:13:35 +0100 > > "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > > Note that I also encountered some hash mismatch on some Rust/Cargo > > package recently, and BR was falling back to sources.buildroot.net. I > > did not have the time to investigate at the time (I was looking into > > another issue, and didn't want to enter an infinite recursion of > > problem solving quest). And now, I don't remember with which package I > > encountered this. But yes, it seems like we have a reproducibility > > issue. > So, I tested with commit b7938d2, i.e. before the rust version bump, and > ripgrep already has a hash issue: > ERROR: ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5.tar.gz has wrong sha256 hash: > ERROR: expected: 6f1d4a8b653ce48d59ad777288b1257cbda607db29db19d031b7e622c60526f8 > ERROR: got : 9d9769e45ffe6089f58bc19fa39dd6b6299aa0c3ad90508d21dfa27a3d3416d5 I took some time to try and pinpoint the issue. Alas, I have no clue, just more questions. I first tried to reproduce the original hash for ripgrep, i.e. when it was converted over to the cargo infra, commit 342fd3e735. But that fails to build because of an unrelated issue in the package infra, which was fixed a few commits later, e27a700f3e. And on that commit, it fails to reproduce a valid hash here: the hash I got was again something else totally: ERROR: got : 37d14c1eecb24e5b921c3b0e8a22ed93501db6f7aa4d0732d6be03dfc8647f77 This is very troubling. My system is a Fedora 39 recently installed on my new laptop. What about I try and reproduce on an older system that was current back when ripgrep was converted? So I used that old Ubuntu 16.04 that lies around, and there, miracle, the hash for ripgrep, on commit e27a700f3e, does match what we expect! So, can that machine get us a proper hash for ripgrep on master? Nope; ERROR: got : 9d9769e45ffe6089f58bc19fa39dd6b6299aa0c3ad90508d21dfa27a3d3416d5 OK, back to square one. So, can our (current) docker-run wrapper help us? Back to commit e27a700f3e, which is known good on ubuntu 16.04, but bad on Fedora 39: ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5.tar.gz: OK (sha256: 6f1d4a8b653ce48d59ad777288b1257cbda607db29db19d031b7e622c60526f8) OK, so what, now? As a reminder, commit e27a700f3e contains the core infra fix just after the conversion of ripgrep to the cargo infra. Here's a little summary of what happens e27a700f3e master Ubuntu 16.04.7; - native OK KO + Fedora 39: - native KO * KO + - ./utils/docker-run OK KO + *: hash 37d14c1eecb24e5b921c3b0e8a22ed93501db6f7aa4d0732d6be03dfc8647f77 +: hash 9d9769e45ffe6089f58bc19fa39dd6b6299aa0c3ad90508d21dfa27a3d3416d5 So, we have two issues: - the cargo version has an impact on the vendoring - the build environment has an impact on the vendoring. On my side, further investigations will probably have to wait for next year... Notably, I'll try and see what diffoscope points out as a delta between those various tarballs... Regards, Yann E. MORIN.
All, On 2023-12-31 10:25 +0100, Yann E. MORIN spake thusly: > On 2023-12-30 20:44 +0100, Yann E. MORIN spake thusly: > > On 2023-12-30 19:00 +0100, Thomas Petazzoni via buildroot spake thusly: > > > Note that I also encountered some hash mismatch on some Rust/Cargo > > > package recently, and BR was falling back to sources.buildroot.net. I > > > did not have the time to investigate at the time (I was looking into > > > another issue, and didn't want to enter an infinite recursion of > > > problem solving quest). And now, I don't remember with which package I > > > encountered this. But yes, it seems like we have a reproducibility > > > issue. [--SNIP--] > I took some time to try and pinpoint the issue. Alas, I have no clue, > just more questions. [--SNIP--] > As a reminder, commit e27a700f3e contains the core infra fix just after > the conversion of ripgrep to the cargo infra. Here's a little summary of > what happens > > e27a700f3e master > Ubuntu 16.04.7; > - native OK KO + > Fedora 39: > - native KO * KO + > - ./utils/docker-run OK KO + > > So, we have two issues: > - the cargo version has an impact on the vendoring > - the build environment has an impact on the vendoring. So, turned out that, on F39, we hit the tar 1.35 issue on e27a700f3e. Building host-tar before trying to vendor ripgrep fixes the issue. So, at least, that's that: we *can* reproduce the proper hash for ripgrep at the time it was bumped. So, we're now left with just the cargo version issue... Which is in fact rather good news: we do not have an unknown dependency on the build environment. Regards, Yann E. MORIN.
All, On 2023-12-31 12:01 +0100, Yann E. MORIN spake thusly: > On 2023-12-31 10:25 +0100, Yann E. MORIN spake thusly: > > On 2023-12-30 20:44 +0100, Yann E. MORIN spake thusly: > > > On 2023-12-30 19:00 +0100, Thomas Petazzoni via buildroot spake thusly: > > > > Note that I also encountered some hash mismatch on some Rust/Cargo > > > > package recently, and BR was falling back to sources.buildroot.net. I > > > > did not have the time to investigate at the time (I was looking into > > > > another issue, and didn't want to enter an infinite recursion of > > > > problem solving quest). And now, I don't remember with which package I > > > > encountered this. But yes, it seems like we have a reproducibility > > > > issue. [--SNIP--] > So, we're now left with just the cargo version issue... Which is in fact > rather good news: we do not have an unknown dependency on the build > environment. So, I could not resist starting a git-bisect. I assumed that the issue was due to some rust version bump. So, now that I had established that the conversion of ripgrep over to the cargo infra was indeed correct, and that the bump to rust 1.74.1 (i.e. master as it is today) produces an incorrectly vendored tarball, I started a git bisect looking for the rust version bump that introduced the failure: $ cat defconfig BR2_arm=y BR2_cortex_a7=y BR2_TOOLCHAIN_EXTERNAL=y BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y BR2_BACKUP_SITE="" BR2_PACKAGE_RIPGREP=y $ export BR2_DL_DIR=$(pwd)/trash-dl $ git bisect 05392a5eae6 e27a700f3e140 -- package/rust-bin/ $ rm -rf "${BR2_DL_DIR}"; make clean; make ripgrep-source Rince and repeat until the first bad commit is found, and... tada... It's the bump to rust 1.74.1 that casues the build failure! Wait, wait, no, that can't be correct: I remember that 05392a5eae6^ was bad. And indeed, a manual test on 05392a5eae6^ yields a broken vendoring. Damn. OK, so e27a700f3e140 *is* defnitely correct, while both 05392a5eae6^ and 05392a5eae6 *are* definitely bad, and there was no rust version bump in-between. So something else causes the bad vendoring. Let's start a full git bisect on the whole tree, not limited to jsut rust version bumps: $ export BR2_DL_DIR=$(pwd)/trash-dl $ git bisect 05392a5eae6 e27a700f3e140 $ rm -rf "${BR2_DL_DIR}"; make clean; make ripgrep-source Rnce and repeat, and after quite a few more tests compared to the previos bisect, we eventually find the first bad commit. Sorry, that's all my fault: 768f9f80f62c1da6e298c680f0f4bfa887f38c78 is the first bad commit commit 768f9f80f62c1da6e298c680f0f4bfa887f38c78 Author: Yann E. MORIN <yann.morin.1998@free.fr> Date: Wed Sep 13 00:15:49 2023 +0200 support/download: generate even more reproducible tarballs When we generate the taballs off a local working copy of a VCS tree, the umask is the one that we enforce in out top-level Makefile. However, it is possible that a user manually tinkers in said working copy (e.g. to check an upstream bug fix, or regression). If the user umask is different from the one Buildroot enfirces, such tinkering can impact the mode bits of the files, even if their content is not modified. When we eventually need to create a tarball from said working copy, the VCS (e.g. git) will only be interested in checking whether the content of the files have changed before chcking them out, and will not look at, and restore/fix the mode bits. As a consequence, we may create non-reproducible archives. We fix that by enforcing the mode bits on the files before we create the tarball: we disable the write and execute bits, and only set the execute bit if the user execute bit is set. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Vincent Fazio <vfazio@xes-inc.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> support/download/helpers | 3 +++ 1 file changed, 3 insertions(+) So, I am not 100% sure how to fix that... For master, it's relatively trivial: we can bump the version and compute a new hash, and be done with that. But for the 2023.11 maintenance branch, which contains the commit above, we do not want to bump the versions. For ripgrep, we have a way out: we can chop one digit off the end of the commit hash, and recompute the new hash, and that's going to be OK. For sentry-cli, since we use a version string, not a hash, we don't have much choice but to switch over to using a commit hash from github... And more generally, we do not have a way to express the fact that our download infra changes. For git and svn, we do have a per-backend version, but not for the generic infra, nor for the vendoring post-processs... I'll think a bit more on that, and send patches as soon as I can... Regards, Yann E. MORIN.
Antoine, All, On 2023-12-28 16:26 +0100, Antoine Coutant spake thusly: > ripgrep previous version hash is no longer valid. > The tarball is modified by rust vendoring so the hash > may change with rust versions. This was very concerning, and if that had been true, could not have been solved just by bumping the version. Indeed, it is not always possible to bump the version, e.g. when the package is already using the latest version. Furthermore, it was a bit surprising that only ripgrep was impacted, not all the other cargo-vendored packages. And it turned out that indeed, another package was impacted, sentry-cli (but we only have the host variant of it). So, that really needed more investigations, to provide a more solid explanation why the hash was wrong, and if possible identify the point in the cargo history where the change happened, to ask upstream if the vendoring scheme was stable or not (in that latter case, we'd have had to introduce the versioning of the vendored archives). However, as you can see in the rest of this thread, the issue has nothing to do with cargo vendoring, in fact, and is caused by an unrelated change in the download infra (my fault!). So, the ripgrep version bump is OK, but not for the correct reasons. ;-) Regards, Yann E. MORIN. > The patch has been rebased to ripgrep 14.0.3. > > Changelog: > https://github.com/BurntSushi/ripgrep/blob/master/CHANGELOG.md > > Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> > --- > > Tested using qemu_aarch64_virt_defconfig and Arm AArch64 13.2.rel1 > toolchain. > > Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> > --- > ...llocator-behind-a-cargo-feature-flag.patch | 52 ++++++++++--------- > package/ripgrep/ripgrep.hash | 2 +- > package/ripgrep/ripgrep.mk | 6 +-- > 3 files changed, 29 insertions(+), 31 deletions(-) > > diff --git a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch > index e2ba68f389..aa073c6e7f 100644 > --- a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch > +++ b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch > @@ -1,4 +1,4 @@ > -From 68c2a4d7a5d9b46f65121958fdb12d5270bfd1b6 Mon Sep 17 00:00:00 2001 > +From e4df6678e3e2d018acccafd47d1e484887d23323 Mon Sep 17 00:00:00 2001 > From: Jonathan Stites <mail@jonstites.com> > Date: Wed, 6 May 2020 12:55:35 +0000 > Subject: [PATCH] puts jemalloc allocator behind a cargo feature flag > @@ -9,6 +9,8 @@ Moves jemalloc behind a feature for musl builds, where it is not > supported by the upstream project, so ripgrep will fail to build. > > Signed-off-by: Sam Voss <sam.voss@gmail.com> > +[Antoine: update for 14.0.3] > +Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> > --- > .github/workflows/ci.yml | 6 ++++++ > .github/workflows/release.yml | 8 +++++++- > @@ -18,10 +20,10 @@ Signed-off-by: Sam Voss <sam.voss@gmail.com> > 5 files changed, 35 insertions(+), 4 deletions(-) > > diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml > -index ab154ec..aa567d9 100644 > +index b37753e..a2cdeee 100644 > --- a/.github/workflows/ci.yml > +++ b/.github/workflows/ci.yml > -@@ -149,6 +149,12 @@ jobs: > +@@ -160,6 +160,12 @@ jobs: > if: matrix.target != '' > run: ${{ env.CARGO }} test --verbose --workspace ${{ env.TARGET_FLAGS }} > > @@ -31,14 +33,14 @@ index ab154ec..aa567d9 100644 > + if: matrix.os == 'nightly-musl' > + run: ${{ env.CARGO }} test --verbose --all --features jemalloc ${{ env.TARGET_FLAGS }} > + > - - name: Test for existence of build artifacts (Windows) > - if: matrix.os == 'windows-2019' > - shell: bash > + - name: Test zsh shell completions (Unix, sans cross) > + # We could test this when using Cross, but we'd have to execute the > + # 'rg' binary (done in test-complete) with qemu, which is a pain and > diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml > -index 7cfb6a4..ad6b82d 100644 > +index b10c076..58a7a12 100644 > --- a/.github/workflows/release.yml > +++ b/.github/workflows/release.yml > -@@ -133,7 +133,13 @@ jobs: > +@@ -153,7 +153,13 @@ jobs: > echo "target flag is: ${{ env.TARGET_FLAGS }}" > echo "target dir is: ${{ env.TARGET_DIR }}" > > @@ -50,25 +52,25 @@ index 7cfb6a4..ad6b82d 100644 > + > + - name: Build release binary (non-linux) > + if: matrix.build != 'linux' > - run: ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} > - > - - name: Strip release binary (linux and macos) > + shell: bash > + run: | > + ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} > diff --git a/Cargo.toml b/Cargo.toml > -index fb78fcb..0d34b1e 100644 > +index f30cc0b..6fe4c79 100644 > --- a/Cargo.toml > +++ b/Cargo.toml > -@@ -56,8 +56,9 @@ version = "2.33.0" > - default-features = false > - features = ["suggestions"] > +@@ -59,8 +59,9 @@ serde_json = "1.0.23" > + termcolor = "1.1.0" > + textwrap = { version = "0.16.0", default-features = false } > > -[target.'cfg(all(target_env = "musl", target_pointer_width = "64"))'.dependencies.jemallocator] > +[dependencies.jemallocator] > - version = "0.3.0" > + version = "0.5.0" > +optional = true > > - [build-dependencies] > - lazy_static = "1.1.0" > -@@ -75,6 +76,11 @@ walkdir = "2" > + [dev-dependencies] > + serde = "1.0.77" > +@@ -70,6 +71,11 @@ walkdir = "2" > [features] > simd-accel = ["grep/simd-accel"] > pcre2 = ["grep/pcre2"] > @@ -81,10 +83,10 @@ index fb78fcb..0d34b1e 100644 > [profile.release] > debug = 1 > diff --git a/README.md b/README.md > -index 46938bc..9917b29 100644 > +index 63c0725..3d35819 100644 > --- a/README.md > +++ b/README.md > -@@ -406,6 +406,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have > +@@ -442,6 +442,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have > `musl-gcc` installed, which might be in a separate package from the actual > MUSL library, depending on your Linux distribution. > > @@ -101,10 +103,10 @@ index 46938bc..9917b29 100644 > ### Running tests > > diff --git a/crates/core/main.rs b/crates/core/main.rs > -index 47385de..c9dae5a 100644 > +index 64f35ce..9aa6663 100644 > --- a/crates/core/main.rs > +++ b/crates/core/main.rs > -@@ -31,7 +31,7 @@ mod subject; > +@@ -27,7 +27,7 @@ mod search; > // have the fastest version of everything. Its goal is to be small and amenable > // to static compilation.) Even though ripgrep isn't particularly allocation > // heavy, musl's allocator appears to slow down ripgrep quite a bit. Therefore, > @@ -113,7 +115,7 @@ index 47385de..c9dae5a 100644 > // > // We don't unconditionally use jemalloc because it can be nice to use the > // system's default allocator by default. Moreover, jemalloc seems to increase > -@@ -39,7 +39,11 @@ mod subject; > +@@ -35,7 +35,11 @@ mod search; > // > // Moreover, we only do this on 64-bit systems since jemalloc doesn't support > // i686. > @@ -127,5 +129,5 @@ index 47385de..c9dae5a 100644 > static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc; > > -- > -2.32.0 > +2.25.1 > > diff --git a/package/ripgrep/ripgrep.hash b/package/ripgrep/ripgrep.hash > index 71e74e1bcf..ff86c12ad5 100644 > --- a/package/ripgrep/ripgrep.hash > +++ b/package/ripgrep/ripgrep.hash > @@ -1,3 +1,3 @@ > # Locally calculated > -sha256 6f1d4a8b653ce48d59ad777288b1257cbda607db29db19d031b7e622c60526f8 ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5.tar.gz > +sha256 2f022889c999ffe00955e586fe24b334d1c79060978fc41b95b52a30946e65d0 ripgrep-14.0.3.tar.gz > sha256 0f96a83840e146e43c0ec96a22ec1f392e0680e6c1226e6f3ba87e0740af850f LICENSE-MIT > diff --git a/package/ripgrep/ripgrep.mk b/package/ripgrep/ripgrep.mk > index d587441cfa..44662749bb 100644 > --- a/package/ripgrep/ripgrep.mk > +++ b/package/ripgrep/ripgrep.mk > @@ -4,11 +4,7 @@ > # > ################################################################################ > > -# Same as 13.0.0, we use a Git commit hash because the hash of this > -# tarball changed when moving to the cargo-package infrastructure, and > -# we can't change the hash of existing tarball. Please switch back to > -# a Git tag at the next version bump. > -RIPGREP_VERSION = af6b6c543b224d348a8876f0c06245d9ea7929c5 > +RIPGREP_VERSION = 14.0.3 > RIPGREP_SITE = $(call github,burntsushi,ripgrep,$(RIPGREP_VERSION)) > RIPGREP_LICENSE = MIT > RIPGREP_LICENSE_FILES = LICENSE-MIT > -- > 2.25.1 > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
Hello Yann, Le 31/12/2023 à 15:36, Yann E. MORIN a écrit : > Antoine, All, > > On 2023-12-28 16:26 +0100, Antoine Coutant spake thusly: >> ripgrep previous version hash is no longer valid. >> The tarball is modified by rust vendoring so the hash >> may change with rust versions. > > This was very concerning, and if that had been true, could not have > been solved just by bumping the version. Indeed, it is not always > possible to bump the version, e.g. when the package is already using > the latest version. > > Furthermore, it was a bit surprising that only ripgrep was impacted, not > all the other cargo-vendored packages. And it turned out that indeed, > another package was impacted, sentry-cli (but we only have the host > variant of it). > > So, that really needed more investigations, to provide a more solid > explanation why the hash was wrong, and if possible identify the point > in the cargo history where the change happened, to ask upstream if the > vendoring scheme was stable or not (in that latter case, we'd have had > to introduce the versioning of the vendored archives). > > However, as you can see in the rest of this thread, the issue has > nothing to do with cargo vendoring, in fact, and is caused by an > unrelated change in the download infra (my fault!). > > So, the ripgrep version bump is OK, but not for the correct reasons. ;-) Thanks for your time spent to look at this issue. Maybe we should consider merging the patch 3/3 that add a new runtime test "TestRustVendoring". Best regards, Romain > > Regards, > Yann E. MORIN. > >> The patch has been rebased to ripgrep 14.0.3. >> >> Changelog: >> https://github.com/BurntSushi/ripgrep/blob/master/CHANGELOG.md >> >> Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> >> --- >> >> Tested using qemu_aarch64_virt_defconfig and Arm AArch64 13.2.rel1 >> toolchain. >> >> Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> >> --- >> ...llocator-behind-a-cargo-feature-flag.patch | 52 ++++++++++--------- >> package/ripgrep/ripgrep.hash | 2 +- >> package/ripgrep/ripgrep.mk | 6 +-- >> 3 files changed, 29 insertions(+), 31 deletions(-) >> >> diff --git a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch >> index e2ba68f389..aa073c6e7f 100644 >> --- a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch >> +++ b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch >> @@ -1,4 +1,4 @@ >> -From 68c2a4d7a5d9b46f65121958fdb12d5270bfd1b6 Mon Sep 17 00:00:00 2001 >> +From e4df6678e3e2d018acccafd47d1e484887d23323 Mon Sep 17 00:00:00 2001 >> From: Jonathan Stites <mail@jonstites.com> >> Date: Wed, 6 May 2020 12:55:35 +0000 >> Subject: [PATCH] puts jemalloc allocator behind a cargo feature flag >> @@ -9,6 +9,8 @@ Moves jemalloc behind a feature for musl builds, where it is not >> supported by the upstream project, so ripgrep will fail to build. >> >> Signed-off-by: Sam Voss <sam.voss@gmail.com> >> +[Antoine: update for 14.0.3] >> +Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> >> --- >> .github/workflows/ci.yml | 6 ++++++ >> .github/workflows/release.yml | 8 +++++++- >> @@ -18,10 +20,10 @@ Signed-off-by: Sam Voss <sam.voss@gmail.com> >> 5 files changed, 35 insertions(+), 4 deletions(-) >> >> diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml >> -index ab154ec..aa567d9 100644 >> +index b37753e..a2cdeee 100644 >> --- a/.github/workflows/ci.yml >> +++ b/.github/workflows/ci.yml >> -@@ -149,6 +149,12 @@ jobs: >> +@@ -160,6 +160,12 @@ jobs: >> if: matrix.target != '' >> run: ${{ env.CARGO }} test --verbose --workspace ${{ env.TARGET_FLAGS }} >> >> @@ -31,14 +33,14 @@ index ab154ec..aa567d9 100644 >> + if: matrix.os == 'nightly-musl' >> + run: ${{ env.CARGO }} test --verbose --all --features jemalloc ${{ env.TARGET_FLAGS }} >> + >> - - name: Test for existence of build artifacts (Windows) >> - if: matrix.os == 'windows-2019' >> - shell: bash >> + - name: Test zsh shell completions (Unix, sans cross) >> + # We could test this when using Cross, but we'd have to execute the >> + # 'rg' binary (done in test-complete) with qemu, which is a pain and >> diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml >> -index 7cfb6a4..ad6b82d 100644 >> +index b10c076..58a7a12 100644 >> --- a/.github/workflows/release.yml >> +++ b/.github/workflows/release.yml >> -@@ -133,7 +133,13 @@ jobs: >> +@@ -153,7 +153,13 @@ jobs: >> echo "target flag is: ${{ env.TARGET_FLAGS }}" >> echo "target dir is: ${{ env.TARGET_DIR }}" >> >> @@ -50,25 +52,25 @@ index 7cfb6a4..ad6b82d 100644 >> + >> + - name: Build release binary (non-linux) >> + if: matrix.build != 'linux' >> - run: ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} >> - >> - - name: Strip release binary (linux and macos) >> + shell: bash >> + run: | >> + ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} >> diff --git a/Cargo.toml b/Cargo.toml >> -index fb78fcb..0d34b1e 100644 >> +index f30cc0b..6fe4c79 100644 >> --- a/Cargo.toml >> +++ b/Cargo.toml >> -@@ -56,8 +56,9 @@ version = "2.33.0" >> - default-features = false >> - features = ["suggestions"] >> +@@ -59,8 +59,9 @@ serde_json = "1.0.23" >> + termcolor = "1.1.0" >> + textwrap = { version = "0.16.0", default-features = false } >> >> -[target.'cfg(all(target_env = "musl", target_pointer_width = "64"))'.dependencies.jemallocator] >> +[dependencies.jemallocator] >> - version = "0.3.0" >> + version = "0.5.0" >> +optional = true >> >> - [build-dependencies] >> - lazy_static = "1.1.0" >> -@@ -75,6 +76,11 @@ walkdir = "2" >> + [dev-dependencies] >> + serde = "1.0.77" >> +@@ -70,6 +71,11 @@ walkdir = "2" >> [features] >> simd-accel = ["grep/simd-accel"] >> pcre2 = ["grep/pcre2"] >> @@ -81,10 +83,10 @@ index fb78fcb..0d34b1e 100644 >> [profile.release] >> debug = 1 >> diff --git a/README.md b/README.md >> -index 46938bc..9917b29 100644 >> +index 63c0725..3d35819 100644 >> --- a/README.md >> +++ b/README.md >> -@@ -406,6 +406,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have >> +@@ -442,6 +442,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have >> `musl-gcc` installed, which might be in a separate package from the actual >> MUSL library, depending on your Linux distribution. >> >> @@ -101,10 +103,10 @@ index 46938bc..9917b29 100644 >> ### Running tests >> >> diff --git a/crates/core/main.rs b/crates/core/main.rs >> -index 47385de..c9dae5a 100644 >> +index 64f35ce..9aa6663 100644 >> --- a/crates/core/main.rs >> +++ b/crates/core/main.rs >> -@@ -31,7 +31,7 @@ mod subject; >> +@@ -27,7 +27,7 @@ mod search; >> // have the fastest version of everything. Its goal is to be small and amenable >> // to static compilation.) Even though ripgrep isn't particularly allocation >> // heavy, musl's allocator appears to slow down ripgrep quite a bit. Therefore, >> @@ -113,7 +115,7 @@ index 47385de..c9dae5a 100644 >> // >> // We don't unconditionally use jemalloc because it can be nice to use the >> // system's default allocator by default. Moreover, jemalloc seems to increase >> -@@ -39,7 +39,11 @@ mod subject; >> +@@ -35,7 +35,11 @@ mod search; >> // >> // Moreover, we only do this on 64-bit systems since jemalloc doesn't support >> // i686. >> @@ -127,5 +129,5 @@ index 47385de..c9dae5a 100644 >> static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc; >> >> -- >> -2.32.0 >> +2.25.1 >> >> diff --git a/package/ripgrep/ripgrep.hash b/package/ripgrep/ripgrep.hash >> index 71e74e1bcf..ff86c12ad5 100644 >> --- a/package/ripgrep/ripgrep.hash >> +++ b/package/ripgrep/ripgrep.hash >> @@ -1,3 +1,3 @@ >> # Locally calculated >> -sha256 6f1d4a8b653ce48d59ad777288b1257cbda607db29db19d031b7e622c60526f8 ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5.tar.gz >> +sha256 2f022889c999ffe00955e586fe24b334d1c79060978fc41b95b52a30946e65d0 ripgrep-14.0.3.tar.gz >> sha256 0f96a83840e146e43c0ec96a22ec1f392e0680e6c1226e6f3ba87e0740af850f LICENSE-MIT >> diff --git a/package/ripgrep/ripgrep.mk b/package/ripgrep/ripgrep.mk >> index d587441cfa..44662749bb 100644 >> --- a/package/ripgrep/ripgrep.mk >> +++ b/package/ripgrep/ripgrep.mk >> @@ -4,11 +4,7 @@ >> # >> ################################################################################ >> >> -# Same as 13.0.0, we use a Git commit hash because the hash of this >> -# tarball changed when moving to the cargo-package infrastructure, and >> -# we can't change the hash of existing tarball. Please switch back to >> -# a Git tag at the next version bump. >> -RIPGREP_VERSION = af6b6c543b224d348a8876f0c06245d9ea7929c5 >> +RIPGREP_VERSION = 14.0.3 >> RIPGREP_SITE = $(call github,burntsushi,ripgrep,$(RIPGREP_VERSION)) >> RIPGREP_LICENSE = MIT >> RIPGREP_LICENSE_FILES = LICENSE-MIT >> -- >> 2.25.1 >> >> _______________________________________________ >> buildroot mailing list >> buildroot@buildroot.org >> https://lists.buildroot.org/mailman/listinfo/buildroot >
Yann, All, On 31/12/2023 15:36, Yann E. MORIN wrote: > Antoine, All, > > On 2023-12-28 16:26 +0100, Antoine Coutant spake thusly: >> ripgrep previous version hash is no longer valid. >> The tarball is modified by rust vendoring so the hash >> may change with rust versions. > This was very concerning, and if that had been true, could not have > been solved just by bumping the version. Indeed, it is not always > possible to bump the version, e.g. when the package is already using > the latest version. > > Furthermore, it was a bit surprising that only ripgrep was impacted, not > all the other cargo-vendored packages. And it turned out that indeed, > another package was impacted, sentry-cli (but we only have the host > variant of it). > > So, that really needed more investigations, to provide a more solid > explanation why the hash was wrong, and if possible identify the point > in the cargo history where the change happened, to ask upstream if the > vendoring scheme was stable or not (in that latter case, we'd have had > to introduce the versioning of the vendored archives). > > However, as you can see in the rest of this thread, the issue has > nothing to do with cargo vendoring, in fact, and is caused by an > unrelated change in the download infra (my fault!). I'm sorry for the confusion I caused by my misunderstanding. Thanks for all your research! Regards, Antoine Coutant > > So, the ripgrep version bump is OK, but not for the correct reasons. ;-) > > Regards, > Yann E. MORIN. > >> The patch has been rebased to ripgrep 14.0.3. >> >> Changelog: >> https://github.com/BurntSushi/ripgrep/blob/master/CHANGELOG.md >> >> Signed-off-by: Antoine Coutant<antoine.coutant@smile.fr> >> --- >> >> Tested using qemu_aarch64_virt_defconfig and Arm AArch64 13.2.rel1 >> toolchain. >> >> Signed-off-by: Antoine Coutant<antoine.coutant@smile.fr> >> --- >> ...llocator-behind-a-cargo-feature-flag.patch | 52 ++++++++++--------- >> package/ripgrep/ripgrep.hash | 2 +- >> package/ripgrep/ripgrep.mk | 6 +-- >> 3 files changed, 29 insertions(+), 31 deletions(-) >> >> diff --git a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch >> index e2ba68f389..aa073c6e7f 100644 >> --- a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch >> +++ b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch >> @@ -1,4 +1,4 @@ >> -From 68c2a4d7a5d9b46f65121958fdb12d5270bfd1b6 Mon Sep 17 00:00:00 2001 >> +From e4df6678e3e2d018acccafd47d1e484887d23323 Mon Sep 17 00:00:00 2001 >> From: Jonathan Stites<mail@jonstites.com> >> Date: Wed, 6 May 2020 12:55:35 +0000 >> Subject: [PATCH] puts jemalloc allocator behind a cargo feature flag >> @@ -9,6 +9,8 @@ Moves jemalloc behind a feature for musl builds, where it is not >> supported by the upstream project, so ripgrep will fail to build. >> >> Signed-off-by: Sam Voss<sam.voss@gmail.com> >> +[Antoine: update for 14.0.3] >> +Signed-off-by: Antoine Coutant<antoine.coutant@smile.fr> >> --- >> .github/workflows/ci.yml | 6 ++++++ >> .github/workflows/release.yml | 8 +++++++- >> @@ -18,10 +20,10 @@ Signed-off-by: Sam Voss<sam.voss@gmail.com> >> 5 files changed, 35 insertions(+), 4 deletions(-) >> >> diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml >> -index ab154ec..aa567d9 100644 >> +index b37753e..a2cdeee 100644 >> --- a/.github/workflows/ci.yml >> +++ b/.github/workflows/ci.yml >> -@@ -149,6 +149,12 @@ jobs: >> +@@ -160,6 +160,12 @@ jobs: >> if: matrix.target != '' >> run: ${{ env.CARGO }} test --verbose --workspace ${{ env.TARGET_FLAGS }} >> >> @@ -31,14 +33,14 @@ index ab154ec..aa567d9 100644 >> + if: matrix.os == 'nightly-musl' >> + run: ${{ env.CARGO }} test --verbose --all --features jemalloc ${{ env.TARGET_FLAGS }} >> + >> - - name: Test for existence of build artifacts (Windows) >> - if: matrix.os == 'windows-2019' >> - shell: bash >> + - name: Test zsh shell completions (Unix, sans cross) >> + # We could test this when using Cross, but we'd have to execute the >> + # 'rg' binary (done in test-complete) with qemu, which is a pain and >> diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml >> -index 7cfb6a4..ad6b82d 100644 >> +index b10c076..58a7a12 100644 >> --- a/.github/workflows/release.yml >> +++ b/.github/workflows/release.yml >> -@@ -133,7 +133,13 @@ jobs: >> +@@ -153,7 +153,13 @@ jobs: >> echo "target flag is: ${{ env.TARGET_FLAGS }}" >> echo "target dir is: ${{ env.TARGET_DIR }}" >> >> @@ -50,25 +52,25 @@ index 7cfb6a4..ad6b82d 100644 >> + >> + - name: Build release binary (non-linux) >> + if: matrix.build != 'linux' >> - run: ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} >> - >> - - name: Strip release binary (linux and macos) >> + shell: bash >> + run: | >> + ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} >> diff --git a/Cargo.toml b/Cargo.toml >> -index fb78fcb..0d34b1e 100644 >> +index f30cc0b..6fe4c79 100644 >> --- a/Cargo.toml >> +++ b/Cargo.toml >> -@@ -56,8 +56,9 @@ version = "2.33.0" >> - default-features = false >> - features = ["suggestions"] >> +@@ -59,8 +59,9 @@ serde_json = "1.0.23" >> + termcolor = "1.1.0" >> + textwrap = { version = "0.16.0", default-features = false } >> >> -[target.'cfg(all(target_env = "musl", target_pointer_width = "64"))'.dependencies.jemallocator] >> +[dependencies.jemallocator] >> - version = "0.3.0" >> + version = "0.5.0" >> +optional = true >> >> - [build-dependencies] >> - lazy_static = "1.1.0" >> -@@ -75,6 +76,11 @@ walkdir = "2" >> + [dev-dependencies] >> + serde = "1.0.77" >> +@@ -70,6 +71,11 @@ walkdir = "2" >> [features] >> simd-accel = ["grep/simd-accel"] >> pcre2 = ["grep/pcre2"] >> @@ -81,10 +83,10 @@ index fb78fcb..0d34b1e 100644 >> [profile.release] >> debug = 1 >> diff --git a/README.md b/README.md >> -index 46938bc..9917b29 100644 >> +index 63c0725..3d35819 100644 >> --- a/README.md >> +++ b/README.md >> -@@ -406,6 +406,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have >> +@@ -442,6 +442,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have >> `musl-gcc` installed, which might be in a separate package from the actual >> MUSL library, depending on your Linux distribution. >> >> @@ -101,10 +103,10 @@ index 46938bc..9917b29 100644 >> ### Running tests >> >> diff --git a/crates/core/main.rs b/crates/core/main.rs >> -index 47385de..c9dae5a 100644 >> +index 64f35ce..9aa6663 100644 >> --- a/crates/core/main.rs >> +++ b/crates/core/main.rs >> -@@ -31,7 +31,7 @@ mod subject; >> +@@ -27,7 +27,7 @@ mod search; >> // have the fastest version of everything. Its goal is to be small and amenable >> // to static compilation.) Even though ripgrep isn't particularly allocation >> // heavy, musl's allocator appears to slow down ripgrep quite a bit. Therefore, >> @@ -113,7 +115,7 @@ index 47385de..c9dae5a 100644 >> // >> // We don't unconditionally use jemalloc because it can be nice to use the >> // system's default allocator by default. Moreover, jemalloc seems to increase >> -@@ -39,7 +39,11 @@ mod subject; >> +@@ -35,7 +35,11 @@ mod search; >> // >> // Moreover, we only do this on 64-bit systems since jemalloc doesn't support >> // i686. >> @@ -127,5 +129,5 @@ index 47385de..c9dae5a 100644 >> static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc; >> >> -- >> -2.32.0 >> +2.25.1 >> >> diff --git a/package/ripgrep/ripgrep.hash b/package/ripgrep/ripgrep.hash >> index 71e74e1bcf..ff86c12ad5 100644 >> --- a/package/ripgrep/ripgrep.hash >> +++ b/package/ripgrep/ripgrep.hash >> @@ -1,3 +1,3 @@ >> # Locally calculated >> -sha256 6f1d4a8b653ce48d59ad777288b1257cbda607db29db19d031b7e622c60526f8 ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5.tar.gz >> +sha256 2f022889c999ffe00955e586fe24b334d1c79060978fc41b95b52a30946e65d0 ripgrep-14.0.3.tar.gz >> sha256 0f96a83840e146e43c0ec96a22ec1f392e0680e6c1226e6f3ba87e0740af850f LICENSE-MIT >> diff --git a/package/ripgrep/ripgrep.mk b/package/ripgrep/ripgrep.mk >> index d587441cfa..44662749bb 100644 >> --- a/package/ripgrep/ripgrep.mk >> +++ b/package/ripgrep/ripgrep.mk >> @@ -4,11 +4,7 @@ >> # >> ################################################################################ >> >> -# Same as 13.0.0, we use a Git commit hash because the hash of this >> -# tarball changed when moving to the cargo-package infrastructure, and >> -# we can't change the hash of existing tarball. Please switch back to >> -# a Git tag at the next version bump. >> -RIPGREP_VERSION = af6b6c543b224d348a8876f0c06245d9ea7929c5 >> +RIPGREP_VERSION = 14.0.3 >> RIPGREP_SITE = $(call github,burntsushi,ripgrep,$(RIPGREP_VERSION)) >> RIPGREP_LICENSE = MIT >> RIPGREP_LICENSE_FILES = LICENSE-MIT >> -- >> 2.25.1 >> >> _______________________________________________ >> buildroot mailing list >> buildroot@buildroot.org >> https://lists.buildroot.org/mailman/listinfo/buildroot
Antoine, All, On 2024-01-10 15:29 +0100, Antoine Coutant spake thusly: > On 31/12/2023 15:36, Yann E. MORIN wrote: > > On 2023-12-28 16:26 +0100, Antoine Coutant spake thusly: > > > ripgrep previous version hash is no longer valid. > > > The tarball is modified by rust vendoring so the hash > > > may change with rust versions. [--SNIP--] > > However, as you can see in the rest of this thread, the issue has > > nothing to do with cargo vendoring, in fact, and is caused by an > > unrelated change in the download infra (my fault!). > I'm sorry for the confusion I caused by my misunderstanding. > Thanks for all your research! Don't worry about it. I got to identify one of my screw-ups, so that's fine! Regards, Yann E. MORIN.
diff --git a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch index e2ba68f389..aa073c6e7f 100644 --- a/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch +++ b/package/ripgrep/0001-puts-jemalloc-allocator-behind-a-cargo-feature-flag.patch @@ -1,4 +1,4 @@ -From 68c2a4d7a5d9b46f65121958fdb12d5270bfd1b6 Mon Sep 17 00:00:00 2001 +From e4df6678e3e2d018acccafd47d1e484887d23323 Mon Sep 17 00:00:00 2001 From: Jonathan Stites <mail@jonstites.com> Date: Wed, 6 May 2020 12:55:35 +0000 Subject: [PATCH] puts jemalloc allocator behind a cargo feature flag @@ -9,6 +9,8 @@ Moves jemalloc behind a feature for musl builds, where it is not supported by the upstream project, so ripgrep will fail to build. Signed-off-by: Sam Voss <sam.voss@gmail.com> +[Antoine: update for 14.0.3] +Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr> --- .github/workflows/ci.yml | 6 ++++++ .github/workflows/release.yml | 8 +++++++- @@ -18,10 +20,10 @@ Signed-off-by: Sam Voss <sam.voss@gmail.com> 5 files changed, 35 insertions(+), 4 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml -index ab154ec..aa567d9 100644 +index b37753e..a2cdeee 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml -@@ -149,6 +149,12 @@ jobs: +@@ -160,6 +160,12 @@ jobs: if: matrix.target != '' run: ${{ env.CARGO }} test --verbose --workspace ${{ env.TARGET_FLAGS }} @@ -31,14 +33,14 @@ index ab154ec..aa567d9 100644 + if: matrix.os == 'nightly-musl' + run: ${{ env.CARGO }} test --verbose --all --features jemalloc ${{ env.TARGET_FLAGS }} + - - name: Test for existence of build artifacts (Windows) - if: matrix.os == 'windows-2019' - shell: bash + - name: Test zsh shell completions (Unix, sans cross) + # We could test this when using Cross, but we'd have to execute the + # 'rg' binary (done in test-complete) with qemu, which is a pain and diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml -index 7cfb6a4..ad6b82d 100644 +index b10c076..58a7a12 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml -@@ -133,7 +133,13 @@ jobs: +@@ -153,7 +153,13 @@ jobs: echo "target flag is: ${{ env.TARGET_FLAGS }}" echo "target dir is: ${{ env.TARGET_DIR }}" @@ -50,25 +52,25 @@ index 7cfb6a4..ad6b82d 100644 + + - name: Build release binary (non-linux) + if: matrix.build != 'linux' - run: ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} - - - name: Strip release binary (linux and macos) + shell: bash + run: | + ${{ env.CARGO }} build --verbose --release --features pcre2 ${{ env.TARGET_FLAGS }} diff --git a/Cargo.toml b/Cargo.toml -index fb78fcb..0d34b1e 100644 +index f30cc0b..6fe4c79 100644 --- a/Cargo.toml +++ b/Cargo.toml -@@ -56,8 +56,9 @@ version = "2.33.0" - default-features = false - features = ["suggestions"] +@@ -59,8 +59,9 @@ serde_json = "1.0.23" + termcolor = "1.1.0" + textwrap = { version = "0.16.0", default-features = false } -[target.'cfg(all(target_env = "musl", target_pointer_width = "64"))'.dependencies.jemallocator] +[dependencies.jemallocator] - version = "0.3.0" + version = "0.5.0" +optional = true - [build-dependencies] - lazy_static = "1.1.0" -@@ -75,6 +76,11 @@ walkdir = "2" + [dev-dependencies] + serde = "1.0.77" +@@ -70,6 +71,11 @@ walkdir = "2" [features] simd-accel = ["grep/simd-accel"] pcre2 = ["grep/pcre2"] @@ -81,10 +83,10 @@ index fb78fcb..0d34b1e 100644 [profile.release] debug = 1 diff --git a/README.md b/README.md -index 46938bc..9917b29 100644 +index 63c0725..3d35819 100644 --- a/README.md +++ b/README.md -@@ -406,6 +406,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have +@@ -442,6 +442,15 @@ build a static executable with MUSL and with PCRE2, then you will need to have `musl-gcc` installed, which might be in a separate package from the actual MUSL library, depending on your Linux distribution. @@ -101,10 +103,10 @@ index 46938bc..9917b29 100644 ### Running tests diff --git a/crates/core/main.rs b/crates/core/main.rs -index 47385de..c9dae5a 100644 +index 64f35ce..9aa6663 100644 --- a/crates/core/main.rs +++ b/crates/core/main.rs -@@ -31,7 +31,7 @@ mod subject; +@@ -27,7 +27,7 @@ mod search; // have the fastest version of everything. Its goal is to be small and amenable // to static compilation.) Even though ripgrep isn't particularly allocation // heavy, musl's allocator appears to slow down ripgrep quite a bit. Therefore, @@ -113,7 +115,7 @@ index 47385de..c9dae5a 100644 // // We don't unconditionally use jemalloc because it can be nice to use the // system's default allocator by default. Moreover, jemalloc seems to increase -@@ -39,7 +39,11 @@ mod subject; +@@ -35,7 +35,11 @@ mod search; // // Moreover, we only do this on 64-bit systems since jemalloc doesn't support // i686. @@ -127,5 +129,5 @@ index 47385de..c9dae5a 100644 static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc; -- -2.32.0 +2.25.1 diff --git a/package/ripgrep/ripgrep.hash b/package/ripgrep/ripgrep.hash index 71e74e1bcf..ff86c12ad5 100644 --- a/package/ripgrep/ripgrep.hash +++ b/package/ripgrep/ripgrep.hash @@ -1,3 +1,3 @@ # Locally calculated -sha256 6f1d4a8b653ce48d59ad777288b1257cbda607db29db19d031b7e622c60526f8 ripgrep-af6b6c543b224d348a8876f0c06245d9ea7929c5.tar.gz +sha256 2f022889c999ffe00955e586fe24b334d1c79060978fc41b95b52a30946e65d0 ripgrep-14.0.3.tar.gz sha256 0f96a83840e146e43c0ec96a22ec1f392e0680e6c1226e6f3ba87e0740af850f LICENSE-MIT diff --git a/package/ripgrep/ripgrep.mk b/package/ripgrep/ripgrep.mk index d587441cfa..44662749bb 100644 --- a/package/ripgrep/ripgrep.mk +++ b/package/ripgrep/ripgrep.mk @@ -4,11 +4,7 @@ # ################################################################################ -# Same as 13.0.0, we use a Git commit hash because the hash of this -# tarball changed when moving to the cargo-package infrastructure, and -# we can't change the hash of existing tarball. Please switch back to -# a Git tag at the next version bump. -RIPGREP_VERSION = af6b6c543b224d348a8876f0c06245d9ea7929c5 +RIPGREP_VERSION = 14.0.3 RIPGREP_SITE = $(call github,burntsushi,ripgrep,$(RIPGREP_VERSION)) RIPGREP_LICENSE = MIT RIPGREP_LICENSE_FILES = LICENSE-MIT