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,
tags 1060985 patch
thanks
Looks like the package has a missing build dependency on python3-six.
Builds successfully with the attached patch.
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/control b/debian/control
index 403eaea..59746b8 100644
--- a/debian
;unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
YPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
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 .../
b1
ii python3-fife0.4.2-5+b1
ii python3-future 0.18.2-6
ii python3-yaml6.0-3+b2
unknown-horizons recommends no packages.
unknown-horizons suggests no packages.
-- no debconf information
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
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?
cale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Disable tests which require network acces
md64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
Fwiw, java.util.jar.Pack200 was removed in JDK 14 and is thus missing
when building with JDK 17.
https://openjdk.org/jeps/367
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
tags 1026608 patch
thanks
See the attached patch which resolves the HTML errors to generate the
JavaDoc and make the package build successfully.
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Fix HTML errors in Javadoc causing build failures
Remove tags, not
will fail with Java 17. They don't seem to
have newer upstream versions though, and I don't know if additional
changes in the code would be required for these to support Java 17.
[1] https://github.com/puppetlabs/puppetdb/blob/main/project.clj#L281
--
mvh / best regards
Hans Joachi
n on
Debian Sid.
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Explicit import for Record
Since this code predates java.lang.Record in the JDK, I'm going to assume
it refers to its own class
---
Forwarded: no
Last-Update: 2022-12-21
--- libjt400-java-9.4.orig/s
: TypeError
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
id
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/sy
md (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Replace html4 option with html5
The html4 option has been removed/replaced in newer JDKs, causing a build
failure.
---
Forwarded: no
--- junit5-system-exit-1.1.2
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
.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescript
PU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
ked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
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!
Hi,
after updating libsane1 yesterday xsane works as expected.
Georg
Scanimage fails starting the scan, too. The result of "scanimage -d
epson2:libusb:002:005 --format png -o /home/georg/unsinn.png" is
"scanimage: sane_start: Operation not supported".
Georg
sages.
I'm tagging this bug 'moreinfo' now, since it will depend on your
availability and abilities to work on it to have it advance.
Have fun,
Hans van Kranenburg
/debian/rb-pkg/unstable/amd64/rally-openstack.html
for more details.
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
d64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
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
Common Vulnerabilities & Exposures) id in your changelog entry.
Yes, it will off course be included in next upload.
Hans
Control: fixed -1 1:10.0.0+r36-1
Oops, forgot to mark it in the changelog
On 11/20/20 8:02 PM, Hans van Kranenburg wrote:
> So,
>
> On 9/21/20 4:16 PM, Hans van Kranenburg wrote:
>> [...]
>>
> [...]
> >8
>
> dh_install: warning: Cannot find (any matches for)
> "usr/lib/debug/usr/lib/xen-*/boot/*" (tried in .
On 11/21/20 5:40 AM, Elliott Mitchell wrote:
> On Fri, Nov 20, 2020 at 08:02:26PM +0100, Hans van Kranenburg wrote:
>> So,
>>
>> On 9/21/20 4:16 PM, Hans van Kranenburg wrote:
>>> [...]
>>>
>>> gcc-Wl,-z,relro -Wl,-z,now -pthread -Wl,-soname
&
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
notfixed -1 xen/4.14.0-1~exp1
reopen
found -1 xen/4.14.0-1~exp1
thanks
Hi,
On 9/4/20 1:55 PM, Hans van Kranenburg wrote:
>
> On 8/24/20 7:03 PM, Gianfranco Costamagna wrote:
>> Source: xen
>> Version: 4.11.4+24-gddaaccbbab-1
>> Severity: serious
>>
>> Hello
3]: *** [Makefile:74: install] Error 2
> make[3]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab/tools'
> make[2]: *** [Makefile:127: install-tools] Error 2
> make[2]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab'
> make[1]: *** [debian/rules:202: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/build/xen-4.11.4+24-gddaaccbbab'
> make: *** [debian/rules:150: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> I: copying local configuration
Hans
Hello
genetic build-depends on python3-multiprocess, which does not
exist in the archive.
Looks like this is now available as part of
https://tracker.debian.org/pkg/multiprocess
So I suppose the only thing now holding back genetic is a missing
source-only upload.
--
mvh / best regards
Hans
== 3 failed, 44 passed in 45.39 seconds
=
Based on the error messages, it looks like these tests require
network access.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
s (over iscsi). So, no ext3
anywhere.
We haven't got bug reports against Debian Xen packages in the BTS about
this.
I have not yet tried to make an ext3 fs on a block device in a test domU
and then have it do things with the fs and reboot it now and then. If
wanted, I can do that and see if there's any problem after a week or
two. Just to add chaos to help correlating.
FWIW,
Hans
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
Hi,
I have the same problem with an HP Officejet 7310 AIO:
sane-find-scanner reports:
"found USB scanner (vendor=0x03f0 [HP], product=0x4211 [Officejet 7300
series]) at libusb:002:012"
but "scanimage -L" fails:
"No scanners were identified."
Unfortunately, I wasn't able to downgrade to 3.20.3+
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.
ecause I initially thought this was a
binary package produced by src:xen, but it was not. At some point (I
think it was our latest IRL work together day of the Debian Xen team) I
realized that it really was not, and from that POV, I can confirm that
it is not used by anything in there.
Thanks,
Hans
Ah, I saw the other bug report but didn't look too much into it since
it had a different error message. So I missed the date it was fixed
and tested with the previous cmake version locally.
Now that cmake is updated, it builds as expected. Sorry about the
noise :)
---
mvh / best regards
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
ed to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
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
Fwiw,
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/flare-engine.html
seems to build successfully. I'm don't see this build failure on my
local
Sid system either.
Maybe it got resolved after library changes in the meantime?
--
mvh / best regards
Hans Joachim Des
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
systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
ii upower 0.99.11-1
pn vainfo
pn vdpauinfo
pn vulkan-utils
ii wireless-tools 30~pre9-13+b1
ii x11-xserver-utils 7.7+8
pn xinput
hw-probe suggests no packages.
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
cture: amd64 (x86_64)
Kernel: Linux 5.4.0-3-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans J
On 1/7/20 11:34 PM, Hans van Kranenburg wrote:
> [...]
>
> Today I have finally been working on this. The result is that I at least
> have a new (WIP) version for buster. I'm running it on a dom0 right now
> and did smoke testing, live migrate, restarting domUs etc.
& Exposures) ids in your changelog entry.
I also added a commit to put in the CVE numbers in previous changelog
entries:
https://salsa.debian.org/xen-team/debian-xen/commit/0ee295f5caf6178f64febeb976d7ea968e44a191
Is this ok/wanted/great/what-you-like? Because, regularly, the numbers
are not available yet when we push out the update.
Thanks,
Hans van Kranenburg
Kernel: Linux 5.3.0-2-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://
(via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/control b/debian/control
index bacbd05..6effc7a 100644
--- a/debian/control
+++ b/debian/control
@@ -3,11 +3,15 @@ Section: science
Priority: optional
Maintainer: Debian
for reporting this. Next step would be to follow Rogers
instructions, and provide config dumps, serial console output etc...
We're certainly available to include changes / etc to fix things, given
proper information / testing reports from the user. But, the user has to
actively he
Control: severity 929905 important
Please keep it in buster, I would like to go the point release route.
that's quite an important prerequisite for continuing. :|
Ian needs to work on that.
I will see if I can manipulate them a bit. All the other ones mentioned
in the changelog should also have the info that it's found in current
version in stable attached to them, so that the version graph shows both.
Hans
lags: TAINT_CRAP
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org
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
1 - 100 of 399 matches
Mail list logo
