Release Ready-To-Flash Firmware-Image

[urjaman]

And yes continuous writes wear it out. When the NAND goes the unit is worthless.

is NAND required at any point when booting from SD?

In the current (auto)boot.txt setup, yes. But it's not mandatory, you just need some more files on the SD (X-Loader (MLO) & U-boot) (and it needs to have a bootable FAT32 partition). So, yeah it can always boot from SD.

 

[torpor]

I'm really seeing bloody stars over all the screwups with the Hotfix packs, ED.

You should be using a fucking repository, for crying out loud! No, I do *not* want to have to keep up with you through the forums just to learn that Hotfix #3 has a SD-card-eating BUG!! THE REPO SYSTEM SHOULD BE DOING THIS SO I DON'T HAVE TO! ITS NOT 1994, for crying out loud!

Honestly, these hotfix packs are garbage. GET THE REPO DONE!

 

[notaz]

Honestly, these hotfix packs are garbage. GET THE REPO DONE!

Yeah and your weeping here will surely give us the repo from heavens. Do you really think ED doesn't know that already?

Finding repo documentation/setup instructions would help to get it done faster. Setting up minimal test repo and documenting your experience would help to get repo done faster. Writing junk with CAPS LOCK ON will not get you the repo faster.

ED is hacking his ass off doing those HFs at nights after his day work. You could say he would better spend that time researching how to set up the repo, but who will fix the broken firmware then? vimacs is not active at the moment, said to be too busy with work. Same for DjWillis. skeezix is on vacation. I only look after the kernel, which is enough work already (you can see by the lack of any non-firmware releases from me, even PicoDrive still sits in a broken state). ED is our one-man firmware army, sure he could keep those HFs in beta threads for a bit longer, but give man a break, not those USELESS CAPS LOCK RANTS of yours.

 

[torpor]

Yeah and your weeping here will surely give us the repo from heavens. Do you really think ED doesn't know that already?

notaz, I think ED doesn't care about setting up a stock-standard, modern, well-maintained repo, or it would be done already. I think ED thinks the Hotfix files are a workable solution, but as we have seen with the last 2 hotfixes, both of which required after-distribution patches to fix them up, this isn't turning out to be so true. The work put into making a single Hotfix so far could've been put into a repo that would burn this problem forever. So, why isn't it being done? Stubbornness.

Now, I respect ED and understand he has a day job alongside his hobby of selling game consoles. But besides being overworked, he is also *an Authority* on the Base OS decisions, and as such he should be using every single technology at his fingertips to make sure the Base OS experience is as rewarding for end-users as possible. I'm sorry, but the last two Hotfixes have disabused *this user* from any thoughts of rewards from the Hotfix patches .. I have now vowed to wait at least 2 weeks after every Hotfix patch before I install them, just in case there are "other last-minute fixes that need to be applied, so that the Pandora doesn't completely hose SD cards or .."

Obviously, ED didn't get enough feedback on the last hotfix. There wasn't "enough time" or some such rubbish. If there were a repo system, beta testers could easily add the beta repo to their Pandoras and we'd start getting a lot more automated feedback on the quality of things. As it stands right now, the only testing ED is getting for his Hotfix pack is coming from near-sycophant devotees who bother to track his daily progress - the rest of us just get lost in the mix.

Finding repo documentation/setup instructions would help to get it done faster. Setting up minimal test repo and documenting your experience would help to get repo done faster. Writing junk with CAPS LOCK ON will not get you the repo faster.

I've volunteered, time and again, to get involved in this problem .. but there is just a stubborn pig-headed response, every single time: "repo's are stupid, its too much work to set up, this is too much work for a volunteer", etc. etc.

So, yes, I rant. I'm a user and a developer. I want the best for *Everybody*, not just whats best for those profiting from the Pandora (ED and co.) I want to remind the core team that sometimes, their pig-headed know-best is not going to be as rewarding as they think it ought to be. I think "Hotfix" should be *banned* from polite conversation among the Pandora cognescenti : pour regular fixes into the repo, update the repo every week or so, let the Pandora's themselves do all the work of updating the Base OS, and leave the user out of it!

This is 2010 : its not 1996! No excuse!

You could say he would better spend that time researching how to set up the repo, but who will fix the broken firmware then?

With a properly maintained repo-based release process - ANYONE could fix the firmware, and be assured that the fix would properly propagate to Pandora users. If there were a working repo, a core team of developers could be involved in the Base OS fixes, not just ED and whoever else happens to be in the 'elite' clique.. I'd be more than happy to roll in about 17 fixes to the Base OS that I've determined on my own need to be fixed - if there was a repo, a repo manager acting as gatekeeper for it, and a trusted means of coordinating fixes between developers, this would work just fine.

It works just fine in plenty of other places where Angstrom is used to deliver bug-fixes and updates: whats so special about Pandora? Answer: nothing - but the Angstrom repo technique is just not understood well enough by the core team, who have zero experience with doing this properly, so far ..

Its very tiresome to have to keep tabs of ED and his progress with the Hotfix patches. I really have to say, its not going to get any better, the more ED puts into it .. and all the more reason to *properly* sort the problem out by putting end-users at the end of the repo line, so that other developers can stream things through the repo delivery mechanism and not have to wait for ED, and his day job, to have the time to build a PND and all related after-distribution bugfixes, and get feedback from his groupies, and so on ..

give man a break, not those USELESS CAPS LOCK RANTS of yours.

I will turn off my CAPS LOCK key, just for you notaz, since you asked nicely.

Now, guys, can we *please* have a proper repo into which to pour Base OS fixes so that these problems don't become a thorny, disastrous cacaphony of patch files, one after the other, for us developers to have to deal with in the end? Please can we have a repo-Master (I volunteer) who is responsible for checking the contributions from other Base OS developers and coordinating the release of these fixes through the public repo for future updates to come?

Honest: I got bit hard by the last Hotfix. I lost my development SD, and thus almost a weeks worth of work on my Pandora projects, because of this silly device handling bug. It was a terrible fuckup.

 

[mali]

^ You get carried away, torpor. It was mentioned that they are working on a repo, iirc. The hotfix practise is an acceptable solution till a repo is ready, imo. No need to start yet another heated debate on that matter, as it was already decided to have a repo for firmware updates.

 

[torpor]

Okay mali, I do get over-excited. But in this case its because I lost my development SD to Hotfix #3, and it set me back a week. I feel like if we'd gotten a repo sooner (I mean, come on guys, you had 2 years to set up a repo so that it would work out of the gate), we'd be having a far different conversation about how to get the Pandora Base OS fixes propagated properly to end users, rather than having to keep track of these threads manually .. so please step it up a bit! The stubborn no-repo attitude is costing people time and effort!

 

[Bosbeetle]

Well you are developers who understand this stuff, I don't I have no idea what a repo is how it works and how it would work for me as a user. I'd probably end up with outdated pandora that doesnt run a lot of stuff because I didnt install the correct packages etc. Probably the pandora has to be connected to the internet for it, there are still people without wireless internet! First you mention easy and then you start mentioning beta's, repo administrators, bla bla. I think thats a lot of stuff us n00bs can do wrong.

I think they have to keep the pandora n00b friendly, a hotfix I understand, run the pnd once and its ready.

Remember were not all linux savvy people.

 

[torpor]

I'd probably end up with outdated pandora that doesnt run a lot of stuff because I didnt install the correct packages etc.

A properly serviced and maintained repo would mean that, when you put your Pandora on the 'net, you get the latest updates and improvements to the Base OS. Not having a repo means that I, as a developer, can never be sure that the bugs reported by users are related to my software, or the Base OS ..

A repo would be *dead easy* for end users, because it works like this: Plug in your Pandora, put it on the 'net, pause a few seconds, Pandora says: "Hi! A new update that provides fixes, stability, and performance boosts is now available. Want to get updated?", you press "Okay", and come back a few minutes later to the latest and greatest, running on your Pandora.

The only issue is that a repo needs people online to have all this work smoothly: well, we can release monthly repo update images that roll everything into one, as well, for those who *Can't* put their Pandoras on the web for some reason ..

Anyway, its a boring issue at this point: I for one look forward to our repo-wielding overlords beating me and my cruddy software into submission. Until then, I'll just have to try to find out the latest Hotfix version, from somewhere, and get it installed on all my Pandora's, somehow ..

 

[EvilDragon]

Yeah and your weeping here will surely give us the repo from heavens. Do you really think ED doesn't know that already?

notaz, I think ED doesn't care about setting up a stock-standard, modern, well-maintained repo, or it would be done already. I think ED thinks the Hotfix files are a workable solution, but as we have seen with the last 2 hotfixes, both of which required after-distribution patches to fix them up, this isn't turning out to be so true. The work put into making a single Hotfix so far could've been put into a repo that would burn this problem forever. So, why isn't it being done? Stubbornness.

Okay, NOW I'm really getting pissed off, since this is exactly different to what I said all the time!
I have no idea how a working repo including stable / unstable stuff works. I'm happy notaz set up an image creator on my server so I can at least make new images after that.
Working on the Hotfix is way easier for me, since I can easily change scripts and fix them, therefore I can release such Hotfixes easily, whereas I would probably need weeks to figure out how to setup a proper automatically maintained repo. Until then, no fixes would occur, which is even worse in my opinion.

I ALWAYS said that a proper repo will be setup and we are working on that, and I also mentioned it should at least be ready with the next BIG firmware release.

So I have no idea how you think I'm stubborn or are not interested. Maybe you are too stubborn and not interested in reading the posts I did at this board but rather try to put things the way YOU think they are?

Now, I respect ED and understand he has a day job alongside his hobby of selling game consoles. But besides being overworked, he is also *an Authority* on the Base OS decisions, and as such he should be using every single technology at his fingertips to make sure the Base OS experience is as rewarding for end-users as possible. I'm sorry, but the last two Hotfixes have disabused *this user* from any thoughts of rewards from the Hotfix patches .. I have now vowed to wait at least 2 weeks after every Hotfix patch before I install them, just in case there are "other last-minute fixes that need to be applied, so that the Pandora doesn't completely hose SD cards or .."

Well, if everyone does think like that and nobody will help testing the stuff, there will always be bugs, as we can't possibly test any theoretical problems with all devices out there.

Obviously, ED didn't get enough feedback on the last hotfix. There wasn't "enough time" or some such rubbish. If there were a repo system, beta testers could easily add the beta repo to their Pandoras and we'd start getting a lot more automated feedback on the quality of things. As it stands right now, the only testing ED is getting for his Hotfix pack is coming from near-sycophant devotees who bother to track his daily progress - the rest of us just get lost in the mix.

I doubt this is because of the repo. The users that want to HELP testing, DO that. And the ones that DON'T want to do that, also won't use the beta repo. It's as easy as that.

 

[Esn]

I think I agree with Bosbeetle.

If I understand your description, torpor, the problem is that the firmware fixes are not open to a larger group of coders to look at and work on. Is there no way to open up the process in this way, work everything out between yourselves, then release a stable "hotfix" for users every so often?

EDIT:

The only issue is that a repo needs people online to have all this work smoothly: well, we can release monthly repo update images that roll everything into one, as well, for those who *Can't* put their Pandoras on the web for some reason ..

Ok, works for me.

 

[EvilDragon]

Finding repo documentation/setup instructions would help to get it done faster. Setting up minimal test repo and documenting your experience would help to get repo done faster. Writing junk with CAPS LOCK ON will not get you the repo faster.

I've volunteered, time and again, to get involved in this problem .. but there is just a stubborn pig-headed response, every single time: "repo's are stupid, its too much work to set up, this is too much work for a volunteer", etc. etc.

To be honest, I can't remember that you ever sent me a PM to get involved in setting up a repo. I also can't remember that I ever said repos are stupid, since it was clear from the very beginning (we were talking about that in internal IRC last year in October already) that we will set it up once we find the time to do that.
And we also posted this multiple times at the boards and in the blog.

So, yes, I rant. I'm a user and a developer. I want the best for *Everybody*, not just whats best for those profiting from the Pandora (ED and co.) I want to remind the core team that sometimes, their pig-headed know-best is not going to be as rewarding as they think it ought to be. I think "Hotfix" should be *banned* from polite conversation among the Pandora cognescenti : pour regular fixes into the repo, update the repo every week or so, let the Pandora's themselves do all the work of updating the Base OS, and leave the user out of it!

You're not ranting at all, for me, this is the most ignorant post I've seen in the last weeks. You tell we're stubborn and don't want repos when we clearly stated a few times we are working on that.
EVEN as reply to your posts, so you can't tell you didn't know:

torpor, on 15 June 2010 - 10:54 PM, said:
My only intention for the use of the Angstrom repo is to use it to get developer tools onboard, but I will really try to avoid installing stuff from it unless necessary .. I really wish we had our own repo based on the Firmware releases itself, instead of 'borrowing' stuff from Angstrom ..

That's the plan

Posted 01 March 2010 - 05:46 PM
For the beginning, we'll have full flashs until things are smooth

Then we'll setup a repo server where tested and working packages are in. They can be updated when you're online.

Maybe we'll even setup a testing repo where you can get a more buggy but bleeding edge OS (and help us report bugs )

And from the official blog:

Saturday, 19 June 2010 18:24 EvilDragon

notaz and me also did work some more on HotFix 3, while DJWillis is currently setting up the official Pandora repro (including sourcecodes).

So, saying that we don't want a repo and are not working on this is PLAIN LYING, sorry.

 

[EvilDragon]

You could say he would better spend that time researching how to set up the repo, but who will fix the broken firmware then?

With a properly maintained repo-based release process - ANYONE could fix the firmware, and be assured that the fix would properly propagate to Pandora users. If there were a working repo, a core team of developers could be involved in the Base OS fixes, not just ED and whoever else happens to be in the 'elite' clique.. I'd be more than happy to roll in about 17 fixes to the Base OS that I've determined on my own need to be fixed - if there was a repo, a repo manager acting as gatekeeper for it, and a trusted means of coordinating fixes between developers, this would work just fine.
[/quote]

A working repo would not help fixing the stuff.
The GIT is online since months, anyone can grab things there and post patches in the bugtracker and send them to me, notaz or DJWills. And guess what: Some people did that and that stuff has been used and included already.

The repo is just how things are distributed, not how they are fixed.

There is no elite clique, everyone can help (and we're happy for EVERYONE who does help us!)

Seems like you are just too stubborn to help out.

Its very tiresome to have to keep tabs of ED and his progress with the Hotfix patches. I really have to say, its not going to get any better, the more ED puts into it .. and all the more reason to *properly* sort the problem out by putting end-users at the end of the repo line, so that other developers can stream things through the repo delivery mechanism and not have to wait for ED, and his day job, to have the time to build a PND and all related after-distribution bugfixes, and get feedback from his groupies, and so on ..

Now, guys, can we *please* have a proper repo into which to pour Base OS fixes so that these problems don't become a thorny, disastrous cacaphony of patch files, one after the other, for us developers to have to deal with in the end? Please can we have a repo-Master (I volunteer) who is responsible for checking the contributions from other Base OS developers and coordinating the release of these fixes through the public repo for future updates to come?

If it's that easy, okay: Please setup a working build server including GITs and proper repos for me for the Pandora OS. Everything to do that is available and ready, I expect it to work next week latest, okay?
You can also be the repo master, no big deal with me.
But talk to DJWillis and notaz about that, since they're the ones that did almost all the OS work so far.

Honest: I got bit hard by the last Hotfix. I lost my development SD, and thus almost a weeks worth of work on my Pandora projects, because of this silly device handling bug. It was a terrible fuckup.

I have no idea what device handling bug you're talking about.
Nothing has changed there - it only uses label names of the SD Cards as mountpoints if they exist and mounts cards with dirsync instead of sync (so you need to wait for two seconds before you remove your SD Card).
This is even mentioned in the changelog:

* Automount: Now using Dirsync instead of sync with 2s Buffer flush. This increases SD Write speed A LOT. However, be sure to wait at least 2 seconds before removing your SD Card after you saved data

Still, there was absolutely NO bug that destroyed any data on any SD card - nothing has changed there.
And a repo wouldn't have changed anything there - if there was a bug, it would also be in the repo and fuck up your SD card as well.

 

[EvilDragon]

@ torpor:

Okay, just read your last posts and saw that you basically were angry when you posted this... still, telling guys that we don't want to setup a repo when we clearly told the complete difference was an absolutely non-neccessary thing.
And that really got me mad - so sorry if there are any offending things that are not true in my above posts.
I won't delete them as you guys probably already read them, but I also don't want to read them over again.

But still: there was no bug in a hotfix that killed SD Cards, since nothing had been changed there.
Must've been a coincidence - but I'd never keep stuff on an SD Card without having a backup.

Yesterday, my SD Card was wiped. But guess what: Not by the Pandora, but by the PC...

 

[Bosbeetle]

*mental note make backup of my pandora sd card

I wish I was in general a bit better with computers, I don't like to be in the n00b segment of users

 

[EvilDragon]

*mental note make backup of my pandora sd card

You should ALWAYS do that.
I had SD Cards dying in my mobile phone, GP2X, WIZ, Dingoo, digital camera, etc.
Most of the times, fsck or chkdsk fixes it, but corruption can always happen.
It especially happens with cheap SD cards (see that thread here, where someone had this SD Card.
People on Amazon all had trouble with losing data from their cards with all kinds of devices....

 

[torpor]

ED: I have worked with repo-based distribution of software for over two decades, and my company is currently using Angstrom in similar ways to how the OPT is using it for the Pandora. The way it works, typically, is there are *two* repo's in use:

1. a Mainstream end-user repo
2. a Beta repo

A core group of developers can push their fixes into the Beta. They have permission to do so, and a common GIT (or whatever) repository for sources and package contributions. Then a core group of testers put those Beta Repo updates through some testing. Once the Beta group says "these updates are ready", they get pushed to the public repo and thus everyone gets updated. Very few serious bugs make it through this filter, at least if the Beta Repo users are competent and contributing.

Now, I have had this repo rant previously, and been told time and again "we are working on it". I've talked about it with DJWillis extensively, and I know that he has a lot of hacky fixups and changes that need to be integrated with a proper Bitbake-driven repo release process. I *know* that the GIT-based stuff is not complete and won't fully integrate into a regular Angstrom repo release production line, because there are hacked-up packages in there that are included in the Base OS, but not built through the Angstrom tools. You *can't* just flick a switch and turn the repo on, because there *are* hacky aspects of the Base OS that haven't been integrated with proper Bitbake recipes to build packages .. yet.

And I do believe DJWillis is doing as much as he can to make this all stock-standard Angstrom-like in terms of usability from the backend, and I realize thats a lot of work. I have volunteered to help, but been told to back off, because its too delicate right now and adding more coder-hands to the problem is not going to solve the problem of the final, public, repo actually *working* for end users and not just hackers.

But I am complaining NOW that it isn't done yet, and that instead you've put a lot of work into another Hotfix release because, my perception is, your time would be better applied to getting the repo system working finally. It seems you just don't know how to use it, and therefore cannot see the benefit of working on it instead of Hotfix distribution. Honestly, I can't see how anyone with actual experience running a repo would instead choose to distribute hacky Hotfix packs! And all I ask for is: please, get the repo running so that you can experience it as well as us users and developers can!


Now .. Hotfix #3 definitely corrupted my Development SD card, ED. The changes to write-syncs is, I believe, the reason for this (I will have to look at the card in detail tonight, and can meet on IRC if you need/want more details about this corruption) .. it also doesn't help that I label all my SD Cards for the Pandora project the same way .. i.e. they are all called "PANDEV" right now .. so, if you'd had a proper Beta repo set up, I would've been subscribed to it, and the *hour* that you push the change to the repo I would've spotted the bug. As it happens, though, I didn't get around to applying your Hotfix manually until a few days after you'd already fixed the bug, and I *didn't know* there was a Hotfix #3 bug-fix released to address same-name volume mounts, until I went searching for details about it in the forum and saw the comments about it. Terribly Frustrating, Dude.

Therefore, really I can't say I have much faith in the decision/qualifications process that allowed you to make this change to the way the Base OS handles SD cards, and I believe if you'd had a repo to have to push this change through, and associated beta testers getting the updates from the Beta Repo, it possibly may not have made it to us public users: because it *IS* dangerous and *CAN* cause SD damage in some cases! For me, developing bollocks-style, anything that has the potential to screw up my SD is a really, really bad day.

BTW, an item in the Changelog is not something I'd expect the average user to read .. in fact I'd say that your putting it in the Changelog is fine and all, but it still doesn't excuse you from having to educate users that the change has occurred. *Nobody* reads Changelog files unless and until they have to, to find out why their system is borked.

Yes, I just blindly applied your Hotfix pack because I'm stupid: I *SHOULD* have manually checked the Changelog before I did it. With a repo handled by the Pandora itself, I would have been forced to see the Changelog by the repo manager before I applied the updates ..

Its all said now, I'll stop repeating myself and boring you core guys with my complaints about it. But please: don't do Hotfix #4. Please, please, please, abandon your faith in the Hotfix style, and bless the world with the Pandora Base OS Repo as soon as possible ..

 

[EvilDragon]

ED: I have worked with repo-based distribution of software for over two decades, and my company is currently using Angstrom in similar ways to how the OPT is using it for the Pandora. The way it works, typically, is there are *two* repo's in use:

1. a Mainstream end-user repo
2. a Beta repo

A core group of developers can push their fixes into the Beta. They have permission to do so, and a common GIT (or whatever) repository for sources and package contributions. Then a core group of testers put those Beta Repo updates through some testing. Once the Beta group says "these updates are ready", they get pushed to the public repo and thus everyone gets updated. Very few serious bugs make it through this filter, at least if the Beta Repo users are competent and contributing.

Well, I know how it SHOULD work. But I've got no idea how to set these things up.

Now, I have had this repo rant previously, and been told time and again "we are working on it". I've talked about it with DJWillis extensively, and I know that he has a lot of hacky fixups and changes that need to be integrated with a proper Bitbake-driven repo release process. I *know* that the GIT-based stuff is not complete and won't fully integrate into a regular Angstrom repo release production line, because there are hacked-up packages in there that are included in the Base OS, but not built through the Angstrom tools. You *can't* just flick a switch and turn the repo on, because there *are* hacky aspects of the Base OS that haven't been integrated with proper Bitbake recipes to build packages .. yet.

So... these changes need to be done before we can open up a repo. I can't do this, I got no time and no clue.
I will gladly setup anything on my server and help out where I can, but this is something I just can't do due to missing time.

And I do believe DJWillis is doing as much as he can to make this all stock-standard Angstrom-like in terms of usability from the backend, and I realize thats a lot of work. I have volunteered to help, but been told to back off, because its too delicate right now and adding more coder-hands to the problem is not going to solve the problem of the final, public, repo actually *working* for end users and not just hackers.

Well, I have no idea what you been talking about with DJWillis, but if he wants to fix it up first and doesn't want anyone to interfere until we have a standard, I can fully understand that.
AFAIK, the building process for OE isn't the easiest thing to setup, and as you said, he seems to have some things hacked in there, so it might happen that a different dev will break something while trying to help out. DJWillis knows what he hacked up - we really were running out of time for the first image. That's why we said the next big image will get a proper repo.

But I am complaining NOW that it isn't done yet, and that instead you've put a lot of work into another Hotfix release because, my perception is, your time would be better applied to getting the repo system working finally. It seems you just don't know how to use it, and therefore cannot see the benefit of working on it instead of Hotfix distribution.

I know the benefit. I'm using all kinds of different Linux distributions and I like the repository system.
But I have no idea about how OE handles this. How can I tell it that it should create multiple repositories? A stable and unstable one?
Currently, it creates an unstable one we could use based on all patches we do in the git. But I want a stable one, too.

How to handle that for guys that don't use the internet on the Pandora?
There needs to be way to automagically collect all the weekly stable updates from the repo and create a file that a normal user can install himself (like the Hotfix).

Not everyone tends to use internet with the Pandora.

 

[EvilDragon]

Now .. Hotfix #3 definitely corrupted my Development SD card, ED. The changes to write-syncs is, I believe, the reason for this (I will have to look at the card in detail tonight, and can meet on IRC if you need/want more details about this corruption) ..

Mounting with dirsync is the standard most other devices do (like Android, etc.)

This is because of:

sync
All I/O to the file system should be done synchronously. In case of media with limited number of write cycles (e.g. some flash drives) "sync" may cause life-cycle shortening.

dirsync is similar to sync - it makes sure that the directories are synced. So when you pull out an SD Card while the system is writing to it, you lose the last files, but the directory structure and all other files are still intact.
With 2 seconds write delay, that means that after waiting 2 seconds after the last write, everything is on the card.

If you shut the unit down properly, there is absolutely no difference.

dirsync
All directory updates within the file system should be done synchronously. This affects the following system calls: creat, link, unlink, symlink, mkdir, rmdir, mknod and rename.

So that would mean that almost ALL devices out there would corrupt your SD Card.

it also doesn't help that I label all my SD Cards for the Pandora project the same way .. i.e. they are all called "PANDEV" right now ..

Which means, that the mountpoint will be PANDEV, PANDEV-1, etc.
But that doesn't have anything to do with dirsync or sync.

so, if you'd had a proper Beta repo set up, I would've been subscribed to it, and the *hour* that you push the change to the repo I would've spotted the bug.

What bug? I still don't know of any bug in the mount.sh-Script.
What bug have you found there?

The only things I had was:
udev_151: Fixed mount.sh to not use cache with blkid

But that lead to a problem that even cards with a wrong label name used the old mountpoint. It didn't corrupt any cards, they just used a wrongly named mountpoint.

And:
udev-151: Modified mount.sh so that spaces in LABELS are also working

But that only meant that SD Cards which had spaces in their names weren't mounted.
Still nothing that could cause corruption.

Also, you could've subscribed to the GIT and see my changes there before they get included in a hotfix...

As it happens, though, I didn't get around to applying your Hotfix manually until a few days after you'd already fixed the bug, and I *didn't know* there was a Hotfix #3 bug-fix released to address same-name volume mounts, until I went searching for details about it in the forum and saw the comments about it. Terribly Frustrating, Dude.

I haven't fixed any bug in the mountscript that would cause SD Card corruption.
Unless you can point me to any.
All the mount.sh changes I did are in the GIT.

Therefore, really I can't say I have much faith in the decision/qualifications process that allowed you to make this change to the way the Base OS handles SD cards, and I believe if you'd had a repo to have to push this change through, and associated beta testers getting the updates from the Beta Repo, it possibly may not have made it to us public users: because it *IS* dangerous and *CAN* cause SD damage in some cases! For me, developing bollocks-style, anything that has the potential to screw up my SD is a really, really bad day.

I doubt more users would report that, as those who are interested in beta testing will get the beta hotfixes.
And those who are not but rather wait for stable versions also wouldn't subscribe to a beta repo.

So you want to tell me the standard that basically all devices and distributions use as mount options for SD Cards are bad for us because they could kill your SD Card?

BTW, an item in the Changelog is not something I'd expect the average user to read .. in fact I'd say that your putting it in the Changelog is fine and all, but it still doesn't excuse you from having to educate users that the change has occurred. *Nobody* reads Changelog files unless and until they have to, to find out why their system is borked.

Well, testing things without even reading what you should test does absolutely make no sense.

Yes, I just blindly applied your Hotfix pack because I'm stupid: I *SHOULD* have manually checked the Changelog before I did it. With a repo handled by the Pandora itself, I would have been forced to see the Changelog by the repo manager before I applied the updates ..

Errm - what? When I do an opkg upgrade, it just updates everything without telling me WHAT has changed...

Its all said now, I'll stop repeating myself and boring you core guys with my complaints about it. But please: don't do Hotfix #4. Please, please, please, abandon your faith in the Hotfix style, and bless the world with the Pandora Base OS Repo as soon as possible ..

So, you want the users to NOT get any updates until someone has set up a proper repo, which might take a few weeks (as we don't want to rush out things like that as that would only lead to errors...).

 

[torpor]

How to handle that for guys that don't use the internet on the Pandora?

Very, very simple: They have a source entry defined in their /etc/opkg/*conf files that points to a directory on their local filesystem (SD card), and if the package manager detects files in that directory, it includes them in the update. The package manager can go to the Internet for updates (really just a webserver) or it can check a locally mounted filesystem for updated .opk files.

When there are new updates and we have to take care of the non-Internet'ed Pandora usrs, well .. the Repo Manager Person simply creates a list of updated packages since the last update, using "opkg list-upgradable" and then copies those .opk files into a .zip for others to download, put on an SD card, and get installed on their non-Internet-accessible Pandora. There will have to be a manually-installable list of .opk's in each major update of the repo, made available through the same mechanism as you are currently using for Hotfix releases: an announcement on the forums and a direct link to the file. Until everyone with a Pandora is on the Internet with it, this is just going to have to be the way things are done, alas: but its not difficult to administer if you're using a repo in the first place to tell you what changed! You could probably script it and integrate it directly with Twitter and so on, even ..

So, you want the users to NOT get any updates until someone has set up a proper repo, which might take a few weeks (as we don't want to rush out things like that as that would only lead to errors...).

I would like for you to make the repo a priority over other updates, yes. I think the time to make this decision is *now* while you only have a few hundred users to deal with, rather than in a month, when you have a few thousand. To me, it makes absolutely no sense to continue with fixes to the firmware using the Hotfix method - how many users are out there that don't have the Hotfix applied? I know: you can't answer this question .. but if you had a repo in place right now, you'd know *exactly* how many Pandora users have done the updates, and what the scene is like for future releases .. right now, though, you're still having to rely on 90's-style forum-checking and hotfix-downloading users to get any progress reports at all, and thats just not doing things for your quality ..

BTW ED, an Angstrom repo is just a bunch of OPK files on an Internet server somewhere, and updates are just a matter of copying the relevant opk files from the build server to the public webserver. All of the tools for administering this are already in place in Angstrom/OE .. its just a matter of DJWillis and co., cleaningup the sources so that they can all be administered using bitbake .. but in the meantime, you (or I) could, for example, take the .opk files that we already have, put them on a public webserver, and start testing the repo features of the Base OS already. You could also decide on and set up mailing lists for the (Core Base OS Developers) -> (Master Base OS Sources repo) -> (Build Server) -> (Beta Repo) -> (Public Repo) production line ..

 

[notaz]

A core group of developers can push their fixes into the Beta. They have permission to do so, and a common GIT (or whatever) repository for sources and package contributions. Then a core group of testers put those Beta Repo updates through some testing. Once the Beta group says "these updates are ready", they get pushed to the public repo and thus everyone gets updated. Very few serious bugs make it through this filter, at least if the Beta Repo users are competent and contributing.

I don't see this to be too different from releasing HF on the beta forum, except distribution. I agree that just running opkg on pandora is much more convenient than hunting for new HF on the forums every time.

Now, I have had this repo rant previously, and been told time and again "we are working on it". I've talked about it with DJWillis extensively, and I know that he has a lot of hacky fixups and changes that need to be integrated with a proper Bitbake-driven repo release process. I *know* that the GIT-based stuff is not complete and won't fully integrate into a regular Angstrom repo release production line, because there are hacked-up packages in there that are included in the Base OS, but not built through the Angstrom tools. You *can't* just flick a switch and turn the repo on, because there *are* hacky aspects of the Base OS that haven't been integrated with proper Bitbake recipes to build packages .. yet.

You are wrong, you probably misunderstood DjWillis. 100% everything can be built using OE, there are no magic binary or other drop-ins. The OE environment I set up on ED's server does not have any hacks, it can run from start to finish with one bitbake command (ok right you need to run bitbake 3 times due to a bug in some .bb, but that can easily be scripted). All http://www.openpandora.org/firmware/ stuff is built this way.
What DjWillis probably meant was that some .bb files are not properly done due to lack of time, which means they can't be sent to OE mainline. And some OE .bbs are hacked up and produce incompatible packages to those found in http://www.angstrom-distribution.org/feeds/ and similar. But all this doesn't prevent us doing our custom repo, and if you can help with that please do.

I have volunteered to help, but been told to back off, because its too delicate right now and adding more coder-hands to the problem is not going to solve the problem of the final, public, repo actually *working* for end users and not just hackers.

That might have been the case some time ago, I don't see any reason for this to be the case right now.

And all I ask for is: please, get the repo running so that you can experience it as well as us users and developers can!

It doesn't seem we have manpower for that, ED can do work during overnight zombie sessions but he doesn't even know where to start. If someone prepared simple nice instructions I'm sure things would start moving forward.

Now .. Hotfix #3 definitely corrupted my Development SD card, ED. The changes to write-syncs is, I believe, the reason for this (I will have to look at the card in detail tonight, and can meet on IRC if you need/want more details about this corruption)

Sad to hear that, but that could be just coincidence. Having sync option on is a braindead thing to do, it drops write performance several times below GP2X levels! The current devsync+write_expire solution seems work to most people with nice write speeds.

.. it also doesn't help that I label all my SD Cards for the Pandora project the same way .. i.e. they are all called "PANDEV" right now .. so, if you'd had a proper Beta repo set up, I would've been subscribed to it, and the *hour* that you push the change to the repo I would've spotted the bug. As it happens, though, I didn't get around to applying your Hotfix manually until a few days after you'd already fixed the bug, and I *didn't know* there was a Hotfix #3 bug-fix released to address same-name volume mounts, until I went searching for details about it in the forum and saw the comments about it. Terribly Frustrating, Dude.

This is unrelated to corruption, but I agree the label bug not well handled and ED rushes things a bit too much (should stay in beta longer), and last HF fix should be named 3.1 or something.