haskell-taffybar-ghc7.8.3-0.3.0-shared broken with glib-0.13.0.1

[eduarrrd]

Upstream bug report: https://github.com/travitch/taffybar/issues/89

rc/System/Taffybar/Widgets/Graph.hs:201:12:
    No instance for (glib-0.13.0.1:System.Glib.UTFString.GlibString
                       string0)
      arising from a use of ‘labelNew’
    The type variable ‘string0’ is ambiguous
    Note: there are several potential instances:
      instance glib-0.13.0.1:System.Glib.UTFString.GlibString
                 Data.Text.Internal.Text
        -- Defined in ‘glib-0.13.0.1:System.Glib.UTFString’
      instance glib-0.13.0.1:System.Glib.UTFString.GlibString [Char]
        -- Defined in ‘glib-0.13.0.1:System.Glib.UTFString’
    In a stmt of a 'do' block: l <- labelNew Nothing
    In the expression:
      do { l <- labelNew Nothing;
           labelSetMarkup l lbl;
           boxPackStart box l PackNatural 0 }
    In a case alternative:
        Just lbl
          -> do { l <- labelNew Nothing;
                  labelSetMarkup l lbl;
                  boxPackStart box l PackNatural 0 }

[peti]

Please report this issue to the authors of taffybar.

[eduarrrd]

I did. See first line of my comment. Why are you closing the bug?

[Fuuzetsu]

The bug is not nix related and so invalid here. It should have been closed earlier.

[puffnfresh]

It was also fixed in https://github.com/NixOS/nixpkgs/commit/a558fdca16b575f518078300c37564746779cbbc

[eduarrrd]

@Fuuzetsu I disagree. That update broke my setup (and presumably everyone's who used taffybar). E.g. imagine replacing/updating the the kernel to a version during the latest merge-window. Saying "hey guys, your complaint is invalid, the nix expression is perfect" might not be the best response to the mob with pitchforks outside your house. I do agree agree with your second point though. I wasn't aware it was no longer an issue.

My question came from @peti closing the bug without a resolution (such as fixed or obsolete).

@puffnfresh ah! That's good to hear. Guess it's time to update ...

[peti]

@eduarrrd, I am sorry for closing the ticket without giving a more helpful response.

My problem was that it wasn't obvious to me what I'm supposed to do about the issue you've reported. Nixpkgs maintainers can -- in general -- not fix bugs in the software we distribute, i.e. I cannot rewrite taffybar to compile with some version of its build inputs. That is something the taffybar author must do -- or someone who's at least familiar with taffybar, which I am not. The fact that the issue had been open and unresponded to for a long time suggested to me that no other Nixpkgs maintainer felt up to the task of fixing this compiler error. So the ticket felt a bit out of place in the Nixpkgs issue tracker.

If you had framed your ticket differently, like, "please apply such and such patch to fix the build error" or "please revert to version x.y.z to fix the build error", then things would have been differently, I guess, but unfortunately the ticket just quoted some compiler error without any additional information about what this complaint means and what we, as Nixpkgs maintainers, are supposed to do about it.

[eduarrrd]

@peti Fair enough. The bug does require context which got lost over time. I was hoping that whoever did the bump (of glib to 0.13) would know how to fix this. I would have provided a suggestion if I knew what to do exactly. My unstated assumption was that the default reaction to breakage would be rollback (followed by investigation of the issue by people who understand more than (my observation that is) "stuff broke").

Nobody expects the nixpkgs maintainers to fix the software they distribute. The software-bug is real and was reported to the developer. However, there is also a "distribution-bug", which is the one this github issue is about. The bug is "pieces of software were updated to a non-working version". That is something distributors are responsible for, I believe.

The "distribution side" fix would have been, I think, to restrict build inputs to a maximum version (e.g. glib<0.13).

[peti]

@eduarrrd, when a package is broken by an update of its dependencies, we may or may not revert the update -- that's decided on a case-by-case basis. Sometimes, I'm perfectly happy breaking packages I perceive as less important so that I can update another package that I perceive as important. In the Haskell world, it's virtually impossible to keep a non-trivial package set compiling and moderately up-to-date at the same time. We have to make choices every now and then.

If a package you need is broken for some reason, then your best bet of getting that fixed quickly is to suggest a concrete solution -- or even better: open a pull request that implements the solution you think is best. Also, making the upstream authors aware of the issue is always a good idea, because if they fix that issue with an update to Hackage, then we'll usually pick that up within a matter of days.

[eduarrrd]

@peti, why break a package intentionally? Isn't the great advantage of nixos that we can have any package in any version in parallel? Why not just make taffybar use glib<0.13 and keep the default glib at >=0.13? Am I missing something?

[Fuuzetsu]

It is the advantage of nix that you can do that but it is not the policy of nixpkgs in general: there are things that do it if the demand is great enough. The problem with this approach is that we need to keep more and more old versions around to make sure everything still compiles. This is considerable maintainer effort (even more than now). So the general approach is to not hold up large updates because a couple of packages break in the process. From nixpkgs point of view, the package is broken with the versions in nixpkgs even if it might compile and work perfectly fine with other versions. Therefore it is marked as broken. ‘broken’ doesn't mean that there are errors in source code or that package has bugs or whatever (although it can), it means there are problems with the package in nixpkgs and currently doesn't build or misbehaves.

But you can do this yourself if you want to: it is easy to put overrides in your ~/.nixpkgs/config.nix which do precisely that, keeping taffybar using the exact version of packages you want it to, regardless of what nixpkgs says.

The best way to mitigate this is to put yourself down in meta.maintainers of the packages you care about. You can then monitor your packages carefully and make sure they still build. Hopefully @peti can then cc the listed maintainer when/before/if he marks a package as broken in a wave of updates.

PS: I know exactly how to fix the reported bug and I still would not do it in nixpkgs. What tends to happen in reality is that updates are done and then we go on upstream issue tracker and ask them to update to latest versions of dependencies. This works well most of the time.

I note that to even see this breakage you'd have to either be on master or nixpkgs/nixos-unstable channels: if you want an environment where everything stays fairly constant and all packages still behave more-or-less the same after an update, a direct git checkout or a channel with ‘unstable’ in it is probably not a good choice! In the end on unstable you can expect a lot of quick updates but you should not be surprised if the updates happen fast enough for upstream to not be able to keep up.

Lastly, IIRC glib 0.12 was kept around as default for quite some time after 0.13 went on Hackage to give packages time to update.

I'm sure someone can correct me if I said anything wrong.