Re: [arch-general] Android support in Linux Arch

2014-04-25 Thread Thiago Barroso Perrotta
Hello,

Yeah, android-udev would be useful in [community]. And what do you think
about moving android-sdk too?

I personally also find more useful to get updates about Android tools from
it rather than using any package managers or aur pkgbuilds.

/opt could still be its install location.

All the best,

Sent from my Android
On Apr 23, 2014 1:28 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote:

 Hi,

 As there is no strong consensus on what to do with Android development
 tools then I am going to leave the situation as-is. Arch users will
 keep either installing the packages using Android installer or by AUR
 packages.

 I am going to move packages android-tool and android-udev to
 [community]. These are small packages that many people find useful.



Re: [arch-general] Android support in Linux Arch

2014-04-23 Thread Anatol Pomozov
Hi,

As there is no strong consensus on what to do with Android development
tools then I am going to leave the situation as-is. Arch users will
keep either installing the packages using Android installer or by AUR
packages.

I am going to move packages android-tool and android-udev to
[community]. These are small packages that many people find useful.


Re: [arch-general] Android support in Linux Arch

2014-04-23 Thread Leonidas Spyropoulos
Hello

On Thu, Apr 17, 2014 at 10:22 PM, Karol Babioch ka...@babioch.de wrote:
 Hi,

 Am 17.04.2014 08:53, schrieb Daniel Micay:
 I think it's best to just install it to your home directory without
 involving the system package manager if you want to use the android
 package manager for anything.

 So you are managing all of this alone and don't use the packages in AUR
 at all? At least android-udev seems useful? Where do you store your SDK?
 Have you added something to your PATH? I'm just looking for good
 practices here, so thanks for any replies!


I've been coding for Android for some time now. I found the
android-udev and android-tools packages very useful but apart from
that I've downloaded and installed locally the Android SDK and IDE
(Android Studio is my preference). I manage android updates separately
without the use of a package manager (or aur). As you understand I had
to specify the paths on my profile. The Android SDK is installed under
home (along with multiple jdk versions)

[...]


On Wed, Apr 23, 2014 at 5:28 PM, Anatol Pomozov
anatol.pomo...@gmail.com wrote:
 Hi,

 As there is no strong consensus on what to do with Android development
 tools then I am going to leave the situation as-is. Arch users will
 keep either installing the packages using Android installer or by AUR
 packages.

 I am going to move packages android-tool and android-udev to
 [community]. These are small packages that many people find useful.

I agree with this approach.

Thanks,
Leonidas

-- 
Caution: breathing may be hazardous to your health.

#include stdio.h

-- 
Caution: breathing may be hazardous to your health.

#include stdio.h
int main(){printf(%s,\x4c\x65\x6f\x6e\x69\x64\x61\x73);}


Re: [arch-general] Android support in Linux Arch

2014-04-18 Thread arnaud gaboury
Please have a look here[1]. It is a Arch based distro developed by Android dev.
You can add the repo in your /etc/pacman.conf


[1]http://bbqlinux.org/


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Karol Babioch
Hi,

Am 17.04.2014 04:22, schrieb GSC:
 You can just chown /opt/android-sdk and it will be easier to install api.

Yeah, although I don't like the idea to mess around in /opt. Maybe it
would be possible to introduce an android group, so it would be
sufficient to add my user to this group?

 especially some huge package like android-ndk.  I don' t know why you
 only consider non-binary packages.

+1. android-ndk is a pain in the ass to compile, especially on older
hardware, where it takes not only long but might run into memory
restrictions, because it takes up so much RAM.

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Daniel Micay
On 17/04/14 02:20 AM, Karol Babioch wrote:
 Hi,
 
 Am 17.04.2014 04:22, schrieb GSC:
 You can just chown /opt/android-sdk and it will be easier to install api.
 
 Yeah, although I don't like the idea to mess around in /opt. Maybe it
 would be possible to introduce an android group, so it would be
 sufficient to add my user to this group?

I think it's best to just install it to your home directory without
involving the system package manager if you want to use the android
package manager for anything.

It's not sane to be giving users access to a directory in the PATH of
other users, especially root. Many people have a single user system
without a true non-administrator account, but packages need to be secure
in cases where this isn't true.



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Karol Babioch
Hi,

Am 17.04.2014 08:53, schrieb Daniel Micay:
 I think it's best to just install it to your home directory without
 involving the system package manager if you want to use the android
 package manager for anything.

So you are managing all of this alone and don't use the packages in AUR
at all? At least android-udev seems useful? Where do you store your SDK?
Have you added something to your PATH? I'm just looking for good
practices here, so thanks for any replies!

 It's not sane to be giving users access to a directory in the PATH of
 other users, especially root.

Yes, I feel very much the same way.

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Daniel Micay
On 17/04/14 05:22 PM, Karol Babioch wrote:
 Hi,
 
 Am 17.04.2014 08:53, schrieb Daniel Micay:
 I think it's best to just install it to your home directory without
 involving the system package manager if you want to use the android
 package manager for anything.
 
 So you are managing all of this alone and don't use the packages in AUR
 at all? At least android-udev seems useful? Where do you store your SDK?
 Have you added something to your PATH? I'm just looking for good
 practices here, so thanks for any replies!

I use the AUR packages without touching the Android package manager at
all. If I did plan on installing stuff from there, I would just install
the SDK to my home directory and use a meta-package (no contents) to
handle the external dependencies. You can add user-specific
binary/library directories to PATH and the library search path (a fairly
sane usage of LD_LIBRARY_PATH).

 It's not sane to be giving users access to a directory in the PATH of
 other users, especially root.
 
 Yes, I feel very much the same way.
 
 Best regards,
 Karol Babioch




signature.asc
Description: OpenPGP digital signature


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Karol Babioch
Hi,

Am 17.04.2014 23:29, schrieb Daniel Micay:
 I would just install
 the SDK to my home directory and use a meta-package (no contents) to
 handle the external dependencies.

Yes, that would probably make sense. Maybe such a package could be
uploaded to the AUR.

I've installed it to my home directory for now. The only dependency I
needed to get it running was swt. I'm not sure why the AUR packages
lists all of the lib32 as dependency (for x86_64). I guess I'll find out
soon enough.

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Hugo Osvaldo Barrera
Looks like my message was silently dropped by mailman. Lemme retry this:

On 2014-04-16 20:49, Hugo Osvaldo Barrera wrote:
 First of all, thanks for all the efort you're putting into moving these
 arch tools into the official repos. I've been wanting to see this (and
 non-bin packages) for ages! :)
 
 On 2014-04-17 00:50, Karol Babioch wrote:
  Hi,
  
  Am 17.04.2014 00:38, schrieb Anatol Pomozov:
   Are there people with Android development background? What exactly do
   you miss in Arch? 
  
  The problem I face with the Android situation in Arch is that currently
  there seems to be no clean (TM) way to install the SDK and related
  stuff. The android-sdk package from AUR is fine and dandy, but one
  usually also needs to install a whole bunch of API specific packages
  through the android tool from the SDK.
  
  - This doesn't work for normal users, e.g. you can update the packages
  using Eclipse, but you need to start /opt/android-sdk/tools/android as
  root
 
 Does this download additional files, or actually replace files the arch 
 package installs?
 
 If it's the former, then you can create a user group (eg: android),
 and make the directory where files are downloaded owned by that group.
 
  
  - Installing any sort of package through the installer mentioned above
  isn't compatible with the whole idea of package management, because the
  package manager isn't aware of these files. I ran into conflicts before,
  which I had to resolve by temporarily removing some components.
 
 If we can make arch packages for all the packages available through that
 installed, that would make it innecesary, though still usable. Something
 similar happens with npm, gem (when used at a system level), pip, etc:
 there's a second package manager that can (optionally) be used, but it's
 a bad idea if you want to keep using arch's.
 
  
  Maybe I'm doing something wrong here, but at least this is what I've
  experienced throughout the last couple of months. Unfortunately I don't
  see a good way how this can be improved, as I like the idea of
  installing only API components that I really need and get instant (!)
  updates for them directly from the upstream project.
  
 
 If you want the instante updated from upstream, then you'd need to update
 the arch package instantly ;) This is exactly what happens with some of
 the above mentioned examples (npm).
 
  Anyone familiar with the situation on other distributions? How do they
  handle all of this?
  
 
 I did a bit of research on this.
 Ubuntu suggest you download the SDK and install into into your home:
 https://help.ubuntu.com/community/AndroidSDK
 (so no useful precedent here).
 
 The same applies for Fedora:
 https://fedoraproject.org/wiki/HOWTO_Setup_Android_Development
 
 Gentoo uses the upstream binaries in their packages (ebuild?):
 https://wiki.gentoo.org/wiki/Android
 
 They DO seem to set permissions to 775, and ownership to root:android,
 so I guess they do something similar to what I suggested above.
 
 Finally, Debian doesn't seem to package anythis other than the packages
 that were mentioned as existing in AUR as source packages, so there's
 nothing to be leart there.
 
  Best regards,
  Karol Babioch
  
 
 Hope this helps a bit,
 
 Cheers,
 
 -- 
 Hugo Osvaldo Barrera



-- 
Hugo Osvaldo Barrera
A: No, it doesn't make sense.
Q: Should I include quotations *after* my reply?


pgpipbq8yMXoQ.pgp
Description: PGP signature


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Karol Babioch
Hi,

Am 18.04.2014 00:35, schrieb Hugo Osvaldo Barrera:
 Does this download additional files, or actually replace files the arch 
 package installs?
 
 If it's the former, then you can create a user group (eg: android),
 and make the directory where files are downloaded owned by that group.

Well, it probably depends on what exactly you select to install. When
there is a new API level, there will definitely be new files. This can
lead to file conflicts, because pacman will complain that the file(s)
already exist once the package gets updated. This can be resolved
easily, but requires some knowledge about package management. Probably
nothing a beginner (either to pacman or to the SDK wants to deal with).

 I did a bit of research on this.

Thanks for that!

 Ubuntu suggest you download the SDK and install into into your home:
 https://help.ubuntu.com/community/AndroidSDK
 (so no useful precedent here).

 The same applies for Fedora:
 https://fedoraproject.org/wiki/HOWTO_Setup_Android_Development

Personally I like this approach the most. Obviously it has drawbacks in
multi-user environments. But it won't lead to conflicts, because pacman
doesn't know anything about it and to be quite honest most of us are the
only user on a system anyway.

However, I kind of like the proposed idea of an empty meta package,
that will only trigger the installation of dependencies. Is this
something you would be interested in?

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Hugo Osvaldo Barrera
On 2014-04-18 01:20, Karol Babioch wrote:
 ...snip...
 Personally I like this approach the most. Obviously it has drawbacks in
 multi-user environments. But it won't lead to conflicts, because pacman
 doesn't know anything about it and to be quite honest most of us are the
 only user on a system anyway.
 
 However, I kind of like the proposed idea of an empty meta package,
 that will only trigger the installation of dependencies. Is this
 something you would be interested in?
 
 Best regards,
 Karol Babioch
 

I actually use the meta-package approach to handle dependencies for
wine-based and steam-based games, so I wouldn't mind (I hate marking
dependencies as explicitly installed, so that's a second reason to
do that).

I'm curious if those are acceptable in the AUR.

-- 
Hugo Osvaldo Barrera


pgpvLQkjBDSlf.pgp
Description: PGP signature


[arch-general] Android support in Linux Arch

2014-04-16 Thread Anatol Pomozov
In my TU application I promised to look at situation with Android
support in Arch.

Android is an open-source project that has a number of sub-projects.
The official website offers prebuild binaries for those sub-projects
such as sdk, ndk, build-tools, IDE plugins,... We want to simplify
Android installation and maintenance and looking into turning it into
real packages. Installing tools by downloading and unpacking is sux
and so 90s.

The naive way to add packages is to use these binaries and just repack
them into Arch packages. Or download-at-installation - something like
what we do for proprietary software. AUR has many android packages
that download binary files from Android website. But using prebuilt
binary packages is something atypical for Arch. There are issues with
it:

- android download site provides only 32-bit binaries so multilib
repositories are required
- prebuild packages do not use standard installation paths
- they compile against older version of third-party projects and
bundled it into download files. The packages should depend on existing
system libraries instead.

The plan is to provide proper Arch packages that do not have the
problems listed above.

I initially tried to build a package that follows build whole Android
source-tree official instructions [1]. And then pack only parts we
need. Oh boy, this was painful. The source tree is several Gb of code,
it pulls prebuilt versions of gcc, clang, python,.. It requires
specific version of make and java. After a week of trying to build
Android on Arch without using prebuilds I gave up.

Actually those instructions [1] build system images that include
kernel and ARM code for a specific hardware. Arch does not need it.
I've decided to attack this problem from other side: find what exactly
we need to pack as Arch packages and then build it from sources.

I've decided to look to AUR non-binary android packages and see what
people vote for (who said that voting is useless?). There are a number
of packages that seems good for moving to [community]:

- android-tools https://aur.archlinux.org/packages/android-tools/ It
contains adb and fastboot. These the packages that I am interested in.
I am not an Android developer I am just an Android user and adb is the
most useful Android tool for me.

- android completion for adb/fastboot
https://aur.archlinux.org/packages/android-bash-completion/  these
files can be merged into previous package.

- android-udev https://aur.archlinux.org/packages/android-udev/ sounds
useful as well

These 3 packages is easy to move to [community] and my gut feeling
says it should be enough for the most Android users.


These is another category of users: those who *develop* for Android
and need a lot of other tools, such as:

sdk
sdk-build-tools: aapt, aidl, dexdump, dx, llvm-rs-cc
ndk
api docs
IDE plugins?
system images?

I did not find source packages for it at AUR. So if we want to add it
[community] we need to create such packages but it might be quite
hard.

Are there people with Android development background? What exactly do
you miss in Arch? Is it worth building our own SDK/eclipse
plugins/...?


[1] http://source.android.com/source/building-running.html


Re: [arch-general] Android support in Linux Arch

2014-04-16 Thread Karol Babioch
Hi,

Am 17.04.2014 00:38, schrieb Anatol Pomozov:
 Are there people with Android development background? What exactly do
 you miss in Arch? 

The problem I face with the Android situation in Arch is that currently
there seems to be no clean (TM) way to install the SDK and related
stuff. The android-sdk package from AUR is fine and dandy, but one
usually also needs to install a whole bunch of API specific packages
through the android tool from the SDK.

- This doesn't work for normal users, e.g. you can update the packages
using Eclipse, but you need to start /opt/android-sdk/tools/android as
root

- Installing any sort of package through the installer mentioned above
isn't compatible with the whole idea of package management, because the
package manager isn't aware of these files. I ran into conflicts before,
which I had to resolve by temporarily removing some components.

Maybe I'm doing something wrong here, but at least this is what I've
experienced throughout the last couple of months. Unfortunately I don't
see a good way how this can be improved, as I like the idea of
installing only API components that I really need and get instant (!)
updates for them directly from the upstream project.

Anyone familiar with the situation on other distributions? How do they
handle all of this?

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature