[Announce] Enhanced BusyBox package - Page 30 - maemo.org

Active Topics

more...

Page 30 of 43

Thread Tools

hxka	2012-08-27 , 17:21
Posts: 204 \| Thanked: 423 times \| Joined on Jan 2011	#291

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.

__________________
Custom NOLO Splash, USB and R&D icons.

Quote & Reply |

The Following 4 Users Say Thank You to hxka For This Useful Post:
Estel, iDont, reinob, stlpaul

iDont	2012-08-27 , 18:50
Posts: 268 \| Thanked: 1,053 times \| Joined on May 2010 @ The Netherlands	#292

Originally Posted by ivgalvez

To help people that might not be aware of this problem, you could simple bump busybox-power version after next CSSU's update to provide a reinstallation. The issue, however, will appear again when that update makes it's way into CSSU Stable (for those using that flavour of CSSU).

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.

Originally Posted by ivgalvez

However, this is by no means a solution to the root cause of this problem, which is that bb-power shouldn't be distributed via Extras as a replacement of a system binary.

The cold, hard truth

. Unfortunately, the only alternative is highly controversial as it seems.

Originally Posted by ade

I thinks it is best that the behaviour of this potrait mode feature is explained in more detail by the ones involved.

Right now, I do not see any change in behaviour with the latest busybox. But I would expect the xterminal to be adapted for that.

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.

Originally Posted by hxka

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.

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

Last edited by iDont; 2012-08-27 at 19:33.

Quote & Reply |

The Following 8 Users Say Thank You to iDont For This Useful Post:
ade, Estel, hxka, ivgalvez, Larswad, nkirk, peterleinchen, reinob

hxka	2012-08-27 , 21:22
Posts: 204 \| Thanked: 423 times \| Joined on Jan 2011	#293

Originally Posted by iDont

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

Well, that's better than suppressing it, right?

Originally Posted by iDont

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

Without that line from /etc/profile bug I described doesn't reproduce, so yes, that's the reason.

__________________
Custom NOLO Splash, USB and R&D icons.

Quote & Reply |

The Following 2 Users Say Thank You to hxka For This Useful Post:
iDont, reinob

mr_pingu	2012-08-28 , 17:56
Posts: 1,163 \| Thanked: 1,873 times \| Joined on Feb 2011 @ The Netherlands	#294

Originally Posted by hxka

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.

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

__________________
N900 loaded with:
CSSU-T (Thumb)
720p recording,
Pierogi, Lanterne, Cooktimer, Frogatto
N9 16GB loaded with:
Kernel-Plus
--
[TCPdump & libpcap | ngrep]
--
donate

Quote & Reply |

The Following 3 Users Say Thank You to mr_pingu For This Useful Post:
Estel, iDont, reinob

	Estel	2012-08-31 , 08:54
	Posts: 5,028 \| Thanked: 8,613 times \| Joined on Mar 2011	#295

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

__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!

Last edited by Estel; 2012-08-31 at 11:42.

Quote & Reply |

The Following User Says Thank You to Estel For This Useful Post:
mr_pingu

ivgalvez	2012-08-31 , 10:12
Posts: 1,397 \| Thanked: 2,126 times \| Joined on Nov 2009 @ Dublin, Ireland	#296

Originally Posted by Estel

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.

/Estel

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

Quote & Reply |

The Following User Says Thank You to ivgalvez For This Useful Post:
sixwheeledbeast

iDont	2012-09-20 , 19:05
Posts: 268 \| Thanked: 1,053 times \| Joined on May 2010 @ The Netherlands	#297

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..

Last edited by iDont; 2012-09-22 at 10:54.

Quote & Reply |

The Following 11 Users Say Thank You to iDont For This Useful Post:
ade, don_falcone, Estel, freemangordon, Hurrian, hxka, ivgalvez, misiak, peterleinchen, reinob, shanttu

Mentalist Traceur	2012-09-20 , 22:25
Posts: 2,225 \| Thanked: 3,822 times \| Joined on Jun 2010 @ Florida	#298

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.

Originally Posted by iDont

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.

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.

Originally Posted by iDont

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).

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

Originally Posted by joerg_rw

We already know since ages that maemo initscripts are all but posix-safe, and that you might get a bootloop by overriding/replacing busybox by proper bash for default shell, and unix-tools. This is clearly a bug in initscripts that in turn only works since busybox also has a bug (as otherwise - if busybox was 100% compatible to bourne shell as it's supposed to be, there wouldn't be that weird bug in the scripts). Now replacing stock 'Nokia' busybox by busybox-power (or a 'bugfixed' normal busybox, see above ref to here) with "a lot of upstream bugfixes" might as well fix that bug in busybox that's needed to make initscripts work. Are you going to analyze all the initscripts to spot those locations where such problem might happen? If yes, please come up with a proper work package done incl complete analysis result report *) and patches to initscripts - if not, please stop arguing at this poor and pretty insulting level.

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?

Originally Posted by joerg_rw

to simplify this task for you, it might actually be sufficient to find out what were the problematic commands in initscripts (back in pre-1.2 times iirc) and just check if the syntax and output (and semantics) of these busybox commands has changed due to the applied upstream fixes, and if the current initscripts still have those defective
lines.
In fact THAT would be some much appreciated contribution to CSSU, as opposed to your constant questioning of qualifications, motivations and decisions of CSSU team which doesn't really help much for anything

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.

Originally Posted by Larswad

Yes, I shouldn't say too much about it until I know how it will be, but just by hearing about it I really really can't see any valid point in introducing that.

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".

Last edited by Mentalist Traceur; 2012-09-21 at 00:44. Reason: Ooops broken quote somehow happened.

Quote & Reply |

The Following 12 Users Say Thank You to Mentalist Traceur For This Useful Post:
Estel, freemangordon, hxka, iDont, ivgalvez, michaaa62, misiak, mr_pingu, peterleinchen, reinob, sixwheeledbeast, StefanL

iDont	2012-09-21 , 18:59
Posts: 268 \| Thanked: 1,053 times \| Joined on May 2010 @ The Netherlands	#299

Originally Posted by Mentalist Traceur

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?

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.

Last edited by iDont; 2012-09-21 at 19:03.

Quote & Reply |

The Following 9 Users Say Thank You to iDont For This Useful Post:
Estel, freemangordon, fw190, hxka, ivgalvez, Mentalist Traceur, nkirk, peterleinchen, sixwheeledbeast

	Estel	2012-09-21 , 20:26
	Posts: 5,028 \| Thanked: 8,613 times \| Joined on Mar 2011	#300

Originally Posted by iDont

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.

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*

Originally Posted by iDont

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).

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).

Originally Posted by iDont

[*]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.

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