Re: haskell-hdf5 build failed on armel, i386 ,s390x and riscv64 due to test fail

On Wed, Oct 05, 2022 at 03:17:01PM +0200, picca wrote: > So what is the right way to fix this issue if a library need this -N option > to be efficient on architecture which support it ? Nearly every instance of this problem is with a testsuite, and it's easier to remove -N across the board and

Re: Adding copilot

On Thu, Jun 16, 2022 at 01:07:18AM +0100, Ivan Perez wrote: > I'm trying to first get things to run without any changes, and then I can > add the modifications for copilot. The package-plan (and, not unrelatedly, unstable) is in a broken state and in need of a considerable amount of labor. The

Re: update to stackage lts-19 (ghc 9.0)?

On Mon, Jun 13, 2022 at 01:11:24PM -0400, Scott Talbert wrote: > OK, so the answer then is - go upload "everything"? Yes, the "best" way forward is to update the package plan to LTS-19, patch/update all the non-stackage packages to be compatible with GHC 9, `dht upgrade` everything that needs

Re: update to stackage lts-19 (ghc 9.0)?

On Sat, Jun 11, 2022 at 10:40:03PM -0400, Scott Talbert wrote: > Do the binNMUs happen automatically for all packages to be rebuilt against > GHC 9.0.2, or does something have to be done manually? I had thought I had > seen that happen automatically in the past, but I don't seem to see any >

Re: highlighting-kate

On Sun, Apr 10, 2022 at 09:55:16AM -0700, John MacFarlane wrote: > I was surprised to see that highlighting-kate is still in > the package repository. > > This is an ancient library, long ago superseded by > skylighting. > > Assuming there aren't things that depend on it, I > think it should be

Re: Would you consider updating the ghc package to version 9 for Bookworm (testing) Debian?

On Thu, Jan 20, 2022 at 02:42:13PM +0100, Marek Ľach wrote: > I would like to ask if there're any foreseeable plans to possibly update the > ghc to at least version 9.0.2 > for the testing > Bookworm distribution? My information may be out

Re: Removing hgettext and possibly other non-key packages

On Thu, Sep 09, 2021 at 01:08:42PM +0200, Sven Bartscher wrote: > I was just looking at the reason why hgettext is marked for removal from > testing. While doing so, I noticed that the last releases of the package > have all been bumps to the dependencies. The last upstream release is from > 2017,

Re: Bug#967991: glirc, build-depends on package which is not in testing

On Thu, Aug 06, 2020 at 11:20:00AM +0100, peter green wrote: > glirc can no longer be built in testing because haskell-regex-tdfa is no > longer > present in testing. Ilias Tsitsimpis has filed a bug report against the > package > saying he intends to remove it and asked the release team to

Re: Bug#965064: pkg-haskell-tools: FTBFS in unstable

On Wed, Jul 15, 2020 at 03:09:24PM +0100, Iain Lane wrote: > Upgrading shake will fix this, or it can be worked around in the In theory we can upgrade shake once js-dgtable clears NEW. It's been sitting there for 3 months.

Re: Transition, libghc-xmonad-dev

On Tue, Jul 14, 2020 at 01:49:19PM +0200, Adam Sjøgren wrote: > And here is a patch for the current xmonad package in unstable: Thanks; https://salsa.debian.org/haskell-team/DHG_packages/-/commit/0d800436a51a0bb09a03afbcf5c05bbc7bd9751f

Re: Transition, libghc-xmonad-dev

On Sun, Jul 05, 2020 at 05:58:57PM +0200, Adam Sjøgren wrote: > I'm not sure where to start, or how I help most efficiently with getting > pandoc updated, so xmonad can be. > > Maybe I should try to get rid of the dependency on Text.Pandoc in > xmonad, it is only used to generate the man-page

Re: Bug#964983: New Upstream Version

On Mon, Jul 13, 2020 at 09:05:28PM +0100, Barak A. Pearlmutter wrote: > There's a new upstream version available, and I cannot update the > github-backup package until libghc-github-dev (>= 0.23) is available. > So I hope to see the new version packaged. Someone would need to package

Re: new upcoming Pandoc dependency

On Mon, Jul 13, 2020 at 12:21:22PM +0200, Jonas Smedegaard wrote: > I will only attempt patching _after_ haskell-doctemplates is installable > in unstable. It's now available on all release architectures but mipsel, mips64el, and s390x.

Re: new upcoming Pandoc dependency

On Sun, Jul 12, 2020 at 03:00:41AM +0200, Jonas Smedegaard wrote: > I am pretty much same place as last I posted to this thread: Waiting for > others in the Haskell team to tell me that dependencies have become > available. And we're waiting for however many months it takes for them to go

Re: Transition, libghc-xmonad-dev

On Sun, Jul 05, 2020 at 05:58:57PM +0200, Adam Sjøgren wrote: > I'm not sure where to start, or how I help most efficiently with getting > pandoc updated, so xmonad can be. So to be a little more focused: If we check the package plan, we see that it calls for pandoc 2.9.1.1. % cabal v1-install

Re: Transition, libghc-xmonad-dev

On Sun, Jul 05, 2020 at 03:11:34PM +0200, Adam Sjøgren wrote: > Is there anything I can help with, with the currently ongoing > transition? * Review https://release.debian.org/transitions/html/haskell.html for packages that are broken on a subset of architectures, and investigate the build

Re: Bug#962973: haskell-readline: Removal notice: broken and unmaintained

On Tue, Jun 16, 2020 at 09:10:32PM -0700, Sean Whitton wrote: > keysafe, in experimental, depends on haskell-readline. > > CCing upstream: Joey, do you think it would be possible for keysafe to > migrate to use something maintained? Some options suggested at

Re: uscan repack cause troubles.

On Wed, Jun 03, 2020 at 06:54:33AM +, PICCA Frederic-Emmanuel wrote: > I endup with this error > > dht debian2dsc -o lab p/gitit/debian > uscan: Newest version of gitit on remote site is 0.12.3.2, specified download > version is 0.12.3.2 > Successfully repacked lab/gitit-0.12.3.2.tar.gz as

Re: Packaging ipynb

On Sun, Dec 22, 2019 at 10:28:02PM -0600, Antoine Latter wrote: > Actual package: > https://gitlab.com/aslatter/DHG_packages/commit/cab7c22b6ab6a928a89f2a6d4f2d234c8c7393d4 Just found this in my spam folder. Thanks, I've built it and uploaded it to NEW. Assuming it gets accepted, the next step

Re: Haskell-* build ordering

On Wed, Jun 03, 2020 at 10:10:05PM +0200, Christian Ehrhardt wrote: > I was wondering if you have a dependency graph, or an upload staging order > that you usually use for your uploads and that I could now apply to the > Ubuntu builds and rebuilds on the Ubuntu side. Once upon a time we used a

Re: Proposal not to allow other packages to hold up ghc and Stackage updates

On Mon, Jun 01, 2020 at 12:09:12PM -0700, Sean Whitton wrote: > If someone wants to work on updating ghc and Stackage in Debian unstable > we typically expect them to make package-plan pass for all packages > first before uploading anything, even to experimental. > > I wonder if we should instead

Re: lts 15.x

On Tue, May 26, 2020 at 11:55:34AM +, PICCA Frederic-Emmanuel wrote: > the other oslution is to upload ghc 8.8.3 into unstable and start to upload > all packages of lts 15.x This is the correct solution. Keep in mind that due to the change in haddock interface, sourceful uploads of all

Re: Haskell binnmus is there a problem?

On Mon, Sep 02, 2019 at 06:40:24PM +0200, Philipp Kern wrote: > I would prefer JSON as an input format, looking roughly like this: > > [{"pkg": "haskell-active", "ver": "0.2.0.13-6", "archs": ["mipsel", > "mips64el"], "suite": "sid", "reason": "semigroupoids changed from 5.2.2 to > 5.3.2"}]

Bug#927689: pandoc: Package newer version available upstream

On Sun, Apr 21, 2019 at 12:37:47PM +0200, Jonas Smedegaard wrote: > As soon as those libraries gets updated - which will happen at some > point _after_ Buster gets released - Pandoc will get updated too. It should be safe now (or when the mirrors update) to upload pandoc 2.5.

Re: Status of libghc-shake-dev

On Sun, Aug 25, 2019 at 04:07:47PM +, Dmitry Bogatov wrote: > So, what is the status? Are there any estimates on when transition will > complete? Maybe I should start rebuilding and uploading? Looks like someone will need to do something about https://hackage.haskell.org/package/js-dgtable

Re: Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

On Mon, Jul 22, 2019 at 01:57:55PM +0200, Mattia Rizzolo wrote: > I don't remember where this was discussed (quite in length actually), > probably debina-qa@ or debian-devel@. It was then implemented in > vcswatch (https://qa.debian.org/cgi-bin/vcswatch) and elsewhere. > I'm positive a result of

Re: Bug#930679: Please add overridable tag for not using dh sequencer

On Sat, Aug 03, 2019 at 07:36:23PM +0200, Mattia Rizzolo wrote: > Anyway, CCing d-haskell@ for input as well. I think it would be fine to switch to a resurrected-and-fixed or written-from-scratch replacement of dh-haskell, especially since cdbs seems to be bitrotting. Who's going to expend the

Re: Bug#933533: FTBFS on x32 (due to optimize-gmp=False): Variable not in scope: unsafeShiftL :: t -> Integer -> t

On Wed, Jul 31, 2019 at 10:29:56AM +0100, Laurence Parry wrote: > The issue appears to have been reported upstream as > "cborg fails to compile when optimize-gmp is disabled" > https://github.com/well-typed/cborg/issues/193 Patch applied, but I'm curious as to why optimize-gmp is False.

Re: Issues with yaml

On Tue, Oct 23, 2018 at 01:11:15AM +, Dmitry Bogatov wrote: > I have hard time to build yaml with ghc-8.4. As in state in > DHG_packages, it fails to build with linking error (attached) > > If I patch yaml.cabal to include 'ld-options: -lyaml', library builds > fine, build test suite fails

Re: test-packages.pl

On Tue, Sep 18, 2018 at 04:15:06PM +0300, kact...@gnu.org wrote: > Okay, I understand, you have another workflow. Could you please > reconfigure Jenkins to build not only master, but also another branches? > > This way I could try another (described above) implementation on > separate branch and

binNMUs.hs

Trying to get `binNMUs` more easily buildable by other people, I ran into a couple of issues: 1) Can we slap some licensing info on this thing? I'm assuming nobody besides Joachim and James have any reasonable copyright claim. 2) Even though GHC is happy to build the current source, cabal

Re: powerpc removed from unstable

On Mon, Jul 23, 2018 at 11:27:59PM +0200, Mikolaj Konarski wrote: > it says "Migrates after haskell-vector/amd64..." > so I thought it's waiting for the BinNMU to succeed. Is it? Take a look at https://release.debian.org/transitions/html/haskell.html Your problem might be that pandoc binNMU

Re: powerpc removed from unstable

On Mon, Jul 23, 2018 at 11:10:49PM +0200, Mikolaj Konarski wrote: > Is this (still?) stuck or just slow to rebuild? (honest newbie question) > > https://buildd.debian.org/status/package.php?p=haskell-vector Not sure what you mean. Are you referring to a particular architecture?

Re: Bug#904055: ghc: Please backport important fix for unregisterised compiler

Even better would be to registerise those architectures.

powerpc removed from unstable

https://people.debian.org/~nomeata/binNMUs-haskell.txt is choking; please rebuild the binary.

Re: Newbie needs help

On Thu, Jul 05, 2018 at 09:13:32AM +0200, Mikolaj Konarski wrote: > like in cabal-debian/debian/rules below? (I have literally no clue > what I'm doing) > > common-binary-arch:: check-ghc-stamp Probably. I see that line in cabal-debian and shellcheck at least. > BTW, >

Re: Newbie needs help

On Mon, Jul 02, 2018 at 05:33:26PM +0200, Mikolaj Konarski wrote: > Clint, thank you very much, it went very well, > except for "Removal request by pochu" in > https://tracker.debian.org/pkg/haskell-lambdahack > probably because haskell-lambdahack breaks the old > allure package. I've updated

Re: Hackage revisions and the current breakage of https://jenkins.debian.net/view/haskell/job/haskell-package-plan/

On Fri, Jun 22, 2018 at 05:36:52PM +0200, Mikolaj Konarski wrote: > 15:33 < dcoutts> mikolaj: yes, all revisions are in the "01" tarball > 15:33 < dcoutts> but if you unpack with standard 'tar' tools they only > unpack out the last one > 15:34 < dcoutts> if you use the Haskell 'tar' lib you can

Re: arm*/mips*/s390x woes

On Tue, Jun 19, 2018 at 08:21:44PM +0300, Ilias Tsitsimpis wrote: > For cryptohash-sha256 (#899166), it seems that ld.gold produces broken > code. I tried with ld.bfd and the tests pass. The reason why this used > to work with GHC v8.0 is because v8.0 uses ld.bfd on mips/mipsel whereas > v8.2 uses

arm*/mips*/s390x woes

We seem to be stalled on these two major blockers: hackage-security: broken on mips/mipsel - could be fixed via cryptohash-sha256 (#899166) or alternately patching to build with cryptohash or cryptonite? pandoc: broken on armhf (due to GHC bug?) and mips and s390x (via cmark-gfm being broken

Re: Newbie needs help

On Sat, Jun 09, 2018 at 10:52:08PM +0200, Mikolaj Konarski wrote: > With the momentum from packaging sdl2-ttf, I also packaged > enummapset, because it's the only (I hope) new package > (or new package versiona) needed for the upgrade > from lambdahack 0.7.1.0 to 0.8.1.1. > > Keep in mind I was

Re: Newbie needs help

On Fri, Jun 08, 2018 at 01:36:03PM +0200, Mikolaj Konarski wrote: > I'm a haskell-lambdahack maintainer and debian-haskell newbie > and I need help. Hi Mikolaj! Thanks for stepping up. What I've done is built the package with pbuilder, and run lintian on the resulting .changes file. One of the

Re: LTS 11?

Things that may need to be fixed or removed: aws 0.19 notest ignore # BROKEN: LTS 11: newer conduit debug-me 1.20170810 binary ignore # BROKEN: LTS 11: newer graphviz derive 2.6.3 ignore # BROKEN: LTS 11: newer haskell-src-exts esqueleto 2.5.3 ignore # BROKEN: LTS 11: newer persistent

Re: LTS 11?

On Mon, Apr 02, 2018 at 10:36:31AM -0400, Joachim Breitner wrote: > hmm, would it be too bad to remove Haskell on mips from testing during > the transition? This way the transition can happen in parallel to the > linker fix being implemented, and mips can catch up once they are > ready. > > Or

Re: LTS 11?

On Sun, Apr 01, 2018 at 09:52:52PM -0400, Joachim Breitner wrote: > I know that given that _could_ just do it myself, so it is a bit > hypocritical to send this mail to the list, but … well, you know how it > is. Anyways, is anyone here on the team going to tackle getting 8.2.2 > and LTS-11 into

Re: [Git][haskell-team/DHG_packages][master] Use salsa.debian.org URLs in Vcs-{Browser,Git} fields

On Fri, Feb 09, 2018 at 09:46:02PM +0200, Ilias Tsitsimpis wrote: > * Use anonscm rewrite map to redirect traffic to Salsa > * Update our wiki to point to the new VCS > * Update `haskell-package-plan` on Jenkins (merged) > * Update packages with new VCS information > * Submit PR to

alioth/salsa

Anyone want to project-manage the alioth->salsa move?

curry-base/curry-frontend on Hackage

Hello, Could you direct me to the right person to ask about why curry-base and curry-frontend 1.0.0 have not been uploaded to Hackage? Thanks

stack, propellor, yi, LTS 10, GHC 8.2.2

It looks like updating stack will require packaging more new dependencies (at least store and unicode-transforms, both already in package-plan). I'm fixing the propellor version in the package-plan. yi is blocked by packages still in NEW Stackage LTS 10 should appear soon. Should we wait for

Bug#881502: RM: haskell-hledger haskell-hledger-ui haskell-hledger-web [mips mipsel] -- ROM; unbuildable

Package: ftp.debian.org haskell-hledger indirectly depends on haskell-src-meta, which is unlikely to be built on mips and mipsel. Therefore please remove haskell-hledger and its reverse dependencies on mips and mipsel.

Re: Steps towards LTS 9

On Sun, Sep 03, 2017 at 07:29:53PM -0700, Sean Whitton wrote: > cryptonite-conduit > data-clist > here > uri-bytestring-aeson Looks like all of these have been done now.

Re: RFC: New Packages to bring yi up to the state in stackage

On Thu, Nov 02, 2017 at 11:49:18AM +0100, Marcel Fourné wrote: > Better late than never, I updated it after yi-core got through new and > did the unreleased ones likewise. I hope they will also get through NEW > in some time. Hmm, did you push your updates? > Newer versions of the packages

Re: Bug#876240: libghc-xmonad-contrib-dev: unmet dependency libghc-x11-xft-dev-0.3.1-c557c

On Wed, Sep 20, 2017 at 12:16:13AM +0200, Sacha Delanoue wrote: > I tried to install libghc-xmonad-contrib-dev by doing > `apt install libghc-xmonad-contrib-dev` on an up-to-date 9.1 Debian. > The install failed with the following information: > > The following packages have unmet dependencies: >

Re: Bug#868369: haskell-hs-bibutils: FTBFS against bibutils 6.0 (experimental)

> Is this something the pandoc-citeproc authors are aware of? Also we seem to now be broken in testing: /usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libbibutils.so: undefined reference to `progname'

Re: RFC: New Packages to bring yi up to the state in stackage

On Tue, Aug 15, 2017 at 08:36:58PM +0200, Marcel Fourné wrote: > With this I was not sure since upstream only does this as a group, but > I did it the way the other yi related packages are done. I think some of the copyright files still won't pass lintian checks.

Re: RFC: New Packages to bring yi up to the state in stackage

On Mon, Aug 14, 2017 at 04:12:48PM +0200, Marcel Fourné wrote: > Thanks, done! Some things you might want to tweak in the yi dependencies: a) debian/changelog should credit you, not the DHG b) debian/control can go to Standards-Version 4.0.1 c) debian/copyright needs some work

Re: Bug#869356: ghc: Eats gigabytes of memory when compiling haskell-skylighting

On Mon, Jul 31, 2017 at 05:44:54PM -0400, Jonas Smedegaard wrote: > Can we please have a newer release of Skylighting in Debian? There you go. I guess you're going to patch pandoc 1.19.2.1 to work with it?

Re: RFC: New Packages to bring yi up to the state in stackage

On Sat, Jul 29, 2017 at 02:59:41PM +0200, Marcel Fourné wrote: > As you may or may not have noticed, these are 8 ITPs I will file before > yi-0.13.7 has all it's dependencies in the Debian. No need for ITPs. > My problem: I don't have upload rights. > > Dear list, does anybody want to work

Re: Bug#869356: ghc: Eats gigabytes of memory when compiling haskell-skylighting

On Sat, Jul 22, 2017 at 10:45:22AM -0500, Samuel Thibault wrote: > Hello, > > As https://buildd.debian.org/status/package.php?p=haskell-skylighting > shows, haskell-skylighting fails to build on a lot of architectures, > from getting out of memory. I have indeed observed the RSS to be going >

Re: RFP - tidal

On Fri, Jul 21, 2017 at 03:52:41PM +0200, Alex McLean wrote: > Tidal 0.8.2 is rather old. I'm guessing updating this is just a matter > of waiting for stack 1.5.0 to be released? We're tracking Stackage LTS 8 until GHC 8.2 is released. Presumably LTS 9 will have tidal 0.9.4 and then we can

Re: Bug#860739: libghc-xcb-types-dev: cannot parse xcb-proto 1.12

On Sun, Apr 23, 2017 at 01:22:33PM +0100, James Cowgill wrote: > It looks like the xcffib dependency from cairocffi is optional, so this > would be a much easier solution. Otherwise we have to backport tons of > stuff or use upstream 0.5.1. So does this mean this is no longer a bug?

Re: RFP - tidal

On Wed, Jun 28, 2017 at 11:22:21PM +0100, Alex McLean wrote: > I'm really keen to get tidal into debian. Would that be possible? https://packages.debian.org/search?keywords=tidal

Re: Bug#868373: Build failed with sbuild and pdebuilder

On Sat, Jul 15, 2017 at 08:57:22AM +0200, Jörg Frings-Fürst wrote: > > $ sbuild > > debian/rules:4: /usr/share/cdbs/1/class/hlibrary.mk: No such file or > > directory > > make: *** No rule to make target '/usr/share/cdbs/1/class/hlibrary.mk'. > > Stop. > > E: Failed to clean source directory >

Re: Bug#868369: haskell-hs-bibutils: FTBFS against bibutils 6.0 (experimental)

On Fri, Jul 14, 2017 at 10:28:59PM -0300, David Bremner wrote: > I ran > > % sbuild -d experimental --build-dep-resolver=aptitude > --add-depends="libbibutils-dev (>=6.0)" haskell-hs-bibutils_5.5-5.dsc > > The build doesn't get very far > > , > | Running debian/hlibrary.setup build

Re: RFP - tidal

On Wed, Jun 28, 2017 at 11:22:21PM +0100, Alex McLean wrote: > I'm really keen to get tidal into debian. Would that be possible? > http://hackage.haskell.org/package/tidal I've uploaded hosc. If that gets through the NEW queue, all of tidal's dependencies will then be available and then we can

Re: Bug#865711: haskell-yaml: FTBFS everywhere (except all)

On Sat, Jun 24, 2017 at 03:34:35AM +0100, James Clarke wrote: > Hi, > haskell-yaml FTBFS on every architecture (except all) due to testsuite > failures: > > > Failures: > > > > test/Data/YamlSpec.hs:440: > > 1) Data.Yaml.Data.Yaml encode invalid numbers > >expected: ".\n" > >

Re: ghc 8.0.2 in unstable?

On Mon, Jun 19, 2017 at 08:19:05AM +, Gianfranco Costamagna wrote: > last thing: should we switch llvm? wrt #850915 I think the GHC 8.2 release candidates are targeting LLVM 4.0.

Re: ghc 8.0.2 in unstable?

On Sun, Jun 18, 2017 at 09:39:47AM +, Gianfranco Costamagna wrote: > Can I start the fun? Unfortunately I won't be able to binNMU stuff like > I did in Ubuntu, so somebody else needs to help me :) > > let me know if this sounds like a good plan :) Sure, then we can start tracking Stackage

Re: add skylighting to the package-plan

On Wed, May 17, 2017 at 10:22:18AM +0200, Félix Sipma wrote: > I'd like to add skylighting, which is required by the newer versions of patat, > to the package-plan. > > The tests seem to go well, but I noted that regex-pcre-builtin (which is a > dependency of skylighting) is explicitly set to

Re: haskell-parallel-tree-search_0.4.1-1_amd64.changes REJECTED

On Fri, May 05, 2017 at 04:41:12PM +, Mike Gabriel wrote: > is this sufficient? Yep, https://jenkins.debian.net/job/haskell-package-plan/changes

Re: haskell-parallel-tree-search_0.4.1-1_amd64.changes REJECTED

On Wed, May 03, 2017 at 07:26:01PM +, Mike Gabriel wrote: > Ouch! Fixing and re-uploading. Could you add this to the package-plan?

Re: doctest + libghc-lens-dev (and other debian haskell libs I guess, on ghc8/testing) = unhandled ELF relocation(RelA) type 42

On Sat, Dec 17, 2016 at 02:28:12AM +, Andreas Reuleaux wrote: > doctest: Could not on-demand load symbol > 'lenszm4zi14zm9dVzzUyOAXSjIX3UgJ3NnoU_ControlziLensziTH_makeLenses_closure' We'll need to rebuild doctest with ghc 8.0.1-17. If you want to ensure that the fix makes it into the

Re: Bug#847677: "unable to decommit memory" data loss

On Sat, Dec 10, 2016 at 11:24:26AM -0400, Joey Hess wrote: > It apparently then led to memory corruption, since git-annex created > some very bogus symlinks: > > lrwxrwxrwx 1 user user 338 Jun 17 22:36 > bup.git/objects/pack/pack-47b493a3bbbd22200d2b390c277e49ce713243cc.pack -> >

Re: Remove packages to allow migration

On Fri, Nov 25, 2016 at 07:38:51PM +, Clint Adams wrote: > I'm trying to reproduce this right now. xcffib build-depends on it, > so it's slightly more bothersome than the other two. Built fine on eller, no idea what the problem is, uploaded the binaries.

Re: Remove packages to allow migration

On Thu, Nov 24, 2016 at 10:53:14AM +0200, Ilias Tsitsimpis wrote: > * haskell-language-python[mipsel] > Build killed with signal TERM after 150 minutes of inactivity I'm trying to reproduce this right now. xcffib build-depends on it, so it's slightly more bothersome than the other two. >

Re: Bug#844323: (no subject)

On Mon, Nov 14, 2016 at 01:34:05PM -0200, Breno Leitao wrote: > reassign ghc > > After some further debug, I found this is, in fact, a ghc bug and it was > fixed in version 8.0.2, as showed in: > > https://ghc.haskell.org/trac/ghc/ticket/12621 Great!

ppc64(el) failure, haskell-zeromq4-haskell, Error: operand out of domain (2 is not a multiple of 4)

Hi Breno, It's unclear how to contact the ppc64el porters. Is there a mailing list? Something appears to have broken with GHC's PPC64 code generation. When trying to build haskell-zeromq4-haskell[0], we get /tmp/ghc8591_0/ghc_6.s:14471:0: error: Error: operand out of domain (2 is

Re: Bug#843791: ghc: builds fail on hurd-i386: /usr/bin/ld: -r and -pie may not be used together

On Thu, Nov 10, 2016 at 06:06:32AM +1100, Erik de Castro Lopo wrote: > > > [ 1 of 18] Compiling Data.Streaming.Zlib.Lowlevel ( > > > Data/Streaming/Zlib/Lowlevel.hs, > > > dist-ghc/build/Data/Streaming/Zlib/Lowlevel.o ) > > > ... > > > [18 of 18] Compiling Data.Streaming.Text (

Re: Bug#843791: ghc: builds fail on hurd-i386: /usr/bin/ld: -r and -pie may not be used together

On Wed, Nov 09, 2016 at 05:47:13PM +0100, Samuel Thibault wrote: > It seems the latest ghc has troubles building packages on hurd-i386: > > [ 1 of 18] Compiling Data.Streaming.Zlib.Lowlevel ( > Data/Streaming/Zlib/Lowlevel.hs, > dist-ghc/build/Data/Streaming/Zlib/Lowlevel.o ) > ... > [18 of 18]

Re: Bug#843487: haskell-xmlhtml: FTBFS from source on hppa - cc1: out of memory

On Sun, Nov 06, 2016 at 07:26:49PM -0500, John David Anglin wrote: > In the latter build, I tried the gcc options that allow haskell-src-exts > to build but this also failed. > > Package appears to need more than 4G of VM to build. What do you suggest?

Re: GHC 8 in stretch

On Mon, Oct 31, 2016 at 09:10:41PM +, Clint Adams wrote: > 2) ghc on mips and mipsel - RAM issue, I'm experimenting to see if we can > work around this; progress is slow May or may not be fixed in sid; in future this will be fixed in gcc itself. > 3

Re: GHC 8 in stretch

On Mon, Oct 31, 2016 at 09:10:41PM +, Clint Adams wrote: > 3) haskell-lambdabot-haskell-plugins - possible ghc bug, see #842740 P.S., other people can't reproduce this with straight ghc 8.0.1, for whatever that tells us.

Re: GHC 8 in stretch

On Wed, Oct 26, 2016 at 11:44:37PM +, Clint Adams wrote: > is patched to not FTBFS, and then any remaining issues can be fixed > in sid. Things still broken: 1) haskell-debian - ghc bug fixed by Ilias, pending upload after mips64el build completes (still going

GHC 8 in stretch

Given the PIE breakage in sid, I think at this point it's actually going to be a lot more work to stay with 7.10 in stretch than to go forward with the move to GHC 8. I also think we should do it as soon as possible so that packages outside the DHG (such as hedgewars-server, git-annex, pandoc)

Re: backports of haskell-concurrent-output

On Tue, Oct 25, 2016 at 09:29:28PM +, PICCA Frederic-Emmanuel wrote: > I would like to know what is the policy of the team for backports. > > in order to backport propellor it is necessary to backports > > haskell-concurrent-output > > >From you point of view what is the proper way to do a

other problems in experimental (hoogle, applicative-quoters)

hoogle: someone needs to figure out how to adapt add-local-location-database.patch to the new version or unbreak update-hoogle some other way applicative-quoters: this is dead upstream and I would suggest removing it but package-plan lists it as a "dep of structured-haskell-mode, by Thomas Koch"

Re: Which version of ghc will stretch have?

On Sun, Oct 23, 2016 at 04:24:12PM +, Clint Adams wrote: > Should we be doing -fno-PIE -fPIC instead? Or dropping -fno-PIE entirely?

Re: Which version of ghc will stretch have?

On Sun, Oct 23, 2016 at 03:00:04PM +, Clint Adams wrote: > That doesn't seem to have worked. Should we be doing -fno-PIE -fPIC instead?

Re: Which version of ghc will stretch have?

On Sun, Oct 23, 2016 at 01:44:03AM +0200, Iustin Pop wrote: > Ah, interesting, I didn't realise one could dig like that through the > dep chain. Looking at hledger-web -> libghc-yesod-static-dev -> > libghc-css-text-dev, which seems to fail with a quickcheck unittest > failure. Already reported

Re: Which version of ghc will stretch have?

On Sat, Oct 22, 2016 at 09:19:21PM +, Clint Adams wrote: > I think in the long run, we'll want all our objects build with -fPIC, so > adapting the OpenBSD patch seems like the right approach. That doesn't seem to have worked.

Re: Which version of ghc will stretch have?

On Sat, Oct 22, 2016 at 09:00:40PM +0200, Iustin Pop wrote: > Sorry for the late reply, but what does here "obsolete" and BROKEN mean? "obsolete" is a lie to keep test-packages.pl from freaking out, and BROKEN was just a note that work was needed. > > hledger-ui 0.27.5 binary obsolete # BROKEN -

Re: Which version of ghc will stretch have?

On Sat, Oct 22, 2016 at 09:17:43PM +0300, Ilias Tsitsimpis wrote: > If I add the `-fPIC' flag (i.e., cabal build --gcc-options='-fPIC') then > it works. I found a very similar upstream report[1] and a patch that > fixes it for OpenBSD[2]. Should we apply the same fix for Debian? > > Another

Re: Which version of ghc will stretch have?

On Thu, Oct 20, 2016 at 06:08:17PM +, Gianfranco Costamagna wrote: > Author: Gianfranco Costamagna > Date: Tue Sep 27 17:01:06 2016 +0200 > > Disable PIE, new patch from Balint Reczey Okay, just uploaded that to experimental.

Re: Which version of ghc will stretch have?

On Thu, Oct 20, 2016 at 05:39:06PM +, Gianfranco Costamagna wrote: > never had issues in that field in Ubuntu, I syncd ghc today (with the new > different > patch), but I don't foresee any haskell issue Everything is failing on i386 with /usr/bin/ld: -r and -pie may not be used together on

Re: Which version of ghc will stretch have?

On Thu, Oct 20, 2016 at 11:20:09AM -0400, Joachim Breitner wrote: > Am Donnerstag, den 20.10.2016, 16:53 +0300 schrieb Ilias Tsitsimpis: > > I think you are right. Joachim fixed a bug in haddock, where it would > > not respect the `--mathjax` option, but we still have to pass the above > > option

Re: shellcheck 0.4.4-2

On Wed, Oct 19, 2016 at 10:40:50AM +0200, Helmut Grohne wrote: > Indeed. I rebased my unpublished local commit and pushed it now. Thank > you for the poke. Great, I've uploaded 0.4.4-3 to experimental to see if it builds with GHC 8.

Re: Which version of ghc will stretch have?

On Wed, Oct 19, 2016 at 07:47:46AM +, Gianfranco Costamagna wrote: > 3) we need to patch ghc to work with llvm 3.8 and remove the armel stuff Not sure why this is a blocker and I don't particularly like the idea of losing git-annex on armel. > I will need help because I know *nothing* about

Re: Which version of ghc will stretch have?

On Fri, Oct 07, 2016 at 07:34:26PM +, Clint Adams wrote: > Things look a lot better now: So I actually think this is viable, with two main blockers: 1) Every -doc package generated by ghc 8.0.1-3 has lintian errors because of

shellcheck 0.4.4-2

Helmut, Did you make a commit and forget to push?

Re: Which version of ghc will stretch have?

On Wed, Oct 05, 2016 at 10:27:25AM -0400, Joachim Breitner wrote: > or we have to remove packages a bit more aggressively. Packages that > are still not compatible with 8.0 do likely not have an active enough > maintainer for our standards. Things look a lot better now: applicative-quoters

  1   2   3   >