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
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: 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):
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
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
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.
I'm fine with it being moved to contrib.
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
Control: severity -1 important
Control: tags -1 -security
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
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
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.
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 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 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 s
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). Ther
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
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?
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.
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.
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
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 .../
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
Control: severity 929905 important
Please keep it in buster, I would like to go the point release route.
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
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.
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
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
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
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"
^~
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
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
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.
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.
Control: severity -1 wishlist
Control: retitle -1 port android-platform-art to ARM, etc.
fastboot is getting pretty close to working on amd64:
https://salsa.debian.org/eighthave/android-platform-system-core/-/jobs/1297944
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
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
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: 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: 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: reassign -1 aapt
Control: merge 977023 977912
This is due to aapt's linking error. The fdroidserver tests rely on aapt.
Control: reopen -1
can't reproduce
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
Do the tests pass with this patch?
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.
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
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: fixed -1 1:10.0.0+r36-1
Oops, forgot to mark it in the changelog
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: 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
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: tags -1 patch
Actually, upstream responded after looking into the details. I was
wrong, we should just fix the tests.
my guess is that this rebuild was done with limited RAM, since the
failure is:
"The system is out of resources."
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.
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
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
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.
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
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
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.
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
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
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.
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.
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
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,
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!
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
why do you think patching would be better? Seems like it would be more
maintenance work than the symlinks.
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.
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
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
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?
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.
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.
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: 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
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.
It is fixed upstream:
https://github.com/buildbot/buildbot/commit/291df50dc3f27adb47a001fc154cf4c55490687e
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
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
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,
Changing MAXPDSTRING will affect everything in Pd, and as another long time
upstream developer, I've never heard of anyone changing it. It does not seem
like a change to make in the final phase of the release cycle. I think it
makes much more sense to remove the new thing that's triggering the i
> i was mainly referring to your objection of changing MAXPDSTRING due to
> limitations of MAX_PATH. anything regarding this?
My objection is that its a big unknown what will happen and this is supposed
to be a releases candidate situation. All sorts of things are done based on
MAXPDSTRING, and
Hey Roland,
Good to see you working on Pd too :) About your patch, I think increasing
MAXPDSTRING is dangerous because Pd uses MAXPDSTRING as the max path length as
well. I think Debian's maximum path length is quite a bit shorter than 1
bytes. Its not a good situation, I know, but that
I made 1.7.0-2 directly from the package's git repo, and the 1.7.0-1.1 NMU
changes where never committed back into the package's git. I noticed that
after uploading 1.7.0-2, made 1.7.0-3 including the NMU code, but then forgot
to upload it. Thanks all for the reminder, uploading now.
.hc
sig
This is an unusual package because it should only ever been installed in a
Debian chroot that is running on an Android device. I cannot think of any
other instance that makes sense to install this package. So if anyone can
think of better tests to enforce that, that would be good.
Also, piupa
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
Tags: help fixed-upstream
Control: merge 738119
This adb package definitely needs some love. I won't have time to work on it
for a while, but I'll contribute where I can. Ray Kohler did some work
towards this goal, but its not ready for upload. For more info:
https://bugs.debian.org/cgi-bin/
The freeze exception I put in was rejected until there are some translations
of the strings. So help with getting the translations in, if you want this to
happen sooner rather than later. I've never handled translations or debconf
questions in a package before.
.hc
signature.asc
Description:
I've sent out a call for translations directly a while back. I don't know how
to get any translations that might have been produced.
signature.asc
Description: OpenPGP digital signature
android-permissions integrates the Android permissions into a Debian chroot
running on Android. This package should only ever run on a Debian chroot
running with an Android kernel. It should modify things like GID_MAX or
LAST_GID in /etc/login.defs and /etc/adduser.conf to reflect the hard-coded
The package android-permissions integrates the Android permissions into a
Debian chroot running on Android. Android permissions are implemented in
Android's Linux kernel using UIDs and GIDs. Therefore, this package should
only ever run on a Debian chroot running with an Android kernel. It adds a
Thanks for the patch, I'm working on including it now.
Unfortunately, android-platform-system-core_21-4 does not fix the other
related bug:
https://bugs.debian.org/769251
I'm working on that still, that fix will be in a different package:
android-platform-frameworks-native
.hc
signature.asc
1 - 100 of 160 matches
Mail list logo
