Changes in haskell-gi cause compilation failures #464
Comments
colonelpanic8
added
bug
|
Well, it's an easy fix... just a one liner. I'm worried though that fixing this for some will break it for others. is this coming from changes to the gir files? |
|
The upgrading of haskell-gi is due to gir changes. But this part, I am not sure. |
|
And with that fixed, more comes: |
colonelpanic8
changed the title
|
@Magicloud @brecht_serckx_gitlab can you please post the gtk/gdk versions that you are using that are causing these errors? |
|
@LeifW Can you confirm this issue? |
I am on gtk 3.24.8 (1:3.24.8+177+gae2ef1472c-1) |
|
Sorry in advance for the extra noise, I was wondering if these errors are in any way related: System:
|
|
@evanjs yes those are likely related. |
|
seems like its not the gtk vesrion, but something else going on here. |
|
@evanjs yeah I'm getting similar errors in gi-xlib: |
|
I am having the same GTK3 as @BrechtSerckx . |
|
You guys can check out my solution: https://github.com/taffybar/taffybar/tree/newHaskellGI |
|
had to set up cachix to get a passing build: https://travis-ci.org/taffybar/taffybar/builds/546567320 |
|
@evanjs Actually was not able to get errors that were similar to the ones you mention there. What exactly did you do to get those? |
|
Anyone building with nix should use https://taffy.cachix.org/ to avoid massive build times when building from source. |
colonelpanic8
changed the title
|
@IvanMalison Would you provide some information about your nixpkgs revision? I'm not doing anything too funky - just following nixos-unstable - but I routinely have difficulty getting taffybar (or something in its dependency chain) to build For instance, on |
|
@NickHu yes, taffybar is broken in nixpkgs unstable right now. The error you are are seeing there is actually in the compilation of gi-dbusmenu, which needs a version of haskell-gi that is newer than what is there. Recently, I've added/fixed a few nix files to the taffybar repository that should help you get taffybar working with nix/in nixos. I'm planning to continue to maintain these files moving forward together with https://taffy.cachix.org/ (currently, I may be getting control of https://taffybar.cachix.org/ but not sure). The only catch is that they will be set up to work with whatever is in master rather than e.g. the latest release. Let me explain what each file does:
If you use the nixos module for taffybar to build your taffybar executable, then you should be able to simply add the overlay to your system configuration like: nixpkgs.overlays = [
(import ./path/to/overlay/overlay.nix)
];If you install taffybar as a user package, you'll need to do something simlar in your user level nix config. If you have a haskell project for your taffybar configuration, you can take a look at what I do: https://github.com/IvanMalison/dotfiles/blob/master/dotfiles/config/taffybar/default.nix I don't think you will NEED to pin nixpkgs to any particular version, but you will need to be on a sufficiently new version of nixpkgs for this to work. Also, note that this will likely require quite a lot of recompilation time because we are overriding a ton of haskell-gi libraries. One way to avoid this is to use the cachix instance I have set up at https://taffy.cachix.org/, but that WILL require that you use the version of nixpkgs pinned in nixpkgs.nix. It occurs to me that it might be valuable to separate the override of taffybar itself from the override of its dependencies in case users want to use the overlay without building from source. I'm going to look in to doing this right now. UPDATE: There is now a separate environment.nix file, which you can use to fix all of taffybar's dependencies without overriding the version of taffybar, so that e.g. you can use a stable version if you want. |
|
@NickHu Do let me know if you are able to get things working with the overlay. You can reach me on gitter if you need help. |
|
Thanks for all your help @IvanMalison, I was able to get it working with home-manager by
Could you perhaps summarise what's going on with respect to this, Hackage, and nixpkgs? From what I discerned when I was trying to debug this myself, some things in the dependency chain want haskell-gi >= 0.22 (gi-dbusmenu or one of its dependencies being one of them), but gi-cairo-render wants < 0.22 right? There's also a bunch of Haskell nix expressions which are broken, e.g. haskell-gi_0_22_4 (i.e. the newer version) because in the nix expression it depends on haskell-gi-base (< 0.22) instead of haskell-gi-base_0_22_2. |
|
Likewise |
Yeah, that's all roughly correct. The only unsatisfiable depdendency was haskell-gi, but this was fixed easily by simply updating gi-cairo-render's version bound, which was just a cabal file edit. That's why the overlay has this: Line 89 in b3ca25b See NixOS/nixpkgs#63500 for more details. They basically recommend something along the lines of #141, so that this doesn't happen again, but I think that might be quite hard. |
Correct, because I didn't pin nixpkgs, I had to compile everything as expected. The build time wasn't horrible (on my desktop machine) - probably around half an hour but I didn't actually check. If you have money/servers to burn, maybe we could set up a hydra instance to build and push to cachix every time nixos-unstable advances (which doesn't seem to be terribly frequently anyway). |
Yeah I don't think that's a particularly great solution because:
Lol. 30 minutes is pretty horrible in my book. That's long enough to be a pretty significant turn off to a lot of people. I think #141 is the long term solution, but at this point I'm just frustrated at how active I have to be in maintaining taffybar. Shit is constantly breaking, and I get the sense that people feel (justifiably) that taffybar offers a really unstable experience on a lot of fronts API/Dependencies/Stability of application itself. Sorry for the rant, I just hate experiences like that as an end user and I'm frustrated that I can't do better here for reasons beyond my control. |
|
FWIW @IvanMalison, I really appreciate and admire the effort you put in! taffybar can be annoying at times, but it's glorious when it all works, and it wouldn't be possible without your frustration. |
|
Completely echo @cjordan's comment @IvanMalison, I also really appreciate all the work you put in to taffybar, especially considering that you effectively revived it after it died. I know that nixpkgs changes very frequently, but nixos-unstable as a channel doesn't advance that often as far as I can see. I would guess it ranges anywhere between 0-4 times a week (depending on how many nixos tests are failing). I'm not too sure what you mean about figuring out how to purge things from the cache. I'd propose something like this: every time nixos-unstable advances, compile both taffybar master and taffybar latest stable release and push to cachix. That way, people who point their system configuration to nixos-unstable can benefit from cachix every time they update, and if they want to do taffybar development or use nixpkgs-unstable then they would probably be expecting to compile a lot of stuff anyway. |
I guess you can't see this unless you are an administrator of the cache, but the taffy cachix instance is currently 546MB. If we keep pushing to cachix every time there is a change in nixpkgs I'm pretty sure we will quickly hit some limit. The only solution I can think of is to purge cachix every now and then, but that means we will only be supporting VERY recent versions of nixpkgs, which is fine, I guess, but if the goal is to keep build times down, might not be that useful for people who use taffybar in their system configuration because bumping nixpkgs will probably cause a simlarly long recompilation. I can try just optimistically pushing to cachix every time the unstable channel changes, but I don't want to be a dick to the cachix people, who have set up something amazing completely free. |
|
I'm attempting to use the overlay but it's now failing on me because of the check for and I asked on IRC about this and was told that this overlay is not pure and therefore won't be able to build on my machine. |
|
@sondr3 Are you sure the overlay is still necessary. I thought haskell-gi had been bumped to a pretty reasonable version quite some time ago. The overlay was designed to work with a git repository, but it looks like you are trying to use it with some other type of source. All you'll need to do is edit the overlay to make sourceTransformer the identity, i.e. |
|
@IvanMalison it isn't in my case, at least (here and here) @sondr3 had mentioned taffybar is marked broken in nixpkgs, but IIRC, this is only the The only other issue I'm aware of at the moment is NixOS/nixpkgs#77588, which can be worked around (most lazily) by not using the current unstable channel. |
|
How would I be able to use the |
I actually build taffybar via cabal (via nix) and import taffybar ( |
|
I am using |
|
For info, what has been working for me, is to use the unstable channel for xmonad & taffybar in my overlays. |
|
@IvanMalison would be nice to have a static binary (as it is the case for |
|
@PierreR taffybar is now in stackage (haskell-gi already was), and nixpkgs uses stackage to form the basis of its package sets. This means that breakage in haskellPackages should not happen anymore. |
|
@dmvianna Unfortunately some crucial fixes did not make it in to nixos-20, so taffybar is only fixed in unstable atm (as mentioned by @PierreR) Furthermore, I changed the overlays to basically be empty because everything is now fixed (the overlays were mainly intended to successfully build in CI). A version of the overlay that should fix everything can be found here: Line 3 in 834940c |
|
I also had to rename |
|
@dmvianna can you post the exact configuration that you are running? |
|
@dmvianna or you know, consider just running unstable (its pretty safe with nixos since you have rollbacks anyway) |
Due to some changes of gtk3 library, haskell-gi was updated. Hence following command cannot build taffybar.
cabal v1-install --constraint='haskell-gi==0.22.3' --constraint='haskell-gi-base==0.22.1' --force-reinstallsError:
The text was updated successfully, but these errors were encountered: