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