Active Topics
-
maemo.org (1)
to Community by sixwheeledbeast - 41 mins ago -
Old stuff for Nokia 770 (0)
to Nokia 770 by teroyk - 4 hrs, 39 mins ago - more...
|
2011-05-09
, 10:24
|
|
Posts: 1,042 |
Thanked: 430 times |
Joined on May 2010
|
#22
|
Originally Posted by mr_pingu
0.o weird... I know I have done that before... Well yeah indeed hostnames shouldn't really support whitespace anyways... But having space is a great feature...
Doesnt work, it still stops after the "\"
|
|
2011-05-09
, 11:00
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#23
|
Originally Posted by Mentalist Traceur
Yes, there actually is such a mechanism
The commands I checked seem to have been symlinked fine, or not symlinked where appropriate. Is there any mechanism in place to make sure that if a user installs busybox-power, then installs, say, a binary for iostat or telnet (or something else that stock busybox lacked), and then uninstalls busybox-power, that the binary (or different symlink) won't get deleted by the uninstaller thinking it's deleting its own symlink?
When deinstalling busybox-power, all symlinks created upon installation are checked if they still are symlinks, and if so, whether the symlink still points to /bin/busybox or not. Only if an utility passes both tests, it will get deleted upon deinstallation.
Originally Posted by mr_pingu
Still looking into it
Doesnt work, it still stops after the "\"
Originally Posted by Xagoln
I actually thought the same, but the stock BusyBox does indeed seem to allow a hostname with a space in /etc/hostname.
@mr_pingu, I thought spaces were not allowed in hostnames as per some RFC. Still, if it worked before...
And any feedback on performance/memory use of the new busybox? If busybox is used to run system startup scripts, a small change in either direction could be significant.
Busybox-power replaces /bin/busybox with the latest upstream version (albeit with Nokia's patches and a slightly different configuration); all scripts are ran with the new binary. I don't have any numbers on performance, but I can imagine some difference as there is a ~3 years time span between Maemo's BusyBox and the latest upstream version. I don't expect too much of a difference though (either positive or negative). I'll see if I can time some operations when I get home.
Update: Some very simple checks (cat /proc/uptime > /root/uptime) in a late startup script didn't show any significant difference in performance: a 0.58% difference in uptime (all measured uptimes were in the 13.7-13.8s range, test was performed three times which both BusyBox versions). This is a very limited benchmark though; feel free to perform additional benchmarks.
Last edited by iDont; 2011-05-09 at 21:35.
| The Following 2 Users Say Thank You to iDont For This Useful Post: | ||
|
|
2011-05-09
, 21:34
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#24
|
Originally Posted by mr_pingu
This has been fixed in busybox-power 1.18.4power3.
bug:
I changed my hostname to Mr Pingu (space included)
the old busybox used to display the whole name
[..]
This new busybox stops after Mr so it doesnt display the full hostname if a space is included in the hostname it stops after this space
I don't know whether it was a bug or a feature: the responsible 'code' was a simple flag (PARSE_GREEDY) passed to a function responsible for parsing files. After removing this flag, the complete hostname (including spaces) was read from files (including /etc/hostname) again.
Last edited by iDont; 2011-05-09 at 21:37.
| The Following 4 Users Say Thank You to iDont For This Useful Post: | ||
 |
|
2011-05-09
, 22:21
|
|
Posts: 565 |
Thanked: 618 times |
Joined on Jun 2010
@ Finland
|
#25
|
Problems when there is ~ in attribute. Example:
Run root while you are root and you get big help message.
Code:
dpkg -i fennec_6.0~a1_armel.deb
| The Following User Says Thank You to laasonen For This Useful Post: | ||
|
|
2011-05-10
, 06:00
|
|
Posts: 2,225 |
Thanked: 3,822 times |
Joined on Jun 2010
@ Florida
|
#26
|
Originally Posted by laasonen
Shouldn't there be a backslash before the tilde? Did you type it in manually or use auto-complete? Does the auto-complete not add a backslash before the tilde where it did with the original busybox?
Problems when there is ~ in attribute. Example:
Run root while you are root and you get big help message.Code:dpkg -i fennec_6.0~a1_armel.deb
|
|
2011-05-10
, 08:29
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#27
|
Originally Posted by laasonen
Thanks for reporting.
Problems when there is ~ in attribute. Example:
Run root while you are root and you get big help message.Code:dpkg -i fennec_6.0~a1_armel.deb
However, this is not because of the ~ in the filename. You'll see the 'help' when you remove it from the filename too. This help appears because of some invalid options passed to a command ran upon both installation and deinstallation of Fennec.
A quick glance revealed the following:
Fennec uses the following command in their preinst and prerm files:
Code:
RUNNING=`ps ax | grep "fennec.*/fennec" | grep -v grep | wc -l`
Update: This seems to be a bug in Fennec's scripts. For more information, see https://bugzilla.mozilla.org/show_bug.cgi?id=656020. Let's hope it'll get fixed, as the bug is not exposed when using the default BusyBox.
I could always write a patch to make ps accept all options again if it won't get fixed. For now, I'll leave this untouched. Installation and removal of Fennec should work fine nonetheless.
Last edited by iDont; 2011-05-10 at 15:20.
| The Following 3 Users Say Thank You to iDont For This Useful Post: | ||
|
|
2011-05-10
, 19:11
|
|
Posts: 2,225 |
Thanked: 3,822 times |
Joined on Jun 2010
@ Florida
|
#29
|
Does the stock busybox need to be a dependency for this package? Seems like the package itself doesn't need to be a necessity, as one can no doubt imagine a working N900 setup where stock busybox has been replaced or removed, but its' binaries have been preserved, or replacements have been moved in.
Now, yes it's unlikely, and really unreasonable for someone to do that, and frak if anyone knows why you'd even bother doing that but then wish to install busybox-power on top of it... *Shrug* But I've always been against adding dependencies that make sense "practically" but aren't actually technically necessary - is there anything that the stock busybox package provides that the busybox-power package needs to have?
Now, yes it's unlikely, and really unreasonable for someone to do that, and frak if anyone knows why you'd even bother doing that but then wish to install busybox-power on top of it... *Shrug* But I've always been against adding dependencies that make sense "practically" but aren't actually technically necessary - is there anything that the stock busybox package provides that the busybox-power package needs to have?
| The Following User Says Thank You to Mentalist Traceur For This Useful Post: | ||
|
|
2011-05-11
, 19:25
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#30
|
Originally Posted by Mentalist Traceur
Busybox-power's (un)installation script needs mkdir, ls, cp and rm, which are all provided by the package coreutils. Coreutils however is always provided by the BusyBox package on Maemo.
Does the stock busybox need to be a dependency for this package? Seems like the package itself doesn't need to be a necessity, as one can no doubt imagine a working N900 setup where stock busybox has been replaced or removed, but its' binaries have been preserved, or replacements have been moved in.
Now, yes it's unlikely, and really unreasonable for someone to do that, and frak if anyone knows why you'd even bother doing that but then wish to install busybox-power on top of it... *Shrug* But I've always been against adding dependencies that make sense "practically" but aren't actually technically necessary - is there anything that the stock busybox package provides that the busybox-power package needs to have?
It would be technically correct to make busybox-power depend on coreutils instead of BusyBox. The only reason BusyBox itself is listed as a dependency is indeed because of practical reasons.
Your post made me think over busybox-power's dependencies. It seems that I've overlooked something very obvious: busybox-power contains BusyBox, so it should never ever have to depend on anything provided by BusyBox (if the (un)installation scripts are made to use the package its BusyBox instead of /bin/busybox). I'll release an update this weekend with the dependency removed
| The Following 2 Users Say Thank You to iDont For This Useful Post: | ||
And any feedback on performance/memory use of the new busybox? If busybox is used to run system startup scripts, a small change in either direction could be significant.