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 [email protected] 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/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
