Bug#1062209: should not block migration to testing

[Hans-Christoph Steiner]

control: severity -1 normal

Thanks for reporting!  In the Android Tools case, the shared libs and packages 
that use them are packaged together, often from the same source package, so I 
can't see why we'd need special versions of it. And when we need to, we can use 
strictly versioned depends, so it should be fine. I'm going to set the bug to 
normal for now.

Bug#1062105: should not block migration to testing

[Hans-Christoph Steiner]

control: severity -1 normal

Thanks for reporting!  In the Android Tools case, the shared libs and packages 
that use them are packaged together, often from the same source package, so I 
can't see why we'd need special versions of it. And when we need to, we can use 
strictly versioned depends, so it should be fine. I'm going to set the bug to 
normal for now.

Bug#1034346: usrmerge: fails to install on Xen VPS due to /lib/modules mount

[Hans-Christoph Steiner]

Package: usrmerge
Version: 25
Severity: serious

I have some VPSes which are based on Xen, so the kernel comes from the host, and 
the VPS has no kernel installed.  /lib/modules is mounted but not via 
/etc/fstab.  When trying to upgrade from bullseye to bookworm, I get:


Preparing to unpack .../archives/usrmerge_35_all.deb ...
Unpacking usrmerge (35) ...
Setting up usrmerge (35) ...

FATAL ERROR:

/lib/modules/ is a mount point.
Probably this system is using User Mode Linux.

To continue the conversion please:
- replace '/lib/modules/' with '/usr/lib/modules/' in /etc/fstab
- reboot
- try again

E: usrmerge failed.
dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error 
exit status 1

Errors were encountered while processing:
 usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)


Here is some more info which should hopefully be helpful:

# umount /lib/modules/
umount: /lib/modules/: target is busy.
# lsof /lib/modules
COMMANDPID USER  FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-u 1145 root memREG   0,20   1503845 
/lib/modules/5.10.104/modules.symbols.bin
systemd-u 1145 root memREG   0,20   3224788 
/lib/modules/5.10.104/modules.alias.bin
systemd-u 1145 root memREG   0,20   119456   10 
/lib/modules/5.10.104/modules.dep.bin
systemd-u 1145 root memREG   0,20 76634 
/lib/modules/5.10.104/modules.builtin.bin

# ps -ef|grep 1145
root  1145 1  0 09:29 ?00:00:00 /lib/systemd/systemd-udevd
root 16599 25980  0 10:11 pts/100:00:00 grep 1145
# dpkg -l linux*
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)
||/ NameVersion  Architecture Description
+++-===---===
un  linux-kernel-log-daemon   (no description available)
ii  linux-libc-dev:amd646.1.20-1 amd64Linux support headers for 
userspace development

# mount |grep /lib
modules on /lib/modules type tmpfs (rw,relatime,size=102400k,mode=700)
# cat /etc/fstab

/dev/xvda1  /   xfs defaults0   0
proc/proc   procdefaults0   0
#

Bug#1029668: confirmed

[Hans-Christoph Steiner]

I'm having the same problem on bookworm, for me, I'm using the default eog 
viewer.  There is a new upstream version of libheif available (v1.15.1), there 
is still time to upload that to bookworm.  I'm a DD and I could do an NMU if 
that is helpful

Bug#1011567: needs com.sun.javadoc migration

[Hans-Christoph Steiner]

Looks like doclava would need to be ported to use the API that replaces 
com.sun.javadoc:


https://docs.oracle.com/en/java/javase/11/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration

If someone does the migration, I can take care of the packaging updates.

Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12

[Hans-Christoph Steiner]

Roger, it is great to see your progress on android-platform-tools.  Are you 
thinking of trying to get it into bookworm?  If so, let me know how I can help. 
It would be really valuable to have there, but I don't know how much work it'll be.

Bug#1012103: upstream still uses java8

[Hans-Christoph Steiner]

Doclava, which does not work with Java newer than 11.  Upstream still builds it 
with java8. As in Android 13 still uses java8 in the build.  Is there any hope?

Bug#1026083: Security: XSS bug in Loofah

[Hans-Christoph Steiner]

Package: ruby-loofah
Version: 2.19.0-1
Severity: serious

control: affects -1 ruby-loofah/2.1.0
control: affects -1 ruby-loofah/2.7.0+dfsg-1
control: tags -1 fixed-upstream security help

An XSS issue has been discovered in Loofah:
https://github.com/flavorjones/loofah/security/advisories/GHSA-228g-948r-83gx

It is fixed in the upstream release v2.19.1.

Bug#1007977: [Android-tools-devel] Bug#1007977: android-platform-system-core: builds adb which is also built (at a higher version) by android-platform-tools

[Hans-Christoph Steiner]

Right, this is an ongoing, incomplete migration.  Anything that is built in 
android-platform-tools should be removed from android-platform-system-core or 
any other android-platform-* packages.  We welcome contributions there!

Bug#982046: marked as pending in golang-github-avast-apkverifier

[Hans-Christoph Steiner]

Control: tag -1 pending

Hello,

Bug #982046 in golang-github-avast-apkverifier reported by you has been fixed 
in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-avast-apkverifier/-/commit/10b6ee64330ddc9a90328db8e6b5de650c0f8d1e


autopkgtest needs ca-certificates (Closes: #982046)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/982046

Bug#973082: confirmed

[Hans-Christoph Steiner]

Great!  Then it sounds like it should be included.  It is a Python Team package 
and the source code is on salsa, so feel free to go ahead and upload.

Bug#973082: confirmed

[Hans-Christoph Steiner]

Do the tests pass with this patch?

Bug#980644: [Android-tools-devel] Bug#980644: android-sdk-platform-tools-common: no Multi-Arch annotation prevents adb upgrade

[Hans-Christoph Steiner]

Control: severity -1 normal

Right now, we can only commit to supporting the arches that upstream supports 
(amd64 and arm64), so I'm downgrading the severity.


I could never wrap my head around the Multi-Arch: stuff.  I would accept a merge 
request on salsa for this, if it passes in gitlab-ci.

Bug#972377: can't reproduce

[Hans-Christoph Steiner]

can't reproduce

Bug#975747: reopen the close to work around BTS bug

[Hans-Christoph Steiner]

Control: reopen -1

Bug#977912: This is due to aapt's linking error.

[Hans-Christoph Steiner]

Control: reassign -1 aapt
Control: merge 977023 977912

This is due to aapt's linking error.  The fdroidserver tests rely on aapt.

Bug#975747: this is actually fixed

[Hans-Christoph Steiner]

Control: fixed -1 1:10.0.0+r36-1
Control: fixed -1 1:10.0.0+r36-2
Control: fixed -1 1:10.0.0+r36-3
Control: fixed -1 1:10.0.0+r36-4

Bug#979329: I think I have a fix

[Hans-Christoph Steiner]

Control: tags -1 pending confirmed

This is also confirmed by CI:
https://salsa.debian.org/android-tools-team/android-platform-system-core/-/jobs/1310262

Testing a fix here:
https://salsa.debian.org/eighthave/android-platform-system-core/-/jobs/1314158

Bug#973082: confirmed

[Hans-Christoph Steiner]

Control: tags -1 help confirmed

In Python 3.9, the plistlib was changed to no longer have the internal 
data structure plistlib.Data, which biplist relied on.  Here's a 
potential fix:


https://github.com/unified-font-object/ufoNormalizer/pull/74/files

Bug#972377: can't reproduce

[Hans-Christoph Steiner]

Control: fixed -1 1.6.1-2

I can't reproduce this, perhaps it was fixed by the upgrade to Python 
3.9.  For example:


https://salsa.debian.org/python-team/packages/pyasn/-/pipelines/214872

Bug#976891: Unable to find next sigaction in signal chain

[Hans-Christoph Steiner]

Now fastboot and aapt build and link but both report this error:

   Unable to find next sigaction in signal chain

Looks like some dynamically loaded code is missing, the error is in 
sigchainlib/sigchain.cc:


static void lookup_next_symbol(T* output, T wrapper, const char* name) {
  void* sym = dlsym(RTLD_NEXT, name);  // NOLINT glibc triggers 
cert-dcl16-c with RTLD_NEXT.

  if (sym == nullptr) {
sym = dlsym(RTLD_DEFAULT, name);
if (sym == wrapper || sym == sigaction) {
  fatal("Unable to find next %s in signal chain", name);
}
  }
  *output = reinterpret_cast(sym);
}

Bug#976891: update

[Hans-Christoph Steiner]

fastboot is getting pretty close to working on amd64:

https://salsa.debian.org/eighthave/android-platform-system-core/-/jobs/1297944

Bug#963058: upstream only supports x86

[Hans-Christoph Steiner]

Control: severity -1 wishlist
Control: retitle -1 port android-platform-art to ARM, etc.

Bug#963058: [Android-tools-devel] Bug#963058: still ftbfs on arm64

[Hans-Christoph Steiner]

It looks like upstream does not support anything but x86, and they've 
added assembly code.  So unless someone steps up to port that to ARM, 
the ARM binaries will be removed.

Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message

[Hans-Christoph Steiner]

also, it looks like libunwindstack uses asm and there isn't any for ARM. 
 So if someone wants to keep the arm packages, they'll need to figure 
that out.  I have zero asm skills.

Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message

[Hans-Christoph Steiner]

Roger Shimizu:

On Wed, Dec 30, 2020 at 3:46 AM Hans-Christoph Steiner  wrote:


Ok, I fixed the dependency issue, now it gets reliably to the point rosh
gets to:


Thanks for fixing the build dependency issue!
I fixed a few other issues (operator script & mterp generation, etc),
and pushed to rosh/refine branch.

Current build breaking point is the same as previous one.
I tried to use different c++ library, such as libstdc++-8-dev, and
clang-9, but seems no help.


I have android-platform-art building as a stage1 now, so I'm working 
again on android-platform-system-core.  I haven't found where these 
symbols are supposed to come from:


clang++ fastboot/bootimg_utils.cpp fastboot/fastboot.cpp 
fastboot/fastboot_driver.cpp fastboot/fs.cpp fastboot/main.cpp 
fastboot/socket.cpp fastboot/tcp.cpp fastboot/udp.cpp 
fastboot/usb_linux.cpp fastboot/util.cpp fs_mgr/liblp/builder.cpp 
fs_mgr/liblp/images.cpp fs_mgr/liblp/partition_opener.cpp 
fs_mgr/liblp/reader.cpp fs_mgr/liblp/utility.cpp fs_mgr/liblp/writer.cpp 
-o fastboot/fastboot -g -O2 
-fdebug-prefix-map=/build/android-platform-system-core-10.0.0+r36=. 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-std=gnu++2a -fpermissive -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG 
-UDEBUG -I/usr/include/android -DPLATFORM_TOOLS_VERSION='"28.0.2"' 
-Iinclude -Imkbootimg/include/bootimg -Iadb -Ibase/include 
-Idemangle/include -Idiagnose_usb/include -Ifs_mgr/include 
-Ifs_mgr/include_fstab -Ifs_mgr/liblp/include -I/usr/include/android 
-I/usr/include/android/f2fs_utils -I/usr/include/android/openssl 
-Ilibsparse/include -Ilibziparchive/include -Wl,-z,relro -Wl,-z,now 
-fPIC -Wl,-rpath=/usr/lib/x86_64-linux-gnu/android -Wl,-rpath-link=. -L. 
-lziparchive -lsparse -lbase -lcutils -ladb -lutils -lssl -lcrypto 
-L/usr/lib/x86_64-linux-gnu/android -lart -l7z -lunwind
/usr/bin/ld: /tmp/utility-794e29.o: in function 
`android::fs_mgr::GetDescriptorSize(int, unsigned long*)':
./fs_mgr/liblp/utility.cpp:49: undefined reference to 
`get_block_device_size'
/usr/bin/ld: ./libbacktrace.so.0: undefined reference to `typeinfo for 
art_api::dex::DexFile'


Check my forks for the most current commits:
https://salsa.debian.org/eighthave/android-platform-art
https://salsa.debian.org/eighthave/android-platform-system-core

.hc

Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message

[Hans-Christoph Steiner]

Hans-Christoph Steiner:

It looks like the clean build stops before the error you reported:

https://salsa.debian.org/eighthave/android-platform-art/-/jobs/1291335

In file included from runtime/runtime.cc:53:
runtime/asm_support.h:24:10: fatal error: 'asm_defines.h' file not found
#include "asm_defines.h"
  ^~~
1 error generated.
make[2]: *** [debian/libart.mk:473: runtime/runtime.o] Error 1

My guess is that the Makefile dependency rules are wrong, since the 
target that builds asm_defines.h works fine when manually run.


If you use your own fork, and force-push commits to your fork's master 
branch, it'll run the CI jobs, which are totally clean builds each time.


Ok, I fixed the dependency issue, now it gets reliably to the point rosh 
gets to:


https://salsa.debian.org/eighthave/android-platform-art/-/jobs/1291535

.hc

Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message

[Hans-Christoph Steiner]

It looks like the clean build stops before the error you reported:

https://salsa.debian.org/eighthave/android-platform-art/-/jobs/1291335

In file included from runtime/runtime.cc:53:
runtime/asm_support.h:24:10: fatal error: 'asm_defines.h' file not found
#include "asm_defines.h"
 ^~~
1 error generated.
make[2]: *** [debian/libart.mk:473: runtime/runtime.o] Error 1

My guess is that the Makefile dependency rules are wrong, since the 
target that builds asm_defines.h works fine when manually run.


If you use your own fork, and force-push commits to your fork's master 
branch, it'll run the CI jobs, which are totally clean builds each time.

Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message

[Hans-Christoph Steiner]

As far as I know, the blocker for fastbook is android-platform-art.  It 
has a crazy upstream build system.  Right now, it almost building, but 
the build is currently dying on this error:


clang++ -o runtime/compiler_filter.o -g -O2 
-fdebug-prefix-map=/build/android-platform-art-10.0.0+r36=. 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC -c 
-std=gnu++17 -Wno-invalid-offsetof -Wno-invalid-partial-specialization 
-D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -fno-rtti 
-fstrict-aliasing -fvisibility=protected -fno-omit-frame-pointer 
-Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -I/usr/include/android -UDEBUG 
-Umips -DART_BASE_ADDRESS_MAX_DELTA=0x100 
-DART_BASE_ADDRESS_MIN_DELTA=-0x100 -DART_BASE_ADDRESS=0x6000 
-DART_DEFAULT_COMPACT_DEX_LEVEL=fast -DART_DEFAULT_GC_TYPE_IS_CMS 
-DART_ENABLE_ADDRESS_SANITIZER=1 -DART_ENABLE_CODEGEN_arm 
-DART_ENABLE_CODEGEN_arm64 -DART_ENABLE_CODEGEN_mips 
-DART_ENABLE_CODEGEN_mips64 -DART_ENABLE_CODEGEN_x86 
-DART_ENABLE_CODEGEN_x86_64 -DART_FRAME_SIZE_LIMIT=1736 
-DART_READ_BARRIER_TYPE_IS_BAKER=1 -DART_STACK_OVERFLOW_GAP_arm=8192 
-DART_STACK_OVERFLOW_GAP_arm64=8192 -DART_STACK_OVERFLOW_GAP_mips=16384 
-DART_STACK_OVERFLOW_GAP_mips64=16384 
-DART_STACK_OVERFLOW_GAP_x86_64=8192 -DART_STACK_OVERFLOW_GAP_x86=8192 
-DART_USE_READ_BARRIER=1 -DBUILDING_LIBART=1 -DIMT_SIZE=43 
-DUSE_D8_DESUGAR=1 -I. -I/usr/include/android/nativehelper 
-I/usr/include/valgrind -Icmdline -Iruntime -Iruntime/generated 
-Ilibartbase -Ilibartpalette/include -Ilibdexfile -Ilibelffile 
-Ilibprofile -Isigchainlib -I/usr/include/android 
-Itools/cpp-define-generator -Idebian/out  runtime/compiler_filter.cc

In file included from tools/cpp-define-generator/asm_defines.cc:36:
In file included from tools/cpp-define-generator/asm_defines.def:21:
In file included from tools/cpp-define-generator/globals.def:23:
In file included from runtime/gc/accounting/card_table.h:22:
In file included from runtime/base/locks.h:25:
In file included from libartbase/base/atomic.h:27:
In file included from libartbase/base/macros.h:24:
/usr/include/android/android-base/thread_annotations.h:139:42: error: 
'acquire_capability' attribute requires arguments whose type is 
annotated with 'capability' attribute; type here is 'std::mutex' 
[-Werror,-Wthread-safety-attributes]

  ScopedLockAssertion(std::mutex& mutex) ACQUIRE(mutex) {}
 ^
/usr/include/android/android-base/thread_annotations.h:57:37: note: 
expanded from macro 'ACQUIRE'

  THREAD_ANNOTATION_ATTRIBUTE__(acquire_capability(__VA_ARGS__))
^
In file included from tools/cpp-define-generator/asm_defines.cc:36:
In file included from tools/cpp-define-generator/asm_defines.def:21:
In file included from tools/cpp-define-generator/globals.def:23:
In file included from runtime/gc/accounting/card_table.h:23:
libartbase/base/mem_map.h:71:35: error: 'requires_capability' attribute 
requires arguments whose type is annotated with 'capability' attribute; 
type here is 'bool' [-Werror,-Wthread-safety-attributes]

  MemMap(MemMap&& other) noexcept REQUIRES(!MemMap::mem_maps_lock_);
  ^
/usr/include/android/android-base/thread_annotations.h:51:37: note: 
expanded from macro 'REQUIRES'



A full build log is available here:
https://salsa.debian.org/android-tools-team/android-platform-art/-/jobs/1274438

Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message

[Hans-Christoph Steiner]

Thanks for jumping in Roger!  I reviewed it with cdesai, and we thought 
those libraries were not used on the "host" version, only when built as 
part of Android OS.  I do think libfec would be useful if someone wants 
to package adbd for Debian.  The Google Android Tools builds do not 
include adbd for the host, only for the Android OS.


Right now, the only blocker I know about is the assembler code in 
android-platform-art, which Michel and I are working on now.

Bug#976718: [Android-tools-devel] Bug#976718: fastboot is completely broken

[Hans-Christoph Steiner]

Control: severity -1 normal
Control: retitle -1 fastboot 10.0.0+r36 not buildable

There is a chance that fastboot won't make it into Bullseye, even though 
the rest of android-platform-system-core will.  In that case, fastboot 
would be removed entirely.  This script is a migration helper, so I'm 
downgrading the severity.


If fastboot is important to you, we welcome contributions!

Bug#966912: fixed in 1:10.0.0+r36-1

[Hans-Christoph Steiner]

Control: fixed -1 1:10.0.0+r36-1


Oops, forgot to mark it in the changelog

Bug#972041: not a showstopper

[Hans-Christoph Steiner]

Control: severity -1 normal

I don't think packages should be kicked of testing for this issue since 
things are working.  We will update as needed if the ABI in question 
changes in future updates.

Bug#959904: marked as pending in android-platform-system-tools-hidl

[Hans-Christoph Steiner]

Control: tag -1 pending

Hello,

Bug #959904 in android-platform-system-tools-hidl reported by you has been 
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/android-tools-team/android-platform-system-tools-hidl/-/commit/df6aa1b8a65011b9161b8230709fa65bbf17b944


Correct patches to resolve FTBFS Bug (Closes: #959904)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/959904

Bug#961702: git breaks fdroidserver autopkgtest: Failed to parse line: ' git config pull.rebase false

[Hans-Christoph Steiner]

Control: notfound -1 fdroidserver/1.1.7-1
Control: found -1 python3-git/3.1.1-1

I can't find any possible reference in fdroidserver, or in python3-git
for that matter.  My guess is that the issue is caused by python3-git
failing to parse something that was added in the most recent git.  So
I'm reassigning this to python3-git since the stacktrace shows the issue
happening pretty deep inside python3-git, and the fdroidserver code does
not call `git config` in anyway that I can figure out.

Paul Gevers:
> Source: git, fdroidserver
> Control: found -1 git/1:2.27.0~rc2-1
> Control: found -1 fdroidserver/1.1.7-1
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of git the autopkgtest of fdroidserver fails in
> testing when that autopkgtest is run with the binary packages of git
> from unstable. It passes when run with only packages from testing. In
> tabular form:
> 
>passfail
> gitfrom testing1:2.27.0~rc2-1
> fdroidserver   from testing1.1.7-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of git to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=git
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/f/fdroidserver/5667747/log.gz
> 
> CRITICAL: Unknown exception found!
> Traceback (most recent call last):
>   File "/usr/bin/fdroid", line 170, in 
> main()
>   File "/usr/bin/fdroid", line 165, in main
> raise e
>   File "/usr/bin/fdroid", line 146, in main
> mod.main()
>   File "/usr/lib/python3/dist-packages/fdroidserver/server.py", line
> 759, in main
> push_binary_transparency(BINARY_TRANSPARENCY_DIR,
>   File "/usr/lib/python3/dist-packages/fdroidserver/server.py", line
> 584, in push_binary_transparency
> local.pull('master')
>   File "/usr/lib/python3/dist-packages/git/remote.py", line 812, in pull
> res = self._get_fetch_info_from_stderr(proc, progress)
>   File "/usr/lib/python3/dist-packages/git/remote.py", line 708, in
> _get_fetch_info_from_stderr
> output.extend(FetchInfo._from_line(self.repo, err_line, fetch_line)
>   File "/usr/lib/python3/dist-packages/git/remote.py", line 708, in
> 
> output.extend(FetchInfo._from_line(self.repo, err_line, fetch_line)
>   File "/usr/lib/python3/dist-packages/git/remote.py", line 292, in
> _from_line
> raise ValueError("Failed to parse line: %r" % line)
> ValueError: Failed to parse line: '  git config pull.rebase false  #
> merge (the default strategy)'
> 

Bug#955695: 1.5.2 has different error

[Hans-Christoph Steiner]

I'm trying to build Manas Kashyap's 1.5.2 update, and got a different
error.  And gradle/wrapper/gradle-wrapper.properties says gradle 5.2.1,
so it looks like they might have added some new gradle tricks

Included projects: [root project 'com.ibm.wala', project
':com.ibm.wala-repository', project ':com.ibm.wala.cast', project
':com.ibm.wala.cast.java', project ':com.ibm.wala.cast.test', project
':com.ibm.wala.core', project ':com.ibm.wala.dalvik', project
':com.ibm.wala.scandroid', project ':com.ibm.wala.shrike', project
':com.ibm.wala.tests.ide_feature', project
':com.ibm.wala.tests_feature', project ':com.ibm.wala.util', project
':com.ibm.wala_feature', project ':com.ibm.wala.cast.test:smoke_main',
project ':com.ibm.wala.cast.test:xlator_test', project
':com.ibm.wala.cast:cast']
Keep-alive timer started
Adding Debian repository to project 'com.ibm.wala'
Adding Debian repository to project 'com.ibm.wala-repository'
Adding Debian repository to project 'com.ibm.wala.cast'
Adding Debian repository to project 'com.ibm.wala.cast.java'
Adding Debian repository to project 'com.ibm.wala.cast.test'
Adding Debian repository to project 'com.ibm.wala.core'
Adding Debian repository to project 'com.ibm.wala.dalvik'
Adding Debian repository to project 'com.ibm.wala.scandroid'
Adding Debian repository to project 'com.ibm.wala.shrike'
Adding Debian repository to project 'com.ibm.wala.tests.ide_feature'
Adding Debian repository to project 'com.ibm.wala.tests_feature'
Adding Debian repository to project 'com.ibm.wala.util'
Adding Debian repository to project 'com.ibm.wala_feature'
Adding Debian repository to project 'smoke_main'
Adding Debian repository to project 'xlator_test'
Adding Debian repository to project 'cast'
Evaluating root project 'com.ibm.wala' using build file
'/build/wala-1.5.2/build.gradle'.
Compiling build file '/build/wala-1.5.2/build.gradle' using
SubsetScriptTransformer.
Compiling build file '/build/wala-1.5.2/build.gradle' using
BuildScriptTransformer.

FAILURE: Build failed with an exception.

* Where:
Build file '/build/wala-1.5.2/build.gradle' line: 35

* What went wrong:
A problem occurred evaluating root project 'com.ibm.wala'.
> Could not find method named() for arguments [test] on task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.

Bug#955695: probably because of libsmali-java update from 2.3.3 to 2.4

[Hans-Christoph Steiner]

My guess is that this issue was caused by the libsmali-java update from
2.3.3 to 2.4.  Hopefuilly its a small fix.

Bug#936790: keysync: Python2 removal in sid/bullseye

[Hans-Christoph Steiner]

Moritz Mühlenhoff:
> On Fri, Aug 30, 2019 at 07:22:02AM +, Matthias Klose wrote:
>> Package: src:keysync
>> Version: 0.2.2-2
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
>>
>> Python2 becomes end-of-live upstream, and Debian aims to remove
>> Python2 from the distribution, as discussed in
>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>>
>> Your package either build-depends, depends on Python2, or uses Python2
>> in the autopkg tests.  Please stop using Python2, and fix this issue
>> by one of the following actions.
> 
> There's no update at https://dev.guardianproject.info/issues/2478.html
> at all, let's remove keysync?

Works for me.

.hc

Bug#954395: binfmt went away

[Hans-Christoph Steiner]

Control: severity -1 important

This is most likely due to binfmt support being removed from the
autopkgtest runner.  Java CLI executables require the Linux binfmt_misc
kernel module to be loaded for a .JAR to find the java executable.

Bug#894284: blocked by Kotlin

[Hans-Christoph Steiner]

Once kotlin is in Debian, then we can use newer upstream versions, which
support the latest JDK.

Bug#953818: python-paver: should this package be removed?

[Hans-Christoph Steiner]

Please remove!

Sandro Tosi:
> Package: python-paver
> Severity: serious
> 
> Hello,
> i believe this package should be removed:
> 
> * python2-only
> * while upstream has released a py3k compatible version (and several others in
>   between the one in the archive), the debian maintainer didnt upload this
>   package since late 2013
> * no rdeps
> * extremely low popcon
> 
> if i dont hear back within a week to keep this package, i'll file for its
> removal.
> 
> Regards,
> Sandro
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages python-paver depends on:
> ii  libjs-jquery  3.3.1~dfsg-3
> ii  python2.7.16-1
> 
> python-paver recommends no packages.
> 
> python-paver suggests no packages.
> 

Bug#929905: autoremoval of fdroidserver

[Hans-Christoph Steiner]

Control: severity 929905 important

Please keep it in buster, I would like to go the point release route.

Bug#924591: this requires linking in libsparse, which is from Android sources

[Hans-Christoph Steiner]

Theodore Ts'o:
> On Mon, Apr 22, 2019 at 06:09:23PM +0200, Jonas Meurer wrote:
>> Hans-Christoph Steiner:
>>> Theodore Ts'o:
>>>> So your choice --- we can either reassign this bug back to fastboot or
>>>> android-sdk-platforms-tools, or I can downgrade the severity of this
>>>> bug for e2fsprogs down to wishlist[1].  Let me know how you want to
>>>> handle this.
>>>>
>>>> [1] This is because I view this both as a "feature request" and "bugs
>>>> that are very difficult to fix due to major design considerations"
>>>> (per https://www.debian.org/Bugs/Developer#severities), not to mention
>>>> that it's going to affect a miniscule fraction of the e2fsprogs
>>>> package's users.
>>>
>>> Makes sense to me.  I'm fine with this being done post-Buster or as a
>>> custom mke2fs in android-platform-system-core.
>>
>> So the bottom line here is that the ext4 formatting support in fastboot
>> remains broken in Buster, right? That would be very unfortunate and a
>> regression compared to Stretch.
> 
> I'm not sure whether or not Stretch was using the old-style
> make_ext4fs from AOSP, or was including the mke2fs from AOSP, but yes,
> it sounds like it's a regression from stretch.  I'm not sure how many
> Debian users are using the Debian-native fastboot versus using the
> version from the Google SDK or the AOSP binaries, though.
> 
> It does seem that if this is considered high priority, the most
> straightforward way to address this bug is going to be to include
> building mke2fs from AOSP and placing it in
> /usr/lib/android-sdk/platform-tools/mke2fs.  I know some folks on the
> android tools teams aren't excited with that approach, but that
> probably is the best thing to do if you want to address this in
> Buster.

That approach sounds fine for buster.  The only question in my mind is
who will do the work...

I don't really know how fastboot in stretch provided the mke2fs support,
but judging by the dependencies, it might have been that fastboot used
to do the formatting itself, based on being linked to
android-libext4-utils and android-libsparse.  The buster version of
fastboot is clearly calling mk2efs, which in AOSP is built from an
inline e2fsprogs fork.

.hc

Bug#924591: this requires linking in libsparse, which is from Android sources

[Hans-Christoph Steiner]

Theodore Ts'o:
> On Thu, Apr 18, 2019 at 09:32:06PM +0200, Hans-Christoph Steiner wrote:
>>
>> One possibility would be including libsparse as a patch, it doesn't
>> change a lot:
>> https://android.googlesource.com/platform/system/core/+log/master/libsparse
>>
>> But it depends on Android's libbase and libz-host.
> 
> This might be "serious" bug from the fastboot package's perspective,
> but there's no way in heck the release time is going to consider this
> a bug that is "serious" priority for e2fsprogs.
> 
> More to the point, there's now way in the world I (or the release and
> installer teams) are going to make e2fsprogs, which is an
> "important=yes" package with priority "required" drag in the
> android-libsparse, android-libbase, and zlib1g packages.
> 
> So the way you changed android-sdk-platforms-tools to use /sbin/mke2fs
> was a really bad choice, especially this while we are in release
> freeze for Buster.  There's no way in the world we are going to make a
> change like this to a package like e2fsprogs which is used by the
> installer at this point.
> 
> If we had more time, and if android-libsparse-dev shipped a static
> library, we could have considered statically linking in
> android-libsparse, android-libbase, and libz --- and see if they would
> bloat the mke2fs and debugfs binaries by only a minimal amount.
> 
> This would also require making changes to e2fsprogs configure and
> Makefiles, since currently we only have support for linking in
> libsparse in the AOSP build files.  The reason for this is historical;
> at the time when the intern working with Android team was working on
> replace Android's make_ext4fs program with mke2fs and e2droid, there
> was no distribution that was shipping libsparse, and trying to make
> libsparse available to Linux desktop environments was *way* beyond the
> scope of the Intern's project and time availability.
> 
> We can work on this trying to find a solution post-Buster --- either
> using static linking, or *possibly* figuring out a way to optionally
> use dlopen() to pull in libsparse for sparse_io.c, much like the way
> libss optionally pulls in the readline library using dlopen at
> runtime, back when we cared about making mke2fs fit on a two 1.44 MiB
> boot/root install floppies.  :-)
> 
> Alternatively, you can build your own version of mke2fs using the
> libsparse from AOSP.  If you want a solution that might make it in
> during the Buster release freeze, that's probably the short-term
> solution I would suggest.
> 
> So your choice --- we can either reassign this bug back to fastboot or
> android-sdk-platforms-tools, or I can downgrade the severity of this
> bug for e2fsprogs down to wishlist[1].  Let me know how you want to
> handle this.
> 
> Cheers,
> 
>   - Ted
> 
> [1] This is because I view this both as a "feature request" and "bugs
> that are very difficult to fix due to major design considerations"
> (per https://www.debian.org/Bugs/Developer#severities), not to mention
> that it's going to affect a miniscule fraction of the e2fsprogs
> package's users.

Makes sense to me.  I'm fine with this being done post-Buster or as a
custom mke2fs in android-platform-system-core.

.hc

Bug#924591: this requires linking in libsparse, which is from Android sources

[Hans-Christoph Steiner]

One possibility would be including libsparse as a patch, it doesn't
change a lot:
https://android.googlesource.com/platform/system/core/+log/master/libsparse

But it depends on Android's libbase and libz-host.

Bug#924591: this requires linking in libsparse, which is from Android sources

[Hans-Christoph Steiner]

Even though buster's e2fsprogs includes support for android_sparse in
the source code, it requires linking against libsparse, which is in
android-libsparse. That means making e2fsprogs Build-Depend on
android-libsparse-dev.

Bug#924591: the bug is in mke2fs

[Hans-Christoph Steiner]

Control: reassign 924591 e2fsprogs 1.44.5-1

Looks like the bug is because buster's e2fsprogs is not building with
the android_sparse option, even though it is included in the source code.

$ strace -f -e trace=execve -s4000 /usr/bin/fastboot
format:ext4:0x180b0 userdata
execve("/usr/bin/fastboot", ["/usr/bin/fastboot",
"format:ext4:0x180b0", "userdata"], 0x7fff4b65fce0 /* 70 vars */) = 0
Warning: userdata size is 0x000180b0, but 0x180b0 was
requested for formatting.
Couldn't parse erase-block-size '0x'.
Couldn't parse logical-block-size '0x'.
strace: Process 2831 attached
[pid  2831] execve("/usr/lib/android-sdk/platform-tools/mke2fs",
["/usr/lib/android-sdk/platform-tools/mke2fs", "-t", "ext4", "-b",
"4096", "-E", "android_sparse", "-O", "uninit_bg",
"/tmp/TemporaryFile-mslQq9", "1575680"], 0x564330202140 /* 71 vars */) = 0
mke2fs 1.44.5 (15-Dec-2018)
/tmp/TemporaryFile-mslQq9: Unimplemented ext2 library function while
setting up superblock
[pid  2831] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2831,
si_uid=1000, si_status=1, si_utime=0, si_stime=0} ---
/usr/lib/android-sdk/platform-tools/mke2fs failed with status 1
mke2fs failed: 1
error: Cannot generate image for userdata

+++ exited with 1 +++
$ /usr/sbin/mke2fs -t ext4 -b 4096 -E android_sparse -O uninit_bg
/tmp/TemporaryFile-3LivFN 1575680
mke2fs 1.44.5 (15-Dec-2018)
/tmp/TemporaryFile-3LivFN: Unimplemented ext2 library function while
setting up superblock
$ /opt/android-sdk/platform-tools/mke2fs -t ext4 -b 4096 -E
android_sparse -O uninit_bg /tmp/TemporaryFile-3LivFN 1575680
mke2fs 1.44.4 (18-Aug-2018)
Creating filesystem with 1575680 4k blocks and 394352 inodes
Filesystem UUID: 45726b57-c5b4-467e-b22d-0165ba9d9e58
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

Bug#924591: e2fsprogs?

[Hans-Christoph Steiner]

I quickly checked the versions of e2fsprogs used by Android vs what it
is in buster.  It seems that buster is as new as the Android version.
So either this specific feature was added via a Google patch or it was
not enabled in the Debian build of e2fsprogs.

Do you have any more information on the specific missing features?

Bug#924591: fastboot format:ext4 misses /usr/lib/android-sdk/platform-tools/mke2fs

[Hans-Christoph Steiner]

circular Depends:/Recommends: are easy, circular Build-Depends: are
what's hard.  Plus using the /usr/bin/ method, that will make fastboot
require e2fsprogs and other packages, rather than just recommend.

Bug#924591: fastboot format:ext4 misses /usr/lib/android-sdk/platform-tools/mke2fs

[Hans-Christoph Steiner]

why do you think patching would be better?  Seems like it would be more
maintenance work than the symlinks.

Bug#924591: should be there

[Hans-Christoph Steiner]

Tags: moreinfo

Thanks for the bug report!  I am guessing you installed fastboot using
`apt-get install fastboot` rather than `apt-get install android-sdk` or
`apt-get install android-sdk-platform-tools`.  Installing either
android-sdk or android-sdk-platform-tools should fix your problem.

The question that remains is: can we handle this better?  I don't think
fastboot should Depends: on android-sdk-platform-tools since the most
common use cases do not require android-sdk-platform-tools to work.  I
think adding Recommends: android-sdk-platform-tools could make sense.

Bug#901952: usability bug

[Hans-Christoph Steiner]

I agree that the issue of older versions not unpacking things made by
newer versions is not an important bug.  I added that as an FYI.

I do think this bug qualifies as RC even though there is a workaround.
The workaround is non-trivial and requires Debian Developers to research
the issue for a process that is normally entirely transparent.  Tools
like pristine-tar become much less valuable if they introduce their own
restrictions to the packaging process.  It changes "use pristine-tar,
and things will work better" into "use pristine-tar and you'll have to
learn some new workarounds, but it'll probably save you time".

Bug#901952: can affect packaged with old source tarballs

[Hans-Christoph Steiner]

this also goes the other way, where tarballs created in tar 1.30 fail to
work in pristine-tar when tar 1.29 is installed:

https://salsa.debian.org/python-team/modules/libcloud/-/jobs/115815

Bug#901952: can affect packaged with old source tarballs

[Hans-Christoph Steiner]

I think this bug does qualify as RC since it can affect any source
tarball that was created with an older version of tar.  So it is not
just that it comes from a different distro/release than buster, but it
could be from a package that has a source tarball that hasn't changed
since tar 1.30.

Bug#894285: some progress

[Hans-Christoph Steiner]

I can get some of this compiling with openjdk-11, but not all.

Ok, here's a fun problem: looks like I can build android-platform-23
with java11, but since it is in effect building Java core classes, the
compiler freaks.

There seems to be something like --patch-module java.base=src to deal
with this
but that won't work with sourceCompatibility 1.8
and Android wasn't Java9 until the most most recent release (9.0.0)
so... anyone have some ideas for alternate approaches?

here's a build log
https://salsa.debian.org/android-tools-team/android-framework-23/-/jobs/114477

Bug#914685: android-platform-frameworks-base FTBFS on C++ "atomic" lib

[Hans-Christoph Steiner]

Package: android-libcutils-dev
Version: 1:8.1.0+r23-3
Severity: critical

When building android-platform-frameworks-base, it fails to build with
errors related to the C++ "atomic" lib.  seamlik says this is due to an
issue in android-libcutils-dev, which provides that lib for the Android
packages.  It is probably related to this patch:
https://salsa.debian.org/android-tools-team/android-platform-system-core/commit/8199845aa4559672859f70876f099fb0312c7279

Two examples:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/android-platform-frameworks-base.html

https://salsa.debian.org/android-tools-team/android-platform-frameworks-base/-/jobs/77824

Bug#901952: downgrading to tar 1.29b-1.1 fixes it

[Hans-Christoph Steiner]

I can confirm that force-downgrading tar to 1.29b-1.1 on Debian/testing
fixes the issue:
https://salsa.debian.org/eighthave/androguard/-/jobs/47348

Bug#901952: another case

[Hans-Christoph Steiner]

here's another case of this bug:
https://salsa.debian.org/eighthave/androguard/-/jobs/47277

I'm often working on a mix of Ubuntu/LTS, Debian/stable, and
Debian/testing.  It was likely that the tarball was added with
gbp-import-orig on Ubuntu/xenial, and that build log is from
Debian/testing with some sid packages.  Here's what's running on
Ubuntu/xenial:

ii  tar  1.29b-1.1   amd64
ii  pristine-tar 1.38amd64

.hc

Bug#907662: python-tvrage: useless after TVRage.com shut down?

[Hans-Christoph Steiner]

yeah, I guess it should be removed.  Feel free to remove this, I won't
have to do it in the near future.



signature.asc
Description: OpenPGP digital signature

Bug#903388: Failure to install with Python 3.7

[Hans-Christoph Steiner]

Package: python3-libcloud
Version: 2.3.0-1
Severity: serious

Setting up python3-libcloud (2.3.0-1) ...
File "/usr/lib/python3/dist-packages/libcloud/compute/drivers/azure.py",
line 1438
  def _perform_post(self, path, body, response_type=None, async=False):
^
SyntaxError: invalid syntax

'async' is a reserved keyword in Python 3.7. This issue has been
previously reported upstream, and was fixed in version 4.3 of
pexpect.[1] The current upstream version is 4.6.

[1] https://github.com/pexpect/pexpect/issues/453

Bug#901952: new info

[Hans-Christoph Steiner]

This is probably some useful new info:
https://salsa.debian.org/eighthave/fdroidserver/-/jobs/26316

gbp:error: Error creating fdroidserver_1.0.6.orig.tar.gz: Pristine-tar
couldn't checkout "fdroidserver_1.0.6.orig.tar.gz": mkdir
/tmp/pristine-tar.SQkF8S8Z0J/workdir/fdroidserver-1.0.6/tests/repo/urzip-;
\320\240\320\260\321\205\320\274\320\260\314\201,
[r\311\220x\313\210man\312\262\311\252n\311\231f]
\330\263\331\212\330\261\330\254\331\212_\330\261\330\256\331\205\330\247\331\206\331\212\331\206\331\210\331\201
\350\260\242\302\267.apk: File name too long at /usr/bin/pristine-tar
line 439.
pristine-tar: failed to generate tarball


The fdroidserver_1.0.6.orig.tar.gz tarball contains a file with
difficult unicode chars as a test that fdroidserver supports unicode
well.  It seems that it also has tested pristine-tar's unicode support.

Bug#901952: xdelta: expected from file (/tmp/pristine-tar.SljdkfANnj/recreatetarball) of length 7557120 bytes

[Hans-Christoph Steiner]

Package: pristine-tar
Version: 1.44
Severity: serious

In Debian/testing:

$ gbp clone https://salsa.debian.org/debian/fdroidserver.git
$ cd fdroidserver
$ rm ../fdroidserver_1.0.6.orig.tar.gz*
$ git reset --hard; git clean -fdx
$ gbp buildpackage -uc -us
gbp:info: Creating /export/share/code/debian/fdroidserver_1.0.6.orig.tar.gz
gbp:error: Error creating fdroidserver_1.0.6.orig.tar.gz: Pristine-tar
couldn't checkout "fdroidserver_1.0.6.orig.tar.gz": xdelta: expected
from file (/tmp/pristine-tar.SljdkfANnj/recreatetarball) of length
7557120 bytes
xdelta: expected from file
(/tmp/pristine-tar.SljdkfANnj/recreatetarball) of length 7557120 bytes
xdelta: expected from file
(/tmp/pristine-tar.gWN3rKYWgn/recreatetarball) of length 7557120 bytes
xdelta: expected from file
(/tmp/pristine-tar.EJo9dG6tou/recreatetarball) of length 7557120 bytes
xdelta: expected from file
(/tmp/pristine-tar.EJo9dG6tou/recreatetarball) of length 7557120 bytes
pristine-tar: Failed to reproduce original tarball. Please file a bug
report.
pristine-tar: failed to generate tarball

You can also see this happening here:
https://salsa.debian.org/debian/fdroidserver/-/jobs/26312

tar   1.30+dfsg-2
pristine-tar  1.44
git-buildpackage  0.9.9


This all works fine using pristine-tar 1.38 in Ubuntu/xenial.
tar1.29b-1.1
pristine-tar   1.38
git-buildpackage   0.8.12.2

Control: notfound -1 1.38

Bug#681726: Time to remove eclipse from Testing?

[Hans-Christoph Steiner]

Markus Koschany:
> On Wed, 15 Nov 2017 18:01:07 +0200 Adrian Bunk  wrote:
> [...]
>> I tried to sort out what I could find as required for getting the
>> ancient eclipse out of testing in [1]:
>>
>> 1. src:bnd
>> You fixed that already.
>>
>> 2. batik -> maven -> guice -> libspring-java -> aspectj -> eclipse-platform
>> Is there some good way to break this dependency chain?
>>
>> 3. split libequinox-osgi-java out of src:eclise
>> Or as a short-term hack, build only libequinox-osgi-java from src:eclipse.
> 
> I have spent some time this weekend on Eclipse again. I have created a
> standalone src:libequinox-osgi-java package and successfully rebuilt all
> reverse-dependencies. We only have to make a small adjustment in
> src:netbeans and src:libnb-platform18-java and update the osgi patch.
> 
> If there are no objections I could go ahead and upload
> libequinox-osgi-java to NEW.
> 
> eclipse-rcp:
> 
> * svnkit:
> 
> There are two Eclipse specific classes that fail to build. As a
> workaround we could remove one of them and patch SVNWCUtil.
> 
> * android-sdktools and android-platform-tools-swt
> 
> According to [1] both packages should be removed anyway.
> 
> After that there would be only three packages left (not counting the
> eclipse plugins) that build-depend on either eclipse-platform (aspectj)
> or eclipse-jdt (lombok, biogenesis)
> 
> Next I'm going to try if a separate eclipse-jdt package from [2] could
> be a drop-in-replacement for our current package. The latest stable
> release appears to be S4_8_0_M5.
> 
> Regards,
> 
> Markus
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879175#10
> [2] https://github.com/eclipse/eclipse.jdt.core

As far as I know, android-sdktools and android-platform-tools-swt are
both deprecated by Google.  So it should be fine to remove them also.
There is a chance that other parts of the Android SDK depend on JARs
from Eclipse, but I guess that's not likely/

.hc

Bug#890593: things never worked on big-endian

[Hans-Christoph Steiner]

Unfortunately, it looks like androguard never worked on big-endian
arches.  For now, the thing to do is just disable those arches.  I'm
sure upstream would welcome patches to port it.  Upstream is currently
focused on getting things polished up on the popular arches.

Bug#874216:

[Hans-Christoph Steiner]

That dialog clearly says MTP.  adb nor any of the Android Tools packages
have anything to do with MTP.  So this is not an adb nor Android Tools bug.

Bug#874216:

[Hans-Christoph Steiner]

What is making the screenshots?  libadb can't do that.  Also, where do
you see the message "Unable to mount Samsung Samsung Android/"?  Where
are you seeing a prompt that asks permission for phone access?

Bug#860656: actually...

[Hans-Christoph Steiner]

Control: tags -1 patch

Actually, upstream responded after looking into the details.  I was
wrong, we should just fix the tests.

Bug#860656: python-biplist: FTBFS on i386: dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 returned exit code 13

[Hans-Christoph Steiner]

The tests don't need fixing, they are pointing out a real issue, check
the bug report to upstream for more info.  If we just want to ship with
this specific issue not fixed, then patching the test could lead people
astray.  Instead, seems like we should just disable that test on 32-bit
archs.

Bug#860656: forwarded upstream

[Hans-Christoph Steiner]

Control: forwarded -1 https://bitbucket.org/wooster/biplist/issues/8

Since the plist format stores the length of the integer, storing a long
should always return a long:

 0001  # of bytes is 2^, big-endian bytes
https://en.wikipedia.org/wiki/Property_list#Mac_OS_X

On python3 this does not matter, since there is no long type, only int.

Bug#860686: build needs lots of RAM

[Hans-Christoph Steiner]

Control: severity -1 wishlist
Control: retitle -1 FTBFS on machines with limited RAM

This is an "Architecture: all" package that should not be built on a
machine with limited RAM.  This is unfortunately a common problem with
gradle builds.  It would be a bug if this failed on amd64.

Bug#860686: [Android-tools-devel] Bug#860686: android-platform-external-doclava: FTBFS on i386: java.lang.StackOverflowError

[Hans-Christoph Steiner]

my guess is that this rebuild was done with limited RAM, since the
failure is:

"The system is out of resources."

Bug#858177: CVE-2016-3921

[Hans-Christoph Steiner]

Control: severity -1 important
Control: tags -1 -security

Bug#858177: not affected

[Hans-Christoph Steiner]

Almost all of the Android CVEs are for the Android OS, not the Android
SDK.  The tricky part is that they are built from the same source tree.
Another thing to note is that some of the Android SDK libs used in the
SDK run at elevated privileges in Android OS, but not when part of the
SDK.  So there is a whole class of exploits that are irrelevant to the
SDK.  And we haven't packaged any part of the Android SDK that interacts
with the network, so anything saying "remote code execution on Android"
seems unlikely to be relevant.

So anyone who wants to look out for these should only look for CVEs that
affect the Android SDK, not Android, e.g.
https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-13517/Google-Android-Sdk.html

CVE-2016-3861 - not affected
* no remote access
* nothing runs as a privileged process
* some affected files not included in any Debian package:
  * libs/binder/Parcel.cpp
  * media/libmediaplayerservice/MediaPlayerService.cpp
* looks worth fixing as a usability bug

CVE-2016-3885 - not affected
* debuggerd/debuggerd.cpp is not included in any Debian package
* the whole debuggerd is not packaged

CVE-2016-3921 - not affected
* libsysutils/src/FrameworkListener.cpp is not included in any Debian
package
* the whole libsysutils is not packaged


So my question to you is: how can we make it easier to ignore these?  I
think its safe to ignore Android CVEs, since there have been some
separate Android SDK CVEs.  I can't think of a security bug in Android
that has affected the SDK in any significant way.

Bug#855846: [Android-tools-devel] Bug#855846: repo: requires software outside of the distribution to function

[Hans-Christoph Steiner]

I'm fine with it being moved to contrib.

Bug#855846: [Android-tools-devel] Bug#855846: repo: requires software outside of the distribution to function

[Hans-Christoph Steiner]

Its more vague than that.  repo clones a git repo for each source repo
that it manages, so it becomes something like the stuff in the .git/
subdir for git repos.  That functionality comes entirely from what's
packaged in Debian.

Bug#852903: [Android-tools-devel] Bug#852903: android-platform-tools-swt: FTBFS: ProfileProvider.java:92: error: cannot find symbol

[Hans-Christoph Steiner]

android-platform-tools-swt is for the old Eclipse plugin, right?  It
would be nice to have that still included in Debian, but yeah, its quite
low priority.

I'm guessing this error is caused by android-platform-tools-swt running
against a newer version of android-platform-tools-base than it should
(e.g. 2.0.0 vs 2.2.2).  Google has just removed
android-platform-tools-swt from the 2.2.2, if I remember correctly.

Bug#850997: [Android-tools-devel] Bug#850997: android-platform-tools-base: FTBFS: InstantRunVerifier.java:172: error: method diffList in class InstantRunVerifier cannot be applied to given types;

[Hans-Christoph Steiner]

There is always hope!  The best way to ensure that this gets updated is
to find people to join in the effort.  We have an update to
android-platform-tools-base underway, but there is still quite a bit to
be done.  I think we have all the dependencies needed for updating this
to 2.2.2 complete, we just need to get the final
android-platform-tools-base 2.2.2 done.  And the core team does not have
much time to spare these days.  The work that needs doing is Java/gradle
building.

.hc

Bug#849390: google-android-installers

[Hans-Christoph Steiner]

It turns out that the approach in google-android-installers is not
maintainable going forward, so we need to split out each source package
from google-android-installers into its own source package.  So we'll
need to remove google-android-ndk-installer from
google-android-installers.  We can leave the rest in
google-android-installers as is for stretch.

Also, only the source package of google-android-installers is
1472023576, the google-android-ndk-installer binary package produced by
it has a binary package version of 12.b+1.

Bug#849346: plan to merge packages

[Hans-Christoph Steiner]

This reminds me: we need to revisit the possibility of merging
android-platform-external-libunwind with the plain libunwind package.
Its such a pain that Android uses all these forks.

Bug#849222: [Android-tools-devel] Bug#849222: FTBFS: missing build dependency libandroid-tools-annotations-java

[Hans-Christoph Steiner]

Looks like we have another circular depends :-/
libandroid-tools-annotations-java comes from
source:android-platform-tools-base which depends on
libandroid-databinding-java/android-platform-frameworks-data-binding.  I
think Java is a lot more tolerant than C, so I'm going to go ahead an
add libandroid-tools-annotations-java as a build dep, even though that
means it will build against the old version.

Bug#823004: point users to dummydroid

[Hans-Christoph Steiner]

Since the credentials in the package are no longer valid, we're no
longer violating Google's Terms of Service.  And the package works if
you generate an AndroidID with dummydroid, and use your own credentials,
so its ready for testing.

Therefore, this bug can be downgraded in severity while we figure out
the best approach to handle this.  We will not be able to auto-generate
the AndroidID since dummydroid is a GUI-only process, so I don't think
its worth anything to prompt the user for their username/password in the
package install.  I think we can post a message saying you have to run
dummydroid or get credentials from elsewhere for this to work.  People
who want to use matlink's credentials are always free to get it from his
git repo.  You have to do that anyway, since the credentials change often.

No one seems willing to maintain the credentials in the package, so I
don't think its so useful right now.  If you set up credentials with
dummydroid, then they stay working.  There are even websites where
people share username/password combos for test accounts, one of those
could be used with dummydroid to generate the AndroidID in a much more
reliable way than including matlink's.

Bug#823004: gplaycli: sensitive information in config file

[Hans-Christoph Steiner]

dummydroid is already included in Debian :-D  I think the best way
forward for this issue is for the gplaycli package to leave out the
default credentials.  Then make it as easy as possible for people to set
up the credentials using dummydroid.

Bug#827215: stub for now

[Hans-Christoph Steiner]

Since renderscript is only used in very few apps, and it looks like a
lot of work to get the whole renderscript system working in Debian, I
propose that we stub out renderscript stuff for now while we are getting
the essential parts working.  So for this issue, how about making it a
shell script that just echos "this is just a stub, implement me!"?
Maybe it could include a URL to this issue: https://bugs.debian.org/827215

Bug#824933: [Android-tools-devel] Bug#824933: Bug#824933: apktool: crashes with every APK

[Hans-Christoph Steiner]

framework-res.apk is not included in the SDK, only the OS.  Packaging
parts of the OS means we are making packages that upstream is not.
There are plenty of places to download framework-res.apk, including the
apktool website itself.

Bug#824933: [Android-tools-devel] Bug#824933: Bug#824933: apktool: crashes with every APK

[Hans-Christoph Steiner]

Perhaps we could include a script that makes it easy to fetch
framework-res.apk from any connected device or emulator?  Its just a
matter of doing `adb pull` as far as I know.

Bug#823309: marked as pending

[Hans-Christoph Steiner]

tag 823309 pending
thanks

Hello,

Bug #823309 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/androguard.git;a=commitdiff;h=5e587dd

---
commit 5e587dd26fbb2364476e55d958050e180f5eee6c
Author: Hans-Christoph Steiner <h...@eds.org>
Date:   Wed Jun 1 12:08:57 2016 +0200

update debian/changelog for upload

diff --git a/debian/changelog b/debian/changelog
index 366a292..4f11b90 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+androguard (2.0-2) unstable; urgency=medium
+
+  * lintian overrides: the included binaries are test objects
+  * manually include python-networkx (Closes: #823309)
+  * include Vcs tags
+  * Uploaders: Debian Python Modules Team
+  * Standards-Version: 3.9.8, no changes
+  * remove pointless README (Closes: #824978)
+
+ -- Hans-Christoph Steiner <h...@eds.org>  Wed, 01 Jun 2016 12:08:23 +0200
+
 androguard (2.0-1) unstable; urgency=low
 
   * Initial release. (Closes: #811421)

Bug#814600: [Android-tools-devel] Bug#814600: android-tools: B-D on obsolete android-system-dev

[Hans-Christoph Steiner]

we're going to be removing this package anyway, so I don't think we need
to fix it.  And if someone wants to backport it, then android-system-dev
can be backported too.

Bug#815105: [Android-tools-devel] Bug#815105: dalvik-exchange: abuses Conflicts

[Hans-Christoph Steiner]

we're going to get to the destination you describe, one step at a time :)

Bug#814876: builds for me

[Hans-Christoph Steiner]

I just tried to build lombok-patcher on my sid chroot, and it built
fine.  This whole lombok group of packages has a bunch of circular deps,
could it be that liblombok-java was out of date on your machine?  I
think that lombok-patcher and/or maybe ivyplusplus need to have
versioned Build-Depends to prevent this kind of thing.

Bug#807728: 0.76 didn't fix it for me

[Hans-Christoph Steiner]

Doh, just saw this is a bug in pbuilder, not cowbuilder.  I updated to
pbuilder 0.221.3 and it fixed the issue for me.

Bug#807728: 0.76 didn't fix it for me

[Hans-Christoph Steiner]

I'm also affected by this issue using cowbuilder 0.75.  Updating to 0.76
did not fix it.  This did:

sudo cowbuilder --login --save-after-login
# mkdir -p /home/hans/.cache

Here's the error:
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
E: Could not create directory: /home/hans/.cache:
boost::filesystem::create_directory: No such file or directory:
"/home/hans/.cache"
E: pbuilder-satisfydepends failed.



To reproduce it, I did:
sudo cowbuilder --login --save-after-login
# rm -rf /home/hans

Bug#790978: [Android-tools-devel] Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default

[Hans-Christoph Steiner]

We are in the process of updating all of the android-platform-* packages.  It
is a large, complex suite so it takes time.  If you need to force the
transition, just go ahead and ignore this package.  The update is more or less
done, we are currently just wanting on this dependency in a different library
that we do not maintain:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793863

Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default

[Hans-Christoph Steiner]

All of the android-* packages must be updated to the latest version at the
same time.  It is more unpredictable to have android-* packages at different
upstream versions since no one is running that configuration, and upstream
does not do anything to support that (e.g. no versioned ABI, etc).  Therefore,
the ABI is guaranteed to be compatible since they'll all be built together.

In practice, this means that the process of updating to the latest upstream
version has to start from the most core packages, then progress to the ones
that depend on it.

That said, this private shared library arrangement allows for security patches
in the android shared code to be applied without having to rebuild everything.



signature.asc
Description: OpenPGP digital signature

Bug#790978: [Android-tools-devel] Bug#790978: android-platform-build: library transition may be needed when GCC 5 is the default

[Hans-Christoph Steiner]

This should be addressed once we update all of the android-platform-* source
packages to the latest version from Google (5.1.1+r8).

Simon is right in that these are basically private libraries.  Upstream
statically links them into each executable.  That didn't seem very Debian-ish,
so instead I structured it as private shared libraries.  Nothing should link
to these android-lib* shared libraries that is not part of the Android source.

A single source package might make some things easier, but it would be about
8-12 gigs in size. That would make it very difficult for many people to work
with that source package.

.hc



signature.asc
Description: OpenPGP digital signature

Bug#786943: [Android-tools-devel] Bug#786943: installing android-libhost doesn't fix the problem either

[Hans-Christoph Steiner]

thanks for the bug report.  I think the workaround is to install
android-libhost-dev.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783174: www.google.com

[Hans-Christoph Steiner]

I'm also affected by this bug.  I think that if there isn't a suitable Debian
server available, then this package should default to whatever ChromeOS is
using as its default, since that is likely the most maintained.



signature.asc
Description: OpenPGP digital signature

Bug#776987: version string in libsqlcipher

[Hans-Christoph Steiner]

FYI, I CC'ed the bug for the record:

Kali Kaneko:
 On Tue, Apr 07, 2015 at 02:53:59PM -0400, Hans-Christoph Steiner

 Unfortunately, I don't think it is going to be as simple as just
 removing the patch that changes VERSION to the SQLCipher version.  Some 
 places need
 the SQLite version and other places need the SQLCipher version
 
 I've been combing thru he sources, and in the source code for SQLCipher
 I don't seem to be able to find any place that's using the sqlcipher
 version for anything. crypto.h has a CYPHER_VERSION, but that's
 hardcoded, and sqlcipher.h doesn't seem to refer to any version string.
 
 The only checks for the SQLITE_VERSION_NUMBER that I see, outside of the
 test suite, seem to be in the extensions (fts and rtree):
 
 #if SQLITE_VERSION_NUMBER=3008002
 
 But this is expecting the sqlite version and not the sqlcipher one.
 
 hans, do you remember which parts of the code (or the packaging) were
 expecting the SQLCipher version?

Here's what I found, its not especially conclusive.  In Makefile.in, the value
of VERSION is used to generate sqlite3.h:

sqlite3.h:  $(TOP)/src/sqlite.h.in $(TOP)/manifest.uuid $(TOP)/VERSION
$(TCLSH_CMD) $(TOP)/tool/mksqlite3h.tcl $(TOP) sqlite3.h


in configure.ac, the value in the file VERSION is put into Makefile variables
VERSION and VERSION_NUMBER:

VERSION=[`cat $srcdir/VERSION | sed 's/^\([0-9]*\.*[0-9]*\).*/\1/'`]
AC_MSG_NOTICE(Version set to $VERSION)
AC_SUBST(VERSION)
RELEASE=`cat $srcdir/VERSION`
AC_MSG_NOTICE(Release set to $RELEASE)
AC_SUBST(RELEASE)
VERSION_NUMBER=[`cat $srcdir/VERSION \
   | sed 's/[^0-9]/ /g' \
| awk '{printf %d%03d%03d,$1,$2,$3}'`]
AC_MSG_NOTICE(Version number set to $VERSION_NUMBER)
AC_SUBST(VERSION_NUMBER)


in tool/mksqlite3h.tcl, it is parsed into zVersion and nVersion, which then
does replacements in src/sqlite.h.in:

set in [open $TOP/VERSION]
set zVersion [string trim [read $in]]
close $in
set nVersion [eval format %d%03d%03d [split $zVersion .]]

...

regsub -- --VERS--   $line $zVersion line
regsub -- --VERSION-NUMBER-- $line $nVersion line

But it seems that it might be that all those machinations end up with really
only SQLITE_VERSION_NUMBER being set in a way that we have to think about.

.hc





signature.asc
Description: OpenPGP digital signature

Bug#776987: version string in libsqlcipher

[Hans-Christoph Steiner]

I did just think of one last thing to check: the SO versioning of the library
file, i.e. libsqlcipher.so

Also, the public representation of the SQLCipher version, like in
sqlcipher.pc, version the SQLite3 version.

.hc



signature.asc
Description: OpenPGP digital signature

Bug#779331: wheezy update

[Hans-Christoph Steiner]

I think this also needs to be a security update in wheezy and jessie. What are
the plans for that?



signature.asc
Description: OpenPGP digital signature

Bug#779331: maven downloads and runs completely unauthed jars via HTTP

[Hans-Christoph Steiner]

Package: maven
Version: 3.0.4-3
Severity: grave
Tags: security

By default, maven versions before v3.2.3 downloads from Maven Central using
plain HTTP and do not check any kind of signature on the code before running
it.  This is a very bad situation, making it quite easy for malicious actors
take over the machines where maven is used:

http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/

Luckily, there is a simple step that greatly improves the situation.  HTTPS is
now fully supported on maven central, so Debian's maven should also default to
HTTPS.  A user can set this in ~/.m2/settings.xml, and it works fine with the
Debian version of maven.  But this really needs to be the default, and it
should just be a matter of adding this config information to
/etc/maven/settings.xml

http://central.sonatype.org/pages/consumers.html#apache-maven




signature.asc
Description: OpenPGP digital signature