On Wed, 5 Aug 2020 at 10:19, Jonas Smedegaard <jo...@jones.dk> wrote: > > Quoting Sebastien Bacher (2020-08-04 23:14:50) > > Hey Aurélien, Jonas, thanks for the replies > > > > Le 04/08/2020 à 19:11, Jonas Smedegaard a écrit : > > > Closing this bugreport does not imply that conversation is closed, > > > only that with the currently presented material there is no further > > > action. We can continue the conversation in a "closed" bugreport. > > > You are still most welcome to provide more information - e.g. more > > > details on why (if so) you think that it is relevant that Debian > > > (not only Ubuntu) uses the build flags that you requested. > > > > > > In addition to the (little) information presented here, I based my > > > judgement on some casual conversation on irc. I explicitly asked > > > there to please share information in a bugreport but nothing came of > > > that. > > > > Sorry for the lack of informations and the ignorance of the context. > > I'm not working on this package, just wanted to see it updated in > > Ubuntu so went to do the merge and saw that the only diff we had was > > recent and not forwarded to Debian so I did that. > > Makes sense. Thanks for the additional context. > > > > I'm not familiar with riscv64 nor the difference between the Debian > > and the Ubuntu port and why it would fail only in Ubuntu. From what I > > can see the build was tried on > > https://launchpad.net/ubuntu/+source/pandoc/2.8.1-2ubuntu1 and failed > > after 2.5 days without letting a build log. > > > > Then Dimitri (Cc here now) added a delta to --disable-optimization, > > which he had done in a previous upload for armhf/arm64. Since I saw > > you basically addressed a similar issue in Debian now with other flag > > I though it would make sense to do the same on riscv64. > > > > The build time are similarly slow on Debian but didn't fail at the end > > so maybe the change is wrong there and more details are needed ... > > Dimitri could you help there? > > In my understanding (lacking any evidence, based only on irc chatter), > Ubuntu compiles riscv64 in an emulator, not on real hardware. >
I'm not sure that is relevant here at all. GHC jumped from using llvm6 toolchain to using llvm9. It appears that this causes extreme regressions in ghc toolchain, on llvm-using architectures, during prof stage of builds. I do not believe this is specific to pandoc at all. It just happens that pandoc build is complicated enough to hit the limits, which were never hit before. And I have seen similar failures in other haskell packages. It is hard to "triange" this, as the stack of packages needing rebootstrap to attempt building pandoc is large, and thus it is near impossible to rebuild ghc with llvm6 again to compare building pandoc with that toolchain. There is native code generation being worked on for arm, so I hope things will get better once there is native code generation in ghc without llvm. I do not expect for that to be available anytime soon for riscv64, as I do not know if anybody is working on that. However, I do expect for riscv64 port of llvm to improve over time. > > > > Hope that helps. A bit. But yes, if ehat you need is to limit the > > > delta of Ubuntu packaging and that alone, then I really am not > > > helping here. > > I've redone the patch to be an Ubuntu specific rules in debian/rules, > > that shouldn't come to much cost to Debian and is quite common in > > other packages [1]. If you believe it's wrong and that riscv64 > > shouldn't be consider a low memory architecture / you don't want to > > carry a rule specific to Ubuntu then it's your choice. > > It does not help to restructure the patch to only affect Ubuntu, Sorry. > > The package is maintained in Debian for all users of Debian, which > includes derivatives of Debian using the package as-is, or rebuilding > from source as-is, or rebuilding from source with patches applied. What > is not accepted is maintaining in Debian any patches for downstream-only > needs - regardless that others in Debian are willing to do so. > > > > I will try to drop the delta and see if the build still fail and if we > > a build log of the error > > I will expect that to continue to be very slow, due to the build being > done on emulated hardware. Whether or not that is acceptable for Ubuntu > is a concern internally for that distribution. > > What makes it a concern worthy of consideration for Debian to maintain > is if it is a rumor - i.e. if building on real risc64 hardware is > extremely slow. > > Debian does not yet officially build for riscv64, and I am unaware if > the unofficial build is done emulated or not. You might try ask the > porters about that. > There is a slight mismatch of riscv64 port status between Ubuntu and Debian. I think it's maybe a little more "releasy" than it is in debian. For example, FTBFS regressions on riscv64 are RC in Ubuntu and block package migrations. Hence for us, patching and keeping pandoc buildable is quite critical, given how many packages build-depend on pandoc. Irrespective of how good, or bad, ghc itself is. We pretty much must always have pandoc installable on riscv64 even if it fails to produce all the inputs/outputs it supports. -- Regards, Dimitri.
