Re: [Announce] Enhanced BusyBox package
 

There is a very annoing bug in busybox power. It sometimes does not send SIGHUP to it's child processes.
Easiest way to reproduce: open new osso-xterm window, run `mc', close window with `X' button. MC will stay running.
Strangely, if you open osso-xterm with `osso-xterm -e sh', run mc in it, and then close it, busybox will kill mc.
This is not reproducible on stock busybox.

Re: [Announce] Enhanced BusyBox package
 

Good idea! I'll certainly consider doing that when BusyBox gets updated by CSSU.

Another option would be creating a startup script that checks whether Maemo has been updated, and if so, checks whether /bin/busybox has been modified. If both conditions are true, it will copy busybox-power's binary to /bin/busybox again.
However, it is questionable to which lenghts we want to go to provide a (from the user's POV) seamless /bin/busybox replacement without touching Maemo's BusyBox package.

The cold, hard truth :(. Unfortunately, the only alternative is highly controversial as it seems.

The stock BusyBox did support portrait mode. However, it messed up terminal output when rotating from portrait to landscape mode by inserting a lot of blank space between the last & current input line. Therefore, portrait mode of osso-xterm was blacklisted in transitions.ini. The described bug in BusyBox has been fixed in CSSU.

Osso-xterm is currently still blacklisted in the community-ssu repository on gitorious.org. That's why it won't rotate, even after the commited fix (both with busybox-power and cssu-devel). I do not know whether osso-xterm will get removed from the blacklist in the near future or not.

Heh, nice timing to report a bug (with all this talk about inclusion of bb-power in CSSU). Nonetheless, thanks for reporting :).

This must be caused by of our workaround for Maemo bug #5317 - "Busybox doesn't handle SIGHUP properly" (here's our commit). I'll look into a better fix.

Edit: By the way, comment #11 in Maemo's bugzilla on bug #5317 seems to be wrong. This bug also affects Harmattan: just open the terminal, type some commands, and close it via the "Running Applications" screen. You'll notice the history does not get saved. For that reason, you can not assume that the applied workaround in busybox-power is not needed because we use BusyBox >= 1.18.x. Just a FYI for those who may have noticed that comment in Maemo's bugzilla ;).

Re: [Announce] Enhanced BusyBox package
 

Well, that's better than suppressing it, right? :)
Without that line from /etc/profile bug I described doesn't reproduce, so yes, that's the reason.

Re: [Announce] Enhanced BusyBox package
 

I guess that may have a relation to my problem/bug described here: http://talk.maemo.org/showpost.php?p...8&postcount=17

Re: [Announce] Enhanced BusyBox package
 

Just as a little clarification:
http://mg.pov.lt/maemo-ssu-irclog/%2...08-31T10:34:53

joerg_rw isn't CSSU maintainer - despite fact, that he like to sound like one. He is (self appointed) "advisor" i.e. any ordinary user, that talk with CSSU team quite a lot, commenting on ideas, releases, etc.

OTHO, as far as I'm aware, merlin1991 actually started reviewing busybox-power for CSSU (iDont could tell more, he talked with merlin), so it's probably all right in CSSUland :)

Considering how well maintained, reliable, essential, and non-distributable via extras (via proper means) busybox-power is, I'm sure it will made it into CSSU, no need to worry about that. Of course, it won't happen in next CSSU-T release, but no need for any haste here, as soon as we know direction.

Or it isn't. Current state is that busybox-power either will be included in CSSU, or won't be :)

Judging by results of last IRC talk, (I can have not most up-to-date info, as CSSU maintainer - this time, real one - decided, that my involvement in discussion isn't necessary, to say at least) process of deciding which package will make it into CSSU is so random complicated, that no one can expect what will happen, and if yes, why and when (disclaimer" personal opinion).

I think, that I fully understand now, why certain devs aren't sure, if CSSU is worth effort at all. Personally, I've lost all faith in CSSU, due to way it's currently maintained.

I promise, that I won't waste busybox-power thread's space for discussing its context in CSSU anymore.

/Estel

Re: [Announce] Enhanced BusyBox package
 

Please, this is completely off-topic to busybox-power.

Re: [Announce] Enhanced BusyBox package
 

I've pushed an intermediate busybox-power version to Maemo's autobuilder, the only change being disabled history saving on exit. I was told not to worry about eMMC wear resulting from appending seperate commandlines to the history file. This has the following positive effects:

• We don't need to trap SIGHUP anymore. After all, we don't need to write out shell history upon shell closure. This restores default signal behaviour, i.e. children will now be closed correctly.
• The history file shouldn't get garbled up anymore when the shell gets killed 'unnicely'. Someone else will have to confirm this though, as I've never managed to reproduce this strange bug.

However, there seems to be a bug in upstream BusyBox: backgrounded jobs don't get signaled when its parent shell receives a terminating signal (like SIGHUP). Try running a program with " &" appended and SIGHUP the shell: your program will keep on running. Bash does not do this.

I've been writing a proper signal handler for ash which basically re-sends the received signal to all children and exits the shell cleanly afterwards. This fixes the above described issue and makes sure history gets written out when the terminating signal is received (for which we previously had the workaround that trapped SIGHUP). Bash installs a similar signal handler for all terminating signals as well. It works already, but I have a few concerns with the code. I plan to ask for upstream feedback on it, either via a bug report (for the described bug), or via BusyBox' mailing list.
That's also why I referred to the new busybox-power release as an intermediate version: getting the signal handler included is the final goal :).

I haven't been able to work on busybox-power as much as I wanted to; real life has been killing me last weeks and will probably continue doing so during the next week. Busybox-power for Harmattan is still on the roadmap though, and so is preparing a build that could possibly be included in CSSU.

Update: the bug report has been filed:
https://bugs.busybox.net/show_bug.cgi?id=5564
though the format got messed up. Oh well..

Re: [Announce] Enhanced BusyBox package
 

Quick (albeit late) note: you don't need to reinstall busybox-power when cssu overrides with busybox - you just need to copy the new stock busybox from /bin/busybox to /opt/busybox-power/busybox.old (if you want to save it) and the currently-installed busybox-power from /opt/busybox-power/busybox.power to /bin/busybox. Make sure you do /copy/ and not move when doing the stock busybox preserving, else busybox ends up outside your path and you'll have to preface your next command with '/opt/busybox-power/busybox.original '.

- Main points: -

I would be completely okay with CSSU folk objecting the the inclusion of busybox-power if they hadn't been ok with including plenty of other functionaly increasing features that also took up some rootfs space, or otherwise messing around with adding functionthat some didn't want, on the basis that others benefitted.

And I would agree that ideally users would have options. Does dpkg/apt not have a way to configure dependencies easily so that a package can depend on package A or package B? Of course it does: for example, kernel-power and family have things like "provides kernel-feature-ipv6" or whatever, for the vast majority of the kernel features. That way, any package that needs IPv6 support can depend on that virtual 'kernel-feature-ipv6' package, and all kernels with IPv6 support can add a provides field for that 'package' in their .deb packaging.

So CSSU could do that with busybox, and other 'optional' system replacements. busybox (stock with cssu fixes) and busybox-power could both provide some virtual package 'busybox-cssu', indicating that it is compatible with cssu installs. CSSU metapackage depends on busybox-cssu, and busybox-cssu's version number increments only when cssu makes some change to busybox. Both busybox and busybox-power just has to increment its own provides busybox-cssu version number as soon as it adds the same features. For cssu-testing and extras-devel users this will still mean some back-and-forth when cssu updates and cssu-included busybox gets overwritten, but for stable repo only users (not that too many of those exist, the longer-term N900 users will continue to be overwhelmingly power users okay with using the officially unstable repos, but still), the updates should, I imagine seemlessly flow, not disrupting their busybox of choice.

Personally, I still think the current busybox-power ought to be the cssu-default, because those who could benefit from some of the added functionality probably significantly outnumber those who would benefit from the extra 500kb of rootfs space.

Either way, we should try to make cssu not override other optional system packages upon every update if possible.

I feel a disturbance in the force, as if thousands of flash storage chips cried out in anguish and were suddenly silenced with either extensive writes to the same block (like our rootfs nand) or with severe fragmentation (as on chips with wear-leveling).

True, you don't need to worry about it if you're using an N900 more or less typically for a relative short (decade or less) scale of time. But I typically type hundreds of commands a day in x-term on my main N900, if not a few thousands on some days. Not sure how many writes that amounts to, but certainly a lot more than most people probably estimate happens.

I think it's still more ideal to do one write one shell quit rather than one on every 'enter', assuming the SIGHUP signal handling is fixed. But I agree it can be ditched while it's causing bugs.

Does this mean once that's done, write-to-history-on-exit will be back?

Does the fact that a bunch of users boot their N900s regularly with busybox-power not logically demonstrate that there aren't any serious breaks in the initscripts? At what volume of such testing do we establish that it is indeed safe?

If I have time this is something I would happily contribute to - unfortunately like most of my intended assistance/contribution to something relevant to this community, that time-having requirement is hard to meet.

The reason for introducing rotation-capability to busybox or xterm is just as valid as the reason for introducing colored 'ls' to busybox power, or busybox-power to cssu, etc.

Because for the 'default' option, you should try to find the 'best for most people' option, which typically means 'the option where the least amount of choices are made for the user'. If I have a busybox that can't handle resizing of the screen during rotation correctly, I can't use it in portrait comfortably if I want to. If I have a busybox that can handle such resizing correctly, I'm not suddenly forced to use it in portrait.

The only valid reasons for /not/ including a feature would be if it somehow forced something negative upon some, and the cost to those people weren't worth the gains to those who want the feature.

Your argument of ''I don't see a valid reason for including that" is about as sound as a person who has perfectly healthy legs not seeing a valid reason for adding wheelchair access ramps to everything. The severity of consequences in my example is greater for emphasis, but the underlying reasoning is about the same: "I've never felt the desire to have this so I don't get why others would".

Re: [Announce] Enhanced BusyBox package
 

Yes, as soon as we get a proper signal handler I'll re-enable saving on exit. I wasn't really clear on that in my previous post, sorry.

Regarding CSSU: we had a lengthy discussion regarding inclusion of busybox-power a few weeks ago. For the complete log, see:
http://mg.pov.lt/maemo-ssu-irclog/%2...08-31T13:25:25
Basically, it comes down to the following two options:

• There will be a cssu-extras repository in the future (no ETA though). Busybox-power could be cleanly distributed via this channel as a proper BusyBox alternative. CSSU's metapackage would be modified to either depend on plain busybox or busybox-power. CSSU users would automagically (i.e. completely transparently) get busybox-power's CSSU flavor, while non-CSSU users get the regular busybox-power package presented. Busybox-power will stay completely optional.
• Split the larger and less frequently used -power features from busybox-power into a separate binary, thus reducing bb-power's /bin/busybox size. Since BusyBox' applets are accessed via symlinks, this split won't be visible to end users. This, combined with extensive regression testing, would make busybox-power eligible for inclusion in the CSSU.

We picked #1 as our solution, but later on we switched to #2 (*around here*), the main argument being having upstream BusyBox in CSSU.
Unfortunately, I haven't found the time to start working on busybox-power's CSSU branch. The little spare time I had available past weeks is spend at the signal handling issue.

Re: [Announce] Enhanced BusyBox package
 

Glad to hear that, as I was also worried about my eMMC.

Also, it's nice to hear, that development of busybox-power is going to (probably) affect mainstream busybox, *again* :)

I wonder, how many people are aware of reason, why cssu-extras is "no ETA" for half of a year, or more. It's quite simple - sexy idea in theory, but no one want to waste precious personal time (devs are quite overprojected, anyway), for establishing such thing. After all, if we have perfectly working things like bb-power - that could land in CSSU right ahead - why bother?

Thus, no surprise, that this idea came from someone not involved in any Maemo development, for at least 2 years. Sure, it's rational and would be great - but, in practice, it's totally unfeasible. No one with enough skills want to touch it, even with a long stick (instead, dedicating precious times for more productive things).

Generally, you're a saint, iDont. For reasons in last paragraph, I can't imagine developer, who would eagerly waste commit own time, to split perfectly working thing into two, then maintain them both, just to satisfy purely theoretical concerns. No surprise, that You haven't found time/motivation to do it, yet.

I really, really respect You, for amount of good will, that you're presenting by agreeing to such ridiculous terms. iDont for president Community Board of Directors leader!

/Estel