libimobiledevice: 1.3.0-date=2023-04-30 -> 1.3.0-unstable-2024-05-20, libimobiledevice-glue: 1.2.0 -> 1.3.0

[C0D3-M4513R]

Description of changes

• libimobiledevice: 1.3.0-date=2023-04-30 -> 1.3.0-unstable-2024-05-20
• libimobiledevice-glue: 1.2.0 -> 1.3.0

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[superherointj]

You have to split in different commits. (And follow the contribution guidelines.)

[RossComputerGuy]

Please split the two package updates into their own commit and properly format commits and PR title to something like libimobiledevice: 1.3.0-date=2023-04-30 -> 1.3.0-date=2024-06-19 and libimobiledevice-glue: 1.2.0 -> 1.3.0.

[superherointj]

https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-naming

Is this date= a new format for unstable?

I think it should be unstable.

[RossComputerGuy]

I'm not sure, this package has been using it since before I became its maintainer. We always could change it or just keep the flow.

[superherointj]

I'm not sure, this package has been using it since before I became its maintainer. We always could change it or just keep the flow.

Thanks for clarifying. I think we should follow the guidelines for contribution unless there is a good reason. And then, the good reason should be documented. I think, this may be just the usual case of unstable usage.

[superherointj]

This package is missing the update script. There is a unstableGitUpdater abstraction exactly for this case of rolling git.

Please add:

passthru.updateScript = unstableGitUpdater { }

Note: unstableGitUpdater parameter has to be declared too.

For testing:

nix-shell maintainers/scripts/update.nix --argstr package libimobiledevice

[C0D3-M4513R]

I've removed the libimobiledevice-glue bump from this pr, added the unstableGitUpdater, made sure nix-shell maintainers/scripts/update.nix --argstr package libimobiledevice works and am currently (again) building.

Please note, that the previous build still has not completed for me.
If that's what you meant, when you said "And follow the contribution guidelines", then I'm sorry.
ofborg-eval is in this case simply way faster at building c.a. 454 packages from source.

I take it, that's all you wanted to happen?

[superherointj]

I've removed the libimobiledevice-glue bump from this pr

A single PR can have multiple commits. The problem was that you added more than a single package to a single commit.
You can keep libimobiledevice-glue here as long as it's a different commit.

added the unstableGitUpdater, made sure nix-shell maintainers/scripts/update.nix --argstr package libimobiledevice works and am currently (again) building.

Good. That's how it's supposed to be. Always favor the update script over manual updates. Only in cases of failure, that the package or update script have to be tweaked that you should do manual updates.

Please note, that the previous build still has not completed for me. If that's what you meant, when you said "And follow the contribution guidelines", then I'm sorry. ofborg-eval is in this case simply way faster at building c.a. 454 packages from source.

FYI, eval is different than building a package. If you propose a package that you haven't built, and you don't know it is building, you may break it for everyone. (And no one wants that.) And you also have to build the downstream of it using nixpkgs-review tool.

I take it, that's all you wanted to happen?

:-)
Actually no. But I don't want to overload you.
I think these packages should be migrated to by-name.
But it is not required atm.

[superherointj]

when you said "And follow the contribution guidelines"

There is a certain format to commit messages. There exist automation to do auto sort of things to get your PR right.

Follow this format:

package-name: oldVersion -> newVersion

Note: I only want to point out you are missing the : in your commit messages.

[superherointj]

I am currently not intrested in becoming a maintainer for these packages. (maybe I'll become one for recaf, but that is not packaged yet [I have a pr branch open to recaf itself])

Are we good to start a ofborg build? And is c.a. 450 packages fine for ofborg?

Up to 500, target master and OfBorg can handle it.
But over it (like thousands), target staging. It's more or less.
I'll attempt to build on my host and post results.

[superherointj]

@ofborg build

I think, you need to specify the packages that you want to be built. If there is downstream packages that you want to be built, you have to specify it too.

Instructions at:

https://github.com/NixOS/ofborg?tab=readme-ov-file#ofborg

[C0D3-M4513R]

I think I'm just not a trusted user. ofborg build only takes in a list of parameters to be passed to nix-build iirc.

[RossComputerGuy]

Thank you @superherointj for reviewing. I'm at work right now but I'll take a look this evening when I'm free.

[superherointj]

Are we good to start a ofborg build? And is c.a. 450 packages fine for ofborg?

Up to 500, target master and OfBorg can handle it. But over it (like thousands), target staging. It's more or less. I'll attempt to build on my host and post results.

My host failed to build it. Indeed, this build is large. I think, you should target staging. Despite not being that many packages numbers wise...

Mark it as a draft first. Because odds are you'll get this wrong and ping everyone in nixpkgs. (I'm saying this because people often get this wrong. Not you specifically.)

[RossComputerGuy]

Set as draft, rebase, retarget, and unmark as draft @C0D3-M4513R

[superherointj]

Rebase to staging.

First, mark the PR as draft. (Actually, only verify it is marked as draft. I've marked it as draft for you.)

Then:
https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#rebasing-between-branches-ie-from-master-to-staging

[C0D3-M4513R]

Are we good to start a ofborg build? And is c.a. 450 packages fine for ofborg?

Up to 500, target master and OfBorg can handle it. But over it (like thousands), target staging. It's more or less. I'll attempt to build on my host and post results.

My host failed to build it. Indeed, this build is large. I think, you should target staging. Despite not being that many packages numbers wise...

Mark it as a draft first. Because odds are you'll get this wrong and ping everyone in nixpkgs. (I'm saying this because people often gets this wrong.)

With instructions as clear as those in the contributing document, it was pretty straight forward. (thanks for linking)
My host personally is still building this (I was at 153/436. I'm starting a build again now).
My plan to use my laptop backfired though, because 16G Ram+ 16G swap is not enough and I got oom'd. pretty quickly)

[superherointj]

With instructions as clear as those in the contributing document, it was pretty straight forward. (thanks for linking) My host personally is still building this (I was at 153/436. I'm starting a build again now). My plan to use my laptop backfired though, because 16G Ram+ 16G swap is not enough and I got oom'd. pretty quickly)

The trick to do larger builds is to lower max-jobs, such that you don't run out RAM and swap doesn't happen, after swap happens host degrades to a halt, and then the build doesn't happen.

My host is larger than yours and I still failed to build. I think, it is better to leave this for hydra at this point.

Certify to look up packages and logs at Hydra when build is done:

https://hydra.nixos.org/project/nixpkgs

I'll be merging this PR when eval is done.

[C0D3-M4513R]

Did I rebase to the right branch? Hydra reports the last staging build to be at 2020-10-05?

[superherointj]

Did I rebase to the right branch?

I think so. Err...

Hydra reports the last staging build to be at 2020-10-05?

Hydra builds the other branch (staging-next).

(But you did name your branch with an unfortunate/misleading name (master), instead of libimobiledevice)

[C0D3-M4513R]

The naming isn't the best, but I'm scared to try to rename the branch using github's ui.

Also I suppose this supersedes #320292 .

[superherointj]

The naming isn't the best, but I'm scared to try to rename the branch using github's ui.

I did not suggest you to rename it at this point in time. Only mentioned it for you awareness. (That you pick a better name for next time.)

Also I suppose this supersedes #320292 .

Yes, will close it.

[superherointj]

Did I rebase to the right branch?

Something could be off. Or staging/staging-next has been merged. [Likely this.]

To guarantee it is solid. Let's do the following:

I have named nixpkgs as upstream. If you have it named something else, use that name.

git fetch upstream staging
git reset --hard upstream/staging
git cherry-pick 07c1f4e1e6be98dddf70a77e29becf56b0639612
git cherry-pick 35b5a13095d8c1ca631afc03df42dbb65dc121bd

Result will be like this: [minus nixpkgs-staging, which is a local branch here]

If you do this, you'll have a clean staging with your commits for sure.

Then, you have to force push it to the remote branch you have used.

[superherointj]

Tested eval on my host. I expect this to be fine.
I'm merging without waiting for CI eval because it takes forever. And I just tested eval (not full build, can't do full build).

[trofi]

The build regressed on clang and gcc-14. Proposed downstream fix as #321723