Arch Linux On The Pandora


on a side note, you may wanna have a chat with GizmoTheGreen who has also been putting in a bit of effort to get Arch running on the Pandora...

http://www.gp32x.de/board/index.php?showtopic=54534&view=getnewpost
 
Last edited by a moderator:
Custom Processing Unlimite said:
hmm... sounds interesting... would the pnd's require alteration (to point to the proper libraries) or are you working to find something more transparent?
I think it would only be useful when the PNDs do not need any kind of modification. This should be possible, either by placing those compatibility libs to the global library search path (might not be such a good idea), or by setting a PND specific library search path through libpnd when running a PND.

Custom Processing Unlimite said:
on a side note, you may wanna have a chat with GizmoTheGreen who has also been putting in a bit of effort to get Arch running on the Pandora...

http://www.gp32x.de/board/index.php?showtopic=54534&view=getnewpost
I didn't know someone else has been trying to run Arch on the Pandora before. Thanks for the link. :)
 
Last edited by a moderator:
glad to pass the info on, wejp... no reason that both of you couldn't combine your efforts to further the project... also no reason why both of you should be working separately on the same thing (unless you have tried and failed due to unresolvable differences :p).

I'm wondering if symlinks would be doable within a companion library PND... ex: you put an SD card with Firefox PND into the pandora running Arch, alongside the Firefox PND is a companion library PND that, when executed (and root password given via gksu or power user password via gksudo) the companion PND would symlink libraries from within the PND to the global locations that Firefox's PND would recognize and require to fully run. It's a starter idea that could possibly get merged into standard PNDs for non-Pandora OS compatibility. Just my 2 cents, hope it makes enough change. :)
 
Like many distributions, Arch has packages for multiple versions of libraries. For the most part, these are in the unofficial user repository. For example, I have old versions of libjpeg and libpng installed alongside the current ones. If the Pandora uses old versions of libraries, then the pandora-libraries package should explicitly depend on the old versions.
 
Tempel said:
Like many distributions, Arch has packages for multiple versions of libraries. For the most part, these are in the unofficial user repository. For example, I have old versions of libjpeg and libpng installed alongside the current ones. If the Pandora uses old versions of libraries, then the pandora-libraries package should explicitly depend on the old versions.
I would like to avoid this for a few reasons:

1) Although there might be some older versions of some packages available, there are most likely at least some still missing.
2) I would like to avoid to pollute the normal system with old libraries. People should not be encouraged to link new applications against those old libraries.
3) pandora-libraries itself does not depend on those packages, so creating dependencies which are not really there, does not make much sense to me. libpnd runs perfectly fine without all those libraries.

One possible solution to that problem, which also does not cause to much work, would be to create one compatibility package that contains the libraries from the Pandora OS. This package would install those libraries to a directory that is not part of the global library search path. The pandora-libraries package would then be modified that it would be aware of that directory (should be easily possible with the environment variable LD_LIBRARY_PATH), so only libpnd would use that directory for searching for libraries in there.
 
Last edited by a moderator:
wejp said:
3) pandora-libraries itself does not depend on those packages, so creating dependencies which are not really there, does not make much sense to me. libpnd runs perfectly fine without all those libraries.
Sorry, I misunderstood what you were doing here. I had envisioned two packages; let's call them libpnd and pandora-compat. The first, libpnd, would contain just libpnd. The second, pandora-compat, wouldn't actually contain anything, and would simply depend on all the libraries that appear in the official Pandora firmware (including libpnd); end users could install this package to quickly get all libraries that apps expect to see on a Pandora. I thought you had combined both of these into one package, pandora-libraries, but instead I see that you're using pandora-libraries just to hold libpnd. I would recommend actually calling it libpnd (that's what it is, after all), but the name hardly matters. However, I would still recommend making pandora-compat; again, it doesn't have to hold anything, it just has to depend on things.

wejp said:
1) Although there might be some older versions of some packages available, there are most likely at least some still missing.
Yes, but that shouldn't stop us from including what's already there. Consider a user trying to run a PND in Arch; they can search for and install packages to try to make it run, but eventually they find that one package doesn't exist. If they had installed pandora-compat, they would already know it doesn't exist. That PND won't run either way, but having the pandora-compat package saved a lot of time trying to find that out. Also, PKGBUILDS for old versions can be made gradually, even if they're not all available now.

wejp said:
2) I would like to avoid to pollute the normal system with old libraries. People should not be encouraged to link new applications against those old libraries.
Two things here: First, I really don't understand the problem with "polluting" the system with old libraries. The two libraries sit next to each other with different filenames and different package names. If a program asks for the new library, it'll get it; if it asks for the old library, it'll get it; if it doesn't specify which version it wants, it'll get the new one. Of all the old library packages I've seen, this is how they always work; there are no conflicts, because programs always get what they want. What makes it a bad thing?

Second, Arch Pandora users are not going to be influencing developers' choice of libraries. The only reason to put old libraries into Arch is because those old libraries are already available in the official firmware. Developers will link to those old libraries because that's what the majority of users have. If you want to encourage developers to use newer libraries, making them unavailable in Arch won't help; you'll have to convince the firmware devs to update those libraries in the official firmware. If you convince them to do that, then it's a simple matter to update pandora-compat to depend on the newer library instead of the older one.

To conclude, I really think this is the easiest way: it allows us to take advantage of existing packages rather than trying to get all of these libraries into one package. I really wish I had a Pandora now so I could make it happen, but until then I'll just have to argue :p

(Sorry, I hope I'm not being a jerk. I still appreciate your work!)
 
Last edited by a moderator:
Tempel said:
wejp said:
3) pandora-libraries itself does not depend on those packages, so creating dependencies which are not really there, does not make much sense to me. libpnd runs perfectly fine without all those libraries.
Sorry, I misunderstood what you were doing here. I had envisioned two packages; let's call them libpnd and pandora-compat. The first, libpnd, would contain just libpnd. The second, pandora-compat, wouldn't actually contain anything, and would simply depend on all the libraries that appear in the official Pandora firmware (including libpnd); end users could install this package to quickly get all libraries that apps expect to see on a Pandora. I thought you had combined both of these into one package, pandora-libraries, but instead I see that you're using pandora-libraries just to hold libpnd. I would recommend actually calling it libpnd (that's what it is, after all), but the name hardly matters.
I named it "pandora-libraries" because that's what it is officially called, not libpnd (which is part of the pandora-libraries).

However, I would still recommend making pandora-compat; again, it doesn't have to hold anything, it just has to depend on things.
I understand what you mean and it makes somewhat more sense now, but I still don't really see the point of doing that. One can expect that all native Arch applications use the more recent libraries, so the older ones really are only useful for compatibility with PNDs. When that's the case, I would simply package those libraries as I said. If you are willing to build and create packages for every single missing one (there are a lot of libraries and for most of them there are no packages available), go ahead. I don't think it is worth the effort, though.

wejp said:
1) Although there might be some older versions of some packages available, there are most likely at least some still missing.
Yes, but that shouldn't stop us from including what's already there. Consider a user trying to run a PND in Arch; they can search for and install packages to try to make it run, but eventually they find that one package doesn't exist. If they had installed pandora-compat, they would already know it doesn't exist. That PND won't run either way, but having the pandora-compat package saved a lot of time trying to find that out. Also, PKGBUILDS for old versions can be made gradually, even if they're not all available now.
Having all the required libs would save them even more time and it would actually run. In most cases I would build one package for each library, but in this case, I don't see any advantage of this. Either you want to install that compatibility stuff or you don't. It is highly unlikely that you want to install only a few of those libraries.


wejp said:
2) I would like to avoid to pollute the normal system with old libraries. People should not be encouraged to link new applications against those old libraries.
Two things here: First, I really don't understand the problem with "polluting" the system with old libraries. The two libraries sit next to each other with different filenames and different package names. If a program asks for the new library, it'll get it; if it asks for the old library, it'll get it; if it doesn't specify which version it wants, it'll get the new one. Of all the old library packages I've seen, this is how they always work; there are no conflicts, because programs always get what they want. What makes it a bad thing?
I know all that, but that's not what I meant. The only use of those packages is to run applications that have not been built for that system, but for another one (the Pandora OS). All those libraries are not needed for normal system operation, but only for running those PNDs.
Maybe I am missing a point here, but why would you want to create dozens of packages, just to achieve something you could achieve much quicker by reusing the existing libraries?

Second, Arch Pandora users are not going to be influencing developers' choice of libraries. The only reason to put old libraries into Arch is because those old libraries are already available in the official firmware. Developers will link to those old libraries because that's what the majority of users have. If you want to encourage developers to use newer libraries, making them unavailable in Arch won't help; you'll have to convince the firmware devs to update those libraries in the official firmware.
That's not the point. I don't care much about what programs/games packaged as PNDs link against. They will always link against the libraries available in the defualt OS and that's fine. But when those old packages are available in Arch by default, people might start linking against those libs.

If you convince them to do that, then it's a simple matter to update pandora-compat to depend on the newer library instead of the older one.
To conclude, I really think this is the easiest way: it allows us to take advantage of existing packages rather than trying to get all of these libraries into one package. I really wish I had a Pandora now so I could make it happen, but until then I'll just have to argue :p
Updating pandora-compat in your scenario is always way more time consuming than with simply reusing the official libs in one compatibility package. Again, what is the advantage of doing that?

(Sorry, I hope I'm not being a jerk. I still appreciate your work!)
That's ok, I simply do not see the advantage in your approach. PNDs will always use different versions of libraries to some extent. There is nothing to be done about that as long as Arch is not the official OS, which is why I would simply take those libraries as they are and bundle them in a single compatibility package instead of putting effort into rebuilding and packaging all those libraries. All that time could be put into something more useful.
 
Last edited by a moderator:
Ah, I think I better understand you now. You want to simply extract all the libraries directly from the official firmware and put them into a single package. I was assuming you wanted to compile all those old libraries and put them in a package, which would be a lot of work. So assuming my understanding is finally right, your way should be quick to implement, and very effective.

I still kinda feel like my approach would be better in the long run, since it could take advantage of existing packages (like libpng12 and python26) to build them natively, and any extra packages we would have to create would be contributed back to Arch as a whole. But making this happen can wait until I have the means to try it; your approach will certainily suffice for the time being, and may convince me otherwise.

wejp said:
I named it "pandora-libraries" because that's what it is officially called, not libpnd (which is part of the pandora-libraries).
:blink: I even have that repository cloned on my machine, yet never noticed the name. It only contains libpnd-related stuff (for now), but yeah, you win this one :p
 
Last edited by a moderator:
Tempel said:
Ah, I think I better understand you now. You want to simply extract all the libraries directly from the official firmware and put them into a single package. I was assuming you wanted to compile all those old libraries and put them in a package, which would be a lot of work. So assuming my understanding is finally right, your way should be quick to implement, and very effective.
Yep, that's what I meant. Sorry, if I wasn't clear enough.

wejp said:
I named it "pandora-libraries" because that's what it is officially called, not libpnd (which is part of the pandora-libraries).
:blink: I even have that repository cloned on my machine, yet never noticed the name. It only contains libpnd-related stuff (for now), but yeah, you win this one :p
I was a little confused about the name at first, too. I guess as that repository contains a few menu related things too, they did not name it libpnd as libpnd is only a part of it, even if it is the most important part.
 
Last edited by a moderator:
NOTE: this project should be added to the wiki... not sure who to contact about that...

http://pandorawiki.org/Software_projects

was it gruso?
 
It's a wiki. Just sign up and edit it yourself.

edit: and I mean that in an entirely serious and helpful way, not sarcastic. No need to wait on others, just dive right on in :)
 
no, it's cool... I get that a lot, but not every wiki is the same, so I usually don't just jump in... so I don't screw something up. :p
 
I tried it on a 1Gb, but you are not having fun with that! Installed a couple of things and the SD was full. Go at least for 4 imho
 
need to get my hands on a 32GB... will definitely do so next paycheck... I might just hold out a little longer and wait till I get enough to get my hands on a 64GB SDXC.... then have all the fun I want! :p
 
Can someone tell me how to extract the .tar.xz file please, Google isn't turning up much. I've tried it using the default package on Ubuntu and I get a bunch of 'cannot mknod' errors.

If I've got the .tar.xz file in the root directory of the SD card I intend to extract to, what's the command to extract in Terminal on the Pandora?

Cheers
 
The terminal command to extract is:
Code:
tar xJvf filename.tar.xz
Do this from within the SD card's directory to extract there.

I can think of two potential causes of the mknod issue. See, it's trying to extract block devices to the SD card, since these are an important part of any Linux root filesystem, but creating them is restricted. It could be restricted to the root user only; try running that command I gave earlier with "sudo" in front of it. It could also be restricted by the rules used when mounting your SD card; try remounting with the "dev" option enabled. The command should look something like this:
Code:
sudo mount -o remount,dev /media/mmcblk0p1
Make sure to replace "/media/mmcblk0p1" with the actual path to your SD card. Then, run the extraction command again, with sudo if you need to.

I hope that helps, but let us know if it doesn't.
 
Maybe the rootfs tarballs should be generated using tar's --one-file-system option, so that it isn't trashed with temporary files or device nodes causing trouble while extracting. All device nodes should be generated dynamically within a virtual file system and therefore don't need to be saved.
 
Tempel said:
The terminal command to extract is:
Code:
tar xJvf filename.tar.xz
Do this from within the SD card's directory to extract there.
Actually, you do not need to specify the compression mehtod at all with almost all tar versions currently in use. So all you need to do is "tar xfv archive", where archive can be uncompressed tar, .tar.gz, .tar.bz2 or .tar.xz .

I can think of two potential causes of the mknod issue. See, it's trying to extract block devices to the SD card, since these are an important part of any Linux root filesystem, but creating them is restricted. It could be restricted to the root user only; try running that command I gave earlier with "sudo" in front of it. It could also be restricted by the rules used when mounting your SD card; try remounting with the "dev" option enabled. The command should look something like this:
Code:
sudo mount -o remount,dev /media/mmcblk0p1
Make sure to replace "/media/mmcblk0p1" with the actual path to your SD card. Then, run the extraction command again, with sudo if you need to.
Mounting with the dev option should not be necessary, but should not do any harm either.

Letalis Sonus said:
Maybe the rootfs tarballs should be generated using tar's --one-file-system option, so that it isn't trashed with temporary files or device nodes causing trouble while extracting. All device nodes should be generated dynamically within a virtual file system and therefore don't need to be saved.
I'll keep that option in mind or the next version. This might save some bytes, but even then the archive should still be extracted with the root user. If anyone has trouble extracting the archive as it is now, you are doing something wrong - either you aren't extracting as root or the filesystem on the target device is incompatible, e.g. fat instead of ext2. As said in my blog, the filesystem should be ext2 and nothing else (yes, this includes ext3 as well - do not use it).
 
Last edited by a moderator:
Back
Top