Debian Bug report logs - #817823
RM: android-libcutils android-libcutils-dev android-liblog android-liblog-dev [arm64 armel armhf mips mips64el mipsel powerpc ppc64el s390x] -- ANAIS; old binaries in architectures not allowed anymore

[Message part 1 (text/plain, inline)]
Package: ftp.debian.org
X-Debbugs-Cc: android-platform-system-core@packages.debian.org

The new version of the android stack restricts the architectures to
amd64, i386, so those old binaries needs to be removes.
There are 3 more binaries other than those, but they will be autoremoved
as cruft (as they are not built anymore anyway) once ready.

The rdep check done by dak rm seems to be wrong here, so this is good to
go:

mattia@coccia ~ % dak rm -n -R -a arm64,armel,armhf,mips,mips64el,mipsel,powerpc,ppc64el,s390x -b android-libcutils android-libcutils-dev android-liblog android-liblog-dev
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

android-libcutils |       21-6 | arm64, armel, armhf, mips, mips64el, mipsel, powerpc, ppc64el, s390x
android-libcutils-dev |       21-6 | arm64, armel, armhf, mips, mips64el, mipsel, powerpc, ppc64el, s390x
android-liblog |       21-6 | arm64, armel, armhf, mips, mips64el, mipsel, powerpc, ppc64el, s390x
android-liblog-dev |       21-6 | arm64, armel, armhf, mips, mips64el, mipsel, powerpc, ppc64el, s390x

Maintainer: Android tools Maintainer <android-tools-devel@lists.alioth.debian.org>

------------------- Reason -------------------

----------------------------------------------

Checking reverse dependencies...
# Broken Depends:
android-platform-system-core: android-system-dev                            <---- That's a cruft package (as said above); I think it's totally safe to partially break it

# Broken Build-Depends:
android-platform-build: android-liblog-dev (>= 1:6.0.0+r26~)                <---- Build-Dep restricted by [amd64 i386]
android-platform-dalvik: android-libcutils-dev (>= 1:6.0.1+r16~)            <---- Builds only amd64/i386 binaries
                         android-liblog-dev (>= 1:6.0.1+r16~)
android-platform-frameworks-base: android-liblog-dev (>= 1:6.0.0+r26~)      <---- Builds only amd64/i386 binaries
android-platform-libnativehelper: android-libcutils-dev (>= 1:6)            <---- Builds only amd64/i386 binaries
                                  android-liblog-dev (>= 1:6)

Dependency problem found.

PS, 殷啟聰: this is one blocker for android-platform-system-core to
migrate to testing, as britney treats the missing builds of those 3
binaries the very same way as FTBFS in those architectures, while they
are not :)

PS2: I'm not sure if the subject like that is going to work as I expect,
I'll check removals.html if the dak command is correct or otherwise
tweak this bug accordingly (or cloning it so there is one per binary).
-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  http://mapreri.org                              : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[signature.asc (application/pgp-signature, inline)]
Thank you for reporting this, looks like this is really blocking the
migration. I have been watching [1] but not [2] so I did not notice
the problem... :(

When will this RM be processed? Ftp-master people randomly select and
process a bug? Or should I do anything to "agree" to this RM as I am
one of the Uploaders?

There is a broken dependency about "android-system-dev", but it is
Provided by another binary package built from the same source package,
so I guess it won't break anything.

[1]: https://release.debian.org/migration/testing.pl?package=android-platform-system-core
[2]: https://qa.debian.org/excuses.php?package=android-platform-system-core

[Message part 1 (text/plain, inline)]
What is the reason for the removal of the ARM builds of adb and
fastboot? It seems odd to not support debug tools for ARM devices from
ARM devices.

i386 is still supported, so it doesn't seem to be a 32bit issue - even
if it was, there should be no particular reason to drop arm64.

Is there an upstream link or reference for why 6.0.1 cannot support
non-x86 architectures?

-- 

Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]
X-Debbugs-CC: android-tools-devel@lists.alioth.debian.org
X-Debbugs-CC: codehelp@debian.org

adb and fastboot are part of the Android SDK which are only officially
supported on x86 platforms. Strictly speaking, Google only supports
its i386 version, because the official SDK are mostly 32-bit
softwares. Although the Android OS runs on x86, ARM and MIPS, the SDK
does not.

We don't want to maintain too many ports of them, there's too much
work. More importantly, even if we can successfully build them on
other platforms, we can't assure that they will work on other
platforms. For example, we used to let android-libunwind build on
other platforms but it FTBFS on MIPS. Another example, 64-bit dexdump
won't work and we can only use its 32-bit version.

You can surely use adb and fastboot on a x86 computer to debug ARM
phones, and I think most people do this?

adb and fastboot are part of the Android SDK which are only officially
supported on x86 platforms. Strictly speaking, Google only supports
its i386 version, because the official SDK are mostly 32-bit
softwares. Although the Android OS runs on x86, ARM and MIPS, the SDK
does not.

We don't want to maintain too many ports of them, there's too much
work. More importantly, even if we can successfully build them on
other platforms, we can't assure that they will work on other
platforms. For example, we used to let android-libunwind build on
other platforms but it FTBFS on MIPS. Another example, 64-bit dexdump
won't work and we can only use its 32-bit version.

You can surely use adb and fastboot on a x86 computer to debug ARM
phones, and I think most people do this?

2016-03-25 4:58 GMT+08:00 Neil Williams <codehelp@debian.org>:
> What is the reason for the removal of the ARM builds of adb and
> fastboot? It seems odd to not support debug tools for ARM devices from
> ARM devices.
>
> i386 is still supported, so it doesn't seem to be a 32bit issue - even
> if it was, there should be no particular reason to drop arm64.
>
> Is there an upstream link or reference for why 6.0.1 cannot support
> non-x86 architectures?
>
> --
>
>
> Neil Williams
> =============
> http://www.linux.codehelp.co.uk/
>
>
> _______________________________________________
> Android-tools-devel mailing list
> Android-tools-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel

-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <http://seamlik.logdown.com>
*/

[Message part 1 (text/plain, inline)]
On Fri, 25 Mar 2016 20:23:57 +0800
殷啟聰 <seamlikok@gmail.com> wrote:

> adb and fastboot are part of the Android SDK which are only officially
> supported on x86 platforms. Strictly speaking, Google only supports
> its i386 version, because the official SDK are mostly 32-bit
> softwares. Although the Android OS runs on x86, ARM and MIPS, the SDK
> does not.

"does not" or "is not supported on" ?

It's not the full SDK that is relevant necessarily. For automated
testing of AOSP development, adb and fastboot binaries are the
principle requirement.

> We don't want to maintain too many ports of them, there's too much
> work. More importantly, even if we can successfully build them on
> other platforms, we can't assure that they will work on other
> platforms.

There are established automated systems which could test exactly this
requirement. Users of such systems have expressed interest in doing
precisely this kind of testing, particularly for and on ARM
architectures. Once more suitable arm64 hardware is available (soon),
LAVA expects to be able to provide such testing but the lack of such
testing currently is not an excuse to remove the architecture just at
the point where this support could be offered.

> For example, we used to let android-libunwind build on
> other platforms but it FTBFS on MIPS. Another example, 64-bit dexdump
> won't work and we can only use its 32-bit version.

The use case for testing adb and fastboot does not have to include
dexdump. Equally, having a validation framework can assist in debugging
*why* dexdump does not work and *fixing* that bug and other bugs related
to architecture-specific flaws in the code.

> You can surely use adb and fastboot on a x86 computer to debug ARM
> phones, and I think most people do this?

This is not about debugging a single phone. This is about automated
testing of dozens of phones and other devices across a range of
infrastructure to do automated testing of AOSP builds to support kernel
development and mainline testing.

LAVA (lava-dispatcher specifically) uses adb and fastboot to deploy and
test on multiple devices. As an ARM test facility, there is a strong
interest in testing using ARM infrastructure wherever possible - that
way we can test the mobile device and the enterprise server at the same
time. If there are tests that can or need to be run to validate adb and
fastboot themselves, those can be run on the server hardware but still
within the same CI framework.

lava.debian.net is the Debian LAVA instance but this is in early stages
of device integration. validation.linaro.org is the established
instance and runs large numbers of AOSP tests on a wide range of ARM
devices.

So ports of adb and fastboot could be tested and validated on ARM
platforms, that is why ARM builds should not be dropped.

The previous builds of adb and fastboot were not tested within Debian
but using this as an excuse to remove them when an established test
system is gaining support to provide that testing does not make sense.
There is an expectation from users that LAVA will be able to use arm64
servers to run tests inside LAVA as part of a CI framework for arm64
kernel support. Hardware to do this is pending but to complete this
service, LAVA needs ARM builds of adb and fastboot. Equally, LAVA can
be used to provide the very testing that has been missing in the past.

If there are no other reasons for shortening the architecture list, at
least arm64 should be recovered. However, with devices like the
cubietruck already running lava-dispatcher services, there is no
particular reason to drop armhf either. Building those packages is not
a problem, the buildd framework is more than capable of that task.

Please retain arm64 and armhf architectures.

> 2016-03-25 4:58 GMT+08:00 Neil Williams <codehelp@debian.org>:
> > What is the reason for the removal of the ARM builds of adb and
> > fastboot? It seems odd to not support debug tools for ARM devices
> > from ARM devices.
> >
> > i386 is still supported, so it doesn't seem to be a 32bit issue -
> > even if it was, there should be no particular reason to drop arm64.
> >
> > Is there an upstream link or reference for why 6.0.1 cannot support
> > non-x86 architectures?
> >
> > --
> >
> >
> > Neil Williams
> > =============
> > http://www.linux.codehelp.co.uk/
> >
> >

-- 

Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Fri, 25 Mar 2016 20:23:57 +0800
殷啟聰 <seamlikok@gmail.com> wrote:

> adb and fastboot are part of the Android SDK which are only officially
> supported on x86 platforms. Strictly speaking, Google only supports
> its i386 version, because the official SDK are mostly 32-bit
> softwares. Although the Android OS runs on x86, ARM and MIPS, the SDK
> does not.

"does not" or "is not supported on" ?

It's not the full SDK that is relevant necessarily. For automated
testing of AOSP development, adb and fastboot binaries are the
principle requirement.

> We don't want to maintain too many ports of them, there's too much
> work. More importantly, even if we can successfully build them on
> other platforms, we can't assure that they will work on other
> platforms.

There are established automated systems which could test exactly this
requirement. Users of such systems have expressed interest in doing
precisely this kind of testing, particularly for and on ARM
architectures. Once more suitable arm64 hardware is available (soon),
LAVA expects to be able to provide such testing but the lack of such
testing currently is not an excuse to remove the architecture just at
the point where this support could be offered.

> For example, we used to let android-libunwind build on
> other platforms but it FTBFS on MIPS. Another example, 64-bit dexdump
> won't work and we can only use its 32-bit version.

The use case for testing adb and fastboot does not have to include
dexdump. Equally, having a validation framework can assist in debugging
*why* dexdump does not work and *fixing* that bug and other bugs related
to architecture-specific flaws in the code.

> You can surely use adb and fastboot on a x86 computer to debug ARM
> phones, and I think most people do this?

This is not about debugging a single phone. This is about automated
testing of dozens of phones and other devices across a range of
infrastructure to do automated testing of AOSP builds to support kernel
development and mainline testing.

LAVA (lava-dispatcher specifically) uses adb and fastboot to deploy and
test on multiple devices. As an ARM test facility, there is a strong
interest in testing using ARM infrastructure wherever possible - that
way we can test the mobile device and the enterprise server at the same
time. If there are tests that can or need to be run to validate adb and
fastboot themselves, those can be run on the server hardware but still
within the same CI framework.

lava.debian.net is the Debian LAVA instance but this is in early stages
of device integration. validation.linaro.org is the established
instance and runs large numbers of AOSP tests on a wide range of ARM
devices.

So ports of adb and fastboot could be tested and validated on ARM
platforms, that is why ARM builds should not be dropped.

The previous builds of adb and fastboot were not tested within Debian
but using this as an excuse to remove them when an established test
system is gaining support to provide that testing does not make sense.
There is an expectation from users that LAVA will be able to use arm64
servers to run tests inside LAVA as part of a CI framework for arm64
kernel support. Hardware to do this is pending but to complete this
service, LAVA needs ARM builds of adb and fastboot. Equally, LAVA can
be used to provide the very testing that has been missing in the past.

If there are no other reasons for shortening the architecture list, at
least arm64 should be recovered. However, with devices like the
cubietruck already running lava-dispatcher services, there is no
particular reason to drop armhf either. Building those packages is not
a problem, the buildd framework is more than capable of that task.

Please retain arm64 and armhf architectures.

> 2016-03-25 4:58 GMT+08:00 Neil Williams <codehelp@debian.org>:
> > What is the reason for the removal of the ARM builds of adb and
> > fastboot? It seems odd to not support debug tools for ARM devices
> > from ARM devices.
> >
> > i386 is still supported, so it doesn't seem to be a 32bit issue -
> > even if it was, there should be no particular reason to drop arm64.
> >
> > Is there an upstream link or reference for why 6.0.1 cannot support
> > non-x86 architectures?
> >
> > --
> >
> >
> > Neil Williams
> > =============
> > http://www.linux.codehelp.co.uk/
> >
> >

-- 

Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]
So, looks like the LAVA team does need adb & fastboot on all ARM
platforms, right? :)

I was wrong about android-libunwind. Actually I remember it was
android-libbacktrace, which is needed by adb, who FTBFS in the other
platforms. What if android-libbacktrace still FTBFS on ARM? In that
case, adb won't be built either, and I fear this will even further
prevent our packages from migrating to testing. Actually, this bug
#817823 is already pulling it from migrating.

_hc, did you remember libbacktrace FTBFS on ARM or MIPS? Do you think
it's OK to build adb/fastboot and their dependencies on ARM and/or
MIPS?

[Message part 1 (text/plain, inline)]
On Sun, 27 Mar 2016 00:36:37 +0800
殷啟聰 <seamlikok@gmail.com> wrote:

> So, looks like the LAVA team does need adb & fastboot on all ARM
> platforms, right? :)

It would be useful and IMHO that is sufficient reason to keep arm64 and
probably armhf in the architecture list of the source package. The need
isn't immediate but as the architecture was previously supported and
the new upstream could soon be supported on arm64, it makes sense to
address this now instead of needing to add it back later.

The LAVA team would be a user of adb and could assist in validation
that it works (hardware for that is coming soon) but problems with
architecture-specific FTBFS would be investigated with the debian-arm
porters as normal.

> I was wrong about android-libunwind. Actually I remember it was
> android-libbacktrace, which is needed by adb, who FTBFS in the other
> platforms. What if android-libbacktrace still FTBFS on ARM? 

Has it been tried with the new upstream version? By dropping the
architecture from the list with the first upload, it didn't get tried.

> In that
> case, adb won't be built either, and I fear this will even further
> prevent our packages from migrating to testing. Actually, this bug
> #817823 is already pulling it from migrating.

817823 can be retitled to not affect selected architectures, those
binaries would then be replaced with the migration as normal, once the
other architecture binaries are removed. ftp.debian.org bugs like this
only occur when architectures previously supported get dropped by a
package, leaving cruft behind. Mark those architectures as supported
and the binaries are no longer cruft. What's blocking the migration is
the change in the list of architectures supported.

> _hc, did you remember libbacktrace FTBFS on ARM or MIPS? Do you think
> it's OK to build adb/fastboot and their dependencies on ARM and/or
> MIPS?

I can't see a bug report for an ARM-specific FTBFS:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=1;src=android-platform-system-core
or
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;repeatmerged=on;src=android-tools

-- 

Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Hey Neil,

Sounds like you are in the perfect position to do this porting and
maintenance since you are working with lots of ARM hardware, and want to
use the Android SDK on ARM as part of your regular work. So I think the
best workflow here is if you start building the android-tools packages
on ARM, and submitting fixes/patches as you go.  If you are committed to
doing this work, then I think it makes the most sense for you to join
the android-tools team, then directly commit to the git repos.
Otherwise, if you have just bits of time here and there, then submitting
patches in bug reports is probably the best way.

.hc

Neil Williams:
> On Sun, 27 Mar 2016 00:36:37 +0800
> 殷啟聰 <seamlikok@gmail.com> wrote:
> 
>> So, looks like the LAVA team does need adb & fastboot on all ARM
>> platforms, right? :)
> 
> It would be useful and IMHO that is sufficient reason to keep arm64 and
> probably armhf in the architecture list of the source package. The need
> isn't immediate but as the architecture was previously supported and
> the new upstream could soon be supported on arm64, it makes sense to
> address this now instead of needing to add it back later.
> 
> The LAVA team would be a user of adb and could assist in validation
> that it works (hardware for that is coming soon) but problems with
> architecture-specific FTBFS would be investigated with the debian-arm
> porters as normal.
> 
>> I was wrong about android-libunwind. Actually I remember it was
>> android-libbacktrace, which is needed by adb, who FTBFS in the other
>> platforms. What if android-libbacktrace still FTBFS on ARM? 
> 
> Has it been tried with the new upstream version? By dropping the
> architecture from the list with the first upload, it didn't get tried.
> 
>> In that
>> case, adb won't be built either, and I fear this will even further
>> prevent our packages from migrating to testing. Actually, this bug
>> #817823 is already pulling it from migrating.
> 
> 817823 can be retitled to not affect selected architectures, those
> binaries would then be replaced with the migration as normal, once the
> other architecture binaries are removed. ftp.debian.org bugs like this
> only occur when architectures previously supported get dropped by a
> package, leaving cruft behind. Mark those architectures as supported
> and the binaries are no longer cruft. What's blocking the migration is
> the change in the list of architectures supported.
> 
>> _hc, did you remember libbacktrace FTBFS on ARM or MIPS? Do you think
>> it's OK to build adb/fastboot and their dependencies on ARM and/or
>> MIPS?
> 
> I can't see a bug report for an ARM-specific FTBFS:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=1;src=android-platform-system-core
> or
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;repeatmerged=on;src=android-tools
> 
> 
> 
> 
> _______________________________________________
> Android-tools-devel mailing list
> Android-tools-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
> 

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On Mon, 28 Mar 2016 10:19:45 +0200
Hans-Christoph Steiner <hans@at.or.at> wrote:

> Hey Neil,
> 
> Sounds like you are in the perfect position to do this porting and
> maintenance since you are working with lots of ARM hardware, and want
> to use the Android SDK on ARM as part of your regular work.

No, not the porting and I am not able to be a maintainer of any
android packages - I have quite enough Debian work to do already. I'm
offering the validation, at no point did I offer to do the porting.
That would be with the help of the ARM porters, as usual for packages
using official Debian architectures.

This isn't about adding an unofficial port. This is about *restoring*
previously *supported* architectures to the relevant packages. There's
no evidence of a FTBFS bug affecting previous versions of these
packages - it makes no sense to treat official Debian architectures in
this way. Why do you think that architecture-specific patches are going
to be necessary?

The new version of the package introduces a regression - this bug would
not be necessary otherwise. I am providing a use case for the
*existing* maintainers to limit the impact of that regression and
provide *some* of the support available with previous versions of the
same packages.

By all means, if there are concerns about running the entire SDK then
the SDK support can be i386 only (as upstream don't support amd64 for
the SDK either) - but the arm64 and armhf packages providing adb and
fastboot should not be dropped as there is a clear use case for these
to exist in Debian provided that these packages are built using the
standard buildd framework and on the official mirrors.

> So I
> think the best workflow here is if you start building the
> android-tools packages on ARM, and submitting fixes/patches as you
> go. 

Why should it require me to build unofficial packages? We have the
buildd framework for that. This is about validation of packages in
Debian, not random manual builds on hardware outside the control of DSA.

> If you are committed to doing this work, then I think it makes
> the most sense for you to join the android-tools team, then directly
> commit to the git repos. Otherwise, if you have just bits of time
> here and there, then submitting patches in bug reports is probably
> the best way.

Sorry, that's impossible. I have time to work with using adb and
fastboot on arm64 hardware in LAVA when that hardware becomes available
and provide data to the android maintainers on the performance of the
supported arm64 (and possibly armhf) packages.

-- 

Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]
We are only talking about official packages. I think some of the
confusion stems from there being an "android-tools" team which manages
many packages and an "android-tools" source package, which is the old
deprecated approach for building adb, fastboot, and fsutils.

I didn't realize that the android-tools source package was ported to all
the other arches. We haven't updated the android-tools source package,
we have created a whole new set of source packages that are much closer
to upstream than the android-tools package. Those new source packages
are what would have to be ported.

On amd64 and i386, the new team source packages have completely replaced
the original android-tools source package. What we can do for the other
arches is just keep the android-tools source package as it is. We have
no plans to update or maintain it though, so it would be orphaned.

here are all the team packages:
https://qa.debian.org/developer.php?email=android-tools-devel%40lists.alioth.debian.org

.hc

Neil Williams:
> On Mon, 28 Mar 2016 10:19:45 +0200
> Hans-Christoph Steiner <hans@at.or.at> wrote:
> 
>> Hey Neil,
>>
>> Sounds like you are in the perfect position to do this porting and
>> maintenance since you are working with lots of ARM hardware, and want
>> to use the Android SDK on ARM as part of your regular work.
> 
> No, not the porting and I am not able to be a maintainer of any
> android packages - I have quite enough Debian work to do already. I'm
> offering the validation, at no point did I offer to do the porting.
> That would be with the help of the ARM porters, as usual for packages
> using official Debian architectures.
> 
> This isn't about adding an unofficial port. This is about *restoring*
> previously *supported* architectures to the relevant packages. There's
> no evidence of a FTBFS bug affecting previous versions of these
> packages - it makes no sense to treat official Debian architectures in
> this way. Why do you think that architecture-specific patches are going
> to be necessary?
> 
> The new version of the package introduces a regression - this bug would
> not be necessary otherwise. I am providing a use case for the
> *existing* maintainers to limit the impact of that regression and
> provide *some* of the support available with previous versions of the
> same packages.
> 
> By all means, if there are concerns about running the entire SDK then
> the SDK support can be i386 only (as upstream don't support amd64 for
> the SDK either) - but the arm64 and armhf packages providing adb and
> fastboot should not be dropped as there is a clear use case for these
> to exist in Debian provided that these packages are built using the
> standard buildd framework and on the official mirrors.
>
>> So I
>> think the best workflow here is if you start building the
>> android-tools packages on ARM, and submitting fixes/patches as you
>> go. 
> 
> Why should it require me to build unofficial packages? We have the
> buildd framework for that. This is about validation of packages in
> Debian, not random manual builds on hardware outside the control of DSA.
>
>> If you are committed to doing this work, then I think it makes
>> the most sense for you to join the android-tools team, then directly
>> commit to the git repos. Otherwise, if you have just bits of time
>> here and there, then submitting patches in bug reports is probably
>> the best way.
> 
> Sorry, that's impossible. I have time to work with using adb and
> fastboot on arm64 hardware in LAVA when that hardware becomes available
> and provide data to the android maintainers on the performance of the
> supported arm64 (and possibly armhf) packages.
> 

We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

android-liblog |       21-6 | arm64, armel, armhf, mips, mips64el, mipsel, powerpc, ppc64el, s390x
android-liblog-dev |       21-6 | arm64, armel, armhf, mips, mips64el, mipsel, powerpc, ppc64el, s390x

------------------- Reason -------------------
ANAIS; old binaries in architectures not allowed anymore
----------------------------------------------

Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it).  Please also remember that the changes have been done on the
master archive and will not propagate to any mirrors until the next
dinstall run at the earliest.

Packages are usually not removed from testing by hand. Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems. The release team can force a removal from testing if it is
really needed, please contact them if this should be the case.

Bugs which have been reported against this package are not automatically
removed from the Bug Tracking System.  Please check all open bugs and
close them or re-assign them to another package if the removed package
was superseded by another one.

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 817823@bugs.debian.org.

The full log for this bug can be viewed at https://bugs.debian.org/817823

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Chris Lamb (the ftpmaster behind the curtain)