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

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

Bug#1029668: confirmed

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

Bug#1011567: needs com.sun.javadoc migration

Looks like doclava would need to be ported to use the API that replaces com.sun.javadoc: https://docs.oracle.com/en/java/javase/11/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration If someone does the migration, I can take care of the packaging updates.

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

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

Bug#1012103: upstream still uses java8

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

Bug#1026083: Security: XSS bug in Loofah

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:

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

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

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

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:

Bug#973082: confirmed

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

Bug#973082: confirmed

Do the tests pass with this patch?

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

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

Bug#972377: can't reproduce

can't reproduce

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

Control: reopen -1

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

Control: reassign -1 aapt Control: merge 977023 977912 This is due to aapt's linking error. The fdroidserver tests rely on aapt.

Bug#975747: this is actually fixed

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

Bug#979329: I think I have a fix

Control: tags -1 pending confirmed This is also confirmed by CI: https://salsa.debian.org/android-tools-team/android-platform-system-core/-/jobs/1310262 Testing a fix here: https://salsa.debian.org/eighthave/android-platform-system-core/-/jobs/1314158

Bug#973082: confirmed

Control: tags -1 help confirmed In Python 3.9, the plistlib was changed to no longer have the internal data structure plistlib.Data, which biplist relied on. Here's a potential fix: https://github.com/unified-font-object/ufoNormalizer/pull/74/files

Bug#972377: can't reproduce

Control: fixed -1 1.6.1-2 I can't reproduce this, perhaps it was fixed by the upgrade to Python 3.9. For example: https://salsa.debian.org/python-team/packages/pyasn/-/pipelines/214872

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

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*

Bug#976891: update

fastboot is getting pretty close to working on amd64: https://salsa.debian.org/eighthave/android-platform-system-core/-/jobs/1297944

Bug#963058: upstream only supports x86

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

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

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

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

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

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

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 pu

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

Hans-Christoph Steiner: It looks like the clean build stops before the error you reported: https://salsa.debian.org/eighthave/android-platform-art/-/jobs/1291335 In file included from runtime/runtime.cc:53: runtime/asm_support.h:24:10: fatal error: 'asm_defines.h' file not found #include

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

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"

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

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=.

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

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

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

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

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

Control: fixed -1 1:10.0.0+r36-1 Oops, forgot to mark it in the changelog

Bug#972041: not a showstopper

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

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

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:

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

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

Bug#955695: 1.5.2 has different error

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',

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

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

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

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

Bug#954395: binfmt went away

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

Bug#894284: blocked by Kotlin

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

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

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

Bug#929905: autoremoval of fdroidserver

Control: severity 929905 important Please keep it in buster, I would like to go the point release route.

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

Theodore Ts'o: > On Mon, Apr 22, 2019 at 06:09:23PM +0200, Jonas Meurer wrote: >> Hans-Christoph Steiner: >>> Theodore Ts'o: >>>> So your choice --- we can either reassign this bug back to fastboot or >>>> android-sdk-platforms-tools, or I c

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

Theodore Ts'o: > On Thu, Apr 18, 2019 at 09:32:06PM +0200, Hans-Christoph Steiner wrote: >> >> One possibility would be including libsparse as a patch, it doesn't >> change a lot: >> https://android.googlesource.com/platform/system/core/+log/master/libsparse >&g

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

One possibility would be including libsparse as a patch, it doesn't change a lot: https://android.googlesource.com/platform/system/core/+log/master/libsparse But it depends on Android's libbase and libz-host.

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

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

Bug#924591: the bug is in mke2fs

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

Bug#924591: e2fsprogs?

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

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

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

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

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

Bug#924591: should be 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

Bug#901952: usability bug

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

Bug#901952: can affect packaged with old source tarballs

this also goes the other way, where tarballs created in tar 1.30 fail to work in pristine-tar when tar 1.29 is installed: https://salsa.debian.org/python-team/modules/libcloud/-/jobs/115815

Bug#901952: can affect packaged with old source tarballs

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

Bug#894285: some progress

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

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

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

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

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

Bug#901952: another case

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

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

yeah, I guess it should be removed. Feel free to remove this, I won't have to do it in the near future. signature.asc Description: OpenPGP digital signature

Bug#903388: Failure to install with Python 3.7

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):

Bug#901952: new info

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

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

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

Bug#681726: Time to remove eclipse from Testing?

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 ->

Bug#890593: things never worked on big-endian

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

Bug#874216:

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

Bug#874216:

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

Bug#860656: actually...

Control: tags -1 patch Actually, upstream responded after looking into the details. I was wrong, we should just fix the tests.

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

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

Bug#860656: forwarded upstream

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

Bug#860686: build needs lots of RAM

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

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

my guess is that this rebuild was done with limited RAM, since the failure is: "The system is out of resources."

Bug#858177: CVE-2016-3921

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

Bug#858177: not affected

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

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

I'm fine with it being moved to contrib.

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

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

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

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

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

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

Bug#849390: google-android-installers

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

Bug#849346: plan to merge packages

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

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

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

Bug#823004: point users to dummydroid

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

Bug#823004: gplaycli: sensitive information in config file

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

Bug#827215: stub for now

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

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

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

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

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

Bug#823309: marked as pending

5e587dd26fbb2364476e55d958050e180f5eee6c Author: Hans-Christoph Steiner <h...@eds.org> Date: Wed Jun 1 12:08:57 2016 +0200 update debian/changelog for upload diff --git a/debian/changelog b/debian/changelog index 366a292..4f11b90 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3

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

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

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

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

Bug#814876: builds for me

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

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

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

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

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:

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

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

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

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).

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

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

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

thanks for the bug report. I think the workaround is to install android-libhost-dev. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783174: www.google.com

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

Bug#776987: version string in libsqlcipher

FYI, I CC'ed the bug for the record: Kali Kaneko: On Tue, Apr 07, 2015 at 02:53:59PM -0400, Hans-Christoph Steiner Unfortunately, I don't think it is going to be as simple as just removing the patch that changes VERSION to the SQLCipher version. Some places need the SQLite version

Bug#776987: version string in libsqlcipher

I did just think of one last thing to check: the SO versioning of the library file, i.e. libsqlcipher.so Also, the public representation of the SQLCipher version, like in sqlcipher.pc, version the SQLite3 version. .hc signature.asc Description: OpenPGP digital signature

Bug#779331: wheezy update

I think this also needs to be a security update in wheezy and jessie. What are the plans for that? signature.asc Description: OpenPGP digital signature

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

Package: maven Version: 3.0.4-3 Severity: grave Tags: security By default, maven versions before v3.2.3 downloads from Maven Central using plain HTTP and do not check any kind of signature on the code before running it. This is a very bad situation, making it quite easy for malicious actors take

Bug#776987: libsqlcipher0: change in VERSION affects code depending on SQLITE_VERSION_NUMBER

Unfortunately, I don't think it is going to be as simple as just removing the patch that changes VERSION to the SQLCipher version. Some places need the SQLite version and other places need the SQLCipher version. Probably the way to do this is make a SQLCIPHER_VERSION file, then edit

Bug#768189: should not automatically change MAC (w/o user consent)

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

  1   2   >