Summary: | dev-haskell/texmath - missing dependency? pandoc fails until texmath is remerged after dev-haskell/aeson update | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marc Joliet <marcec> |
Component: | Current packages | Assignee: | Gentoo's Haskell Language team <haskell> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | marcec |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | The build log of app-text/pandoc. |
Description
Marc Joliet
2013-11-05 14:47:20 UTC
Created attachment 362623 [details]
The build log of app-text/pandoc.
> * //==-- Please, run 'haskell-updater' to fix broken packages --==//
Please do, reopen if that doesn't fix it; thank you in advance.
(In reply to Tom Wijsman (TomWij) from comment #2) > > * //==-- Please, run 'haskell-updater' to fix broken packages --==// > > Please do, reopen if that doesn't fix it; thank you in advance. Damn it, how did I overlook that :-/ . Well, it doesn't matter, because it's already fixed (as I already wrote). But isn't the entire point of using subslots to avoid the necessity of haskell-updater and the like? So I don't understand why you'd be satisfied with it being fixed by haskell-updater. Could you please explain? Is the migration to subslots WIP? (In reply to Marc Joliet from comment #3) > Well, it doesn't matter, because it's already fixed (as I already wrote). Sorry, have missed that as I had focused on the log and the first paragraph. > But isn't the entire point of using subslots to avoid the necessity of > haskell-updater and the like? The sub slot / version was not changed; so, it didn't trigger a rebuild. > So I don't understand why you'd be satisfied > with it being fixed by haskell-updater. Could you please explain? It would catch things that subslots don't. I think that in this case texmath wasn't rebuild with the current Haskell version, which leads to it being inconsistent and thus causing the failure; as to why texmath wasn't rebuild, I have no idea... > Is the migration to subslots WIP? As far as I know it is not WIP, we're confident that they work and they are already present in quite some places throughout the Portage tree. While they get used more and more, they have been here for a while. (Please note that I am a bug wrangler and not a Haskell herd member) First off, thanks for the helpful reply! I know it must take some time to formulate a useful answer like that. (In reply to Tom Wijsman (TomWij) from comment #4) > (In reply to Marc Joliet from comment #3) > > Well, it doesn't matter, because it's already fixed (as I already wrote). > > Sorry, have missed that as I had focused on the log and the first paragraph. No problem! > > But isn't the entire point of using subslots to avoid the necessity of > > haskell-updater and the like? > > The sub slot / version was not changed; so, it didn't trigger a rebuild. > > > So I don't understand why you'd be satisfied > > with it being fixed by haskell-updater. Could you please explain? > > It would catch things that subslots don't. > > I think that in this case texmath wasn't rebuild with the current Haskell > version, which leads to it being inconsistent and thus causing the failure; > as to why texmath wasn't rebuild, I have no idea... Well, I know for a fact that prior to the upgrade, pandoc was working fine (i.e., "ipython nbconvert" worked). So IIUC it was only the aeson upgrade that caused the problem. The previous haskell packages update I had consisted of the following four packages, none of which broke pandoc: dev-haskell/monad-control-0.3.2.2 dev-haskell/lifted-base-0.2.1.0 dev-haskell/resourcet-0.4.9 dev-haskell/conduit-1.0.8 Looking further with genlop, the one before that (on 21. October), for instance, *did* trigger a texmath rebuild. > > Is the migration to subslots WIP? > > As far as I know it is not WIP, we're confident that they work and they are > already present in quite some places throughout the Portage tree. While they > get used more and more, they have been here for a while. I meant that question more in the sense of whether the subslots in the dev-haskell ebuilds are known to be correct or if there is still ongoing work, or whether the devs are still looking out for bugs. That kind of thing, not whether subslots in portage itself are WIP. > (Please note that I am a bug wrangler and not a Haskell herd member) I kind of wish a Haskell herd member would respond, just so I can better understand what's going on and whether my expectations are simply wrong. The fact is, I have no clue about Haskell; it just happens to be the implementation language of a tool that a tool that I use happens to depend on. (In reply to Marc Joliet from comment #5) > I kind of wish a Haskell herd member would respond, just so I can better > understand what's going on and whether my expectations are simply wrong. Assigned this bug to them such that they can look at your question. (In reply to Tom Wijsman (TomWij) from comment #6) > (In reply to Marc Joliet from comment #5) > > I kind of wish a Haskell herd member would respond, just so I can better > > understand what's going on and whether my expectations are simply wrong. > > Assigned this bug to them such that they can look at your question. Yeah, it's another manifestation of mising feature (bug #449094): the dependency chain is the following: - 'pandoc' uses 'aeson' and 'pandoc-types' - 'pandoc-types' uses 'aeson' - 'texmath' uses 'pandoc-types' (no direct 'aeson' depend, but indirect via 'pandoc-types') Due to limitation of current EAPI=5 subslots there is no way to express that: texmath will break due to aeson upgrade (due to pandoc-types breakage). Thus portage have caught only direct aeson users. (In reply to Sergei Trofimovich from comment #7) > (In reply to Tom Wijsman (TomWij) from comment #6) > > (In reply to Marc Joliet from comment #5) > > > I kind of wish a Haskell herd member would respond, just so I can better > > > understand what's going on and whether my expectations are simply wrong. > > > > Assigned this bug to them such that they can look at your question. > > Yeah, it's another manifestation of mising feature (bug #449094): > > the dependency chain is the following: > - 'pandoc' uses 'aeson' and 'pandoc-types' > - 'pandoc-types' uses 'aeson' > - 'texmath' uses 'pandoc-types' (no direct 'aeson' depend, but indirect via > 'pandoc-types') > > Due to limitation of current EAPI=5 subslots there is no way to express that: > texmath will break due to aeson upgrade (due to pandoc-types breakage). > > Thus portage have caught only direct aeson users. Ah! Thank you for the explanation :) . |