From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Antoine Coutant <antoine.coutant@smile.fr>,
romain.naour@smile.fr, sebastian.weyer@smile.fr,
buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v2 2/3] package/ripgrep: bump to version 14.0.3
Date: Sat, 30 Dec 2023 23:08:49 +0100 [thread overview]
Message-ID: <ZZCU8UABqefYpf8n@landeda> (raw)
In-Reply-To: <ZZBzIdHGdJufQNWn@landeda>
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.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2023-12-30 22:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-28 15:26 [Buildroot] [PATCH v2 1/3] package/{rust, rust-bin}: bump to version 1.74.1 Antoine Coutant
2023-12-28 15:26 ` [Buildroot] [PATCH v2 2/3] package/ripgrep: bump to version 14.0.3 Antoine Coutant
2023-12-29 22:13 ` Yann E. MORIN
2023-12-30 18:00 ` Thomas Petazzoni via buildroot
2023-12-30 19:44 ` Yann E. MORIN
2023-12-30 22:08 ` Yann E. MORIN [this message]
2023-12-31 9:25 ` Yann E. MORIN
2023-12-31 11:01 ` Yann E. MORIN
2023-12-31 14:25 ` Yann E. MORIN
2023-12-31 14:36 ` Yann E. MORIN
2024-01-10 14:22 ` Romain Naour
2024-01-10 14:29 ` Antoine Coutant
2024-01-10 20:27 ` Yann E. MORIN
2023-12-28 15:26 ` [Buildroot] [PATCH v2 3/3] support/testing: test_rust.py: Add test to check correct vendoring Antoine Coutant
2023-12-30 18:01 ` [Buildroot] [PATCH v2 1/3] package/{rust, rust-bin}: bump to version 1.74.1 Thomas Petazzoni via buildroot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZZCU8UABqefYpf8n@landeda \
--to=yann.morin.1998@free.fr \
--cc=antoine.coutant@smile.fr \
--cc=buildroot@buildroot.org \
--cc=romain.naour@smile.fr \
--cc=sebastian.weyer@smile.fr \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.