Bug#848852: [Android-tools-devel] Bug#848852: adb command error with backtrace

2016-12-21 Thread Senthil Kumaran S


On Tuesday 20 December 2016 04:11 PM, Hans-Christoph Steiner wrote:
> what about the sid and stretch instances?  Do they also have the package
> version mismatch?

No they won't, since it is a fresh installation of sid and stretch
within a qemu device on top of jessie host.

-- 
Senthil Kumaran S
http://www.stylesen.org/
http://www.sasenthilkumaran.com/



signature.asc
Description: OpenPGP digital signature


Bug#848852: [Android-tools-devel] Bug#848852: adb command error with backtrace

2016-12-20 Thread Hans-Christoph Steiner

what about the sid and stretch instances?  Do they also have the package
version mismatch?



Bug#848852: adb command error with backtrace

2016-12-20 Thread Senthil Kumaran S


On Tuesday 20 December 2016 03:05 PM, Hans-Christoph Steiner wrote:
> Do the LAVA instances with the URLs have the same problem?

The instance ie., staging02.lavalab runs jessie as seen below:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 8.6 (jessie)
Release:8.6
Codename:   jessie


> We need to add versioned Depends: to packages like adb.  Right now adb
> just "Depends: android-libadb" which is problematic.  It should be
> "Depends: android-libadb (>= 7.0.0+r1~).

Yes that will help solving the purge issue.

-- 
Senthil Kumaran S
http://www.stylesen.org/
http://www.sasenthilkumaran.com/



signature.asc
Description: OpenPGP digital signature


Bug#848852: adb command error with backtrace

2016-12-20 Thread Hans-Christoph Steiner

Do the LAVA instances with the URLs have the same problem?

We need to add versioned Depends: to packages like adb.  Right now adb
just "Depends: android-libadb" which is problematic.  It should be
"Depends: android-libadb (>= 7.0.0+r1~).



Bug#848852: adb command error with backtrace

2016-12-20 Thread Senthil Kumaran S


On Tuesday 20 December 2016 02:51 PM, Hans-Christoph Steiner wrote:
> I can't reproduce these on my stretch amd64 chroot, adb works fine for
> me.  So we'll need to figure how what in the environment is triggering
> the issue.  Are all the machines mentioned here ARM? Or what arches?

All these machines are amd64.

> For "adb: symbol lookup error: adb: undefined symbol: kFeatureShell2",
> my guess is that your android-libadb package has a different version
> than your adb package.  They should all have an exact matching upstream
> version (7.0.0+r1). Can you include the output of this:

I had android-tools-adb installed previously in this machine. I did the
following to upgrade:

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get purge android-tools-adb
$ sudo apt-get install adb

(Maybe, the purge didn't work reliably and left some old libraries?)

> dpkg -l adb

Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  adb1:7.0.0+r1-1 amd64Android Debug Bridge


> dpkg -l android-lib*

Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  android-libadb 1:6.0.1+r55- amd64Library for Android Debug
Bridge
ii  android-libbac 1:7.0.0+r1-1 amd64Android backtrace library
ii  android-libbas 1:7.0.0+r1-1 amd64Android base library
ii  android-libcut 1:7.0.0+r1-1 amd64Android utils library for C
ii  android-libext 7.0.0+r1-2   amd64Android ext4 utility library
ii  android-libf2f 7.0.0+r1-2   amd64Android F2FS utility library
ii  android-liblog 1:7.0.0+r1-1 amd64Android NDK logger interfaces
ii  android-libsel 7.0.0+r1-2   amd64Security-Enhanced Linux for
Andro
ii  android-libspa 1:7.0.0+r1-1 amd64Library for sparse files
ii  android-libunw 7.0.0+r1-3   amd64libunwind for Android
ii  android-libuti 1:7.0.0+r1-1 amd64Android Utility Function
Library
ii  android-libzip 1:7.0.0+r1-1 amd64Library for ZIP archives


> My guess is that this change in the exit int of adb comes from upstream.
>  It seems appropriate for adb to exit with 1 in this case, no?

Yes it should exit with a 1 when there is a backtrace.

Thank You.
-- 
Senthil Kumaran S
http://www.stylesen.org/
http://www.sasenthilkumaran.com/



Bug#848852: adb command error with backtrace

2016-12-20 Thread Hans-Christoph Steiner

I can't reproduce these on my stretch amd64 chroot, adb works fine for
me.  So we'll need to figure how what in the environment is triggering
the issue.  Are all the machines mentioned here ARM? Or what arches?

For "adb: symbol lookup error: adb: undefined symbol: kFeatureShell2",
my guess is that your android-libadb package has a different version
than your adb package.  They should all have an exact matching upstream
version (7.0.0+r1). Can you include the output of this:

dpkg -l adb
dpkg -l android-lib*



> This also changes the behavior of adb command where, previously ie., as in 
> case
> of jessie the command exits with a 0 when the daemon is not started, but now
> ie., as in case of stretch and sid the command exits with a 1.


My guess is that this change in the exit int of adb comes from upstream.
 It seems appropriate for adb to exit with 1 in this case, no?

.hc



Bug#848852: adb command error with backtrace

2016-12-20 Thread Senthil Kumaran S
Package: adb
Version: 1:7.0.0+r1-1
Severity: normal

Dear Maintainer,

I upgraded to the latest version of adb in my machine and while trying to use
adb command I get the following error:


stylesen@harshu:~$ adb devices
adb: symbol lookup error: adb: undefined symbol: kFeatureShell2
stylesen@harshu:~$ sudo adb devices
adb: symbol lookup error: adb: undefined symbol: kFeatureShell2
stylesen@harshu:~$ sudo su
root@harshu:/home/stylesen# adb devices
adb: symbol lookup error: adb: undefined symbol: kFeatureShell2
root@harshu:/home/stylesen#


The expected result is to start the adb daemon if it was not running and list
the devices attached, if any.

Alternatively, I tried adb within an LXC container, which throws a detailed
trace just for the first time adb gets started, as seen in this paste -
http://paste.debian.net/903367/

Also, I ve reproduced this bug with the help of LAVA (Linaro Automated
Validation Architecture) in stretch and sid. This does not occur in jessie. It
is reproducible consistently.

stretch:
  job - https://staging.validation.linaro.org/scheduler/job/158283.2
  error - https://staging.validation.linaro.org/scheduler/job/158283.2#L790

sid:
  job - https://staging.validation.linaro.org/scheduler/job/158283.0
  error - https://staging.validation.linaro.org/scheduler/job/158283.0#L802

jessie:
  job - https://staging.validation.linaro.org/scheduler/job/158283.1
  error - https://staging.validation.linaro.org/scheduler/job/158283.1#L772

Top level job - https://staging.validation.linaro.org/scheduler/job/158283

This also changes the behavior of adb command where, previously ie., as in case
of jessie the command exits with a 0 when the daemon is not started, but now
ie., as in case of stretch and sid the command exits with a 1.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages adb depends on:
ii  android-libadb 1:6.0.1+r55-1
ii  android-libbase1:7.0.0+r1-1
ii  android-libcutils  1:7.0.0+r1-1
ii  libc6  2.24-8
ii  libgcc11:6.2.1-5
ii  libstdc++6 6.2.1-5

Versions of packages adb recommends:
ii  android-sdk-platform-tools-common  23.0.0+4

adb suggests no packages.

-- no debconf information