Control: severity 104 normal
Lucas Nussbaum:
Hi,
On 27/05/24 at 22:24 +0200, Lucas Nussbaum wrote:
Hi,
An update on this:
I plan to take care of the Debian vagrant package (in the framework of
the Ruby team, as this is currently done). I uploaded the latest free
version of Vagrant to
https://github.com/hashicorp/vagrant/issues/13571#issuecomment-2597468213
> We are currently running with the workaround of setting VAGRANT_SERVER_URL to
"https://vagrantcloud.com/api/v2/vagrant";. FWIW, updated vagrant packages for
Fedora will be available soon with internal code changes to re
F-Droid still relies on the Debian Vagrant boxes. We are working on migrating
away from them, but I'd rather not rush it. Seems like we could find some
alternate official hosting for them as a quick workaround. Both Debian and
F-Droid are plugged into a substantial network of mirrors. Per
Control: tag -1 pending
Hello,
Bug #1084238 in android-platform-art 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-art/-/co
Maybe updating this to the latest upstream would fix it? 15 is now available.
Also, I noticed that the original reporter built on amd64 while rosh's different
results were from arm64.
Control: tag -1 pending
Hello,
Bug #1061842 in sdkmanager 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/python-team/packages/sdkmanager/-/commit/c193e579f7cf7
I see the problem now: looseversion is defined in setup.py, but somehow
debhelper didn't figure that out. Perhaps it is because of the more complicated
declaration:
install_requires=[
"argcomplete",
"requests > 2.12.2, != 2.18.0",
"urllib3<2",
'loosevers
It is fixed upstream:
https://github.com/buildbot/buildbot/commit/291df50dc3f27adb47a001fc154cf4c55490687e
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,
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,
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 .../
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
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.
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.
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?
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-228
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!
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-av
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.
Do the tests pass with this patch?
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
can't reproduce
Control: reopen -1
Control: reassign -1 aapt
Control: merge 977023 977912
This is due to aapt's linking error. The fdroidserver tests rely on aapt.
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
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
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
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
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
fastboot is getting pretty close to working on amd64:
https://salsa.debian.org/eighthave/android-platform-system-core/-/jobs/1297944
Control: severity -1 wishlist
Control: retitle -1 port android-platform-art to ARM, etc.
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.
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.
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 pushe
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 foun
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"
^~
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=.
-f
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
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
Control: fixed -1 1:10.0.0+r36-1
Oops, forgot to mark it in the changelog
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.
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-pla
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 r
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
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.
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 t
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.
Once kotlin is in Debian, then we can use newer upstream versions, which
support the latest JDK.
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 up
Control: severity 929905 important
Please keep it in buster, I would like to go the point release route.
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,
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/libspa
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.
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.
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/fast
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 th
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.
why do you think patching would be better? Seems like it would be more
maintenance work than the symlinks.
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 q
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 p
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
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.
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
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
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
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
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
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):
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/
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/deb
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 -> aspect
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.
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.
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?
Control: tags -1 patch
Actually, upstream responded after looking into the details. I was
wrong, we should just fix the tests.
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.
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 n
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.
my guess is that this rebuild was done with limited RAM, since the
failure is:
"The system is out of resources."
Control: severity -1 important
Control: tags -1 -security
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 ther
I'm fine with it being moved to contrib.
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.
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
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
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
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.
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 liband
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 fi
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.
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 t
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.
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.
5e587dd26fbb2364476e55d958050e180f5eee6c
Author: Hans-Christoph Steiner
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
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.
we're going to get to the destination you describe, one step at a time :)
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 t
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.
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/.cach
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 l
1 - 100 of 160 matches
Mail list logo
