Active Topics
-
Porting apps to Leste (32)
to Maemo 7 / Leste by Arno_11 - 1 day, 21 hrs ago -
[ANNOUNCE] CSSU-thumb thread - stable Thumb2 on N900 (2,264)
to Maemo 5 / Fremantle by panjgoori - 3 days, 15 hrs ago -
Full linux distros on Sailfish OS (254)
to SailfishOS by qoh - 4 days, 13 hrs ago - more...
|
2012-08-27
, 18:50
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#292
|
Originally Posted by ivgalvez
Good idea! I'll certainly consider doing that when BusyBox gets updated by CSSU.
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).
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
The cold, hard truth
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.
. Unfortunately, the only alternative is highly controversial as it seems.
Originally Posted by ade
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.
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.
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
Heh, nice timing to report a bug (with all this talk about inclusion of bb-power in CSSU). Nonetheless, thanks for reporting
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.
.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.
|
|
2012-08-27
, 21:22
|
|
Posts: 204 |
Thanked: 423 times |
Joined on Jan 2011
|
#293
|
Originally Posted by iDont
Well, that's better than suppressing it, right?
Heh, nice timing to report a bug (with all this talk about inclusion of bb-power in CSSU). Nonetheless, thanks for reporting
Originally Posted by iDont
Without that line from /etc/profile bug I described doesn't reproduce, so yes, that's the reason.
This must be caused by of our workaround for Maemo bug #5317 - "Busybox doesn't handle SIGHUP properly" (here's our commit).
__________________
Custom NOLO Splash, USB and R&D icons.
Custom NOLO Splash, USB and R&D icons.
|
|
2012-08-28
, 17:56
|
|
Posts: 1,163 |
Thanked: 1,873 times |
Joined on Feb 2011
@ The Netherlands
|
#294
|
Originally Posted by hxka
I guess that may have a relation to my problem/bug described here: http://talk.maemo.org/showpost.php?p...8&postcount=17
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.
__________________
N900 loaded with:
CSSU-T (Thumb)
720p recording,
Pierogi, Lanterne, Cooktimer, Frogatto
N9 16GB loaded with:
Kernel-Plus
--
[TCPdump & libpcap | ngrep]
--
donate
N900 loaded with:
CSSU-T (Thumb)
720p recording,
Pierogi, Lanterne, Cooktimer, Frogatto
N9 16GB loaded with:
Kernel-Plus
--
[TCPdump & libpcap | ngrep]
--
donate
 |
|
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 sorandom 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
Last edited by Estel; 2012-08-31 at 11:42.
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.
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
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!
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.
| The Following User Says Thank You to Estel For This Useful Post: | ||
|
|
2012-08-31
, 10:12
|
|
Posts: 1,397 |
Thanked: 2,126 times |
Joined on Nov 2009
@ Dublin, Ireland
|
#296
|
Originally Posted by Estel
Please, this is completely off-topic to busybox-power.
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
| The Following User Says Thank You to ivgalvez For This Useful Post: | ||
|
|
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:
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.
- 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.
| The Following 11 Users Say Thank You to iDont For This Useful Post: | ||
|
|
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.
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.
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.
- 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 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).
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.
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
Does this mean once that's done, write-to-history-on-exit will be back?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).
Originally Posted by joerg_rw
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?
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.
Originally Posted by joerg_rw
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.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
Originally Posted by Larswad
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.
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.
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.
| The Following 12 Users Say Thank You to Mentalist Traceur For This Useful Post: | ||
|
|
2012-09-21
, 18:59
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#299
|
Originally Posted by Mentalist Traceur
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.
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?
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.
| The Following 9 Users Say Thank You to iDont For This Useful Post: | ||
|
|
2012-09-21
, 20:26
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#300
|
Originally Posted by iDont
Glad to hear that, as I was also worried about my eMMC.
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.
Also, it's nice to hear, that development of busybox-power is going to (probably) affect mainstream busybox, *again*
Originally Posted by iDont
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?
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).
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
Generally, you're a saint, iDont. For reasons in last paragraph, I can't imagine developer, who would eagerly
[*]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.
I really, really respect You, for amount of good will, that you're presenting by agreeing to such ridiculous terms. iDont for
/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!
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-09-21 at 20:29.
| The Following 4 Users Say Thank You to Estel For This Useful Post: | ||
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.