.next development

Just wanted to stop by and say: GREAT! that this is being worked on. I look forward to its future progress, and shall duly report for my regular IRC bashing as necessary to continue to keep aTc motivated. ;P
As SuperZaxxon will see a final release today, I'll start concentrating on .next from now on as well.
The final version has a more recent version of the 3.2 kernel as well as some more fixes that have been reported (NAND trashing, WiFi a bitg unstable, etc.)

Other things we could not reproduce could not be fixed - and won't be fixed unless someone who HAS these issues can help debugging.
if it'll sort out the hard reset NAND issue, I'll be over the moon! :)
Other things we could not reproduce could not be fixed - and won't be fixed unless someone who HAS these issues can help debugging.

I was interested to provide some bug reports through the bugs.pandora website, but I am still waiting for my account to be activated (see other thread on this).

If there is another way to provide bug reports with detailed information, please let me know -
Well, there was the Beta Testing thread where you could have reported, both for the OS version and the bugs for the kernel.

I activated your account in the bugtracker now.
As I understand PND stuff does not work on .next, because it waits for user login. So could someone enlighten me (or us, if there are more people interested in this) how does (or should) pnd system work? Where should I start poking around, etc :)
skeezix could answer best, but it's mostly up to pndnotifyd. You could run it manually from command line with debug options. If it really waits for user to log on, then it's probably the /tmp/currentuser file, that's normally created by .xinitrc IIRC, and maybe HUP(?) signal too that .xinitrc sends to pndnotifyd.

Currently I'm downloading image "Angstrom-openpandora-xfce-image-eglibc-ipk-v2012.05-omap3-pandora.rootfs.tar.bz2" but it would be helpful if there is an README.TXT which would describe what are (if any) differences between several of the images currently located there. I can see 4, that have no apparent difference in the file size, but different names. So, which one of those is "lean & mean" and which "bloated"?

Also, my suggestion is to set up an "testing procedure", steps that anyone willing to test should do and send the report. This way the most important functionality could be systematically tested and compared, and perhaps then there would be less of "noone said it didn't work" and "but there were reports somewhere".
Angstrom-openpandora-xfce-image-eglibc-ipk-v2012.05-omap3-pandora.rootfs.tar.bz2 is the one you want. The other images aren't there at the moment. It's slightly easier to just have to worry about keeping one image up to date, then having to rebuild 4 of them every time a package gets updated.

Changes between images are really too small and too frequent to bother writing a readme file for, and you can just look at the git commit logs to see what has changed. (and those are also sent to the firmware mailing list)

There's a very experimental sysv image there too, which is only there because someone wanted to test some stuff. (The old firmware used sysv for everything, and this new one systemd, and there are some small config problems that need to be fixed).

The two other images, without the Angstrom part at the start, are simply symlinks to the real Angstrom-* file.

We aren't really at the "testing" stage yet, more at the "trying to get the base system to work" bit. Once that's in place, we can start to worry about actually testing it properly.

Now that i finally have access to the bugtracker, i'll try to get some todo list on there.
Thank you for the explanation. Using browser it is not apparent which are just links, so that was my confusion about it.

Can I just keep on updating packages using opkg instead of downloading an entire image every time there are changes?
Yes, it should work in most cases.

It can fail when we do changes to config files, since those don't seem to get replaced.. but that might also have to do with some old pandora packages doing things in slightly the wrong way.

(Like appending stuff to config files from other packages in the postinst stage)
I would like to suggest to stop using auto-generated /usr/share/applications/* this is a pain when porting other OS and wanting to do subtle modifications.

Also, a more refined usage of sudoers would be welcome, first for security reasons, second because it will force cleaning of op scripts, forcing absolute pathes etc..
Me too.

The whole pnd system is already a disaster, the implementation is even worse.

And the rest of the pandora addons aren't much better, just look at all the junk the pandora-scripts need.

I mean, wtf does it even need to include entire pnds, just to get a script to show up as a menu entry ?

All that's needed is 1 simple pandora settings program, and all that junk can go out.
I have no particular idea about the .pnd system, as i made only a few of them. Have no comment on it.

But i myself don't understand why a pnd AND a .desktop are needed for op_settings*.
I mean, wtf does it even need to include entire pnds, just to get a script to show up as a menu entry ?
I agree on this. Hence why I added the WiFi options directly into the MiniMenu.

I still don't understand why the Pandora button has a script to open the XFCE menu. I've been using it through the shortcut key config ever since I asked about it in November last year, and never had any problems. I was confused on why menu items never showed icons, until I found a seperate setting for that, and now it works perfect...
Last edited by a moderator:

I have created an login on bugs.openpandora.org, so that I can report a few bugs that I have noticed, and possibly to try to fix them too, and put there the solution. It seems that someone will have to authorize my account smilnovi for me to be able to do so.