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.