Hi, Am Samstag, den 06.08.2011, 10:48 +0200 schrieb Philipp Kern: > > easy azureus/4.3.0.6-4 swt-gtk/3.7-2 > > easy swt-paperclips/1.0.4-1 swt-gtk/3.7-2 > > easy swt-gtk/3.7-2 swtcalendar/0.5-1 > > easy swt-gtk/3.7-2 trident/1.3+dfsg-5 > > easy swt-gtk/3.7-2 zekr/1.0.0+repack-5 > > So we get those because they are minimal? (Instead of one swt-gtk > hint.) Yes. It is probably valid to migrate swt-gtk alone, but any of the other packages need the new swt-gtk. > Or are they unable to migrate all together? They should be (at least within the constraints SAT-Britney knows). The algorithm is: First find a largest possible transition, then break it down into small transitions that cover the large transition. > > easy gammu/1.30.0-2 libdbi/0.8.4-5.1 icinga/1.4.2-1/amd64 > > icinga/1.4.2-1/armel icinga/1.4.2-1/i386 icinga/1.4.2-1/ia64 > > icinga/1.4.2-1/mips icinga/1.4.2-1/mipsel icinga/1.4.2-1/powerpc > > icinga/1.4.2-1/s390 icinga/1.4.2-1/sparc > > rrdtool/1.4.3-3.1/kfreebsd-i386 rrdtool/1.4.3-3.1/sparc > > syslog-ng/3.2.4-1/amd64 syslog-ng/3.2.4-1/armel > > syslog-ng/3.2.4-1/i386 syslog-ng/3.2.4-1/ia64 > > syslog-ng/3.2.4-1/kfreebsd-i386 syslog-ng/3.2.4-1/mips > > syslog-ng/3.2.4-1/mipsel syslog-ng/3.2.4-1/powerpc > > syslog-ng/3.2.4-1/s390 syslog-ng/3.2.4-1/sparc > > Somehow I doubt that this one works, but let's see. (My libdbi hint > failed.) If it does not work, I’d like to know why, to find out if it is something that I can fix easily (forgotten or badly modeled transition requirement, or something involving conflicts) > > easy flightgear/2.0.0-4 openscenegraph/3.0.0-2 fgrun/1.5.2-1/amd64 > > fgrun/1.5.2-1/armel fgrun/1.5.2-1/i386 fgrun/1.5.2-1/ia64 > > fgrun/1.5.2-1/mips fgrun/1.5.2-1/mipsel fgrun/1.5.2-1/powerpc > > fgrun/1.5.2-1/s390 fgrun/1.5.2-1/sparc ossim/1.7.21-3/amd64 > > ossim/1.7.21-3/armel ossim/1.7.21-3/i386 ossim/1.7.21-3/ia64 > > ossim/1.7.21-3/mips ossim/1.7.21-3/mipsel ossim/1.7.21-3/powerpc > > ossim/1.7.21-3/s390 ossim/1.7.21-3/sparc > > easy libcitygml/0.1.3+r114-2+3p0p0 openscenegraph/3.0.0-2 > > fgrun/1.5.2-1/amd64 fgrun/1.5.2-1/armel fgrun/1.5.2-1/i386 > > fgrun/1.5.2-1/ia64 fgrun/1.5.2-1/mips fgrun/1.5.2-1/mipsel > > fgrun/1.5.2-1/powerpc fgrun/1.5.2-1/s390 fgrun/1.5.2-1/sparc > > ossim/1.7.21-3/armel ossim/1.7.21-3/i386 ossim/1.7.21-3/ia64 > > ossim/1.7.21-3/mips ossim/1.7.21-3/mipsel ossim/1.7.21-3/powerpc > > ossim/1.7.21-3/s390 ossim/1.7.21-3/sparc > > So it's the openscenegraph tansition one time with libcitygml and one > time with flightgear? Seems like it. I guess the verisons of libcitygml and flightgear in testing both work with the new openscenegraph, so it is valid to migrate only one of the two with the new openscenegraph. It would probably also be valid to migrate only openscenegraph, but this transition was already contained in one found before (the flightgreat transition), hence it is not shown separately. I could modify the algorithm to spit that out first... I’ll try that right away. Greeetings, 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