Re: [Announce] Enhanced BusyBox package
 

well, then i hope those bugfixes are in that CSSU bugfix of standard busybox as well (though, not really, see two § below). Otherwise don't blame me but the one who missed to include them. However that argument is irrelevant regarding inclusion of busybox-power to CSSU.
The really funny thing is your effort to turn my words against me by perverting their meaning. CSSU is conservative, and quality of paramount importance (basically both one same thing) and thus we won't lightheaded consider swapping a whole distro to a different toolchain and build options (means 'new' untested program versions for basically everything) just for getting the new property of saved bytes in rootfs, while same time we won't include busybox-power not only because of introducing changes and thus risks that are not justified by general need (since everybody has the option to get busybox-power from default extras-* repos, something that per definition excludes inclusion to CSSU), but also we don't waste kilobytes of rootfs for this (regarding CSSU) absolutely useless improvement (maybe to stop shitstorms: it's useless just for CSSU, in the sense that nothing in CSSU depends on busybox-power improvements)

Your wish be my order, this single time: 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.

/j



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

Re: [Announce] Enhanced BusyBox package
 

Hi peterleinchen,
as you already noticed you can "live with" optional installation of busybox-power. That's your freedom of choice. You also mentioned that you "can't live" without busybox-power. Now maybe other users "can't live" without those 500k rootfs storage space. Keeping busybox-power optional is about their freedom of choice to keep those 500k free, as much as it is about yours to install busybox-power on top of CSSU.
That's one of highest principles in CSSU, not to force anything on users that they as well might decide on by themselves.
It about freedom of choice.

cheers
Joerg

Re: [Announce] Enhanced BusyBox package
 

First of all, it is not place to discuss CSSU ideals, IMO. Fortunately, for what I know, both busybox-power and cssu-thumb - mentioned here - are on their perfect way for inclusion into CSSU, despite attempts by "some vocal ones with almost no (if any) actual coding contribution (to CSSU) for the last 2 years". I'm glad, that it's time, when people more active in contributing to Maemo (outside IRC) during last years, start to decide more and more how CSSU should look like.
---

As for busybox itself, I don't necessary understand, why busybox-power upstream patches should be extracted and included into another incarnation of busybox project, in Your opinion. Busybox-power is *all* of upstream patches, so why to clone it? You just don't like anything with "power" in name, or what?

Last but not least, busybox-power is well tested (and nothing from standard Maemo "busybox-aware" scripts gets broken), both by developer, and by countless users - I would risk to say that more, than CSSU have or will ever have. No matter of the above, it's definitely better tested, that parts of CSSU have been (swapping return with kp_enter)

Kudos to IDont for all great work put into busybox-power - don't get distracted completely minor thumbs down, based on non-merit reasons. We all keep thumbs, both up and kept ( :) ) for busybox-power (and again set of thumbs-up for merlin1991, for, basically, deciding to include busybox-power in CSSU, sooner or later).

/Estel

Re: [Announce] Enhanced BusyBox package
 

dream on dreamer!
Those who know to read will judge you on your words. And as much as you try to suggest, you're neither maintainer nor any form of active contributor of CSSU, nor any active council member anymore despite what your signature tells, and thus not in a position to define what's criteria for merit to have a word on CSSU. It's actually like it's you who is trying to push "own prefferences" and "ideology", but we've seen that pattern a lot with you accusing others for what you currently are doing yourself.

PS: since it's not been me who started that nonsense here, I only can say I'll not further contribute to this (don't feed the troll). And just a suggestion to others: don't believe the lies estel continuously spreads! every second sentence of him includes an implicit lie. Quotes? sure! >>and again set of thumbs-up for merlin1991, for, basically, deciding to include busybox-power in CSSU, sooner or later<<

Re: [Announce] Enhanced BusyBox package
 

So why even bother with such useless features as portrait mode in busybox then!?...

Wouldnt it be *much* better to spend time on bugfixing or cleaning up annoyances with hildon for example, or even to have a life, rather than to spend a lot of time and effort to introduce such an annoying *bug* as a rotating terminal?

Re: [Announce] Enhanced BusyBox package
 

500 Kb of rootfs is by no means a valid reason to ban busybox-power from CSSU. And if rootfs space was so important to even care so much about 500 Kb, we should then jump right now to Thumb2 to fix that incredibly important limitation.

You have commented a lot of times that CSSU is here to provide updates and fixes for packages that can't be distributed via Extras. OK, then busybox-power, that can't be really distributed in a very clean way (it needs to replace original binary!!), is a perfect example of something that should be distributed by CSSU. Otherwise, you could argue that everything can be distributed providing binary replacements instead of upgrading packages (let's include Qt4.7.4 in Extras as a substitution of .so files!!).

If busybox-power is in Extras, it's simply because it was packaged before CSSU started. It was such an important need for users that it was one the first replacements to original Nokia software. Also it comes with tons of fixes not available in CSSU, not simply new features.

Re: [Announce] Enhanced BusyBox package
 

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

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.

Re: [Announce] Enhanced BusyBox package
 

If true, I'm kinda of curious, why in the world would anyone want a busybox with portrait mode support when the hardware keyboard only makes sense in landscape mode.
This would only irritate people if the terminal keeps rotating all the time (like many other applications usually do when they most of the time shouldn't).
On top of that, CSSU would in such case replace the busybox-power (which is much improved compared to the stock one) with this rotating atrocity. So how's that for freedom of choice?
Well at least to me, that would be the worst crap feature of the year.
Where's that thread discussing this matter, I'd really like to know who came up with the "brilliant" idea.

Re: [Announce] Enhanced BusyBox package
 

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.

If we get a proper proper portrait virtual keyboard (looks like it is arriving), I would not mind that option. It should switch back to landscape if the keyboard is open.

Until I have seen more info about this, I can't really judge it.

Re: [Announce] Enhanced BusyBox package
 

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.
One of the reasons to stick with the N900 is that the terminal is so GOOD with the phys. keyboard. Why would I then start typing on a virtual keyboard, that indeed would SHRINK like half of the screen in portrait mode (the whole thing is actually kind of laughable).
Ok, if it wouldn't rotate when the keyboard is out, I wouldn't mind that much (even if it makes no sense to rotate it even if the keyboard is in), but if it forces itself to install over the busybox-power it really irritates me even if I can reinstall busybox-power.

I just hope the CSSU team doesn't add things to the CSSU just because they can code them.

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

Re: [Announce] Enhanced BusyBox package
 

Seriously guys? On Maemo with its constant swapping you are worrying about damaging flash with shell history? Really?

Re: [Announce] Enhanced BusyBox package
 

Most "power" users run at least one swap on SD.
I also wish to reduce flash wear as best as I can, not promote it.

Re: [Announce] Enhanced BusyBox package
 

But if you put that new split-off binary with the '-power' features into /opt/.../whatever, while it might not cause problems for users using relative stock devices, it causes problems for any busybox-power user that uses busybox-power features at early-boot stages, such as my /sbin/preinit shell prompt thing - I see later down in the log this got brought up, and I even got mentioned by name, so I see my main concern isn't likely to be a problem with this setup, but then, if we're okay with 100/150kB size increase, saying we're not okay with 500kB is pretty arbitrary - especially when other rootfs-located files are larger by orders of magnitude and some of those can be safely optified on the vast majority of devices. (Edit: and by this I mean most likely all devices, I just can't bring myself to speak in absolutes unless I am damn certain there aren't exceptions, on principle.)

I do appreciate the fact that everyone in that log, in their own way, is trying to make sure users are happy. But at the same time, after reading the log I still see very little merit to the arguments presented against inclusion of busybox power as-is (maybe it's because I actually pay attention to what unoptified packages cram my rootfs after install, and go through the trouble of optifying the biggest offenders? I actually have shell scripts saved for optifying GCC, G++, libc-dev, Ruby, PHP, so I don't have to manually do it every time an N900 requires reflashing....). The whole thing seemingly boils down to "it got compiled in with new features, so the 500kB of extra size is bad" - but if that same 500kB of extra space came from upstream bugfixes and code improvements only, I somehow don't think anyone would be arguing against it as much - mainly because CSSU has happily updated other system packages in a way that by now has probably netted far more rootfs consumption than busybox-power could.

If we want to optimize things to conserve rootfs space, there's plenty of libraries in rootfs, and more-over other standard linux/unix directories that currently map to rootfs that other packages tend to install things into, that don't really need to be in rootfs, and could safely be moved and symlinked over by CSSU, that are vastly less likely to be desirable in a rootfs-mounted-only state, than busybox-power commands. Even things like httpd in busybox-power are likely to be more useful to someone than, say, having the microb-engine or the nokia-maps files in rootfs, because how likely are you to be browsing the internetz with microb or using maps when only rootfs is mounted? And these are optifications known to be completely harmless since the N900 was fairly new - and who's impact on performance is negligible. (And just optifying either of those by default leaves far more free space in rootfs than 500kb extra of busybox-power does.) If either of these optifications have been made standard in CSSU installs and I haven't noticed, I apologize for missing it, but I don't think they have? (And if they have, then we're already far into net gain for rootfs space, even with busybox-power.)

I also somehow I don't think if, for example, mohammadAG (who if I recall correctly helped get the CSSU organized to the point of finally being released initially) had decided to upgrade the busybox package with the features of current busybox-power, any one of the CSSU maintainers would have blinked at just making it the default busybox or even thought too hard about allowing user choice to preserve that 500kB.

(As I said in my prev. post though, I think user choice is wonderful, but I think the greatest advantage to the greatest amount of users, with the least choices forced upon the user, is in this case to make the standard CSSU busybox, busybox-power, and a less feature-filled busybox for space-conservation can be limited to those who really want the rootfs space. Failing that, I am undecided as to whether separate packages are really worse than one that splits the -power features into opt, since two packages might inconvenience some users minutely, but one package will greatly inconvenience a small amount of users. Yes, I might only care for a few specific tools that -power brings, for /sbin/preinit - but we sure can't use me as the standard for what -power features ought to stay in rootfs, because I am hardly the epitome of shell-scripting skill.)

Meh. Worse case scenario, some users be where we are now anyway (having to manually redo things with busybox after every official update) while most others are hopefully happy or at least happier, with the new predicament.

- Edit 2 -
Yes I know I forgot to really address the whole issue of thorough testing being needed before CSSU inclusion of busybox upstream fixes, let alone busybox-power, that's mainly because I am tired, although in short I consider countless users booting without noticed problems countless times to be a very good test - it's not a rigorous test, but to reject it as being insufficient until enough manpower/hours is spent on complete code coverage of initscripts or whatever the proper terminology is simply 'perfect solution fallacy'. And as an aside I feel like that's a pragmatic issue which is to be considered only after the more principle-relevant issue of whether or not (and how) busybox-power or some subset thereof ought to be included into cssu.

Re: [Announce] Enhanced BusyBox package
 

Thanks Mentalist, that is exactly my thinking.
So just want to second to your argumentation.

Re: [Announce] Enhanced BusyBox package
 

+1 one to that. Glad to have you back, I am a bit jalous how well you can elaborate and support your reasonable opinion (and the opinion of others, incl me). Thanks!

Re: [Announce] Enhanced BusyBox package
 

I'm absolutely glad, that so many respectable users opt for busybox-power in CSSU. hoever, I would suggest pasting those posts to CSSU-testing thread - I got sneaky suspicions, that CSSU maintainers doesn't have habit of reading this thread. Really!

Re: [Announce] Enhanced BusyBox package
 

The biggest reason to include power in cssu is that programs that are dependant on power can be easily distibuted to everyone thru the repositories, and for scriptdevelopers, no need to worry about if a command is a powercommand or not...
The same with discussions in the forums, no need to worry about powercommands when helping someone.
The whole function of powerbusybox is to add functionality and useroptions that are vastly more powerful than portraitmode.
-So, if it is important to save space, then remove portrait support and let that portrait busybox be distributed in the repositories, since that doesnt matter where it is distributed.

Edit:
CSSU should focus on internal stuff inside the system, add functionality that other programs can rely on, and that developers and other people can safely assume that they are there for everyone.

And not as it is now to add bells n whistles that can be distributed elswhere without any difference.
Powerbusybox adds functionality that can be used by other programs, while portraitmode and other themes, only wastes some space and processingpower on a *theme* without any added functionality at all to the system itself.
-Just let those who wants portraitmode to install it themselves, and dont distribute it thru cssu, since it doesnt belong there at all.

Re: [Announce] Enhanced BusyBox package
 

Thanks for the pretty good explanation on why bbp is not any helpful in rootfs and mandatory CSSU.
a) if your package really *needs* bbp commands in early boot where /opt isn't yet available, you have a problem anyway and should consider how to solve it locally in your pkg
b) if packages generally want to use bbp commands, they can DEPEND on bbp and use proper FQN to the binary, to invoke those commands.
c) IF we'd provide bbp to 'everyone', where would all those packages live that actually exploit those extended functions? In extras? In extras-devel? In CSSU-testing, as optional packages? There's no way a package in extras(-*) repo could DEPEND on CSSU stuff.

As a general rule, CSSU isn't inclined to sacrifice backward compatibility to stock maemo, for convenience of lazy (script-)coders

/j

ps: portrait support in bb-basic is a 2char patch that adds ZERO in bytesize to what bb binary will use - pretty easy both to verify patch sanity as well as considering storage space requirements in rootfs.

Re: [Announce] Enhanced BusyBox package
 

But why to talk about it again? It's already clear, that busybox-power will be in CSSU, if iDont will waste commit time to separate it into two packages. I though, that opinion of both busybox-power author, and CSSU maintainers, is already 100% clear, and advocates from outside CSSU "team" - like me or joerg - have nothing to do anymore, in this case?
---

Going back on topic - iDont, have I missed something, or Your latest update haven't made it into cssu-thumb, and thumb equivalent is one version into the past? Is it just forgotten, delayed, or I just got confused?

/Estel

Re: [Announce] Enhanced BusyBox package
 

I figured I would push a new version of busybox-power pretty quickly after the last (intermediate) version, hence I skipped sending the sources to freemangordon for inclusion in community-thumb. However, I was wrong, evidently.

Since it looks like it can take a little while longer to get a response over at BusyBox' bugzilla (re the terminating signal handler), I'll probably just go ahead and include my patch in busybox-power and keep that build in extras-devel until I've got some upstream response. I'll make sure freemangordon received the appropriate sources for the new build as well.

Thanks for this. There's not much more to be said with regards to busybox-power & CSSU (it's up to me now), so I'd prefer to let the subject rest as well for now.

Re: [Announce] Enhanced BusyBox package
 

Alright, who wants to test busybox-power for Harmattan?

You'll need to incept the deb, or install it with AEGIS_FIXED_ORIGIN=com.nokia.maemo if you're running Open Mode*. I previously said this wouldn't be necessary, but although I did got it working that way, I learned that busybox-power will be a lot less cleaner and less user friendly if we go that route.

Busybox-power for Harmattan has two dependencies not found in busybox-power for Fremantle: aegisctl and meego-confirm-text.

• Aegisctl is used to temporarily disable the source origin check for binaries during the period between (un)installing busybox-power and a reboot**. We could do away with this dependency by reloading Harmattan's refhashlist after (un)installation (which we do ayway), but then there would be a very brief period in which /bin/busybox would be inaccessible (!). As brief as this period is, I can't guarantee that no script on the entire device will try to access /bin/busybox in that period, hence the dependency.
• Meego-confirm-text is a small (~20KiB) QML/C++ application I made to provide a maemo-confirm-text implementation for Harmattan. It is used to display the warning you'll have to agree with during the first busybox-power installation and displaying encountered issues during uninstallation, just like on Fremantle. This application might be useful for other packages or scripts as well (for displaying Licence agreements or warnings).

Please go forth and test this testing release. I've tried the most obscure (un)install situations I could think of and did not encounter any issues, so I have good faith in the current (un)install framework. Furthermore, since Harmattan ships with a pretty recent BusyBox version, little problems should arise from using busybox-power (I have yet to encounter any ;)). If you do find a regression however, don't hesitate to let me know!

Obligatory warning: Prepare for the worst, backup your important data. Download links:
Meego-confirm-text: https://garage.maemo.org/frs/downloa....0.1_armel.deb
Aegisctl: http://talk.maemo.org/showthread.php?t=82991
Busybox-power for Harmattan (needs to be incepted): https://garage.maemo.org/frs/downloa...tan0_armel.deb

On other news: I've integrated dpkg-divert in busybox-power for Fremantle. I was previously unaware of this nifty little utility (I don't run a Debian-based OS on my laptop), hence it was not used before. By creating a diversion for /bin/busybox, future BusyBox updates (e.g. by CSSU) won't overwrite our binary.
Unfortunately Nokia has disallowed diversions on Harmattan, so we can't use them there.

All changes made to busybox-power, as well as meego-confirm-text's source, will be pushed shortly to busybox-power's garage page.

* I have not tested busybox-power in Open Mode yet, but I can't think of any issues that would arise. Please hold off installing the deb for a while until I've tested it myself if you want verification. I'll have to read up on entering Open Mode first though :o.

** I do have some code ready to re-enable the check accordingly to its previous state, but I'm not sure it'll work in Open Mode and is therefore not included yet. I plan to include this feature as soon as my device gets into Open Mode. Until then, it is best to reboot your device after (un)installing busybox-power for maximum security.

Edit: heh, forgot that this topic is posted in the "Maemo 5 / Fremantle" subforum. Well, I suppose that this thread will need to be moved to "Applications" once busybox-power for Harmattan sees its final release.

Re: [Announce] Enhanced BusyBox package
 

Awesome. I assume that we can skip rebuilding refhashlist with Open Mode?

Edit: Didn't read the part where you didn't test it under Open Mode.
I'll go test it myself, then.

Re: [Announce] Enhanced BusyBox package
 

The refhashlist gets automatically resigned in postinst/prerm. Unless the signing actually fails in Open Mode (accli return a non-zero status), installation should go fine. I assume the singing will go fine, although it obviously won't have any effect in Open Mode.
If the signing would fail however, the postinst/prerm will handle it gracefully.

P.S. you could inspect the postinst/prerm file yourself, the relevant commands can be found in INSTALL() and UNINSTALL() respectively. If you, or anyone else, sees something that would not work in Open Mode, let me know. I'll try to go into Open mode myself today, so I hope to know by the end of the day whether the (un)installation in its current form works in Open Mode or not.

Update: there are two flavours of Open Mode: one with aegis neutered ("patched" Open Mode), and one without. The current busybox-power installation works on both, but is less than ideal when running patched Open Mode. I need to create a function that can reliably determine whether aegis' source origin check is enabled or not and call aegisctl accordingly. Aegisctl itself won't do for this check, it reports the check is enabled in patched Open Mode.
The function is required since it's best not to call aegisctl to modify security options in patched Open Mode; aegisctl appears to fail when you try to run it a second time without a reboot in between. Stay tuned for updates.

Re: [Announce] Enhanced BusyBox package
 

I would definitely wonder how exactly you'd check for that using the regular Aegis tools, as with the neutered Aegis ("Yes, we passed all checks, sire!") kernel, it does what it says on the lid - not return an -EPERM.

Perhaps check uname for the build date? IIRC there is no versioning method published for these kernels, especially that they're not flashable on-device like the N900.

I suggest that new aftermarket kernels leave a sysfs entry (/sys/kernel/security/validator/neutered, perhaps?) to let developers know which kind of device they're working with. Especially when it's an unknown ratio of Inception:Openmode users.

Re: [Announce] Enhanced BusyBox package
 

The only way I can think of to reliably determine aegis' true enforcement status, is by actually testing it. We only need to get an executable file under aegis' protection, backup & modify it, and test whether it can still be executed. This executable file could be a simple shell script that calls "exit 0".
The executable file and code to "test it" (and restore it afterwards) could be included in busybox-power's packaging or a separate "aegis-test-enforcement" package (which could be reused by other packages).

Unfortunately, this is by all means not a proper solution to the problem. And besides that, it only tests one aspect of aegis' security options.

This crossed my mind as well. The build date doesn't say anything about aegis being neutered or not however.
And including a list of known patched Open Mode kernels doesn't really sound sustainable as well :-/.

This would most definitely be a good solution. We need to be able to reliably differentiate patched Open Mode kernels from regular kernels missing Nokia's signature, and the (lack of) presence of a sysfs entry could do this job.

Re: [Announce] Enhanced BusyBox package
 

Time for some updates!

First of all, Harmattan support is done. Well, I'm not aware of any bugs at the moment to put it differently ;). (Un)installation works in normal mode, open mode, and patched open mode; you won't have to worry about that part at all. To view the magic, click here and here.
I've contacted MohammadAG for inclusion of busybox-power for Harmattan in his incepted-repo and got a positive response (thanks ivgalvez for the suggestion!). The sources have been sent already ;).
As always, debs are also available from busybox-power's garage page. Scroll all the way down to find the Harmattan builds. Don't forget to incept the deb or install it with AEGIS_FIXED_ORIGIN=com.nokia.maemo.

Do note that even though I have all faith in busybox-power for Harmattan (you don't want to know how much I've tested), it is still new and therefore has a higher chance to contain a bug.

Busybox-power for Harmattan depends on meego-confirm-text, which isn't available from Harmattan's community repositories yet. I have to make myself familiar with the current status of Harmattan's community repositories first. For the time being, you'll have to grab the deb and install it yourself. Luckily you only have to do this once ;).

Secondly, busybox-power for Fremantle has been updated too. It now integrates dpkg-divert in the (un)installation process, so we won't have to worry about future busybox upgrades overwriting the enhanced binary. You can grab the thumbified version of this latest update from our garage page until it's available from community-thumb.

Lastly, most applets execute faster since our latest release. We've increased the copy buffer size in BusyBox' configuration, which -I quote from Debian's changelog- "increases [the] speed of various applets dramatically". Some quick tests performed by myself confirm this. Both the N900 as well as the N9(50) have enough resources to accommodate this larger buffer.

Enjoy!

Re: [Announce] Enhanced BusyBox package
 

First of all thank you for your efforts,
kind of out of the way, what about creating a separate announce thread for harmattan version ? we dont want things to be mixed up as in apkenv thread :(
best wishes

./sifo

Re: [Announce] Enhanced BusyBox package
 

Thanks for the suggestion. I still have to decide what's best re: threads here. Currently I'm leaning towards a request to move this thread to the application section at TMO (and rename this thread to [N900/N9/N950] Enhanced BusyBox package" or something like that). I'll keep everyone updated regarding this topic.

Re: [Announce] Enhanced BusyBox package
 

+1 for idea of different topic for harmattan version.

It's not about "separatism" - it's just too much different boats, to be healthy mixed, comprehensiveness of thread get hurt in the process.

/Estel

Re: [Announce] Enhanced BusyBox package
 

At first I would also say so, but rethinking there will also be lot of common tasks/problems/updates/announces and so on.
Take your time iDont and do what you think is the best.