combatopera / cowpox Goto Github PK

e.g. 100% Computing updates... is flushed but leapfrogs Update build-tools to: 30.0.3 and similarly 100% Unzipping... android-8.1.0/build. is all the way at the bottom of the file - this is almost certainly due to stdout being fully buffered not line buffered, so the easiest fix would be to direct this text to stderr

• what other stdout do we have? - a lot more, but it doesn't go via sys.stdout so won't trigger python to flush its buffer

it currently takes about half an hour which is much too long

once sdk/ndk/deps/gradleplugins etc have been downloaded, it shouldn't be necessary to download anything again until a version is changed

2 kinds of location:

• importable extension module
• interim copy of .so file under build/lib.linux-x86_64-3.6

or wherever wheels and things normally go

e.g. pyrbo did not pull in nativecommon

every pyc includes the source path, let's minify it to save space

adb: failed to install project-debug.apk: Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package ... signatures do not match the previously installed version; ignoring!]

perhaps Cowpox should build things in a temporary area in the container, and copy each one to bind mount when done?

e.g. xt_RATEEST.h and xt_rateest.h try to occupy the same path and their content is different, there are a few other examples

• why isn't the mount case sensitive? - apparently insensitive is the default on macos
• how to fix?

https://developer.android.com/games/sdk/frame-pacing

a few things can be simplified

sitecustomize and all the java probably. these should have the same header as in buildozer/p4a. need some way of organising these files so that pyven doesn't check them, the current exception when parent name is contrib is probably not enough

i believe it's not a simple case of bumping the version

it should follow a similar convention to sdist/wheel names, also see #9

fix #15 first. two cases:

• running egg_info to get requires out of setup.py, in this case we can throw away upper
• building the source, in this case we keep upper
• need to setup before dropping privileges - could we use fstab to allow non-root remount, thus allowing manipulation of upper dir while unmounted?

python alpine

python is capable of doing such tasks

• retire naming based on location, require name on class and use that for lookup
• make additional locations for plugin discovery configurable (this is more of an enhancement and could be a separate ticket)

• it should be buildable by docker hub - done, we still need a u/g (as some parts of the build want a home dir to put things in) but they are now made on startup
• set uid/gid in example project - not needed, Cowpox gets them from the mount

docker hub doesn't really support options, so this doesn't need to either. probably add a tag entry to project.arid

embarrassing!

Cowpox is a GPL project incorporating MIT-licensed (and some Apache) code from buildozer and python-for-android. The best info i could get on how to achieve that in the source is in this document: http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

• it looks like the upstream projects don't have per-file notices, which makes things easier. we need to keep the LICENSE file, which is identical in both upstream projects - cool, i never deleted it
  • on closer inspection some have an apache notice - this is also compatible with gpl, so i can simply leave such notices in
• each file will need a rather large header as per the above document - done
  • pyven support for testing - implemented via a licenses list to which you can add MIT
  • check pyven enforcement covers all substantial files - it covers the important ones now, notably not C files, but i'm not going to touch those at the moment we can add them later
  • release pyven changes - done, version 42 - made MIT path configurable in 43
• we can add the usual COPYING file next to LICENSE - done
  • do i need to explicitly say they both apply you can't pick one? - we're going to add a header to each file, so hopefully it shouldn't be necessary - renamed to LICENSE.kivy just in case
  • check what github licence detection makes of this - "View license" links to COPYING, which is fine
• rebase the code so that any snapshot including (not yet public) work i've done also includes these changes - we can do the licensing in a branch, make that public first, then rebase my changes on top of that - done, glad that's over
  • take opportunity to rename master to trunk - done!

including python, which is important as 3.9 is around the corner

if the recipe version satisfies the range it's all good, otherwise need to work out a sensible thing to do