dbvisualizer: init at 24.2.2

[boldikoller]

Description of changes

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.

[momeemt]

Result of nixpkgs-review pr 344225 run on aarch64-darwin 1

1 package built:

• dbvisualizer

[momeemt]

Thanks for your contribution. I left the comment about mainProgram, besides this, lgtm.

[momeemt]

You should also split the commit into maintainers: add boldikoller and dbvisualizer: init at 24.2.2. ref

[boldikoller]

You should also split the commit into maintainers: add boldikoller and dbvisualizer: init at 24.2.2. ref

Should be fixed, thanks again!

[momeemt]

Thank you for your work! LGTM.

[boldikoller]

Would it be better to set env.strictDeps as opposed to just strictDeps?

[Bot-wxt1221]

@boldikoller I wonder why we should define strictDeps.

[boldikoller]

@boldikoller I wonder why we should define strictDeps.

I am sorry, I must be misunderstanding something. I previously understood strictDeps turned on as a setting to tell Nix to separate buildInputs from nativeBuildInputs. So that nativeBuildInputs are not also runtime dependencies (although the nativeBuildInputs not used at runtime would end up being stripped out either way). Is that incorrect?

Also, is strictDeps only read by the builder script from the environment variables? And not at all used on the Nix language side? If that is the case, then I can understand why to instead use env.strictDeps. However, I could find no documentation about whether that is the case or not. Excuse me if that is on me.

Edit: If this is the case, then I must be doing something wrong, because it does not even build with env.strictDeps = true with the error of "The env attribute set cannot contain any attributes passed to derivation.".

[boldikoller]

Is there anything that still needs to be changed?

[Bot-wxt1221]

@boldikoller always fix ofborg first.

[Bot-wxt1221]

Please tell us why this.

[boldikoller]

I enabled strictDeps because I was pretty sure it is considered a best practise to enable it? Is it not? Should I disable it? Let me try if that fixes ofborg

[boldikoller]

@boldikoller always fix ofborg first.

@Bot-wxt1221 I do not know how to fix this. The error ofborg gives is error: access to URI 'https://www.dbvis.com/product_download/dbvis-24.2.2/media/dbvis_linux_24_2_2.tar.gz' is forbidden in restricted mode.

Isn't it ran in restricted mode because the license is unfree? Or am I wrong about this?

I do not know how I should go about fixing this

[Bot-wxt1221]

@boldikoller Please run nix build /path/to/nixpkgs#package-name to check whether it can pass build.

[boldikoller]

@boldikoller Please run nix build /path/to/nixpkgs#package-name to check whether it can pass build.

@Bot-wxt1221 It builds just fine locally. I've tested before with nix-build /path/to/nixpkgs -A dbvisualizer, and I get the same result with nix build /path/to/nixpkgs#dbvisualizer.

Are you sure the reason ofborg failing is not because the license is set to unfree?

[Bot-wxt1221]

@boldikoller Not because of unfree.

[boldikoller]

@boldikoller always fix ofborg first.

@Bot-wxt1221 ofborg has been fixed it.

[pluiedev]

Does it have to be Temurin? (i.e. does openjdk17 work?)

[boldikoller]

It does not need to be temurin. My reasoning was that temurin-jre-bin-17 is 136MB as opposed to openjdk17 which is 470MB. Makes sense, since it is just the runtime as opposed to an sdk.

Probably there is a way to take only the jre from openjdk? When looking through nixpkgs I only found jre17_minimal as a potential candidate, but I was not sure what minimal implied. And sure enough, it does not run with jre17_minimal. Thus I just went for temurin.

[boldikoller]

Otherwise, seems to run just fine with openjdk17.

[pluiedev]

We removed the JRE-only builds from Nixpkgs a while back as a part of an overall refactor. OpenJDK is preferred since it's something that we built ourselves, rather than Temurin which is a prebuilt, binary-only distribution, and that it's the generic "baseline" for Java packages in Nixpkgs — if there's no special requirements then Nixpkgs packages should always use OpenJDK

[boldikoller]

Alright then, in the name of uniformity I concede.

It would be nice if there was a way to only include the JRE, however. Maybe as an argument to the openjdk package in the future? As an override? Ultimately, it's not a big deal, but in this case it basically doubles the download size, which is suboptimal.

[pluiedev]

After doing some more digging, I think you might be able to make jre_minimal work by overriding it with more modules, like jre17_minimal.override { modules = [ "java.base" "java.logging" ]; }. Yes, this is undocumented, yes, this sucks, I'll probably make a separate issue about it

[pluiedev]

Should it be symlinked, or simply renamed?

[boldikoller]

That's a good question. In my opinion either can make sense. My reasoning behind symlinking it is that I did not want to modify the layout of the tarball, only add onto it. Maybe that is just silly and it should be mvd instead.