libimobiledevice-drvs: update all with major rebuilds #342961
Draft
+220
−154
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
from
24436d8
to
b285fd2
Compare
|
Let's wait a bit before merging this for things to settle down, since some development has been going on these past days out of nowhere, probably because of the sequoia/ios18 release and we'll want to get the latest commit with these changes, so it works on the newer devices/systems as well. |
clebs
suggested changes
Sep 20, 2024
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
from
b285fd2
to
f77c7d0
Compare
Blocked. Waiting about a week or so before merging in. |
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
from
f77c7d0
to
d677994
Compare
|
EDIT: Also noticing @ofborg is failing to evaluate given this missed the last staging cycle. What's the acceptable fix here? Leaving it as is or performing a rebase? 24.11 will soon be cut for release: #344920 It's imperative this gets through before then to avoid leaving this PR dangling for too long. I will check upstream activity and if it has died down, I'm unblocking this PR and bumping ALL sources to their current latest. |
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
from
d677994
to
742cb20
Compare
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
from
742cb20
to
e04f426
Compare
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
from
e04f426
to
ab5422a
Compare
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
2 times, most recently
from
2ea66a3
to
a3e6a1e
Compare
Rebase
I'll take a look at this soon. |
I'll take a look at this as soon as I can. I've been trying to get to Orlando so I'm kinda stuck on airplanes. I should be able to take a look tomorrow (Saturday). |
No worries, just wanted to keep you in the loop regarding the mass rebuild failures. |
|
upower failed to build for me, one test failed. Will get more info after the current |
|
Result of 54 packages marked as broken and skipped:
760 packages failed to build:
507 packages built:
|
Seems the test daemon failed to restart in |
|
Perhaps a timeout? I cannot recall this exact scenario explicitly but there were a few tests that timed out for me. I ended up re-running the build outside of nixpkgs-review and that usually fixed this up. |
|
Result of 54 packages marked as broken and skipped:
524 packages failed to build:
743 packages built:
|
|
I think at this point with how many rebuilds we've got and how many fail, it might be best to retarget this to staging and throw it into this cycle. |
|
Maybe it'll be better to split this up across multiple PR's, is there any reason why this needs to get in before 24.11? |
Not really tbh. At first I was hoping to squeeze it in before we locked out commits, but given the fact that it's been a real PITA I don't see the point in rushing it. I do agree that throwing it into staging may be a good idea, because it does eventually succeed, just not fast. Perhaps we should disable or bump the timeouts on some of the failing tests? Seems awfully annoying if they're going to continue interrupting the build this way. |
Why? It's 19 commits but it'll be more reliable to test.
I don't think we can bump or disable the timeouts on Ofborg. |
Ah sorry I should clarify, my "Not really tbh" was an answer to "Is it necessary to get in before the cutoff". I am absolutely a-okay with splitting it up, though I will say from my previous rebasing testing, libusbmuxd is the rebase step that caused a ton of rebuilds. It may even be the only one, but I cannot confirm that as I didn't directly test beyond that point. As for the timeouts, I meant directly in the testing code that checkPhase runs. A lot of the timeouts are around 15-30 seconds, I think bumping them to a more comfortable 60s could possibly help with evaluation. Though on the flipside a majority of these tests fail purely due to resource exhaustion, so maybe it wouldn't do anything but hang longer per test. I could do another rebase and determine the scope of rebuilds each commit causes, by just doing an evaluation. I could then grab all the small/no rebuild commits and move them to a separate PR, then rebase this one back onto staging and keep only the massive rebuilds here. Would that be acceptable? |
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
from
ea0d17c
to
30c62da
Compare
13 tasks
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
from
30c62da
to
01a693d
Compare
|
As requested, minor rebuilds have been separated into a different commit (see #349567). I kept all the massive rebuilds here, and I did not separate each commit into its own PR because they largely all target the same derivations, ie there are too many common rebuilds to justify separation, as each commit would cause approximately the same amount of rebuilds anyways. I cannot commit to another cycle of testing, so I will refrain from bumping these drvs again, despite the fact that upstream has new commits. I am also considering removing Furthermore, I am considering dropping myself from maintainer for just these packages for the same aforementioned reasons. I cannot commit myself to building and testing these packages, as my system is simply incapable of such a task, and I think it would be unwise for me to act as maintainer without being able to fulfill such a basic responsibility. This would unfortunately leave some of them orphaned, hopefully other members in the community with an interest can adopt them. cc @RossComputerGuy @restoration578 I would appreciate if you both could roll with another NOTE: I have temporarily kept the |
|
Marking as draft to prevent accidental merge |
Frontear
changed the title
Frontear
force-pushed
the
update-libimobiledevice-drvs
branch
from
fa8d0c1
to
3869ed6
Compare
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
Blocked by #349567, as a derivation here relies on said PR to be merged.
Updates derivations from https://github.com/libimobiledevice that cause mass rebuilds. These were accompanied by cleanup that is shared between both PRs.
Cleanup includes:
Adding(considering removal, see my latest comment)unstableGitUpdaterto all derivations (see explanation by @restoration578 here)meta.licensemore consistently to upstreammeta.homepageplatforms.unixfor all derivations inmeta.platformspkgs/by-nameAdding myself as maintainer(considering removal, see my latest comment)Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.