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

Re: ghc now almost ready for migration



Hi Mehdi,

Am Dienstag, den 07.06.2011, 14:17 +0200 schrieb Mehdi Dogguy:
> 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.

I started rebuilds on mips*, but nevertheless asked for removal – if the
builds work, then the packages will just migrate later, if it does not
(kinda likely), then we can carry on.

> >> - 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.

Ack.

> >> - 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.

Asked for removal, and also retried haskell-lexer.

> >> 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.

For fixing pandoc, removal of pandoc on these three arches is
sufficient, right?

BTW, is it a problem to have the dummy packages from haskell-dummy,
which are arch all, depend on their libghc-*-dev counterpart even though
it might not exist on all arches? Or is britney satisfied if the
dependencies of an arch:all packages are satisfiable on at least one
architecture?

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: