Re: [Announce] Enhanced BusyBox package
 

Now I'm not able to reproduce it. Seems to be totally random. :(

Anyway, considering the low amount of similar reports I think it must be a combination of different pieces of software.

Now back to preenv,. it's strange that it seems not to work any more. I can run WebOS games from WebOS Game Manager application but not from the command line using preenv. After executing preenv, trying to run any executable fails with a can't locate any of the SDL libraries.

I have even reinstalled preenv with no luck, so I wonder if this is not working due to Busybox Power managing something related with environment variables different than standard Busybox.

I have yet to test if uninstalling Busybox Power results in preenv working again. In the meantime, has anyone tried to run preenv from the command line and execute a WebOS game with Busybox Power?

Re: [Announce] Enhanced BusyBox package
 

I had the known history problem so I installed busybox-power and the problem remained, until I manually deleted the history file. Thought I should let you know.

Re: [Announce] Enhanced BusyBox package
 

It seems to suffer from the same issue as TMPDIR.
Add these two lines to /etc/environment:
And starting preenv programs from the commandline will probably work again.

Re: [Announce] Enhanced BusyBox package
 

Enhanced BusyBox shell 1.19.3power4 is suitable for promotion to Extras. Did you receive the message from Autobuilder?

Re: [Announce] Enhanced BusyBox package
 

Confirmed. Ade's right about the issue causing this.
I'm leaning towards reverting the whole SUID-situation to how things were with busybox-power 1.19.3power1 (that is: no SUID bit and no workaround patch at all). Being able to run ping, su, etc. as a non-privileged user seems to be not worth the effort and the risk of breaking applications like preenv (there may be other applications getting broken that we're not aware of).

Yep, just read the message. However, I'm having second thoughts on promoting it to extras. As much as I hate to basically discard the hard-won thumbs-up (three months of voting), breaking an application like preenv outbalances the features of 1.19.3power4 over 1.19.3power1 (which is currently in extras).


I'll very most likely push out a new busybox-power version this weekend with the whole SUID-situation reversed, and promote that version to extras-testing. I know, it's a real shame of the thumbs-up, but I think this is the best thing to do. My apologies to all the testers, I hope y'all understand.

Re: [Announce] Enhanced BusyBox package
 

I did not look into it to the matter thoroughly, but it only effects starting preenv from the command prompt. As almost all users will use the menu for starting preenv apps, I see the impact as very minor.
Next to this issue I have not seen any other related findings.

I am very satisfied with the current implementation, but would also have no objections if you decide to revert the SUID situation :)

Re: [Announce] Enhanced BusyBox package
 

Aren't there any programs/scripts that are going to break after removing suid bit? why it was introduced for the first tiem - for sole purpose of using few command-line tools, or was it requested to allow easier handling of some scripts for developers?

I.E - aren't there any drawbacks sneaking on us, due to reversing SUID?

/Estel

Re: [Announce] Enhanced BusyBox package
 

Thank you for your input. IMO, even though that there might be just a few applications actually affected, the issue is very real. I didn't mind having to include a workaround or two (like the $TMPDIR thing), but the recent report of preenv revealed the underlying issue to be of a much more far-reaching nature than I had originally figured. That has made me want to reverse the situation to how it was before.

You've got a very good point here. However, the SUID bit was indeed only introduced to be able to run several applets as an unprivileged user -- convenience. There weren't any special requests for this feature. Also, there are no packages explicitly depending on busybox-power (except for yamas, which is executed as root anyway), so we should be fine.

Re: [Announce] Enhanced BusyBox package
 

A major update to busybox-power is on its way to extras-devel! Last Sunday, BusyBox 1.20.0 was released. Not soon thereafter, busybox-power got updated against this new release. This update brings 285 upstream commits to our beloved mini Linux boxes.
I've waited a few days for hotfixes to emerge prior to pushing this busybox-power update. The released hotfixes are already integrated in this update.

Please note that major updates have a larger chance to break stuff than minor updates (although nothing should break, of course). As always, let me know if you encounter any issues with the new release.

By the way, we need one more vote to get busybox-power 1.19.4power1 out of extras-testing and into Maemo's extras. If you've been running this version from extras-testing or -devel and are satisfied about it, please consider giving it a thumbs up. Thanks!

edit: whoa, that was fast! Two thumbs up within a few minutes after posting, thanks! The package has been promoted.

Re: [Announce] Enhanced BusyBox package
 

It happened again :(
Ash history corruption...

Just for info:
I updated my system to kp 50 and busybox 1.20.0 hand other devel stuff).

Yesterday night my N900 did shutdown unexpected (batt is old, keeps me up 1 day, but on low voltage just let my N900 "die"; i. e. it does not terminate all processes nicely. just kills and is off, in below 2 seconds time).

This morning I had again corrupted .ash_history (see att).
This time it looks like some conf file, but I also had already parts of my e-mails or other unrelated text. It looks like the text is randomly taken from memory or file system.
So I can confirm the cause (x-term killed "unnicely", but do not any clue about reason).

I had two x-terms open, one as user and one as root, and it happened to both it seems. Once I checked for root history it contained only the last few commands entered this morning. After closing user x-term, I checked user .ash_history and it contained also only the last few commands.

Maybe this helps you, iDont?
Not demanding anything, as this happens rarely and is just an inconvenience.