From: Kaelyn <kaelyn.alexi@protonmail.com>
To: John Kehayias <john.kehayias@protonmail.com>
Cc: guix-devel <guix-devel@gnu.org>, Efraim Flashner <efraim@flashner.co.il>
Subject: Re: Update to source-highlight seems to have broken rust
Date: Mon, 29 Jan 2024 23:39:01 +0000 [thread overview]
Message-ID: <GYaltxtPAvB8yJhDMPE7J_T5JFgjrhmgopJcb5O7M351LKcz-uXNFFBaYSVceshsxPz-raUvhiq4BQHo3KVoYT2UpF3h1X-AhFW4dWoVkVw=@protonmail.com> (raw)
In-Reply-To: <Fzq4nNmDb_ZsT0gNzRFzKPrysRFWnSqDyvTHIIDLE6bCR_-cUpnp583gUsuaa99oDSke_9IWn9Oaq56wAr-picUh5Pl3nxqyaeR90ES55vI=@protonmail.com>
On Monday, January 29th, 2024 at 9:49 AM, John Kehayias <john.kehayias@protonmail.com> wrote:
>
>
> Hi Kaeylyn,
>
>
> On Monday, January 29th, 2024 at 12:26 PM, Kaelyn kaelyn.alexi@protonmail.com wrote:
>
> > Hi Efraim and guix-devel,
> >
> > Based on my local cuirass instance and some spot testing this morning, it appears the change to source-highlight in commit 367bc2d198 has broken the build of rust 1.73.
> > * `guix refresh -l source-highlight` reports modifying the package would require a large number of rebuilds ("Building the following 6129 packages would ensure 9069 dependent packages are rebuilt").
> > * I am seeing a consistent test failure for rust starting with that commit.
> > * `guix weather rust@1.73` reports 100% availability for both ci.guix.gnu.org and bordeaux.guix.gnu.org at commit fbeae77ae6 but 0% availability at commit 367bc2d198.
>
>
> This was reverted in 0fb160a5e8b0b800426489c0a2ad387c6934fba so maybe you were just unlucky in what commit you were at?
>
> I can't comment on the details of the change or rust, but hopefully just pulling to a newer commit will go back to good coverage for you as well.
>
> Hope that helps!
That does help, thank you! I think I missed the revert because of a minor misbehavior? of cuirass (so me getting unlucky about the commit in a different way!).
I have a local cuirass server set up to build the packages in a local channel, along with a job configured to build the packages in my Guix Home configs (currently using a manually generated manifest file that is checked in as part of the local channel)--but I don't have notifications set up and I only occasionally check on its status. This morning I happened to notice that wine64-staging was reported as having been failing for a while, because of ffmpeg-6.1.1 failing to build due to the rust failure (i.e. cuirass reported ffmpeg as the root failed build, and looking at the error log was what revealed that it was actually rust that failed). I then mistakenly assumed the issue was still present because the list of evaluations and evaluation dashboard reported wine64-staging as still failing up through the evaluation for commit 2c5293a from a few hours prior to my email. I'm guessing the underlying issue for the rebuild not happening for the revert commit is tied to dependency propagation triggering rebuilds (as a likely-related example, I find it odd that while cuirass showed the wine64-staging rebuild failed because its dependency ffmpeg failed to build, but claimed ffmpeg was the failed package when it was a unit test in the rust build that actually failed).
Thank you again, John, for your response about the commit having already been reverted!
Cheers,
Kaelyn
> John
>
> > The consistently-reported failure is:
> >
> > ---- metadata::cargo_metadata_non_utf8 stdout ----
> > thread 'metadata::cargo_metadata_non_utf8' panicked at crates/cargo-test-support/src/paths.rs:155:33:
> > failed to mkdir_p /tmp/guix-build-rust-1.73.0.drv-0/rustc-1.73.0-src/build/x86_64-unknown-linux-gnu/stage1-tools/x86_64-unknown-linux-gnu/tmp/cit/t1684/foo/�/./src: Invalid or incomplete multibyte or wide character (os error 84)
> > note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> >
> > failures:
> > metadata::cargo_metadata_non_utf8
> >
> > test result: FAILED. 2801 passed; 1 failed; 198 ignored; 0 measured; 0 filtered out; finished in 92.81s
> >
> > error: test failed, to rerun pass `--test testsuite`
> >
> > I don't exactly understand how wrapping scripts in source-highlight ended up breaking the above rust test, nor do I use rust, so I wanted to bring it to folks' attention since the failure appears to affect a great many packages (I noticed it in an ffmpeg build failure on my local cuirass instance).
> >
> > Cheers,
> > Kaelyn
prev parent reply other threads:[~2024-01-29 23:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 17:26 Update to source-highlight seems to have broken rust Kaelyn
2024-01-29 17:49 ` John Kehayias
2024-01-29 23:39 ` Kaelyn [this message]
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='GYaltxtPAvB8yJhDMPE7J_T5JFgjrhmgopJcb5O7M351LKcz-uXNFFBaYSVceshsxPz-raUvhiq4BQHo3KVoYT2UpF3h1X-AhFW4dWoVkVw=@protonmail.com' \
--to=kaelyn.alexi@protonmail.com \
--cc=efraim@flashner.co.il \
--cc=guix-devel@gnu.org \
--cc=john.kehayias@protonmail.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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).