Re: Why is package X not in testing yet?
Il Martedì 19 Agosto 2014 21:21, Sven Bartscher
sven.bartsc...@weltraumschlangen.de ha scritto:
On Mon, 18 Aug 2014 21:55:37 +0100
Gianfranco Costamagna costamagnagianfra...@yahoo.it wrote:
Hi again Sven,
I would just ask one (I hope little) feature, I'm not an haskell guy,
so I find rather difficult to submit a patch :)
I would like to see also this
outputUrl =
people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
(maybe with a deletion of ~/.reasons/update_output.txt)
and replace doesn't with doesn't ;)
maybe something like renaming update_output.txt.{ubuntu,debian} and
passing something like -d {debian,ubuntu} by command line will make this
program universally used and easily extensible to other debian based distros.
Greetings,
I'm now at a point, where I would like to start implementing this.
I'm not really into Ubuntu, so I have to ask a few questions.
My tool fetches the excuses using grep-excuses. Is the version of
grep-excuses in Ubuntu configured to fetch the right excuses (the ones
for Ubuntu)?
I don't really know, I'm on ubuntu and grep-excuses always fetched the debian
excuses, the man doesn't say anything useful I think
For analysing if out of date excuses are interesting it fetches
information from buildd.debian.org/stats/. Is this information
available in Ubuntu? Where do I get it?
don't know either, there seems to be something similar here
http://people.canonical.com/~ubuntu-archive/proposed-migration/
(maybe under logs)
Sorry for not being terribly helpful, but I'm more a debian man, rather than an
ubuntu one too :)
Cheers,
Gianfranco
Regards
Sven
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1408521469.53929.yahoomail...@web171802.mail.ir2.yahoo.com
Re: Why is package X not in testing yet?
Dear Pietro, Am Montag, den 18.08.2014, 23:51 +0200 schrieb Pietro Abate: On 18/08/14 18:10, Sven Bartscher wrote: If we have a package, which doesn't migrate to testing, we usually check the Why does package X not in testing yet? page or the PTS. Usually they do a great job in telling us why our package doesn't migrate. But sometimes you have packages, which have complicated dependencies, that don't make it easy to tell why our package doesn't migrate. Usually the PTS and Why is package X not in testing yet? fail at those packages and don't give any useful explanation. For example look at the page for haskell-hgettext[1]. you might want to have a look at comigrate [1] a tool designed to answer these kind of questions and provide explanations that are as compat as possible. For example for haskell-hgettext [2] . If you find it useful, I'm sure the authors would be happy to hear from you. unfortunately, comigrate doesn’t cut it for our case. From the page for haskell-hgettext, I get redirected to haskell-uniplate, and from there to other packages, none of which are the real culprit. Sven’s tool has an idea of what must migrate together (relying on britney’s autohinter) and ignores, for example, any dependency problems that are among these packages. Nevertheless, thanks for the pointer to comigrate. I think it could make use of more visibility. Maybe a link from the PTS, along with the links to other explanation pages? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Why is package X not in testing yet?
On Mon, 18 Aug 2014 23:51:43 +0200 Pietro Abate pietro.ab...@pps.univ-paris-diderot.fr wrote: Hei Sven, On 18/08/14 18:10, Sven Bartscher wrote: If we have a package, which doesn't migrate to testing, we usually check the Why does package X not in testing yet? page or the PTS. Usually they do a great job in telling us why our package doesn't migrate. But sometimes you have packages, which have complicated dependencies, that don't make it easy to tell why our package doesn't migrate. Usually the PTS and Why is package X not in testing yet? fail at those packages and don't give any useful explanation. For example look at the page for haskell-hgettext[1]. you might want to have a look at comigrate [1] a tool designed to answer these kind of questions and provide explanations that are as compat as possible. For example for haskell-hgettext [2] . If you find it useful, I'm sure the authors would be happy to hear from you. I looked at it and it's a great tool to identify problems with migrations, but it's not really what I was aiming for when I wrote my tool. The web interface does list that haskell-src-exts needs to migrate, which is right, but not really helpful. To find the root causes of the problem I need to navigate through all the packages with their own listings. If my browser wouldn't mark links I already visited I would have a great chance to end up in a loop. So it's just too much data to understand what's the problem and what to do against it. The command line interface couldn't provide as much information. It follows the dependency chain until it ends up at pandoc and doesn't know what to do. My tool (which still doesn't have a name, suggestions welcome) has another approach of identifying the problem. Instead of checking dependencies it checks for the autohint the package in question is in. So instead of searching for the relevant information itself, it takes a huge amount of information and filters it for the useful informations. Wile this approach gathers more relevant information than other tools (I know), I still don't know if it identifies all issues a package might have. So in conclusion: comigrate is a really nice tool. But, as far as I know, it's not really suitable to analyse transitions, as big as haskell transitions. Regards Sven signature.asc Description: PGP signature
Re: Why is package X not in testing yet?
On Mon, 18 Aug 2014 21:55:37 +0100
Gianfranco Costamagna costamagnagianfra...@yahoo.it wrote:
I would just ask one (I hope little) feature, I'm not an haskell guy, so I
find rather difficult to submit a patch :)
I would like to see also this
outputUrl =
people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
(maybe with a deletion of ~/.reasons/update_output.txt)
and replace doesn't with doesn't ;)
done.
maybe something like renaming update_output.txt.{ubuntu,debian} and passing
something like -d {debian,ubuntu} by command line will make this program
universally used and easily extensible to other debian based distros.
That's a bit more tricky than it seems, due to limitations in wget.
wget doesn't support the -N (only download if remote file if newer)
together with -O. So if I rename them wget won't be able to check their
timestamps.
Even worse I'm currently working on a filter for out of date excuses,
which uses information from the buildds, which are Debian specific.
So support for derivates won't come very soon. But I will look at it as
soon as I have a clue how to do it.
thanks again for the nice and useful work you did!
Regards
Sven
signature.asc
Description: PGP signature
Re: Why is package X not in testing yet?
Hi, Am Dienstag, den 19.08.2014, 12:46 +0200 schrieb Sven Bartscher: That's a bit more tricky than it seems, due to limitations in wget. wget doesn't support the -N (only download if remote file if newer) together with -O. So if I rename them wget won't be able to check their timestamps. You can use curl instead of wget; in one instance I am using $ curl -R http://mirror.bm.debian.org/debian/dists/sid/main/source/Sources.gz \ -z unstable-main-Sources.gz \ -o unstable-main-Sources.gz Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Re: Why is package X not in testing yet?
Hi Joachim, On Tue, 19 Aug 2014 11:07:57, Joachim Breitner wrote: unfortunately, comigrate doesn’t cut it for our case. From the page for haskell-hgettext, I get redirected to haskell-uniplate, and from there to other packages, none of which are the real culprit. Sven’s tool has an idea of what must migrate together (relying on britney’s autohinter) and ignores, for example, any dependency problems that are among these packages. I agree that the online report on http://coinst.irill.org/report/ is not appropriate in your case. In general, it will not report all issues preventing the migration of a package, and the issues are not presented conveniently on a single page. You should try the command line tool (Debian package 'coinst') instead. Still, the report provides a lot more information than what you say. (Some list items can be unfolded by clicking on them or by clicking on the 'Expand all' button.) Here is what I can see regarding haskell-hgettext. haskell-hgettext needs (to migrate together with) haskell-uniplate which needs haskell-unordered-containers and yi. yi needs haskell-unordered-containers and haskell-regex-tdfa. haskell-unordered-containers will not migrate as it would break some packages on armel: haskell-github, pandoc and kfreebsd-amd64: haskell-snap, haskell-yesod-static, pandoc haskell-regex-tdfa will not migrate as it has not yet been rebuilt on mips. Some binaries packages from haskell-hakyll, haskell-regex-tdfa-utf8, haskell-hledger-lib and haskell-unixutils depends on the obsolete binary package. Besides, the package cannot migrate as this would break haskell-hakyll on armel, kfreebsd-i386 and kfreebsd-amd64. Thus, Bin-NMUS are needed for haskell-github, pandoc, haskell-snap, haskell-yesod-static and haskell-hakyll, haskell-regex-tdfa-utf8, haskell-hledger-lib and haskell-unixutils. The online report does not list all issues preventing the migration of haskell-hgettext. But note than none of the issues above are reported by Sven's tool. Regards, -- Jérôme -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f38120.30...@pps.univ-paris-diderot.fr
Re: Why is package X not in testing yet?
On Tue, 19 Aug 2014 18:53:52 +0200 Jérôme Vouillon jerome.vouil...@pps.univ-paris-diderot.fr wrote: Hi Joachim, On Tue, 19 Aug 2014 11:07:57, Joachim Breitner wrote: unfortunately, comigrate doesn’t cut it for our case. From the page for haskell-hgettext, I get redirected to haskell-uniplate, and from there to other packages, none of which are the real culprit. Sven’s tool has an idea of what must migrate together (relying on britney’s autohinter) and ignores, for example, any dependency problems that are among these packages. I agree that the online report on http://coinst.irill.org/report/ is not appropriate in your case. In general, it will not report all issues preventing the migration of a package, and the issues are not presented conveniently on a single page. You should try the command line tool (Debian package 'coinst') instead. Still, the report provides a lot more information than what you say. (Some list items can be unfolded by clicking on them or by clicking on the 'Expand all' button.) Here is what I can see regarding haskell-hgettext. haskell-hgettext needs (to migrate together with) haskell-uniplate which needs haskell-unordered-containers and yi. yi needs haskell-unordered-containers and haskell-regex-tdfa. haskell-unordered-containers will not migrate as it would break some packages on armel: haskell-github, pandoc and kfreebsd-amd64: haskell-snap, haskell-yesod-static, pandoc haskell-regex-tdfa will not migrate as it has not yet been rebuilt on mips. Some binaries packages from haskell-hakyll, haskell-regex-tdfa-utf8, haskell-hledger-lib and haskell-unixutils depends on the obsolete binary package. Besides, the package cannot migrate as this would break haskell-hakyll on armel, kfreebsd-i386 and kfreebsd-amd64. Thus, Bin-NMUS are needed for haskell-github, pandoc, haskell-snap, haskell-yesod-static and haskell-hakyll, haskell-regex-tdfa-utf8, haskell-hledger-lib and haskell-unixutils. The online report does not list all issues preventing the migration of haskell-hgettext. But note than none of the issues above are reported by Sven's tool. That's not really true. My tool DID report that haskell-regex-tdfa is out of date on mips and thus requires a binNMU. All reverse dependencies would have been reported once haskell-regex-tdfa is rebuilt. This is not really the best way, because it doesn't allow ordering binNMUs in large groups. Regards Sven signature.asc Description: PGP signature
Re: Why is package X not in testing yet?
On Tue, 19 Aug 2014 19:15:25 +0200 Sven Bartscher sven.bartsc...@weltraumschlangen.de wrote: On Tue, 19 Aug 2014 18:53:52 +0200 Jérôme Vouillon jerome.vouil...@pps.univ-paris-diderot.fr wrote: Hi Joachim, On Tue, 19 Aug 2014 11:07:57, Joachim Breitner wrote: unfortunately, comigrate doesn’t cut it for our case. From the page for haskell-hgettext, I get redirected to haskell-uniplate, and from there to other packages, none of which are the real culprit. Sven’s tool has an idea of what must migrate together (relying on britney’s autohinter) and ignores, for example, any dependency problems that are among these packages. I agree that the online report on http://coinst.irill.org/report/ is not appropriate in your case. In general, it will not report all issues preventing the migration of a package, and the issues are not presented conveniently on a single page. You should try the command line tool (Debian package 'coinst') instead. Still, the report provides a lot more information than what you say. (Some list items can be unfolded by clicking on them or by clicking on the 'Expand all' button.) Here is what I can see regarding haskell-hgettext. haskell-hgettext needs (to migrate together with) haskell-uniplate which needs haskell-unordered-containers and yi. yi needs haskell-unordered-containers and haskell-regex-tdfa. haskell-unordered-containers will not migrate as it would break some packages on armel: haskell-github, pandoc and kfreebsd-amd64: haskell-snap, haskell-yesod-static, pandoc haskell-regex-tdfa will not migrate as it has not yet been rebuilt on mips. Some binaries packages from haskell-hakyll, haskell-regex-tdfa-utf8, haskell-hledger-lib and haskell-unixutils depends on the obsolete binary package. Besides, the package cannot migrate as this would break haskell-hakyll on armel, kfreebsd-i386 and kfreebsd-amd64. Thus, Bin-NMUS are needed for haskell-github, pandoc, haskell-snap, haskell-yesod-static and haskell-hakyll, haskell-regex-tdfa-utf8, haskell-hledger-lib and haskell-unixutils. The online report does not list all issues preventing the migration of haskell-hgettext. But note than none of the issues above are reported by Sven's tool. That's not really true. My tool DID report that haskell-regex-tdfa is out of date on mips and thus requires a binNMU. All reverse dependencies would have been reported once haskell-regex-tdfa is rebuilt. This is not really the best way, because it doesn't allow ordering binNMUs in large groups. Sorry. s/is out of date/misses a dependency/ signature.asc Description: PGP signature
Re: Why is package X not in testing yet?
Hi Sven, Thanks a lot for taking the time to look at comigrate! On Tue, 19 Aug 2014 12:45:59, Sven Bartscher wrote: On Mon, 18 Aug 2014 23:51:43 +0200 Pietro Abate pietro.ab...@pps.univ-paris-diderot.fr wrote: Hei Sven, On 18/08/14 18:10, Sven Bartscher wrote: [...] you might want to have a look at comigrate [1] a tool designed to answer these kind of questions and provide explanations that are as compat as possible. For example for haskell-hgettext [2] . If you find it useful, I'm sure the authors would be happy to hear from you. I looked at it and it's a great tool to identify problems with migrations, but it's not really what I was aiming for when I wrote my tool. The web interface does list that haskell-src-exts needs to migrate, which is right, but not really helpful. To find the root causes of the problem I need to navigate through all the packages with their own listings. If my browser wouldn't mark links I already visited I would have a great chance to end up in a loop. So it's just too much data to understand what's the problem and what to do against it. You are correct that the Web interface is not really appropriate to analyze large transitions. The command line interface couldn't provide as much information. It follows the dependency chain until it ends up at pandoc and doesn't know what to do. The command line interface is meant to be used interactively. Here, the tool tells you that haskell-hgettext cannot migrate as this would break package libghc-pandoc-dev. You can decide that its fine to break this package (for now) by adding '--break libghc-pandoc-dev' to the command line, and then run the tool again to find other issues. Alternatively, you can tell the tool to do as if the package pandoc was removed from unstable by using the '--remove pandoc' directive. The --break directive is useful to find issues when preparing a transition. The --remove directive is most useful at the final stage, to see which broken packages have to be removed from testing for the transition to take place. By iterating, you can find all issues reported by your tools, and more. This is tedious when there are many issues, so maybe that could be automated somehow. My tool (which still doesn't have a name, suggestions welcome) has another approach of identifying the problem. Instead of checking dependencies it checks for the autohint the package in question is in. So instead of searching for the relevant information itself, it takes a huge amount of information and filters it for the useful informations. Wile this approach gathers more relevant information than other tools (I know), I still don't know if it identifies all issues a package might have. As far as I can see, for haskell-hgettext, it misses some dev and prof binaries from the following packages that needs to be recompiled: haskell-active, haskell-authenticate-oauth, haskell-diagrams-cairo, haskell-diagrams-core, haskell-diagrams-gtk, haskell-diagrams-lib, haskell-diagrams-svg, haskell-esqueleto, haskell-github, haskell-hakyll, haskell-happstack-heist, haskell-hledger-lib, haskell-hledger-lib-prof libghc-http-conduit, haskell-hxt-tagsoup, haskell-hxt-xpath, haskell-hxt-xslt, haskell-osm, haskell-pandoc-citeproc, pandoc, haskell-persistent, haskell-persistent-postgresql, haskell-persistent-sqlite, haskell-persistent-template, haskell-pipes-attoparsec, haskell-regex-tdfa-utf8, haskell-snap, haskell-snaplet-acid-state, haskell-unixutils, haskell-vector-space, haskell-vector-space-points, haskell-xml-hamlet, haskell-yesod-auth-account, haskell-yesod-auth-oauth, haskell-yesod-persistent, haskell-yesod-static Some of these packages depend on other out of date packages. For instance, libghc-unixutils-dev depends on libghc-regex-tdfa-dev. I understand why this package is not listed: your tool has no way to know that recompiling libghc-regex-tdfa-dev is not going to be sufficient. But your tool also misses binary package dependency issues, which are not listed in Britney's excuses. For instance, it does not see that libghc-pandoc-dev needs to be recompiled. I don't see how to fix that. You could look at the autohinter failure output, but you are going to get a lot of false positive if the hint is not quite correct. In the case of haskell-hgettext, there should be no failure on the i386 architecture, for instance, but package yi and several others packages are missing from the hint. Regards, -- Jérôme -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f37dc9.30...@pps.univ-paris-diderot.fr
Re: Why is package X not in testing yet?
On Mon, 18 Aug 2014 21:55:37 +0100
Gianfranco Costamagna costamagnagianfra...@yahoo.it wrote:
Hi again Sven,
I would just ask one (I hope little) feature, I'm not an haskell guy, so I
find rather difficult to submit a patch :)
I would like to see also this
outputUrl =
people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
(maybe with a deletion of ~/.reasons/update_output.txt)
and replace doesn't with doesn't ;)
maybe something like renaming update_output.txt.{ubuntu,debian} and passing
something like -d {debian,ubuntu} by command line will make this program
universally used and easily extensible to other debian based distros.
Greetings,
I'm now at a point, where I would like to start implementing this.
I'm not really into Ubuntu, so I have to ask a few questions.
My tool fetches the excuses using grep-excuses. Is the version of
grep-excuses in Ubuntu configured to fetch the right excuses (the ones
for Ubuntu)?
For analysing if out of date excuses are interesting it fetches
information from buildd.debian.org/stats/. Is this information
available in Ubuntu? Where do I get it?
Regards
Sven
signature.asc
Description: PGP signature
Re: Why is package X not in testing yet?
From: Sven Bartscher sven.bartsc...@weltraumschlangen.de
Hi again Sven,
Greetings,
If we have a package, which doesn't migrate to testing, we usually
check the Why does package X not in testing yet? page or the PTS.
Usually they do a great job in telling us why our package doesn't
migrate.
But sometimes you have packages, which have complicated dependencies,
that don't make it easy to tell why our package doesn't migrate.
Usually the PTS and Why is package X not in testing yet? fail at
those packages and don't give any useful explanation. For example look
at the page for haskell-hgettext[1].
Those packages usually have to go into testing together with a few other
packages. If it's getting worse your package needs to go into testing
with a lot of other packages (usually if your package is part of a
bigger transition).
If your package is part of a transition you might have luck and the
transition page can tell you what the problem is. But sometimes not
even that pages help.
For that reason I made a tool that takes a package name and tries to
find out why your package doesn't migrate to testing.
When run, it gathers all packages that block our given package X.
Then it fetches all excuses for these packages and throws all of them
away, except those that are identified as interesting. These types of
excuses are identified as interesting:
- out of date on arch
- pkg has new bugs
- Too young
This takes a long time (for me 3 Minutes) depending on your internet
connection.
This is mostly useful for haskell packages, as they have very close
dependencies. However, it might be interesting in any other transition.
The source code is attached and can be found in the tools repository[2]
of the Haskell Group.
In order to compile it you need the following packages:
- ghc
- libghc-regex-pcre-dev
- libpcre++-dev (This should be a dependency of libghc-regex-pcre-dev
but it isn't due to a bug)
Compile it with:
ghc --make reasons.hs
To run it you need the following packages:
- devscripts
- wget
- ca-certificates
- locales (you should use an UTF-8 encoding, otherwise its guaranteed
you will have problems.)
Also you must have enabled the source URIs in you sources.list.
There are still some rough edges. The most notable ones are:
- Most errors that can happen aren't catched. So an haskell exception
will be thrown, which gives not very much information of the problem.
- The excuses are fetched with grep-excuses. So the excuses file is
downloaded over ad over again. There is already a bug with a patch
filed against grep-excuses to fix this.
- out of date excuses are all considered interesting, even though it
would be better to only include those that aren't in state B-D
unistallable.
A bit more detail on the workflow of this tool is described in this[3]
post.
I would just ask one (I hope little) feature, I'm not an haskell guy, so I find
rather difficult to submit a patch :)
I would like to see also this
outputUrl =
people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
(maybe with a deletion of ~/.reasons/update_output.txt)
and replace doesn't with doesn't ;)
maybe something like renaming update_output.txt.{ubuntu,debian} and passing
something like -d {debian,ubuntu} by command line will make this program
universally used and easily extensible to other debian based distros.
thanks again for the nice and useful work you did!
cheers,
Gianfranco
[1]:
https://release.debian.org/migration/testing.pl?package=3Dhaskell-hgettext
[2]: http://anonscm.debian.org/cgit/pkg-haskell/tools.git/
[3]: https://lists.debian.org/debian-haskell/2014/08/msg00027.html
--MP_/ptLm4kgDdV4o5zwF+5AjRiy
Content-Type: text/x-haskell
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=reasons.hs
import Text.Regex.PCRE
import System.Environment
import System.Exit
import System.Process
import System.IO
import Data.Maybe
import Data.List
import Data.Char
import qualified Data.Set as S
import Control.Exception
import System.IO.Error
import System.Directory
import Debug.Trace
data Excuses =3D Excuses String [String]
isEmpty :: Excuses - Bool
isEmpty (Excuses _ []) =3D False
isEmpty (Excuses _ _) =3D True
excuses2String :: Excuses - String
excuses2String (Excuses pkg excuses) =3D unlines $ (pkg ++ :):(map
( =
++) excuses)
main =3D do
package - getArgs =3D parse
output - fmap lines acquireBritneyOut
let bins =3D getBinBlockers output package
result - try (fmap nub $ mapM getSrcPackage bins) :: IO (Either ErrorCal=
l [String])
srcBlockers - case result of
Left e - putStrLn packageNotFoundMsg exitFailure
Right pkgs - return pkgs
excuses - mapM getExcuse srcBlockers
additionalExcuses - getAdditionalExcuses srcBlockers excuses
let filteredExcuses =3D filterExcuses isInteresting $
Re: Why is package X not in testing yet?
Hei Sven, On 18/08/14 18:10, Sven Bartscher wrote: If we have a package, which doesn't migrate to testing, we usually check the Why does package X not in testing yet? page or the PTS. Usually they do a great job in telling us why our package doesn't migrate. But sometimes you have packages, which have complicated dependencies, that don't make it easy to tell why our package doesn't migrate. Usually the PTS and Why is package X not in testing yet? fail at those packages and don't give any useful explanation. For example look at the page for haskell-hgettext[1]. you might want to have a look at comigrate [1] a tool designed to answer these kind of questions and provide explanations that are as compat as possible. For example for haskell-hgettext [2] . If you find it useful, I'm sure the authors would be happy to hear from you. [1] http://coinst.irill.org/comigrate/ [2] http://coinst.irill.org/report/p/haskell-hgettext.html pietro -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818215143.ga2...@zed.irill.org
Re: Why is package X not in testing yet - where's the page
* Frank Küster ([EMAIL PROTECTED]) [041209 17:25]: I used to check testing migration with the link http://bjorn.haxx.se/debian/testing.pl but the host is no longer found. Does anybody know whether this is just a temporary problem? Or is there an alternative site? Both nameservers (which are just one ip-adresses next to each other) are not found currently. If the author wants, I'd offer secondary DNS servers. Also, we might perhaps consider to integrate these scripts into pts or on release.d.o. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Why is package X not in testing yet - where's the page
Frank Kster frank at debian.org writes: I used to check testing migration with the link http://bjorn.haxx.se/debian/testing.pl but the host is no longer found. Does anybody know whether this is just a temporary problem? Or is there an alternative site? Hello, It worked yesterday, and I've no idea what the status of the /site/ actually is because the nameservers for haxx.se seem to be down. cu andreas
