[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ghc now almost ready for migration



On 06/06/2011 23:22, Joachim Breitner wrote:
> 
> highlighting-kate is one of the big beasts that tend to fail on weaker
> arches; on some of them it works with some buildds and not others.
> Should I
>  * give back the package once or twice to find out if there is a strong
> buildd or
>  * should I request removal of the out-dated packages (and depending
> packages) on these arches, to allow for the transition to happen?
> 

You can try that. option 1, and then option 2, if the first one doesn't work.

>> - haskell-hsql-mysql needs mysql-5.1… which is not going to migrate soonish.
> 
> Ah, hmm. Should we then postbone the haskell transition and keep
> updating stuff (e.g. the just released new ghc)? Or will you force-hint
> haskell-hsql-mysql with a subsequent binNMU in testing to fix the
> package there? Or do you want to remove the package in testing (seems
> like it, given the hint file)?
> 

Nothing depends on haskell-hsql-mysql, afaics. So, why should we postpone
the haskell transition for it? I think (and that's what I was going to do)
that temporarily removing it from testing is our best option here.

>> - haskell-leksah-server is ood on mips (needs haskell-haddock).
> 
> haskell-haddock fails with error 9, sounds like OOM killed or timed out
> or something related. I’ll ask mips@buildd.debian.org if they have a
> timeout or something.
> 

Ok.

>> - haskell-pretty-show is ood on mips/mipsel (needs haskell-lexer).
> 
> OOM for haskell-lexer. I guess we have to remove it from these arches.
> 

It's up to you.

> 
>> If we try to migrate the whole of haskell stuff (without haskell-dummy),
>> britney fails with the following:
>>
>> endloop: 87+0: i-1:a-0:a-0:i-0:k-43:k-43:m-0:m-0:p-0:s-0:s-0
>>     now: 134+0: i-33:a-3:a-1:i-0:k-46:k-46:m-1:m-1:p-1:s-1:s-1
>>     * i386: configfile-doc, ftphs-doc, gitit, haskell-agda-doc,
>> haskell-convertible-doc, haskell-cpphs-doc, haskell-edison-api-doc,
>> haskell-edison-core-doc, haskell-haskelldb-doc, haskell-hdbc-doc,
>> haskell-hdbc-odbc-doc, haskell-hdbc-postgresql-doc,
>> haskell-hdbc-sqlite3-doc, haskell-hscurses-doc, haskell-hsql-doc,
>> haskell-hsql-mysql-doc, haskell-hsql-odbc-doc,
>> haskell-hsql-postgresql-doc, haskell-hsql-sqlite3-doc, haskell-http-doc,
>> haskell-pcre-light-doc, haskell-regex-base-doc, haskell-regex-compat-doc,
>> haskell-regex-posix-doc, haskell-src-exts-doc, haskell-uulib-doc,
>> haskell-zlib-doc, ldap-haskell-doc, libghc6-gitit-dev, libghc6-pandoc-dev,
>> magic-haskell-doc, missingh-doc
>>     * amd64: gitit, libghc6-gitit-dev, libghc6-pandoc-dev
>>     * armel: libghc6-pandoc-dev
>>     * kfreebsd-amd64: gitit, libghc6-gitit-dev, libghc6-pandoc-dev
>>     * kfreebsd-i386: gitit, libghc6-gitit-dev, libghc6-pandoc-dev
>>     * mips: libghc6-pandoc-dev
>>     * mipsel: libghc6-pandoc-dev
>>     * powerpc: libghc6-pandoc-dev
>>     * s390: libghc6-pandoc-dev
>>     * sparc: libghc6-pandoc-dev
>>
>> FWIW, the attached file haskell.txt has my britney hint. Remove
>> haskell-dummy from the final list if you want to see the failure.
>> Otherwise, it will say only: “failed: haskell-dummy”.
> 
>> FWIW, only gitit (in testing) build-depends on libghc6-pandoc-dev and
>> nothing build-depends on libghc6-gitit-dev. In sid, libghc6-pandoc-dev and
>> libghc6-gitit-dev are not used at all. So why not simply getting rid of
>> them? I don't see the point of keeping them around.
> 
> gitit in unstable build-depends on libghc-*-dev, without any 6 in the
> name – shouldn’t gitit just migrate along? Or maybe I’m not following
> you here...
> 

pandoc is not migratable in its current state in sid. And, gitit depends
on pandoc. I tried to remove both gigit and pandoc from testing during my
tests to see if ghc could migrate, but it doesn't because we need
haskell-dummy, which needs both gitit and pandoc through
libghc6-{gitit,pandoc}-{dev,doc}. If you want to keep those old -dev
packages, then you'll have to fix pandoc. If you drop them, then I think
we might be able to migrate ghc. Other packages I've mentioned in my mail
are not a blockers since they can be removed from testing easily.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


Reply to: