Hi,

Hi, wine is held back because of a lot of missing packages in testing,
but only on kfreebsd-amd64 [0].  It took me a while to realize this
was the underlying problem since the statements on the migration page
don't make it clear that only one specific arch is problematic.  I
think it would be really helpful if the output looked more like e.g.

   alternative 1/2: wine-unstable [kfreebsd-amd64] depends on
ia32-libs-dev [kfreebsd-amd64] which is not available in testing

and so on for all of the other cases; instead of the current arch-less
listing e.g.

    alternative 1/2: wine-unstable depends on ia32-libs-dev which is
not available in testing

Thanks,
Mike

[0] http://release.debian.org/migration/testing.pl?package=wine-unstable

user release.debian.org@packages.debian.org
usertags 649460 - britney
thanks

The issues you're describing relate purely to the output in
migration/testing.pl, not britney; there isn't really an appropriate
usertag for migration/, but it's not britney :)
[...]

It's somewhat confusing that you mention the "wine" package, and then
refer to a link which is about the "wine-unstable" package.

In any case, you appear to have overlooked the fundamental issue.  The
reason that wine-unstable isn't migrating has nothing to do with
kfreebsd-amd64.  I assume you're deducing this from the "dependency
analysis" section - the section that also suggests that:

eglibc depends on hurd-dev >= 20080607-3, which is not available in
testing

which is clearly not a kfreebsd-amd64 issue.

The reason that wine-unstable isn't migrating is listed at the top of
the page:

    wine-unstable is not yet built on amd64: 1.1.34-1 vs 1.1.35-1 (missing 19 binaries)
    wine-unstable is not yet built on powerpc: 1.1.29-1 vs 1.1.35-1 (missing 18 binaries)

i.e. it has build regressions on multiple architectures.  The same is
true for wine/amd64.

Regards,

Adam

I did notice that, but I'm fairly certain that is not the fundamental
problem here.  The particular issue that I'm pointing out is that
ia32-libs is only intended for ia64 and amd64 not kfreebsd-amd64 (see
its control file or [0]) as wine wants.  That of course is a wine
issue, and its clear now that is the issue that needs fixed here, but
I decided to report this to hopefully make this problem clearer in
other/future cases.

Yes, I did see that, but none of that is relevant to this particular
issue, so I chose to exclude this extraneous info from my initial
report.

Best wishes,
Mike

[0]  http://packages.qa.debian.org/ia32-libs

I must admit I'm confused then.

Your original mail said "wine is held back because of a lot of missing
packages in testing, but only on kfreebsd-amd64", so I assumed that you
were suggesting that such kfreebsd-amd64 issues were actually affecting
the package's migration to testing - otherwise the fact that the
packages aren't in testing is irrelevant.

However, the package has never built on kfreebsd-amd64, so that's not an
issue for testing.  Regardless of whether the output of the migration
page in terms of dependency analysis is optimal (which I'll quite
happily admit it's not), the package is not being "held back" from
testing because of anything on kfreebsd-amd64, so the reasons that the
package actually *is* being "held back" don't seem at all extraneous,
which was the point I was making.

The dependency analysis section has far greater issues than nicely
showing unmet build-dependencies on architectures where there aren't
even any packages, which is what I was trying to highlight by pointing
out its inclusion of hurd packages in the output.  I think that _is_ the
fundamental issue - with the exception of simple cases, I'm not
convinced the current output is helpful to anyone and, as this report
demonstrates, actually appears to be confusing people.

Regards,

Adam

Well, either version is equally wrong, to be honest.  wine-unstable
*build-depends* on ia32-libs-dev.  As such, the fact that ia32-libs-dev
doesn't exist on kfreebsd-amd64 in testing is utterly irrelevant.

(Although as I've already attempted to explain - apparently
unsuccessfully - any mention of kfreebsd-amd64 is a complete red herring
in terms of the package's testing migration in any case.)

Regards,

Adam

Isn't the dependency analysis normally taken into account when testing
migratability?  If not, it seems like that would be something very
useful to check (regardless of whether the package on that arch has
been in testing before or not).

Anyway, my point is that the current output makes it seem like a
missing ia32-libs-dev package is among the reasons the whole package
is being held back (again assuming the dependency analysis actually
matters).  But that's not true since testing does have ia32-libs-dev
on amd64, so it shouldn't be a problem there.  However, the dependency
analysis as is derives its output from all archs, but doesn't make
that clear, so it takes some work to figure out that the output in
this case comes from issues only on kfreebsd-amd64.

Best wishes,
Mike

Maybe the real issue here is that the build-depends dependency
analysis is only done on i386 (according to the wording "including
build-depends; i386 only"), and the ia32-libs-dev package of course
doesn't exist there?

Anyway, I think my original point remains.  For the dependency
analysis to be unambiguous like in this case, it needs to be generated
on a per-arch basis.

Best wishes,
Mike

Dependency analysis is, yes, otherwise how would britney be able to
determine whether a package were installable?  The section labelled
"dependency analysis" on migration/testing.pl, is not considered at all,
for reasons that will hopefully be clarified below if not already clear
enough.

I've never mentioned anything about whether the package has previously
been in testing on a particular architecture.  My point was that there
are _no kfreebsd-amd64 wine-unstable packages *in unstable*_ and never
have been, so there's no way at all that could be relevant to migration.

For clarity, the information:

     wine-unstable has no old version in testing (trying to add, not
update)
     wine-unstable is not yet built on amd64: 1.1.34-1 vs 1.1.35-1
(missing 19 binaries)
     wine-unstable is not yet built on powerpc: 1.1.29-1 vs 1.1.35-1
(missing 18 binaries)

is derived from britney.  The "dependency analysis" section is produced
by the script which produces the web pages, by parsing Packages and
Sources file.  It's intended (I assume) to be useful, but it's purely
informational and often not that helpful.

It doesn't matter, which might be part of the issue with this bug
report. :)

The only things that matter are going to be _above_ the "dependency
analysis" header, which are also things you could find in a combination
of grep-excuses (and therefore the PTS) and britney logs.  In the case
of wine-unstable, those are the three lines I quoted above.

Again, your conclusion is incorrect. :-(

Dependency analysis only derives its output from Sources + i386, which
is precisely _why_ it's showing ia32-libs-dev as unavailable.  It's not
being mentioned because it's unavailable on kfreebsd-amd64, it's being
mentioned because it's unavailable _on i386_.  If we annotated the
dependencies, it would say "wine-unstable[i386] depends on ia32-libs-dev
which is not available in testing", which doesn't seem like it would be
helpful.

It's also broken because it mixes build-dependencies and runtime
dependencies together - the binary packages produced by wine don't
depend on ia32-libs-dev - but that's a side issue.

Regards,

Adam

That's one of the many reasons why that section of the page is
unhelpful, yes.

It also shouldn't mix runtime and build dependencies, and shouldn't
care a hoot whether build-dependencies exist in testing or not.  In
fact, it probably shouldn't care if they exist in unstable, to be
honest, as they have no direct relevancy to migration.

Your original point seemed to be that you'd "worked out" that
ia32-libs-dev not being in testing on kfreebsd-amd64 was somehow
affecting the wine-unstable packages.  What I've been trying to do is to
point out to you why you were mistaken in what you believed that page
showed, before you wasted any further time attempting to fix issues that
don't exist. :-/  (The failures on amd64 and powerpc do matter, otoh).

Indeed.  If you'd started from that point and not mentioned any of the
confused kfreebsd-amd64 stuff, my original response would probably
simply have been "patches welcome" and we could have left it there... ah
well.

Regards,

Adam

retitle 649460 release.debian.org: arch-specific output in dependency analysis
thanks

I did finally just realize this as stated in my last message :(  My bad.

But wine-unstable[i386] does not build-depend on ia32-libs-dev at all,
and that wouldn't make any sense.  So, it seems another problem here
is that the "ia32-libs-dev [amd64 kfreebsd-amd64]" build-depends is
being interpreted wrongly.

That's the confusing part, especially since build-depends don't affect
testing migration.  It seems unnecessarily confusing to list any of
those until they actually matter (bug #145257).

I suppose I have a tendency of being too verbose and just dumping my
working memory sometimes.  It seems to have significantly distracted
from the small problem that I was trying to convey here.  I actually
don't care that much about wine-unstable migration, but I was quickly
glancing at that at the time, saw problems, and quickly wrote it up.

Anyway, I'll look into patching it now that it's clear whats wrong.

Best wishes,
Mike

No worries, it's not the most obvious of output to try and work out.

Well, it's not being interpreted at all, really... :-/  The code does
this, where @alternatives may only contain a single item:

       for my $p (@alternatives) {
       ...
           if ($p =~ /(.+?)\s*\[(.+?)\]/) {
               $p = $1;
           }

i.e. the architecture information is simply discared.

Regards,

Adam