Re: Why doesn't aspectc++ migrate?
On 2013-11-09 08:11, Paul Gevers wrote:
> [Disclaimer: I am not part of the release team]
>
> On 09-11-13 04:49, Reinhard Tartler wrote:
Hi,
First of all, thanks for paying attention to the migration status of
your package. It is much appreciated. :)
>> I wonder why the package aspect++ does not migrate. According to
>> http://release.debian.org/migration/testing.pl?package=aspectc++, it
>> seems to be because of missing arm builds. I expected that not to
>> matter as the package is no longer in testing, but obviously I'm
>> wrong.
>
> As far as I know, what counts is if the package is in unstable. And as
> it build in the past on arm/armel, the package is still valid on unstable.
>
Indeed; what matters is whether you have "out of date binaries" in
unstable or not. You can also see this on buildd.d.o[1].
(Also, pedantic note here: It is "armhf" and not "arm". The latter is
no longer supported by Debian).
>> Upstream is aware of the issue but does not consider this a priority.
>
> Do you know if the package was not only building on arm/armel but was
> actually useful? Then I think Debian does consider this a "priority".
>
>> I ask now what do you think would be the best course of action:
>
> I would say that depends on the answer to my question above.
>
>> a) adding some hint so that it migrates anyway
Not an option; we can (or will?) not let any package with out of date
binaries migrate.
>> b) change to source to include only i386 and amd64 in the Architecture
>> line, as these are the only upstream supported architectures
This is overly restrictive since the package builds on 5 other
architectures. Regardless, you still need to get the binaries removed
(see d1).
>> c) both a) and b)
>> d) something else.
>
> d1: if it was never useful, ask ftp-master to remove the arm/armel
> packages from the archive by filing a removal request, migration will
> then happen automatically if I am correct. In that case also add the
> appropriate archs in the debian/control file.
In this case, you would be taking undertaker on those architectures as
well[2]. Also, the proper order would be to upload the package first
with reduced architectures and then file the removal (else there is a
possible race condition leaving you with out of date binaries).
> d2: if the package is useful on arm and armel, I believe it is the
> responsibility of the maintainer (normally with the help of upstream) to
> fix (or find help to fix) such issues.
>
> Paul
>
>
You also have the option to ask the arm porters (d-arm@l.d.o) if they
can help you come up with a patch.
The "being nice, while still moving forward"-approach would probably be
asking the porters for help. If they cannot or do not have time to help
you figure out (i.e. debug) the underlying problem in aspectc++ then go
for d1.
~Niels
[1] https://buildd.debian.org/status/package.php?p=aspectc%2b%2b
Note the "out-of-date" vs "uncompiled" in the state.
[2] AFAICT, undertaker would become unbuildable on these architectures
if aspectc++ was removed. Admittedly, I only had a quick glance, so I
could be wrong here.
Reply to: