Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xorg: allow overriding via overrideScope' #45328

Merged
merged 7 commits into from Oct 18, 2018

Conversation

thefloweringash
Copy link
Member

Motivation for this change

Wanted to modify some xorg.* packages in an overlay, ran into #11944. I did a fairly straight forward conversion into makeScope / overrideScope, but I don't have a good idea of the state of the art in this area.

Additionally discovered that while pkgs/servers/x11/xorg/default.nix is auto-generated, it has been manually updated for a few packages. I updated the source lists so that regenerating default.nix doesn't change any packages. The exception to this is xeyes, which gained a new buildInput. The source lists should be converted to https, but I'd prefer to do that in a separate PR.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

Copy link
Member Author

@thefloweringash thefloweringash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The generator script attempts to use a caching feature of nix-prefetch-url which no longer exists. Every time it's run it downloads everything from scratch.


libxcb = (mkDerivation "libxcb" {
libxcb = callPackage ({ stdenv, libxslt, libpthreadstubs, python, libXau, xcbproto, libXdmcp }: stdenv.mkDerivation {
name = "libxcb-1.12";
builder = ./builder.sh;
src = fetchurl {
url = http://xcb.freedesktop.org/dist/libxcb-1.12.tar.bz2;
sha256 =
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved this to overrides.nix. It got lost in the regeneration.

(Github is displaying incorrectly for me, this comment should be attached to xkeyboardconfig's configureFlags).

configureFlags = attrs.configureFlags or []
++ malloc0ReturnsNullCrossFlag;
# the include files need ft2build.h, and Requires.private isn't enough for us
postInstall = ''
sed "/^Requires:/s/$/, freetype2/" -i "$dev/lib/pkgconfig/xft.pc"
'';
};
passthru = {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The generated file no longer applies // { inherit $buildInputs; } to each package. Qt3 relies on being able to access libXft.freetype and libXft.fontconfig. Updated to passthru.

@@ -13464,7 +13464,7 @@ with pkgs;
libdrm = if stdenv.isLinux then libdrm else null;
abiCompat = config.xorg.abiCompat # `config` because we have no `xorg.override`
or (if stdenv.isDarwin then "1.18" else null); # 1.19 needs fixing on Darwin
} // { inherit xlibsWrapper; } );
} // { inherit xlibsWrapper; } ) [ "packages" ]);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to remove the "packages" attribute from xorg's scope. Otherwise it gets merged into the main attribute set and makes lambdabot fail. I don't yet know why it's not a problem to have "callPackage", etc from makeScope

defaultBuildBuildScope = pkgs.buildPackages.buildPackages // pkgs.buildPackages.buildPackages.xorg;
defaultBuildHostScope = pkgs.buildPackages // pkgs.buildPackages.xorg;

makeScope = newScope: f:
let self = f self // {
newScope = scope: newScope (self // scope);
callPackage = self.newScope {};
overrideScope = g:
makeScope newScope
(self_: let super = f self_; in super // g super self_);
packages = f;
};
in self;

They should probably also be removed. Should this be done in all-packages.nix or splice.nix?


libxcb = (mkDerivation "libxcb" {
libxcb = callPackage ({ stdenv, libxslt, libpthreadstubs, python, libXau, xcbproto, libXdmcp }: stdenv.mkDerivation {
name = "libxcb-1.12";
builder = ./builder.sh;
src = fetchurl {
url = http://xcb.freedesktop.org/dist/libxcb-1.12.tar.bz2;
sha256 =
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this (xeyes) is the only rebuild in this PR.

@thefloweringash thefloweringash changed the title xorg: allow overriding via overrideScope [WIP] xorg: allow overriding via overrideScope Aug 19, 2018
@thefloweringash thefloweringash force-pushed the xorg-override branch 2 times, most recently from af84145 to e53faef Compare August 20, 2018 15:45
@thefloweringash
Copy link
Member Author

This is at the point that I need some feedback. Some questions:

  • why did the old version import some dependencies for xorg via inherit (buildPlatform) ...;? Does this break cross?
  • the "has clean-up" tag suggests a removed package, but there shouldn't be any. How do I list changes?

cairo epoxy;
inherit (buildPackages) pkgconfig xmlto asciidoc flex bison;
inherit (darwin) apple_sdk cf-private libobjc;
xorg = recurseIntoAttrs ((lib.callPackagesWith pkgs ../servers/x11/xorg {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You actually want callPackageWith. callPackagesWith will push the override into the inner attributes which is no longer correct.

inherit (buildPackages) pkgconfig xmlto asciidoc flex bison;
inherit (darwin) apple_sdk cf-private libobjc;
xorg = recurseIntoAttrs ((lib.callPackagesWith pkgs ../servers/x11/xorg {
}).overrideScope (lib.callPackageWith pkgs ../servers/x11/xorg/overrides.nix {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we do inline

(lib.fixedPoints.extends (lib.flip g) f);
to get something like

(lib.fixedPoints.extends (import ../servers/x11/xorg/overrides.nix) (import ../servers/x11/xorg)

(This ignores the flip. That would be for the odd order of self: super:, when you already did idiomatic self: super:.)

@Ericson2314 Ericson2314 added this to the 18.09 milestone Sep 10, 2018
@Ericson2314
Copy link
Member

Why did the old version import some dependencies for xorg via inherit (buildPlatform) ...;? Does this break cross?

So first of all, I think you meant buildPackages. And to answer your question, yes, it is needed because callPackagesWith pkgs is being used directly. See the unfortunate "splicing' stuff that goes into normal callPcakges. callPackagesWith pkgs doesn't get that, and so is missing packages.

Now that splicePackages is exposed, however, you can let-bind a callPackageWithoutXorg which will obviate the need to sort specific packages by hand.

@Ericson2314
Copy link
Member

Overall, great work! It would be nice to get this into 18.09 as it's a good cleanup and will make any xorg backports easier if we do so.

@thefloweringash
Copy link
Member Author

Rebased to resolve the conflict, fixed callPackagesWith vs callPackageWith.

It sounds like you've got a clear idea of how to make this nicer, but I'm not familiar enough with the splicing to grasp it. Can you expand a bit on how implementing callPackageWithoutXorg would look?

As for usinglib.fixedPoints.extends, would that require changing default.nix and overrides.nix to take pkgs explicitly instead of being called with callPackage?

Thanks for looking at this!

@Ericson2314
Copy link
Member

I'm going to make a few fixes here, then merge soon.

Copy link
Member

@Ericson2314 Ericson2314 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

N.B. to other reviews I will fix cross

@samueldr samueldr modified the milestones: 18.09, 19.03 Oct 6, 2018
@Ericson2314
Copy link
Member

Ericson2314 commented Oct 18, 2018

Well, it's all good now! Finally!!

@Ericson2314 Ericson2314 changed the title [WIP] xorg: allow overriding via overrideScope xorg: allow overriding via overrideScope Oct 18, 2018
@Ericson2314 Ericson2314 changed the title xorg: allow overriding via overrideScope xorg: allow overriding via overrideScope' Oct 18, 2018
@dtzWill
Copy link
Member

dtzWill commented Oct 19, 2018

Can this (master, really) be merged over into staging? Otherwise various X updates (gathered in #48549) will make it a pain when wanting to merge staging back over. It will probably be a pain to rebase that on top of this but not too bad and better to do that in a PR, under review, than down the line by some poor soul trying to merge and hoping they don't break everything :P (and hopefully the updates can be auto-generated to fit this anyway :)).

@Ericson2314
Copy link
Member

@dtzWill Sorry just saw. Sure that makes sense, will do!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants