Two Tutorials ...

[mcobit]

Although I never had these opkg problems, you could try to copy all the files from /etc/opkg (without rootextend mounted!) to a directory on your sd and the mount the rootextend and replace the files with the ones you copied over.

If that doesn't help, maybe your opkg files are corrupted anyways. Try to extract them from an image and replace your old ones.

Good luck.

 

[Esn]

Although I never had these opkg problems, you could try to copy all the files from /etc/opkg (without rootextend mounted!) to a directory on your sd and the mount the rootextend and replace the files with the ones you copied over.

If that doesn't help, maybe your opkg files are corrupted anyways. Try to extract them from an image and replace your old ones.

Good luck.

Could you be a bit more specific about where everything is located, please? I'm not quite sure about what directory it's putting everything in when the extends are mounted...

Also: does it matter which directory I'm in when I do "sudo opkg update"?

Also, another question: is it possible to port games that are written in Fenix?

 

[mcobit]

Hi, I think you should get the files from an extracted firmwareimage
http://www.openpandora.org/downloads/Pandora-Flashkit-2010-08-Zaxxon.zip

take all files from /etc/opkg and replace the files on your firmware on the device in /etc/opkg with them.

then try to run the update again.

it doesn't matter which directory you are in, when performing opk update.

As for Fenix, I am not sure. As this is an in terpreted language and I can't find it in the angstrom repositorys, you might have to compile it prior to running your game.

 

[torpor]

Arrgh, this opkg stuff is a hassle, guys .. so I just wanna interject this here:

A rule for on-Pandora opkg maintenance: *Always* do "opkg update" before you install new packages, including and especially if you will be installing *-dev packages, and *never* do "opkg upgrade" unless you really, really know what its going to upgrade.

The reason for "opkg update" is that the angstrom repo's will update their build versions occasionally - and when they do so, library-dependencies based on those versions is *also* going to change. So its quite possible to go out of sync, nearly completely, and lose dependency-tracking. So, please do updates when you are putting new -dev pkgs onboard, because you need to.

Do *not* do opkg upgrade, because it will almost always bork your system. Instead, upgrade each package individually, by hand, as you know you need them (for development) - yes, you cannot just do auto-upgrade, if you decide to use opkg. This is clear by now, but I mention it for future reference in relation to the difference between important 'opkg update' and very dangerous 'opkg upgrade'. You *may* upgrade packages (related to -dev packages, for example) by hand, if you really need to get the libs and includes and so on for a new package onboard (happens often).

 

[CPUnltd]

Why not have a Pandora-only repository that supercedes the Angstrom one? It could be set up to diff and auto-build on it's own and report errors to a part time maintainer so upgrades would be possible and simple. Only covering the Pandora specific packages.

 

[mcobit]

Arrgh, this opkg stuff is a hassle, guys .. so I just wanna interject this here:

A rule for on-Pandora opkg maintenance: *Always* do "opkg update" before you install new packages, including and especially if you will be installing *-dev packages, and *never* do "opkg upgrade" unless you really, really know what its going to upgrade.

The reason for "opkg update" is that the angstrom repo's will update their build versions occasionally - and when they do so, library-dependencies based on those versions is *also* going to change. So its quite possible to go out of sync, nearly completely, and lose dependency-tracking. So, please do updates when you are putting new -dev pkgs onboard, because you need to.

Do *not* do opkg upgrade, because it will almost always bork your system. Instead, upgrade each package individually, by hand, as you know you need them (for development) - yes, you cannot just do auto-upgrade, if you decide to use opkg. This is clear by now, but I mention it for future reference in relation to the difference between important 'opkg update' and very dangerous 'opkg upgrade'. You *may* upgrade packages (related to -dev packages, for example) by hand, if you really need to get the libs and includes and so on for a new package onboard (happens often).

Hey topor, he has problems with opkg update. Not upgrade! Did you read one single post in this topic?

 

[Esn]

Hmm, looks like someone else also has a problem with opkg update, and it was due to a wifi connection:
http://www.gp32x.de/board/index.php?/topic/58541-solved-opkg-wont-update/

I don't have access to too many wifi connections... oh well, I guess I'll wait for the next hotfix and see if matters are improved.

 

[Esn]

I tried this with Homebank and followed the instructions up until "./autogen.sh", at which point I got this:

The autogen.sh script is used to generate the "configure" one. If autogen.sh isnt there but the configure one is there, just go to next step

What if the configure one isn't there either? (looking at the tarball of iabc from sourceforge)

Also, just for future reference, how do I know which software uses SDL? Is there a nice list somewhere of software for which the method in these tutorials should work?

 

[mcobit]

Hi esn,
A google search would have spit out a long list of software using sdl.
Also http://www.happypenguin.org/ has information for each game, if it uses sdl or other frameworks.

Also, there are just a few games, that you can compile with exactly these instructions. Most of them need a bit of editing and compiling additional libraries.

Let me know, if you have anything specific in mind and we could walk through that.

 

[Esn]

Ok, I've sent a PM... thank you for the offer.

I did do a Google search, but I found only one list of SDL apps (specifically, this one); most lists are of games.

I did succeed in compiling the SDL Synaesthesia program with your instructions, by the way, but I don't know how to test it; it's command-line and mainly works with CDs, and I don't have a CD drive. Oh well, maybe another time.

 

[quartercast]

Wow, what an excellent set of tutorials. I don't remember seeing this earlier, will follow your tutorial later since I'm interested in these extends partitions.

Sticky somewhere? Dev section?

 

[Esn]

Hi. I seem to have broken something because any time I try any sudo commands with these extends mounted now, I get:

Sorry, try again.
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts

The first time I type one in, I get that. So I guess I should redownload a fresh copy of the extends, if noone has any other ideas.

 

[Esn]

What does it mean if I do ./configure and it tells me
"./configure: line 1: pkg-config: command not found"? There seems to be a "configure" file in the directory (abcmusiex).

Also, with another program, I got this error: EDIT: Nevermind. Apparently need to sudo opkg install pkgconfig.

configure: error: The pkg-config script could not be found or is too old.  Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

Alternatively, you may set the environment variables PYGTK_CFLAGS
and PYGTK_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

To get pkg-config, see <http://pkg-config.freedesktop.org/>.

 

[Stuckie]

Right *rolls up sleeves*

All the old Extend Utils stuff has now been deprecated, and I've removed it from my server.
The current stuff still lives, but in a different place ( no longer in the misleadingly named "SimpleDev" folder. )

The old ( old old really old ) dev.extend stuff linked on the first post is over a year old now! The problems people have been having is due to libraries in the extend overriding the ones on the NAND. This is generally what you want, but the NAND is newer than the extend, so lots of badness occurs. Therefore, they're all gone.
However, so that people can still have a quick start easily enough, I've spent the day wrapping up a Debian-based dev extend, which you can grab over here: http://www.gp32x.de/board/index.php?/topic/59740-extend-utils/
I've also wrapped the mount script in a PND, so you can get going with as little fiddling as possible.

Additionally, keep all Extend Utils problems and queries to that thread so I can track them.. else, I generally won't know about them!

Hope this helps

 

[Esn]

Just thought I'd also mention here, that there's a wiki tutorial for using Stuckie's new Debian extend + a home extend:
http://pandorawiki.org/Extend_Utils#Debian

So you can mount those instead of the old ones in the first part of this tutorial. Everything else seems to be the same except that you'll use "apt-get" instead of "opkg" in your terminal commands. And you'll need to manually create the /mnt/utmp folder because it doesn't exist by default in the Lenny Debian extend.

Anyway, once I figure everything out I'm going to try to update this tutorial.

EDIT: One question:

#!/bin/sh
# We don’t want to let the program write its configuration, savestates etc. to the NAND.
#So we need to export our HOME environment variable first.
export HOME=/mnt/utmp/abe

# There may be libs, that the program needs and that are not on the NAND by default.
#So we need to export the LD_LIBRARY_PATH environment variable to point to the libs we will package into our pnd.
export LD_LIBRARY_PATH=LD_LIBRARY_PATH:/mnt/utmp/abe/lib
#Now we need to launch our program.
./bin/abe
#You can attach any commandlinearguments to the above line, if a program needs them.

What if the program has not just library-dependencies, but also program-dependencies? What path would you put them in? For example, EasyABC uses the abcm2ps program, and its readme says it should be "on the executable path".

 

[mcobit]

What if the program has not just library-dependencies, but also program-dependencies? What path would you put them in? For example, EasyABC uses the abcm2ps program, and its readme says it should be "on the executable path".

If you have to compile a program, that the other program is using, you should prefix it with /mnt/utmp/yourprogram and install it. The executables will end up in /mnt/utmp/yourprogram/bin .
You can add this binfolder to the PATH variable to make them executable, while the mainprogram is running.

export PATH="$PATH:$PWD/bin"

Hope that helps.