Re: ghc will ever reach testing?

Da: Joachim Breitner nome...@debian.org A: Gianfranco Costamagna costamagnagianfra...@yahoo.it Cc: debian-haskell@lists.debian.org Inviato: Lunedì 15 Luglio 2013 22:44 Oggetto: Re: ghc will ever reach testing? Hi, Am Montag, den 15.07.2013, 17:18 +0100

Re: ghc will ever reach testing?

- Messaggio originale - Da: Joachim Breitner nome...@debian.org A: Gianfranco Costamagna costamagnagianfra...@yahoo.it Cc: debian-haskell@lists.debian.org debian-haskell@lists.debian.org Inviato: Martedì 16 Luglio 2013 11:08 Oggetto: Re: ghc will ever reach testing? Hi, Am

Re: ghc will ever reach testing?

. Attached the debian patch. (sorry, but I never used darks) Gianfranco From: Gianfranco Costamagna costamagnagianfra...@yahoo.it Date: Wed, 31 Jul 2013 09:51:49 +0200 Subject: [PATCH] Fixed bug #711948 and maybe #712228 ---  changelog | 10 ++  control   | 14 +++---  rules |  9

Re: GHC lintian warnings and testing migration

- Messaggio originale - Da: Joachim Breitner nome...@debian.org A: Gianfranco Costamagna costamagnagianfra...@yahoo.it Cc: debian-haskell@lists.debian.org Inviato: Mercoledì 28 Agosto 2013 15:35 Oggetto: Re: GHC lintian warnings and testing migration Hi Gianfranco, Am Mittwoch

Re: Re: Mentoring a haskell port

Hi Wookey, the great Colin Watson has already done a whole great job in this! https://lists.debian.org/debian-haskell/2014/04/msg0.html I think you will find interesting his work, it is for 7.8 but I think with some backports can be done with ghc 7.6 too... Did you already saw the work?

Re: Re: Mentoring a haskell port

I wish to have access to a real hardware for helping Colin in this taks, but I cannot help you, maybe asking and syncing with him can help you both :D have a nice weekend to all, Gianfranco Il Venerdì 4 Aprile 2014 16:42, Wookey woo...@wookware.org ha scritto: +++ Gianfranco Costamagna

Re: tools and all-packages moved to git

Il Martedì 15 Aprile 2014 9:06, Joachim Breitner nome...@debian.org ha scritto: Hi, Am Dienstag, den 15.04.2014, 07:02 +0100 schrieb costamagnagianfra...@yahoo.it: Hi Joachim, sory but I missed why you should login and logout from ssh at each new repository. Can't you just put

Re: Patches for armhf and armel (ghc 7.8* series)?

Hi Joachim, Il Martedì 6 Maggio 2014 23:49, Joachim Breitner nome...@debian.org ha scritto: Dear Gianfranco, Am Dienstag, den 06.05.2014, 14:38 +0100 schrieb Gianfranco Costamagna: I remember a while ago in some discussion you pointed out that without people working on arm* platforms

Re: hgettext not migrating without reason.

Hi Sven Il Lunedì 18 Agosto 2014 18:53, Sven Bartscher sven.bartsc...@weltraumschlangen.de ha scritto: On Mon, 18 Aug 2014 16:03:56 +0200 Joachim Breitner nome...@debian.org wrote: Hi, Am Montag, den 18.08.2014, 15:18 +0200 schrieb Sven Bartscher: it would be great if it

Re: Bug#763078: confirmed llvm change broke ghc

Hi Joey, llvm maintainer (Sylvestre) says that llvm-3.4 is going to disappear (not before jessie, but somewhen after), and llvm-3.5 is built correctly on arm{el,hf}. Isn't it better to just upload with llvm-3.5 and do some binNMUs instead of using the old one and be hit (or be a blocker) for

Re: Moving to experimental?

Hi joachim, as fair as I remember when I upload something on experimental it is built with unstable b-d (look at logs, the startup doesn't pick up experimental packages). Doesn't hard coding 7.8 in packages makes them just bd-uninstallable? did I miss something? cheers, Gianfranco Sent from

Re: Packaging a library from a subdirectory

Hi Benjamin, I presume you already tried something like dh $@--sourcedirectory=your-source I think the best solution usually is to package the library separately from the other code, because other people might find it useful too. sorry if the answe isn't haskell oriented :-) cheers, G.

llvm-3.4 is not the default llvm-dev

Hi Joachim and all Haskell group. Since we are in the early Stretch release, I propose to change - llvm-3.4 [armel armhf], + llvm-3.4 [arm64 armel armhf],into llvm-3.5, since it is the default on unstable/testing right now (or maybe even llvm-3.6, I guess it will be uploaded shortly on

Re: Next steps to a sane state

Hi Joachim, in order to see ghc in testing I see some blockers: - #783891 (is that fixed in the -4 upload?) - broken Build-Depends: ghc-testsuite: ghc-dynamic this one seems that should be updated, in order to decruft ghc (I think I can help if needed, just I don't know this testsuite where

Re: Next steps to a sane state

Hi Joachim, probably the bugtracker is confused by the strange version sequence that I had to use to fix my mistake in experimental. I just closed the bug now. oh yes, the versioning in experimental should have confused it for sure. Maybe we should ping ftpmasters to remove the experimental

Re: Next steps to a sane state

Hi again Joachim, I updated the testsuite for 7.8.4 http://mentors.debian.net/package/ghc-testsuite It builds it correctly on both amd64 and i386 Sum of the changes: * Team upload * Conflict with ghc 7.8.4 * New upstream release * Bump std-version to 3.9.6, no changes * Remove ghc-dynamic

Re: Next steps to a sane state

great. Any reason you did not simply push to darcs.debian.org/pkg-haskell/ghc-testsuite? is I hate everything that isn't git a valid reason? :) I had this problem when I fixed the ghc lintian stuff one year ago, and we had a couple of mails where you told me how to fix it, but I changed my

Re: Next steps to a sane state

quite right; building a new package right now. Maybe it also fixes the build failures on arm: https://buildd.debian.org/status/package.php?p=ghcsuite=experimental Yes, I hope so :) BTW the last blocker for ghc in testing seems to be ghc-testsuite, at least according to the decruft-daily [1]

Re: Next steps to a sane state

the last blocker... besides everything in https://people.debian.org/~nomeata/binNMUs-haskell-amd64.txt Remember that GHC cannot migrate without all Haskell packages! of course, I can help with the decruft, not being a DD and not understanding haskell makes it difficult to help with the NMUs

Re: Next steps to a sane state

Hi Joachim, I believe it is, but the bug is about upgrading to experimental, which is irrelevant for the testing migration. I don't think so grep-excuses ghc ghc (7.6.3-21 to 7.8.4-4) Maintainer: Debian Haskell Group 6 days old (needed 5 days) old binaries left on amd64: ghc-dynamic (from

Re: Next steps to a sane state

Hi Joachim, no need, I’m buliding 7.10 right now, when that is uploaded to experimental the version sequence is history. seems that you forgot to use the right llvm, did you? -llvm-3.4 [arm64 armel armhf], -llvm-3.5 [arm64 armel armhf], this way you can close 784245 at least for experimental

Re: Next steps to a sane state

I’m sure this will come up again next DebConf, when the Haskell Group meets, as you are not the online one. Are you going to be there? I'll try to be at least online, last time I had some problems in attending (don't remember if it was a timezone problem, or something else) :) I tried to

Re: Next steps to a sane state

changes pushed :) thanks! G. Il Mercoledì 13 Maggio 2015 16:06, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: Bad me, the Debian host key change of months ago triggered that problem Host svn.debian.org git.debian.org bzr.debian.org hg.debian.org darcs.debian.org

Re: Next steps to a sane state

, Joachim Breitner nome...@debian.org ha scritto: Hi, Am Mittwoch, den 13.05.2015, 11:50 + schrieb Gianfranco Costamagna: I tried to debcheckout or darcs get it, but I fail darcs get darcs.debian.org:/darcs/pkg-haskell/ghc-testsuite I did an ssh git.debian.org and files are there, I also

Re: Next steps to a sane state

Hi Joachim and haskell folks since the ghc/7.10 on experimental is building fine I looked at the build failure on arm64. Googling around brings me to [1], a dupe of [2] with a patch on [3], looking at the sources seems that part of the patch is applied, but another part isn't (at least

Re: Next steps to a sane state

Donnerstag, den 14.05.2015, 21:03 + schrieb Gianfranco Costamagna: since the ghc/7.10 on experimental is building fine I looked at the build failure on arm64. Googling around brings me to [1], a dupe of [2] with a patch on [3], looking at the sources seems that part of the patch is applied

Re: Focusing our efforts: Key packages

Hi Joachim, I'm not sure I followed what you wrote. Then, the following packages should be in Debian: * Key packages, * their dependencies, * and all packages that were previously in Debian and are also part of stackage (as I expect that these incur very little extra overhead). sounds

Re: Focusing our efforts: Key packages

22.06.2015, 16:13 + schrieb Gianfranco Costamagna: (ok, so my question wasn't so dumb (yeah! I still do not understand the whole haskell stuff, but I need it for hedgewars, so I try to care and fix whatever I can) I guess I sometimes assume you do because I stop reading your name too early

Re: followup to irc conversation about building 7.8 with 7.6

Hi Joachim and Peter, I’ve seen this before, but because I always build with sbuild, it did not itch me too much so far. Patches welcome. If anyone feels like cleaning stuff up; ghc’s debian/rules is quite convoluted and could use some re-thinking. But again, not a high priority, at least for me.

Re: followup to irc conversation about building 7.8 with 7.6

packaging (experimental) I'm testing the builds right now :) cheers, G.From 2b743035588ef9ac342b98e59dceaa4a2133cec2 Mon Sep 17 00:00:00 2001 From: Gianfranco Costamagna costamagnagianfra...@yahoo.it Date: Sat, 27 Jun 2015 13:35:08 +0200 Subject: [PATCH 1/3] Wrap and sort --- debian/control | 86

Re: Best VCS layout for our packages?

Hi Joachim, you wrote: It is not possible to check out just one package. But maybe        that is a good thing, for such a tightly coupled package set. http://stackoverflow.com/questions/600079/is-there-any-way-to-clone-a-git-repositorys-sub-directory-only with git 1.7 and sparse checkout

Re: [Pkg-haskell-commits] darcs: gitit: Use system JS

Hi Dmitry, I might be wrong, but I remember this approach might work only on newer releases. I recall I did something similar for libsdl2-gfx (IIRC) and I had to lower the version in d/changelog, to allow uscan find a newer release. can you please double check? (copyright from sdl and

Re: Refactor ghc rules file

, Gianfranco From 2b743035588ef9ac342b98e59dceaa4a2133cec2 Mon Sep 17 00:00:00 2001 From: Gianfranco Costamagna costamagnagianfra...@yahoo.it Date: Sat, 27 Jun 2015 13:35:08 +0200 Subject: [PATCH 1/3] Wrap and sort --- debian/control | 86 ++-- debian

R: 710 packages in 2,5h

Hi Joachim -- Il mer 19 ago 2015 22:32 CEST, Joachim Breitner ha scritto: Hi, on the powerful machine that Geert Stappers provided us we can rebuild all of our packages (master branch) in less than 2½h: real144m49.133s user756m16.224s sys 156m37.084s

Re: Darcs repositories decommissioned

I think we could solve that problem, by still having separate git repositories for each package and bundling them all up into one through submodules. This would still have the advantage of having all packages together, but still allow to checkout a package alone. I don’t have much experience

Re: Continuing the transition

Hi Sven, >I just started with way 1 and marked some packages for upload, that >were rejected because of missing uploaders fields. Could someone please >upload them (btw my nm process is still going or rather stalling...)? >When these are uploaded, we should wait until they are built (check

Re: Packaging my first haskell package

Hi Andreas, I'm not an haskell man, but haskell is in a "permanent transition" state. Particularly, some days ago, ghc 7.10 reached unstable, and now a lot of packages needs binNMU and source uploads (from experimental mainly), to make things settle down again. this will take a lot of time

Re: Packaging my first haskell package

Hi >At this point, the only things I'm aware of needing sourcewise work >are ghc-mod and ghc-testsuite. I think I can do the testsuite :) cheers, G.

Re: ghc-mod and haskell-cabal-helper

Hi, >I recently prepared new uploads for haskell-cabal-helper and ghc-mod. >As I'm still in the NM process and not DD yet, could someone please >review/upload them? >Thanks! > I did build and upload haskell-cabal-helper on delayed/2 and ghc-mod on delayed/3. Please don't shoot at me if I did

Re: ghc-mod and haskell-cabal-helper

Hi, >Joachim actually didn't upload ghc-mod and haskell-cabal-helper, >because there are a lot of tags missing in the repository, but you >couldn't know that, as we discussed it on IRC. >Since the tag problem was solved earlier today, I don't see any reason >to shoot at you. :) (I know delayed

Re: LTS-6 status

Hi, >DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags --get CFLAGS >-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security In case of ghc the harderning flags are turned off https://sources.debian.net/src/ghc/7.10.3-9/debian/rules/ and yes, I'm going to commit that in

VCS-GIT fields wrong?

Hi, I noticed some vcs-* were wrong, because they contained cgit and moreover some VCS-darcs were still around. I should have changed all of them to be the same url, in the experimental branch. Can anybody please check and review? this is the first time I script some sed stuff like this with

Re: VCS-GIT fields wrong?

..@debian.org> ha scritto: Hi, didn’t review yet, but this might make merging from master difficult. Can you merge master into experimental first? Thanks, Joachim Am Donnerstag, den 02.06.2016, 13:40 + schrieb Gianfranco Costamagna: > Hi, I noticed some vcs-* were wrong, because

Re: LTS-6 status

Hi, >if you think so, then simply commit it to the repo (experimental >branch). I would like to avoid that, without any other opinions on the matter. I can do and I did it for my packages, I don't know too much haskell and the pie stuff. Probably experimental might be a good place to test, but

Re: haskell-open-browser_0.2.1.0-1_amd64.changes REJECTED

Hi it seems another one failed the upload  https://lists.alioth.debian.org/pipermail/pkg-haskell-maintainers/2016-June/041998.html G. Sent from Yahoo Mail on Android On Wed, 1 Jun, 2016 at 19:41, Sven Bartscher wrote: On Wed, 01 Jun 2016 16:47:21

Re: LTS-6 status

Hi, before uploading the new ghc on unstable (if I read correctly LTS-6 requires GHC-8, right?) could you please check if the Ubuntu delta can be added to the Debian packaging? https://patches.ubuntu.com/g/ghc/ghc_7.10.3-7ubuntu1.patch thanks G. Il Mercoledì 1 Giugno 2016 15:38, Joachim

Re: LTS-6 status

Hi, >no, LTS-6 is GHC-7; LTS-7 will be GHC-8. We upload LTS-6 now, get it >into testing (which will require manual intervention for mueval and >lambdabot - any volunteers?) and then look into getting ghc-8 into >unstable, together with LTS-7. indeed, I found it out just after clicking enter

Re: sid uninstallble package

Hi, https://packages.qa.debian.org/h/haskell-memory.html [2016-01-10] Accepted 0.10-1 in unstable (medium) (Clint Adams) I guess it has been uploaded this morning :) (also committed on git) cheers, G. Il Domenica 10 Gennaio 2016 13:21, Dmitry Bogatov ha scritto: In

Re: GHC-8.0 and llvm

Hi Looking at it was on my to-do list Anyway llvm 3.7 should be in unstable and testing https://packages.qa.debian.org/l/llvm-toolchain-3.7.html Cheers G. Sent from Yahoo Mail on Android On Mon, 18 Jan, 2016 at 9:26, Joachim Breitner wrote: Hi, I have uploaded

Re: Encouraging stackage (Re: Several Pending Autoremovals)

Hi >I took your packages-not-in-stackage list and tried to fill the gaps >scraping hackage; I attach the result, I hope it is useful. Note that >`yesod-init-test` and `hedgewars-server` are missing from the list >because they are not present in hackage unC0Rr, how do you feel about adding

Re: mips64el binNMUs?

probably the right script is this one http://anonscm.debian.org/cgit/pkg-haskell/tools.git/tree/binNMUs.hs :) g. Il Mercoledì 16 Marzo 2016 20:19, Gianfranco Costamagna <costamagnagianfra...@yahoo.it> ha scritto: Hi, quoting -haskell on irc: [20:08:13] who's usually doing the b

Re: Several Pending Autoremovals

Hi, git clone git+ssh://git.debian.org/git/pkg-haskell/DHG_packages.git cat .ssh/config Host svn.debian.org git.debian.org bzr.debian.org hg.debian.org darcs.debian.org arch.debian.org User blah-guest so you should be able to clone them without having to manually put the user steps to add

Re: DEB_ENABLE_HOOGLE

Hi, >Codesearch is your friend: > > https://codesearch.debian.net/search?q=DEB_ENABLE_HOOGLE > >Nope, only defined, not used anywhere in Debian currently. it might be used in experimental, AFAIK codesearch has only an index for unstable. (but yeah, you are probably right!) G.

Re: Introduction

Hi Sean, >I've been lurking around here for a while, but yesterday I found that I >wanted to update the hlint packaging, so I submitted a request to join >the team, which has been approved. So just a quick e-mail to introduce >myself. I've been trying to learn Haskell for the past two years and

I: Running binNMU on wuiet

libraries reach testing in the permanent transition. FWIW I just started doing the transition in Ubuntu some days ago. cheers, Gianfranco Il Mercoledì 10 Agosto 2016 18:01, Joachim Breitner <nome...@debian.org> ha scritto: Hi, Am Montag, den 08.08.2016, 15:01 + schrieb Gianfranco Cost

Re: Missing correct version of libghc-enclosed-exceptions-dev and libghc-enclosed-exceptions-dev on debian unstable

Hi, >enclosed-exceptions's cabal file claims compatibility with lifted-base >0.2.3.8, so we just need to binNMU enclosed-exceptions, right? I think you are right, a lot of binNMUs of the above two packages are also shown here https://people.debian.org/~nomeata/binNMUs-haskell.txt G.

Re: Running binNMU on wuiet

Hi Joachim! >$ ./binNMUs --sql | tee binNMUs.txt| grep . | grep -v ^# > >reviewing the output (but I barely glance over it now, the system seems >to work reliabled) and then running > >$ wb < binNMUs.txt I'm doing right now (since few days) the rebuilds in Ubuntu, so far things are going

Re: GHC 8.0.2

Hello >That's a pretty weird error. > > >I assume the package builds fine if you disable the docs? yes I opened an haddock upstream bug report G.

Re: GHC 8.0.2

Hello, >* haskell-secret-sharing (haddock fails with): > > haddock: internal error: renameType: HsSpliceTy > CallStack (from HasCallStack): >error, called at > utils/haddock/haddock-api/src/Haddock/Interface/Rename.hs:266:30 in > main:Haddock.Interface.Rename I got this on zesty/amd64

Re: GHC 8.0.2

Hello, >I added this on d/rules (just like suggested by the error message): > > DEB_SETUP_GHC_CONFIGURE_ARGS += '--ghc-options="-fsimpl-tick-factor=1000"' this did the trick! Now I got some new packages: agda -> new directory and part of this patch:

Re: GHC 8.0.2

sim...@gmail.com> ha scritto: Hi again! On Fri, Jan 27, 2017 at 08:22AM, Gianfranco Costamagna wrote: > Now I got some new packages: > > haskell-shake ->> needs this patch: > https://github.com/ndmitchell/shake/commit/9ccc022e5b02343ac48ce1d4245c9082f6ab86ef.patch I opted for h

Re: GHC 8.0.2

Ilias, all, >I'm afraid this will have to wait for buster. No way we do a full >haskell>transition at this stage. maybe we can go for experimental? G.

Re: GHC 8.0.2

Hello, >How is this going to work? We would have to upload every Haskell package >in experimental, right? Or are you referring just to ghc? probably all :/ (not worth the effort I think) G.

Re: GHC 8.0.2

Hello! >haskell-dependent-sum (FTBFS) >haskell-cabal (newer directory) >hasktags (newer directory) >haskell-filestore (newer directory) >haskell-snap-templates (newer directory) >haskell-vector-algorithms (FTBFS) >haskell-concurrent-output (newer directory) > >Up until now, I have not updated

Re: GHC 8.0.2

Hello, >I think I'll upload on Ubuntu and see what happens :) a lot of red, will start binNMUing as soon as the build is finished http://people.canonical.com/~ubuntu-archive/transitions/ghc.html G.

Re: Fix: cabal-debian 4.33-4 cannot detect GHC built-in packages correctly

Hello, >Yes, I would like to fix these issues for stretch. I'm not quite sure what >this output means, though. Could you explain what you expected to see and >what you are >actually seeing, and how I can reproduce the error? The latest version has been uploaded in Debian some hours ago,

Re: GHC 8.0.2

Hello Joachim, >I guess we want GHC-8.0.2 in unstable, and hopefully in stretch – or is >there a reason not to do that? quoting upstream [1] "Compatibility fixes with macOS Sierra and recent Linux distributions. Many, many bug fixes. A bug has been fixed that caused standalone derived Ix

Re: GHC 8.0.2

Hi, >this looks good. Did any libraries with GHC got their version bumped in >a way that requires changing the .cabal file in any of our other >libraries? I don't know how to test that, sorry >I am not following things too closely these days, but the changelog >looks good :-) actually I did

Re: Which version of ghc will stretch have?

Hi, >I wonder if its not time for Debian to ship more than one major version >of the compiler? Personally I like to have at least the last there major >releases of GHC on all me development machine. wouldn't this mean forcing a version while building each package, and making mistakes when

Re: Which version of ghc will stretch have?

Hi, >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. > >This in in particular has been fixed. > >We should at least start staging in the repo and/or experimental (but >it is

Re: GHC 8 in stretch

Hi, >outside the DHG (such as hedgewars-server, git-annex, pandoc) have hedgewars-server is fixed in git, no issues from my side >Any objections? None from my side :) We have 3 months to fix stuff, having ghc 8 might be really nice :) G.

Re: Which version of ghc will stretch have?

Hi, 3) we need to patch ghc to work with llvm 3.8 and remove the armel stuff I can do that. >1) Every -doc package generated by ghc 8.0.1-3 has lintian errors > because of

Re: Which version of ghc will stretch have?

Hi, >Great. Are we also going to need to modify haskell-devscripts to undo >this PIE breakage, or is that going to be a ghc-only fix? 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 G.

Re: Which version of ghc will stretch have?

Hi, >Which patch are we talking about? commit 3354959ffaddb30572e3609841f20a26859323ff Author: Gianfranco Costamagna <costamagnagianfra...@yahoo.it> Date: Tue Sep 27 17:01:06 2016 +0200 Disable PIE, new patch from Balint Reczey G.

Re: newer cabal-install (1.24) in sid, please

Hi >ghc8 having entered unstable/sid - thanks a lot to everyone >involved in this effort - it is barely usable for me as is, >as I get error messages of my cabal being too old. > >ghc8 seems to require cabal-install 1.24, not 1.22, as I understand, >thus it would be nice if this could be

Re: haskell-hoogle is marked for autoremoval from testing

Hello, >> haskell-hoogle is still broken BTW> >Could you elaborate on this? It passes the CI tests[1] and works for me >as well. > >[1] https://ci.debian.net/packages/h/haskell-hoogle/ from PTS Version 5.0.1+dfsg1-2 of haskell-hoogle is marked for autoremoval from testing on 2017-01-29. It

Re: haskell-hoogle is marked for autoremoval from testing

Hi >This should be fixed once libjs-chosen v0.9.15-2 migrates to testing, right? my bad, you are probably right, it isn't a direct dependency! (my d.org address have been rejected by the remote mail handler) G.

Re: haskell-hoogle is marked for autoremoval from testing

Hello, >Happy new year! you too! >It appears that node-temp (on which libjs-chosen build depends) is >broken as well, and marked for autoremoval from testing [#834915]. > >I modified the Made-compression-work-with-uglify-js2 patch to not use >node-temp, and uploaded it on mentors[1]. Could you

Re: haskell-hoogle is marked for autoremoval from testing

Hello again >sigh, done! haskell-hoogle is still broken BTW G.

Re: haskell-hoogle is marked for autoremoval from testing

Hi, I'm sponsoring after committing the work and doing some more changes, * fix copyright years * Move to team upload * compat=10 * Fix vcs fields thanks! https://anonscm.debian.org/git/pkg-javascript/libjs-chosen.git/ G. Il Lunedì 19 Dicembre 2016 10:45, Ilias Tsitsimpis

Re: haskell-hoogle is marked for autoremoval from testing

Thanks to you for fixing! G. Sent from Yahoo Mail on Android On Mon, 19 Dec, 2016 at 16:39, Ilias Tsitsimpis<i.tsitsim...@gmail.com> wrote: Hi Gianfranco, On Mon, Dec 19, 2016 at 03:30PM, Gianfranco Costamagna wrote: > Hi, I'm sponsoring after committing the work and doing

Re: ungrade pandoc

Hello Jonas >I have a newer Pandoc prepared, but cannot upload it until dependencies >are co-installable - e.g. libghc-aeson-dev and libghc-yaml-dev. well, you can always upload and make it go in dep-wait, but yeah, aeson is fixed at least on 50% of the architectures, and yaml will be fixed in

Re: ungrade pandoc

Hello, >dep-wait? Where is that documented so I can learn more? source uploading the package, will make it go in the "build-dependencies unsatisfied state" and be processed automatically when they start building again I think buildd page shows them as "BD-Uninstallable". You can test it

Re: ungrade pandoc

Hello, >I guess "dht build-all" downloads sources not yet in debian and builds >all build-dependencies as unofficial packages locally. No, I find that >to be cheating: I will upload source-only package when I have >succesfully built in a purely Debian unstable envirenment. > >Also, I find it

Re: ungrade pandoc

>Seems you agree with me that only real gain is timing. > >If your point(s) was/were _other_ benefits than timing then please >elaborate (because then I missed them). hello, I agree with you, timing is the real gain here! (one day we will probably have some sort of automatic rebuild system for

Re: libghc-skylighting-dev on amd64

Hello, >Is there a reason why libghc-skylighting-dev is not available on amd64? it has been uploaded in new queue, probably with some missing binaries https://lists.alioth.debian.org/pipermail/pkg-haskell-maintainers/2017-July/051716.html seems to show that only one amd64 binary has been

Re: Bug#850915: ghc: Please switch to llvm 3.8 or, better, 3.9

Hello, >Now that we shipped strech, I really would like to see llvm 3.7 removed. >Can we go ahead now ? as said, with ghc 8.0.1 and 8.0.2 this seems a little impossible, but as Clint said on debian-haskell >> last thing: should we switch llvm? wrt #850915 >I think the GHC 8.2 release

Re: ghc 8.0.2 in unstable?

Hello, >Sure, then we can start tracking Stackage LTS 8. I'm not really sure about the implications and how to do it, but I guess I'll get some help :) Uploaded in deferred/15 and committed on git. last thing: should we switch llvm? wrt #850915 G.

ghc 8.0.2 in unstable?

Hello, with Stretch released, I guess it is time to do some haskell fun :) The work has been already done in Ubuntu, so it should be just a matter of ~10-15 sourceful uploads and a lot of binNMUs as usual. Can I start the fun? Unfortunately I won't be able to binNMU stuff like I did in Ubuntu,

Re: GHC Android Cross-compiler

Hello, >As some of you may have heard, we are writing Haskell games targeting >iOS and Android. >Depending on where it's running (debian, other linux, mac), and the >target, we use a different setup: we can install GHC+Cabal+base with a >Deb (currently, from our own archive), unpack from a

Re: Midimory to Debian

Hello, >People keep asking me to play that game on their machines (without knowing >about Haskell or GHC). Thus my question: What can I do to get it, e.g. >into Debian? >As far as I know, precondition for inclusion in Debian-Haskell is that all >imported packages must be in Debian, too.

Re: [DHG_packages] 01/01: haskell-x11: add xss to -dev package, to fix build of x11-xft

im Am Dienstag, den 26.12.2017, 21:02 + schrieb Gianfranco Costamagna: > This is an automated email from the git hooks/post-receive script. > > locutusofborg pushed a commit to branch master > in repository DHG_packages. > > commit de45c9abe0f5e21b6bd81fd7b2dfcfa8564c4

Re: Bug#892004: Please adapt to gnome-settings-daemon 3.28 by March 15

hello, >I am unable to do something this week. Could someone else apply the >change and upload the package? in deferred/2 G.

R: Re: Including Yampa

Hello, you need to become a Debian Maintainer only if you need to upload your package without a sponsor. If you want to look for a sponsor each time you want to upload to unstable a new revision, you don't need to declare anything... But sponsorship process might take long time due to the lack

mediawiki2latex

Hello, you can just upload whenever you wantthe package is already waiting for testing migration, so I guess there is no harm in uploading a new version G. Il sabato 31 agosto 2019, 12:01:14 CEST, Dirk Hünniger ha scritto: Hi, I am the maintainer of mediawiki2latex. I got two weeks

Re: mediawiki2latex

will be unbuildable on these architectures. So if there is any way I can support this part of the project just let me know. Yours Dirk On 9/4/19 12:28 PM, Gianfranco Costamagna wrote: Hello, you can just upload whenever you want the package is already waiting for testing migration, so I

binNMU wanted please

Hello, after my ghc 8.8.1 upload targeted to the wrong suite (sorry for that!)I tried to quickly rebootstrap ghc and I went successful, for amd64 all i386 arm64 and ppc64el IIRC. Unfortunately armhf escaped from my jail, and went built successfully, and the build I did failed, when I retried

Re: binNMU wanted please

Hello, I went to coccia, looked at daklog, and grepped all the armhf uploads since 11 of september, then cutted the ACCEPT message, and stripped down the non binNMUed version attached the list. If you schedule them, please ping me and I'll take care of what is bd-failed state, with some

Re: binNMU wanted please

thanks you both! yes, my list had double packages (I'm pretty sure nmu will disregard duplicated lines),and most important, some binNMUs on armhf scheduled after 11 of septembers were already good, because they picked up the "good" ghc and didn't depend on anything that picked up the bad one.

Re: binNMU wanted please

-prof" changes) G. Il sabato 21 settembre 2019, 10:30:10 CEST, Gianfranco Costamagna ha scritto: thanks you both! yes, my list had double packages (I'm pretty sure nmu will disregard duplicated lines),and most important, some binNMUs on armhf scheduled after 11 of septembers were al

  1   2   >