Summary: | app-admin/haskell-updater gets stuck in rebuilds on haskell binpkgs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Frédéric Pierret <frederic.pierret> |
Component: | Current packages | Assignee: | Gentoo's Haskell Language team <haskell> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | gentoobugs |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | http-client-tls-build.log |
Description
Frédéric Pierret
2020-08-24 09:47:24 UTC
It says you should run `haskell-updater'. haskell-updater-should succeed. If it fails it's a bug. Can you attach full build.log of a failed dev-haskell/http-client build? (In reply to Jeroen Roovers from comment #1) > It says you should run `haskell-updater'. I've already posted the result of `haskell-updater` in the original post where the result is: 'ERROR: Updater stuck in the loop and can't progress' Created attachment 656576 [details]
http-client-tls-build.log
(In reply to Sergei Trofimovich from comment #2) > haskell-updater-should succeed. If it fails it's a bug. > > Can you attach full build.log of a failed dev-haskell/http-client build? I've attached the failing build.log of "dev-haskell/http-client-tls". "http-client" itself does not fail if emerging from source or binary. Only "http-client-tls" fails if "http-client" is emerged from binary. After this fail, running "haskell-updater", makes emerging again "http-client" from binary so the problem is "looping" indeed. I'm not sure about this "dev-haskell/cookie" dependency but, running "haskell-updater" should detect potential issue between current retry and ending package problem. Here it tries to fix "http-client" and it ends by "http-client" issue. Maybe "haskell-updater" should attempt a retry after such case by ignoring binpkg? To clarify context, I've enabled a freshly built binpkgs host with all those packages successfully built. The target was "pandoc" and all it's dependencies. Oh, you are using binpkgs. binpkgs don't really work for dev-haskell/*. To keep haskell-updater implementation simple we could unconditionally pass emerge option to always disable binpkgs. Or you can pass it manuall with 'haskell-updater -- <extra-emerge-opts>'. (In reply to Sergei Trofimovich from comment #6) > Oh, you are using binpkgs. binpkgs don't really work for dev-haskell/*. > > To keep haskell-updater implementation simple we could unconditionally pass > emerge option to always disable binpkgs. > > Or you can pass it manuall with 'haskell-updater -- <extra-emerge-opts>'. oh no. do you know how do you debug such issue with binpkg? My current workaround is to have built pandoc-bin. The original idea is to speed up continuous integration build and tests. (In reply to Frédéric Pierret from comment #7) > (In reply to Sergei Trofimovich from comment #6) > > Oh, you are using binpkgs. binpkgs don't really work for dev-haskell/*. > > > > To keep haskell-updater implementation simple we could unconditionally pass > > emerge option to always disable binpkgs. > > > > Or you can pass it manuall with 'haskell-updater -- <extra-emerge-opts>'. > > oh no. do you know how do you debug such issue with binpkg? I'm not sure I understand your question. What specifically you would like to achieve (or find out)? Maybe below is good enough. > My current workaround is to have built pandoc-bin. The original idea is to speed up > continuous integration build and tests. Haskell library ABI is quite fragile. ABI hash is explicitly stored in $(ghc --print-global-package-db). In Gentoo pandoc installs both binary and haskell library. Every time 'haskell-updater -q -l' reports broken packages you effectively have to rebuild all binpkgs in the list. |