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

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. Curiously, the master branch of AOSP SDK now seems to support ARM64:

Bug#960897: Update android-platform-external-libunwind and build for ppc64el

> According to the source trees at both > https://github.com/Unity-Technologies/android-libunwind and > https://android.googlesource.com/platform/external/libunwind/, ppc64[le] > systems are supported. I doubt it. Android never officially supported architectures other than x86, ARM or MIPS.

Bug#933264: gradle: update SID version to new version?

Newer version of Gradle requires Kotlin, which is being worked on right now. See https://java-team.pages.debian.net/gsoc-kotlin-blog signature.asc Description: OpenPGP digital signature

Bug#931215: many well known Android devices not supported

Control: severity -1 wishlist > You raised the severity of this bug to serious. I think that was by mistake. Since this is a "metabug", I am now giving it a `wishlist`. signature.asc Description: OpenPGP digital signature

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

> 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. I would say downgrade it for the moment. We can deal with it after

Bug#915144: Restrict Tar to at least 1.29b for `--verbatim-files-from`

Package: pristine-tar Version: 1.45 Severity: normal I was checking out the tarball on Debian/kFreeBSD and got the following error: ``` seamlik@debian:~/Documents/debian/android-platform-system-core$ pristine-tar checkout ../android-platform-system-core_8.1.0+r23.orig.tar.xz tar: unrecognized

Bug#859195: Assigning the "fixed" version

Control: fixed -1 1:8.1.0+r23-1~stage1 This bug seems to be caused by 2 SSL patches which were removed in the Oreo upload. For more info please see the report by Bernhard Übelacker at . signature.asc Description: OpenPGP digital signature

Bug#913785: ITP: android-platform-art -- Android Runtime Utilities

Package: wnpp Severity: wishlist * Package name: android-platform-art * Version : 8.1.0+r23-1 * Upstream Author : Google * License : Apache-2.0 * Languages : C++ * Description : Android Runtime Utilities * Homepage:

Bug#913551: [build-rdeps] Provide an option to grep user-defined component

Package: devscripts Version: 2.18.4 Severity: wishlist The default behavior is to grep `main` `contrib` `non-free`, but Ubuntu has a different set of components. Without an option to specify user-defined components, `build-rdeps` can't grep the whole Ubuntu archive. There is a downstream bug

Bug#859195: *** Error in `adb': free(): invalid pointer: 0x81fa9590 ***

Control: tags -1 unreproducible `adb shell` works for me. Can you reproduce the problem? I believe it was an incompatibility between upstream libssl and ADB. We now use BoringSSL instead. signature.asc Description: OpenPGP digital signature

Bug#802469: android-tools-adb: adb client cannot setup server to listen on tcp transport via -a option

Control: tags -1 moreinfo ADB from Android Oreo defaults to start the daemon on a TCP socket. I suppose this bug report no longer applies? signature.asc Description: OpenPGP digital signature

Bug#759611: android-tools-fastboot: fastboot fails to detect device over USB3.0

`fastboot` has been updated since. Can you still reproduce the problem? signature.asc Description: OpenPGP digital signature

Bug#738128: android-tools-adb: adb server locks out subsequent users by using common unix-domain socket location without cleanup

ADB is now updated to Oreo release, and I just tested `start-server` regarding your report. > "adb start-server" starts the adb service with a unix-domain socket by > default (local:5037 maps to /tmp/5037). This is potentially a risky > process (e.g. like the symlink attack from the logfile

Bug#911322: Please link fastboot with system libraries

Control: tags -1 wontfix Control: severity -1 wishlist I will just keep this bug open so people with similar confusion will see this. signature.asc Description: OpenPGP digital signature

Bug#893368: fastboot too old

> /nexus5x-bullhead-install/bullhead-opm3.171019.016$ ./flash-all.sh > fastboot too old > > ie. the latest Android Google Nexus factory images cannot be flashed. Thanks for the report. Now that `fastboot` has been updated to Oreo release, is it still too old? Please let me know if you find the

Bug#858764: adb shell crashes with invalid pointer error

> the command `adb shell` crashes with the following error: > > $ adb shell > * daemon not running. starting it now on port 5037 * > *** Error in `adb': free(): invalid pointer: 0x5653aea7bba0 *** Thanks for the report. ADB has been updated to Oreo release, and I can't reproduce the

Bug#912421: RM: android-platform-system-core [mipsel mips mips64el] -- NBS; stopped building on mips*

Control: retitle -1 RM: android-libadb-dev android-libadb adb fastboot [mipsel mips mips64el] -- NBS; not built on mips* anymore Thanks Mattia. I added the "RM:" back, now it looks a bit better. :) signature.asc Description: OpenPGP digital signature

Bug#912421: RM: android-platform-system-core [mipsel mips mips64el] -- NBS; stopped building on mips*

Thanks for the report. In fact `android-libadb-dev`, `android-libadb`, `adb` and `fastboot` are no longer built on MIPS architectures, so please remove them and them only. Other packages build fine on MIPS for now. I'm not sure how to specify a removal of binary packages on the bug system

Bug#911322: [Android-tools-devel] Bug#911322: Please link fastboot with system libraries

> All of these already exist in the archive: libselinux1, libsepol1, libunwind8 That is because AOSP has forked those projects and added something else to the code, which many components of Android SDK need. As a result, the upstream version of those libraries are not compatible any more.

Bug#911322: [Android-tools-devel] Bug#911322: Please link fastboot with system libraries

> Any reasons why fastboot is linked againt the bundled libraries of > android? Those libraries (e.g. liblog, libutils) are used by Android SDK only and not for general use, and due to their generic SONAME it would be unwise to put them in `/usr/lib`, so we put them in a dedicated directory. >

Bug#911262: fastboot: no fastboot version 8 in experimental

There is an circular dependency between `android-platform-system-core` and `android-platform-system-extras` and the way we solve it is to do staged uploads on `android-platform-system-core`. `fastboot` is disable on stage1, and we will bring it back in a full upload soon. signature.asc

Bug#909949: RFS: android-platform-system-extras/8.1.0+r23-1 (experimental)

Hello Roger, > > The problem is you didn't mention +ds or +repack in version in d/changelog. > I guess the version need to be changed to 8.1.0+r23+ds-1 or > 8.1.0+r23+repack-1. > > Cheers, > Truth to be told, almost all packages in Debian are "repacked" either by applying a different

Bug#898705: [Android-tools-devel] Bug#898705: android-platform-libcore 8.1 upload to unstable?

I am going to upload the Oreo version of src:android-platform-libcore to `unstable` on 9 October if no one objects. The Oreo (8.x) of this package only builds `android-platform-libcore-headers` and `libandroid-json-java` so the majority of the SDK don't really rely on this source package any

Bug#909949: RFS: android-platform-system-extras/8.1.0+r23-1 (experimental)

Thanks for the sponsor again, Roger! I did push the changes already, check . Or do you mean you want a dedicated merge request so you can leave comments their so that in a more

Bug#909949: RFS: android-platform-system-extras/8.1.0+r23-1 (experimental)

replacing the obsolete android-tools-fsutils [ Kai-Chung Yan ] * Debhelper level => 11 * d/rules: Use dh-auto-build instead of plain make thanks to Helmut Grohne * Fix the conflicting types errors (Closes: #892170) * Standards-Version => 4.2.1 Regards, 殷啟聰 | Kai-Chung Yan signature

Bug#905820: android-platform-external-boringssl: Incomplete debian/copyright?

> Uploaded; thanks! Please address the Lintian errors on the next upload, > mind you... Thanks for the upload. Already fixed the error now, don't know why Lintian never told me about that... signature.asc Description: OpenPGP digital signature

Bug#909305: RFS: android-platform-system-core/1:8.1.0+r23-1~stage1.1

> Yes, but for case of ~stageX in version, you need to just change 1 > byte or 2 to comfort lintian. > Why not? Maybe a new versioning scheme would be better, for example, "1:8.1.0+r23-1~stage1+revision1". The current one is indeed not ideal. > This time seems OK for mips* > - >

Bug#909305: RFS: android-platform-system-core/1:8.1.0+r23-1~stage1.1

Hello Roger, > -1~stageX means preparing version -1. Well, it means preparing a version that is earlier than -1. > Hope you can address some lintian on next upload: > - > http://debomatic-armel.debian.net/distribution#experimental/android-platform-system-core/8.1.0+r23-1~stage1.1/lintian Most

Bug#909305: RFS: android-platform-system-core/1:8.1.0+r23-1~stage1.1

Hello Roger! > I just quickly checked the version on salsa, and find d/changelog is > not uploaded yet. I was planning to push the changes to Salsa after it gets uploaded. I just did it a while ago. > So could you change the version to 1:8.1.0+r23-1~stage2 ? No, we will stick with this

Bug#909305: RFS: android-platform-system-core/1:8.1.0+r23-1~stage1.1

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "android-platform-system-core" * Package name: android-platform-system-core Version : 1:8.1.0+r23-1~stage1.1 Upstream Author : Android Open Source Project * URL :

Bug#906134: RFS

Hello Jason, I am not a DD, but this thread might seem inappropriate to appear as a "sponsorship-requests" bug. How about posting it to debian-mentors [1] and then closing this bug? [1]: https://lists.debian.org/debian-mentors signature.asc Description: OpenPGP digital signature

Bug#905820: android-platform-external-boringssl: Incomplete debian/copyright?

> No, sorry, please provide a HTTP-accessible link to .dsc with all the > sources, etc. Just like a regular sponsor request… I understand now, sorry I haven't used that procedure for a long time... Here it is: https://mentors.debian.net/package/android-platform-external-boringssl And the link

Bug#905820: android-platform-external-boringssl: Incomplete debian/copyright?

Hello Chris, > Sorry, please provide a .dsc; I am very busy, alas... Understood... I have attached the .buildinfo, .dsc and .changes files, hopefully they are sufficient? Format: 3.0 (quilt) Source: android-platform-external-boringssl Binary: android-libboringssl, android-libboringssl-dev

Bug#905820: android-platform-external-boringssl: Incomplete debian/copyright?

Hello Chris, > I will happily sponsor individual uploads if provided with a .dsc but I > am not in a position to evaluate the DM (I assume?) status. Then sponsor it is, thanks. I just gave you access to the repository, and prepared the changelog. We use the standard git-buildpackage workflow. >

Bug#905820: android-platform-external-boringssl: Incomplete debian/copyright?

Hello Chris, I just polished [1] the changelog file and I'm about to upload the fix. Could you grant me the upload rights to this package? Thank you. Cheers, Kai-Chung Yan [1]:

Bug#896436: gradle FTBFS: error fetching java api url when building with openjdk-10

@ebourg Shouldn't this be fixed at the `java-common` side instead of here? Switching back to `default-jdk` seems like a step back to me. signature.asc Description: OpenPGP digital signature

Bug#853310: android-platform-system-core: ftbfs with GCC-7

> Anyway, I sponsored this upload targetting experimental. Thank you for the sponsor. I am surprised it got cleared in the queue so quickly. There's a FTFBS on MIPS, I think I can handle it. signature.asc Description: OpenPGP digital signature

Bug#853310: android-platform-system-core: ftbfs with GCC-7

> Who are the DD in the team? Are there other contributors currently > following the process to become a DD? Mostly Hans (eighthave) is the DD involved a lot, and Markus (apo) occasionally helps. I am currently going through the process of becoming a DD but it is going very slowly. > It would

Bug#853310: android-platform-system-core: ftbfs with GCC-7

Hello Raphael, Sorry for being dormant on the matter. We had been in the process of updating the whole SDK suite to Oreo but it is blocked by an upload of this package. The latest update produces several new packages so I don't have the permission to upload it, and the DDs in the team were too

Bug#851860: [Android-tools-devel] Bug#851860: Intent to NMU google-android-installers to fix longstanding l10n bugs

Hello Helge, I am one of the devs at `android-tools` team although I don't maintain the contrib installer packages like this. AFAIK Mouaad is MIA after his work in GSoC 2016, but I can say he will be fine with the NMU and he is not preparing for a new release yet. Please go ahead with your

Bug#905836: Uninstallable on a Clean Sid - update-alternatives Fails to Create a Symbolic Link

Package: openjdk-10-jre-headless Version: 10.0.2+13-1 Severity: grave This package fails to install on the Docker image "debian:sid-slim". The postinst fails to execute successfully. Below is the log: ``` seamlik@zenbook:~$ sudo docker run --rm -it debian:sid-slim bash [sudo] password for

Bug#904978: ITP: protobuf-2 -- This is the protobuf pacakge but version 2.6.1 same as that foudn in jessie but is being packaged to unstable since kotlin-1.1.1 needs it. p.s kotlin-1.1.1 is also being

It needs JetBriains's fork of JDOM [1]. [1]: https://github.com/JetBrains/intellij-deps-jdom Emmanuel Bourg 於 2018年08月09日 16:33 寫道: >> We can do this to `picocontainer`, `protobuf`,`spullara-cli-parser` >> and `jdom`. > > We already have two version of jdom (libjdom1-java and libjdom2-java). >

Bug#904978: ITP: protobuf-2 -- This is the protobuf pacakge but version 2.6.1 same as that foudn in jessie but is being packaged to unstable since kotlin-1.1.1 needs it. p.s kotlin-1.1.1 is also being

l 30, 2018 at 05:23:15PM +0800, 殷啟聰 | Kai-Chung Yan wrote: > > Yes, that Kotlin by Jetbrains. Packaging a language is quite > > complicated, and we are bootstrapping an older version (so the process > > can be a lot easier), and then we will update it to the latest v

Bug#904978: ITP: protobuf-2 -- This is the protobuf pacakge but version 2.6.1 same as that foudn in jessie but is being packaged to unstable since kotlin-1.1.1 needs it. p.s kotlin-1.1.1 is also being

is no longer used by the latest Kotlin. Thanks! Colin Watson 於 2018年07月30日 18:43 寫道: > On Mon, Jul 30, 2018 at 05:23:15PM +0800, 殷啟聰 | Kai-Chung Yan wrote: >> Yes, that Kotlin by Jetbrains. Packaging a language is quite >> complicated, and we are bootstrapping an older version (so the

Bug#823933: ITP: android-platform-external-boringssl -- Fork of OpenSSL that is designed to meet Google's needs

Control: retitle -1 ITP: android-platform-external-boringssl -- Fork of OpenSSL that is designed to meet Google's needs This ITP was intended to fulfill the requirements of Android SDK packages. Now we have decided to package the BoringSSL fork inside AOSP as BoringSSL already states [1] that

Bug#899005: Maven POM refers to a non-existing parent

Package: libfindbugs-java Version: 3.1.0~preview2-3 Severity: important The Maven POM (installed at `/usr/share/maven-repo/com/google/code/findbugs/findbugs/debian/findbugs-debian.pom` refers to a parent POM `org.sonatype.oss:oss-parent:debian` which is not provided by this package. In fact,

Bug#898910: ITP: dd-plist -- Java library for working with property lists

Package: wnpp Severity: wishlist * Package-Name : dd-plist * Version : 1.20-1 * License : MIT * Programming-Lang: Java * Description : Java library for working with property lists * Vcs : https://salsa.debian.org/java-team/dd-plist This package builds the following binary package: *

Bug#898610: Should stop running tests during build as they are for `autopkgtest`

Package: maven-debian-helper Version: 2.3~exp1 Severity: wishlist Java team does not have a generalized `autopkgtest` workflow or suite, so I am setting it `wishlist` for now. signature.asc Description: OpenPGP digital signature

Bug#894290: gradle should raise the source/target level to the minimum supported by the default JDK

Control: reassign -1 gradle-debian-helper 1.6 I would say this is not the fault of Gradle itself, but it the tricks can be provided by `gradle-debian-helper`. We shouldn't modify the behavior of the build tools too much. Let's keep the severity as is for now, as FTBFS is quite serious indeed.

Bug#895886: testng: jcommander classes not found

Yeah, I misunderstood you too. Strange, if `htsjdk` does not configure `jcommander` in `maven.rules`, `1.x` should have been replaced by `debian` on the fly. Maybe `gradle-debian-helper` ignores test classpath? signature.asc Description: OpenPGP digital signature

Bug#895886: testng: jcommander classes not found

By `debian/maven.rules` I mean [1]. It's at line 3. This file configures Gradle as well. Gradle understands the relocations, but it won't add it to the build classpath, that's why it fails. [1]: https://sources.debian.org/src/testng/6.9.12-2/debian/maven.rules signature.asc Description:

Bug#895886: testng: jcommander classes not found

Control: tags -1 |confirmed I relocated `jcommander` from version `1.x` to `debian`, but unfortunately Gradle does not recognize Maven artifact relocations. To fix this, simply remove the line about `jcommander` in `debian/maven.rules`. Hmm, now I have no idea why it used `1.x` in the first

Bug#895601: [Android-tools-devel] Bug#895601: simg2img: Please build simg2img and img2simg for other architectures, specifically arm64

I personally agree with enabling other architectures. You never know if there are arch-specific bugs if you don't build them. And now that we have LAVA to test them for us, which is a win-win.

Bug#847428: Package the Entire "eclipse.jdt.core"

Thank you for this! However, the Jack & Jill toolchain is deprecated now and we no longer plan to package it... signature.asc Description: OpenPGP digital signature

Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java

Control:  forwarded -1 https://issues.apache.org/jira/browse/FELIX-5795 signature.asc Description: OpenPGP digital signature

Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java

forwarded -1 https://issues.apache.org/jira/browse/FELIX-5795 signature.asc Description: OpenPGP digital signature

Bug#883327: repo: Why is this package in contrib if all of its dependencies are in main?

As far as I know, "repo" clones its code from AOSP with Git and then use the downloaded "repo" to do the job. This behavior is similar to a "XXX-installer" package, that's why we put it in "contrib". signature.asc Description: OpenPGP digital signature

Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java

I removed the javadoc package now and it builds find in Sid. Shall I upload it right now? (I still need the upload permission) signature.asc Description: OpenPGP digital signature

Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java

I adopted the patch from Fedora and it looks good. The package builds fine now and 154 of its reverse-build-dependencies built successfully. 27 failed: * activemq-activeio * activemq * apache-directory-server * dnssecjava * istack-commons * jackson-datatype-joda * javassist * jayway-jsonpath *

Bug#875336: FTBFS with Java 9: _ as identifier

I just tried building it and Groovy was fine enough, but now Gradle complains Theoretically, ALL Gradle packages FTBFS since the current version is too old to play with Java 9's fancy version number. signature.asc Description: OpenPGP digital signature

Bug#892603: ITP: android-platform-system-extras-ext4 -- this package will contain the necessary tools required to make android images(.img) with the ext4 file systems and hence replace android-tools-f

Extending the existing "android-platform-system-extras" source package is more than sufficient signature.asc Description: OpenPGP digital signature

Bug#875336: FTBFS with Java 9: _ as identifier

I recently updated the package to 3.5.0 just to find out the current Groovy (2.4.8) does not support Java 9 [1]. Groovy was used by the bootstrapping script. Setting source & target to Java 8 doesn't solve the problem either. [1]: https://github.com/gradle/gradle/issues/2995 signature.asc

Bug#892519: ITP: maven-dependency-tree-2 -- Tree-based API for resolution of Maven project dependencies

Package: wnpp Severity: wishlist * Package Name : maven-dependency-tree-2 * Version : 2.2-1 * License : Apache-2.0 * Programming Lang: Java * Description : Tree-based API for resolution of Maven project dependencies * VCS : https://anonscm.debian.org/git/pkg-java/maven-dependency-tree-2.git This

Bug#891695: "mh_linkjar" and "mh_installpoms" Do Not Support "--relocate"

Because I was trying to get around with the error of "mh_linkjar" I admit that is a wrong attempt. But never mind, the point is to let all "mh_" sequence support all options in "*.poms" files but ignore whatever is irrelevant to them. signature.asc Description: OpenPGP digital signature

Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java

This is getting awkward... Maven Bundle Plugin does not only rely on old Maven Dependency Tree, but also targets Maven 2.x [1]. What's worse, Maven Dependency Tree 2.x also relies on Maven 2.x [2]. I tried building Maven Dependency Tree 2.2 against Maven 3.x and found that it uses removed

Bug#892268: ITP: felix-resolver -- OSGi Resolver implementation by Apache Felix

Package: wnpp Severity: wishlist * Package Name : felix-resolver * Version : 1.14.0-1 * License : Apache-2.0 * Programming Lang: Java * Description : OSGi Resolver implementation by Apache Felix * Vcs : https://anonscm.debian.org/cgit/pkg-java/felix-resolver.git This is a subproject of Apache

Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java

I propose to bring back Maven Dependency Tree 2.x as a new package that coexists with its latest version. Even in the latest (3.5.0) version, Maven Bundle Plugin still uses those deprecated APIs in Maven Dependency Tree 2.x. These deprecated APIs have been removed from Maven Dependency Tree

Bug#891695: "mh_linkjar" and "mh_installpoms" Do Not Support "--relocate"

I put this in the .poms: > debian/pom.xml --no-parent --usj-name=osgi.cmpn > --relocate=org.osgi:org.osgi.compendium:debian The point is to let all mh_ sequences support all options and simply ignore anything that's irrelevant to themselves. signature.asc Description: OpenPGP digital

Bug#891695: "mh_linkjar" and "mh_installpoms" Do Not Support "--relocate"

Package: maven-repo-helper Version: 1.9.2 Severity: important If I use "jh_maven_repo_helper" and then add a "relocate" option to ".poms", "mh_linkjar" shows the following error: > Invalid option: relocate So I move the "relocate" option to "debian/rules" as ```make override_mh_installpoms:   

Bug#885580: debhelper: dh add-ons are order sensitive

I encountered a similar situation, hope this help with the issue. I was developing a addon called "maven-repo-helper-extras" who depends on "maven-repo-helper" [1]. The dh sequences in my addon need to be inserted after the sequences introduced by "maven-repo-helper", so I was seeking a way to

Bug#890597: ITP: maven-repo-helper-extras -- Additional plugins complementing maven-repo-helper

Package: wnpp Severity: wishlist * Package Name : maven-repo-helper-extras * Version : 0.1 * License : Apache-2.0 * Programming Lang: Java * Description : Additional plugins complementing maven-repo-helper * URL : https://salsa.debian.org/seamlik-guest/maven-repo-helper-extras This package

Bug#584882: devscripts: [build-rdeps] should offer a list-only output of packages, too

I believe the "--quiet" option in at least 2.17.12 (currently in Buster) solves this issue. signature.asc Description: OpenPGP digital signature

Bug#890345: Depending on "default-jre-headless" Should be Sufficient

Package: jflex Version: 1.6.1-2 Severity: wishlist "jflex" seems to me a commandline program, thus depending on "default-jre-headless" should be sufficient. Right now it depends on "default-jre" and "pbuilder" always fetches the whole graphical stack while building "libsmali-java".

Bug#890222: ITP: jnacl -- Pure Java implementation of the NaCl: Networking and Cryptography library

Perhaps urge him to make a release? signature.asc Description: OpenPGP digital signature

Bug#888741: Does Not Honor defaultTasks

Package: gradle-debian-helper Version: 1.6 Severity: normal One may specify the default tasks to run in a Gradle script, thus avoid messing with the commandline. However gradle-debian-helper makes it impossible to use this feature, for it adds a "jar" task if no task is specified. It could be

Bug#879175: androidsdk-tools: Duplicate of android-platform-tools-swt

(I am one maintainer of android-platform-tools-swt) To be honest, both should be removed since Google has abandoned android-platform-tools-swt. That's why it remains unbuildable as of today. signature.asc Description: OpenPGP digital signature

Bug#876764: Update to Release 2.0.0 and Point Homepage to GitHub

Package: libscout Version: 0.0~git20161124~dcd2a9e-1 Severity: minor Upstream has newer release now and they also moved the code to GitHub [1]. [1]: https://github.com/reddr/LibScout signature.asc Description: OpenPGP digital signature

Bug#862529: uncommons-watchmaker-doc: Rename the documentation package to lib*-java-doc

The reason behind this package name is that it provides the Javadoc for both of the 2 library packages (libuncommons-watchmaker-framework-java & libuncommons-watchmaker-swing-java). If I split their Javadocs, there will be dead hyperlinks (or in fact the class fullname instead of hyperlinks)

Bug#860110: Point "Homepage" to the real one

Package: ibus-table-emoji Version: 1.3.9-2 Severity: minor The "Homepage" section currently points to [1], however the project home is actually [2] according to `debian/watch` file. Please fix this in order to avoid confusion to other maintainers. [1]: https://github.com/ibus/ibus/wiki [2]:

Bug#860109: Clarify in the package subtitle and description that it is for emoticons instead of emoji

Package: ibus-table-emoji Version: 1.3.9-2 Severity: wishlist Control: forwarded -1 https://github.com/moebiuscurve/ibus-table-others/issues/15 In modern days, an emoji [1] means a single graphical character which is part of the Unicode standard while an emoticon [2] means a graphical token

Bug#856996: libjacoco-java: Where is the jacoco agent located?

As ebourg said, maven-pgp-plugin isn't necessary for the build process, IMO. Well if it does affect the process, then something's probably not right... I tried updating maven-shade-plugin to the latest version (3.0.0) but gave up since it introduces quite a few new dependencies that are absent in

Bug#856996: libjacoco-java: Where is the jacoco agent located?

Hello Quinson, I won't say the package is unusable since `org.jacoco.core.jar` and `org.jacoco.report.jar` are used when building Gradle Android Plugin. I tried enabling the build of `org.jacoco.agent` and `org.jacoco.agent.rt` in this package but maven-shade-plugin always gave me error. I

Bug#856996: libjacoco-java: Where is the jacoco agent located?

Hello Quinson, The current Debian package only provides 2 JARs: `org.jacoco.core.jar` and `org.jacoco.report.jar`. It is an incomplete package at the moment because building the whole project requires a lot more new packages. At the time when I was packaing it, JaCoCo was only used by the Gradle

Bug#856386: Rename the package to android-sdk-helper

Control: retitle -1 ITP: android-sdk-helper -- Helper tools for building Android apps using Debian's Android SDK Control: owner -1 !

Bug#856386: android-debian-helper -- Helper Tools for Building Android Apps Using Debian's Android SDK

Package: wnpp Severity: wishlist * Package Name: android-debian-helper * Version : 0.1 * License : Apache-2.0 * Programming Lang: Java * Description : Helper Tools for Building Android Apps Using Debian's Android SDK * Alioth :

Bug#855861: ITP: libscout -- Third-party libraries detector for Android apps

Package: wnpp Severity: wishlist * Package Name: libscout * Version : 0.0~git20161124~dcd2a9e-1 * Upstream Author : Erik Derr * License : EPL-1.0 * Programming Lang: Java * Description : Third-party libraries detector for Android apps * URL

Bug#855274: ITP: smali-1 -- assembler/disassembler for Android's dex format

Package: wnpp Severity: wishlist * Package Name: smali-1 * Version : 1.4.2-1 * License : BSD-3-clause * Programming Lang: Java * Description : assembler/disassembler for Android's dex format * URL : https://github.com/JesusFreke/smali * Alioth :

Bug#855270: ITP: wala -- Static analysis on Java bytecode and related languages

Package: wnpp Severity: wishlist * Package Name: wala * Version : 1.3.9-1 * Upstream Author : IBM Corporation * License : EPL-1.0 * Programming Lang: Java * Description : Static analysis on Java bytecode and related languages * URL : http://wala.sourceforge.net

Bug#855262: Set System Encoding as UTF-8

Package: gradle-debian-helper Version: 1.5.1 Severity: wishlist On Debian Buildd the default encoding on Java is usually not UTF-8, which results in compilation failure on source files containing CJK symbols or even a "©". Currently we need to add `-Dfile.encoding=UTF-8` to

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

`hasUpperCaseCharacter()` has been removed from android-platform-tools-base 2.2.2, and android-platform-tools-swt is already abandoned by upstream. Therefore I have no intention to fix this bug at the moment. android-sdk-meta does not depend on this package either, so removng it won't affect

Bug#847428: Package the Entire "eclipse.jdt.core"

Source: ecj Version: 3.11.0-7 Severity: wishlist Control: block 847427 by -1 Dear maintainers, android-toolchain-jack requires both the existing libecj-java and the "org.eclipse.jdt.compiler.apt" module in "eclipse.jdt.core". As the upstream of src:ecj is exactly "eclipse.jdt.core", so I wish

Bug#847427: ITP: android-toolchain-jack -Java Android Compiler Kit

Package: wnpp Severity: wishlist * Package Name: android-toolchain-jack * Version : 1.3~b8 * Upstream Author : The Android Open Source Project * License : Apache-2.0 * Programming Lang: Java * Description : Java Android Compiler Kit * URL :

Bug#845606: The Bytecode Should Not Be Targeting Java 1.2

In version 1.3~b8 that I have been packaging, Jack uses ASM 5.0.4 [1]. The upstream Jack is not affected by this particular problem because the source of Jack includes the source of all external dependencies which are compiled using Ant and javac and are included into `jack.jar` when Jack is

Bug#845606: The Bytecode Should Not Be Targeting Java 1.2

I tried building Jack using the asm-all.jar from jcenter and it failed with the same error. And when I checked the classes in this JAR it gave me "Java 1.2" as well. So looks like the same problem applies to the upstream as well.

Bug#845606: The Bytecode Should Not Be Targeting Java 1.2

FYI, I forwarded the bug to ASM's upstream issue tracker [1]. I propose the follwing patch to fix the bug: ``` diff --git a/debian/rules b/debian/rules index 734f78c..ed59b80 100755 --- a/debian/rules +++ b/debian/rules @@ -6,7 +6,7 @@ VERSION ?= $(shell dpkg-parsechangelog | sed -rne

Bug#846855: ITP: android-platform-tools-analytics-library -- Libraries for tracking the usage analytics of Android SDK

Package: wnpp Severity: wishlist * Package Name: android-platform-tools-analytics-library * Version : 2.2.2-1 * Upstream Author : The Android Open Source Project * License : Apache-2.0, EPL-1.0 * Programming lang: Java * Description : Libraries for tracking the usage

Bug#846845: A New Option for Prefixing usj-name with Group ID

Package: maven-repo-helper Version: 1.9.2 Severity: wishlist There are Java libraries that are forks of some upstreams or are some internal libraries that are never released to be used by other projects. There are also libraries whose names are too general (e.g.

Bug#844531: mh_depends: Generate ${maven:Depends} Accorfing to *.poms

Control: reassign -1 maven-repo-helper 1.9.2 Oops, wrong command.

Bug#844531: mh_depends: Generate ${maven:Depends} Accorfing to *.poms

Control: reassign -1 src:maven-repo-helper maven-repo-helper It's not a source-wise or build-wise problem, so it's better to stay in the binary package section.

Bug#844021: libnative-platform-java 0.11-4 is not compatible with programs built with 0.10*

Hi Vincent, Thanks for the patch, I think breaking libgradle-core-java is enough as this is the very package that uses libnative-platform-java. I'm uploading it soon.

  1   2   3   >