yashsingh1/xdaforums huggingface dataset:
[Desire Android Development] theGanymedes:
Thanks for the ideas very much.

X system on VNC, as you put, just sucks :) It's slow as hell and having a Linux setup (seperately) is unnecessary I think - we have a working Linux (android) as of now, so why not use it instead of having a separate copy, right? This was precisely my motive. It's why I didn't even try to compile Xfce or any other window manager - it's mostly useless if you're to run just a couple of applications and then quit... I'm not trying to run Linux under Android - I'm just trying to merge them. Under Xorg, there are virtual keyboard software and such which can be used, I'm relying on them for now :) Didn't actually try to test usability much :)

Emacs - well didn't compile it yet but I can do if you want. A friend of mine told me Vim is enough so I didn't even attempt. I'll take care of it ;)

Git - that's a great idea. I've already compiled Curl (kinda hard it was :) ) and I think Git is not much different. I'll get my hand on it once I've done my assignments - I'm still studying at university :)

I mentioned dual boot, because that'd made testing - porting from linux to android faster; but then I thought it'd be unnecessary. I do have an image backed-up which allows me to boot Debian NATIVELY (not on VNC or such) right now and I can use it. My idea was just to be able to boot it with a flick of finger but; as I said, that's no big deal (actually, I pended that because it turned out I should write a bootloader myself - don't have time for it yet :) )

I even do have GCC for Android right now.. If everything fails, I can use it to compile the stuff you ask for! :D

Live Image- do you really think that's necessary? I mean, I already published the instructions and it really doesn't take more then 10 minutes to follow them. So, making a LiveCD for something like this would be a little bit "too much" don't you think? Well, maybe sometime I can try that instructions on a small Linux Distro (like pen-drive linuces available on the net) and then distribute image of that but distributing a LiveCD of a toolchain is not on my schedule right now.
[Desire Android Development] torwag:
Yep VNC is not really nice. However, the entire GUI stuff does not work well on a phone in general. Unlike there would be a window manager wich is able to improve the usability on smartphones, I do not see the point to get a program running where 30% of my screen is consumed for eye-candy of the Window-manager.

I mentioned the chroot method because it is obviously faster rather then rebooting your system.

Well on tablets we are talking about a complete different thing. Getting your libc and stuff running under e.g. the ASUS Transformer would enable people to switch between a Netbook mode and an Android mode.

I don't see the point of an entire reboot so. As I understood you want avoid a parallel installation of an other OS. Thus, the question is, is it possible to boot android in some kind of text-shell and instead of starting the Android-GUI you would start X and a Window manager. However, this would be something like killing one window system and start another one. I doubt this is easy possible since Android does much more in the background rather then GUI stuff.

However, if you come to the point of really require rebooting then you have to ask yourself why would I like to do all this if I could run and completely fine working e.g. Ubuntu... If there could be a program capable to get remote X sessions running under Android well this might be really usefull. Since one would not to have to switch anything.

Please :)

Well as I said git could be a killer-app and promise real sync without the need of any cloud-service. Furthermore, I guess if you announce, e.g. git is running under android, android-dev people will very quickly add this as a feature to there apps or write a GUI to operate git easily from mobile phones.

Well I would be glad to see a copy of this ;)

Well, live image might be a to big word indeed. I was thinking of a way to provide an environment to enable people porting software to Android. Guess it is kind of important to make sure all use he same settings, the same paths, the same libs, etc.

By the way, what would happen if one tries to install a ARM-based package from Debian or Ubuntu. Basically, they are compiled for ARM already but I guess they do not get the entire pathsystem right. Might be more interesting providing the glue to make e.g., the entire Ubuntu repros running under Android (at least in theory) and rely on the package build system from them rather then trying porting any single package by hand.

E.g. you said you had problems to get curl running. What would be required if you start with the curl package for armel in the ubuntu repros?
[Desire Android Development] cdesai:
Dual booting is a lot easier than you think, i tried it once on my tab(2 roms, one default partitons, and the other was an img on sd- loop)

Just check for something - a file/ keypress(dmesg), anything you can think of

So if you wanna boot into OS 2, you just reboot and while booting, press a key so it mounts the img of the 2nd OS , and then maybe backup the current data each switch, and restore by detecting OS, or sth like that

You dont need to write a new bootloader, its too much lol
[Desire Android Development] Droidzone:
Do you still have the scripts of this setup? I'd like to have a look at it some time
[Desire Android Development] theGanymedes:
Well, yeah, this approach is quite simple but I was planning to make even Kernel booted different on the second boot system - it's why I needed a bootloader - hoewever, later I've found out that a little tweaked Android kernel can run a native Linux distro as well; so that've gone go basket :)

Well, about Git: That'd be really good, I'll definitely work on it; but I do need a GUI-Helpers for tools like these but I don't know Android programming (just yet ;). Otherwise, I know that, running everything from terminal is not of every user's job; we need to make it more "available to use" if you know what I mean... Going to compile it tho ;)

About GCC: It takes ~ 160 MB.. I'm not that patient to set it for recovery upload it with this crappy connection I've at home :) Maybe later...

About making Android run on Linux: well, Android's init is completely different and requires it to run under kernel all the time to do some Android stuff - maybe we can port it but that might need a lot of job. I'll eventually try it, but not before I can master other stuff first ;)

About Debian packages: Yeah, the placement of stuff is way different in Debian but I don't know if we can convert those placements to Android "on-the-air" - that might require a lot of editing of source code, conditionals and stuff.. Also, those applications are compiled with armv4t toolchain - which is quite compatible but lacks the tweaks Arm v7 chips has.. Our code is faster then theirs :P After all, if I can make Apt-get run flawlessly (couldn't test it thoroughly) all I've to do is edit the Debian package scripts and will be good to go...

About X on Android: I've also thought of stubbing Xorg functionality for Android but, well, don't you think it's a massive job? Can't get my hands on these stuff yet I think...
[Desire Android Development] rikmer:
Sorry for not answering for such a long time.

I checked the data partition size and it should be large enough.

I don't know, perhaps I am to stupid, but I cannot figure out how to modifiy the rom before installation in order to get glibC working properly from your descriptions in the first posts. Or is this again a stupid thing ... but I recon it should be possible to unpack and pack the boot.img with the correct parameters before installing the rom.

I don't know if it is too much to ask but it would be awesome if you could provide a kind of instruction to do it beforehand. I will then try to implement it into Oxygen and perhaps be able to modify your flash zip accordingly to also provide AOSP users the possibility to easily install your project.

As I said before ... I love this project.

EDIT: I just read your flash zip some more and saw that "flash_image" is needed at the end. It is not in my /system/bin. As I can see this it not provided with your zip. I will install the binary and try your script again.

EDIT2: Didn't change anything.
[Desire Android Development] theGanymedes:
Weird thing is, i'd understand if your device would simply hang during the boot; that'd be more understandable; but a boot-loop - that I cannot understand..

Well, during installation; I'm making a check whether u're using Data2sd or Data2ext or a2sd and try to make some linkages at that level. May you please try to send me the recovery.log file after the flash at recovery?

Flash_image is used to flash boot image - it's necessary to make /lib point to /data/lib - that cannot be a reason for bootloop I think...

PS: you can search for recovery.log at recovery level with adb shell find / -name "recovery.log" command; then use adb pull to pull it to your PC.

PS2: I'll add flash_image to package from now on.
[Desire Android Development] theGanymedes:
Sorry guys, couldn't do much lately - my pc crashed; I was trying to recover :)
[Desire Android Development] theGanymedes:
Back online!

BTW: After I noticed my pc uses eGlibC; I've started to have thoughts about it as well? Do you think I should stick with GlibC, or move to eGlibC? eGlibC tries to (but not necessarily) be as compatible as it can with GlibC; and allegedly has better support for ARM... What do you think?
[Desire Android Development] torwag:
As long as it can compile whatever we want to run on the device... why not.

If you say it runs on your computer, which distro do you?

Any news from Emacs and Git?

---------- Post added at 05:58 PM ---------- Previous post was at 05:51 PM ----------

There is uClibc as well... just to threw in another... aahhhh open-source software world, the freedom and pain of choice.
[Desire Android Development] theGanymedes:
Debian and Ubuntu is already running eGlibC because apparently Ulrich Drepper (manitainer of GlibC) is very strict and doesn't allow patches to be mainstream - which is sometimes needed to compile GlibC on ARM devices.

I tried compiling it, but locales were not compiling well - and since we successfully compiled GlibC, I thought making a change now is unnecessary.

Emacs and git is on suspend now; but I compiled PERL (it was needed for apt-get and dpkg to work completely). I think I'm going to start compiling git and other user-space binaries after I'm done with apt and prepared a repo for it (this way it'd be much more easier for users to download and install everything ;)

Sorry for the delay guys, but don't worry; I didn't forget the project ;)
[Desire Android Development] Droidzone:
Ha...I thought I was the only person with issues compiling glibc for Ubuntu.. :)
[Desire Android Development] theGanymedes:
APT-repo

Guys, do any of you know of a host where I can setup my own APT repo? I cannot use my computer for it - it has a crappy connection and isn't 24/7 online.

Even though not necessary, it'd be great if I can run some exeecutable tools on the serverside as well - like reprepro or some bash scripts - but as I said, not necessarily...
[Desire Android Development] danarama:
Github?
[Desire Android Development] theGanymedes:
Hmm, didn't try it.. Let me see ;)
[Desire Android Development] theGanymedes:
Guys: Unstripped Emacs is 100 MB.. You sure you're not OK with Vi? :)

Good thing is that, you can install it to your SDcard; it's not a native application after all.
[Desire Android Development] theGanymedes:
Well, I gained speed : Git is done; GPG (Gnu Privacy Guard) is done; Gcrypt (GNU Crypto Library) is done; Libassuna and LibKSBA is done; Apt is nearly fully functional; PTH (Portable Thread Library) is done..

Now I should really focus on how to make repo..

BTW: Git didn't work for repo; I had to find a free hosting corp. Thanks to byethost.com; they gave me 5.5 Gig's space and 200GB traffic - which is enough, don't you think :)
[Desire Android Development] cdesai:
That's cool

Give x10hosting a try!
[Desire Android Development] theGanymedes:
Please read post #2 - I added something I've forgotten to say before :)
[Desire Android Development] rikmer:
Hey again,

again apologies for the late response.

See attached the recovery.log after I flashed the zip. I had a short look at it and recognised that some commands were not found, for example cpio. Interesting thing is that beforehand when I checked if it is available in terminal it was. At least after granting the terminal super user rights.

I will have a look at the standard rights of the commands in /system/bin.

so long ...

EDIT: I checked cpio via terminal and without su again and it is included in busybox v1.19.2-cm71 bionic . I wonder why it is not accessible via recovery console. I am no expert but aren't there different ways to install busybox. Perhaps the method differs from the SENSE custom rom method.

EDIT2: I checked with a root file explorer and all commands (cpio, awk, ...) are stored in /system/xbin and have executable rights. Again I don't know why they are not accessible while in recovery mode. Perhaps the mounting points differ in AOSP?
[Desire Android Development] theGanymedes:
During recovery, /system isn't mounted; and PATH is just showing a /sbin directory of recovery - try running cpio when you're at recovery; using adb shell. If it can find it, then problem is elsewhere...

IF it couldn't, I'll suggest you to use 4EXT recovery (Which I use, and test everything at) or clockwork recovery (not sure, but should work as well.). The links are found in the forum.

I'll see the log to determine problem; keep up ;)...

EDIT: Saw the problem: your DATA2SD solution isn't recognized - the system recognized it's not an APP2SD; but it's not carrying the bits of neither Ownhere's Data2Ext not sibere's Data2SD. If you're really not using any of these, please inform me where your MTD partition is mounted; how I can differentiate the solution from others (if you can see a "special" file somewhere). If you have no idea what I'm talking about; send me the init script for data2sd solution.

EDIT2: Major problem is, since your system cannot find Cpio; I cannot create a new boot image with the new ramdisk, ergo corrupting your boot. It's why it cannot get to there.

One optimal solution would be to ship the package with a special "busybox" which includes everything I need and then runs it. Bad news is, for your case, this is not ultimate solution as well - even though your phone boots, your library won't work if I cannot determine your data2sd solution.
[Desire Android Development] rikmer:
Hmmm that's interesting. As far as I know I am using Sibere's Data2SD. I followed the instructions here ( http://xdaforums.com/showthread.php?t=852219 ) and flashed the zip provided in the link and data2sd was working properly. I attach the used 01data from init.d .

When I am in recovery mode I cannot find cpio but awk which is inside busybox (BusyBox v1.15.3 (2010-02-06 17:13:19 CET) multi-call binary ). I probably could install cpio at recovery level, if I am right. Is cpio included in clockwork recovery? What is it what I see when in recovery mode using adb shell? The hboot structure or what? Sorry but I didn't do anything at this low level up to now.

Thank you for all the help.
[Desire Android Development] theGanymedes:
Recovery issue

Well, sorry to say that but no: you cannot install anything to the recovery - it's a special area (MTD2 actually) in your MTD disk which is read when you boot to recovery. Unless you unpack, add what you want to, and then repack&flash to your phone; you cannot install something there - believe me, no need to do that :)

Well, I found the problem: it's kinda my fault. Sibere's flasher zip makes data2sd.prop file at sd-ext partition while droidzone's flasher (which is actually very similar) makes this file at MTD data partition. Since you're using sibere's one, and since I didn't know this difference before, your data2sd solution is unidentified. I'll fix it right away.

BTW: Don't install GlibC 0.6 - it's still missing necessary binaries for you. With version 0.7, I'll add a busybox which has every command I use to the zip file and then you shall be able to use it too. Sorry for the inconvenience; I'll fix it soon.

EDIT: Whoa, this buggy thing affected all the packages I made... Now I've to re-upload everything :S

EDIT2: Re-uploaded eveything, including a new version of GlibC.. I didn't test it yet, tho, may you please? ;)
[Desire Android Development] theGanymedes:
Packages..

I compiled so many packages and can't test them all.. Would you mind if I upload them without testing ? I use an automation script to make installation recovery packages; thus see no reason for them not to work - for since the old ones were working well - but still they might require something extra..

What do you think about this: let me upload them and if you feel like you can test it, install and test them. If you find an error, inform me so I can fix it - or if you can't find an error, inform me so I can mark it "ready to use"...

What do you say?

EDIT: I assigned Post #8 for this aim :)
[Desire Android Development] rikmer:
Thank you for all your work but I have to tell you that it won't work even with the new version 0.7. I did a fresh ROM install after wiping everything. Installed the data2sd version again and flashed your zip. I again had a short look at the recovery.log and it seems that now it can find all commands. Nevertheless the system loops before possible adb access after restarting after the flashing procedure. See the new recovery.log attached.

Can I provide you with any other information, in order to get this work?
[Desire Android Development] theGanymedes:
Weird.. May you please try flashing after you booted your phone once?

Also, the recovery.log you sent contains nothing :S

EDIT: I'll install your ROM and recovery today to test. Tomorrow I'll be clear about it .
[Desire Android Development] rikmer:
Sorry. Somehow confused the recovery Logs.

I did the whole procedure again, rebooting between the steps (Flash ROM / Remove app2sd script from init.d / reboot / flash data2sd script / reboot / flash glibc 0.7 script / reboot / loop). Regretfully no difference.

See attached the right log now.

I really appreciate your motivation towards my problem. Thank you very much.
[Desire Android Development] theGanymedes:
Hmm. It gave segmentation fault somewhere - shows that it couldn't read or parse your boot.img - the busybox I compiled might be the problem. I think I'll be able to solve this problem when I install that AOSP ROM to my device..

That's alright, man, after all this is my project and you're collaborating in it by installing it to your device; and giving me output. This is exactly what I want to see: that I'm doing something of interest :)

I'll let you know about the results; see you around.

EDIT : I SAW THE PROBLEM SOURCE: Problem is caused by the recovery - the recovery is shipped with a very old Linux kernel (recovery images do have their own kernel) and because of this, my ramdisk editing commands don't work. And since I cannot edit the ramdisk properly; I'm corrupting yours - writing an empty ramdisk - and this is why bootloops occur.

Change into another recovery - like 4EXT or clockwork - and try again. As I said, 4ext is the one I use and it's pretty cool also.
[Desire Android Development] rikmer:
It worked!!! YES! Thank you very much again. Already started playing around with it.
[Desire Android Development] rikmer:
I habe a problem, terminal emulator FCs all the time.
[Desire Android Development] theGanymedes:
Are you using the one at the Market, or the one in the Android itself? I'm using the one at the Market and it's fine.

Check the output of the LogCat whilst you run the Terminal emulator. It'll give you guidance.
[Desire Android Development] theGanymedes:
Well, guys, tried using Emacs a little: wow, it's even more complicated than vi! It's nearly ready, but I tell you: I have no idea how you're going to use it :)

Gonna upload all of them soon.

BTW: I have bad news: In order to make applications co-exist in MTD and SD-ext partitions together, I had to devise an alternative way which required so many changes in code. So, I have to ask of you to uninstall all previously installed packages - or reinstall them - soon again. Sorry for that, but I think I had managed to find a good solution now.

See you soon.
[Desire Android Development] Droidzone:
I love Emacs, esp all its shortcuts. Reminds me of good ol' wordstar :)

You go ahead and change whatever you like however you want to. People who try this out are advanced users anyway and shouldnt have any problems fixing it ;)
[Desire Android Development] theGanymedes:
PRIOR NOTICE:

Ladies and gentleman.

Tonight, I'm going to make a massive upload: all the packages are updated, and new packages (including apt!) is to be added.

But before this, I'll remove all the links. For since this shift can't be done smoothly, I'll have to act in a sudden manner - sorry for that. The links will be updated by tomorrow evening...

What has changed?

Well, as you realized with GlibC 0.3; I was trying to make applications installed on both MTD and Sd-card cooperatively - the motive behind this was simple: we had empty space in MTD partition, and I wanted to make use of it. Also, some libraries needed to be ready to use on boot time too, so it was necessary.

Up until now, my solution was working well. It was simple, I was just linking the directory to the correct place, and we're good to go. However, as I compiled new applications, I started to see this was not enough anymore, because applications that are installed to MTD partition in this manner causes problems about the applications that will be installed to SD-ext.

The new solution is quite simple as well, but not as neat: When an application is installed to MTD, and Data2SD is being used for instance, a snapshot of MTD application is done to sd-ext data with symbolic links. So, for every application installed to MTD data, you have a signature at sd-ext partition. The script does a simple test if this is necessary first, of course.

For since these two solutions don't comply well with each other - due to cp command's restrictions - you need to uninstall and reinstall old packages.

To be honest, I think Apt will solve all this burden soon. I already started to run tests about this. Soon, I'll set everything up and ready.

Keep up guys...