Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 2 days, 20 hrs ago - more...
 |
|
2015-01-11
, 23:53
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#1342
|
what we learned:
1) use full qualified cmd path in all scripts:
2) never ever change anything in busybox. Not even fix any bugs in it, unless you made absolutely sure the fix won't break some behavior somebody relies on (e.g. nobody will depend on busybox segfaulting, so such a bug of course must get fixed as soon as it gets detected)
3) don't replace busybox by any other shell, not even busybox-power. Install any such augmented shell as concurrent alternative and keep original busybox in place
[edit]
4) there's a reason why gnu packages install into /bin/gnu/* and not into /bin/*. There's a rationale behind my $PATH looking like
/j
Last edited by joerg_rw; 2015-01-12 at 19:27.
1) use full qualified cmd path in all scripts:
Code:
CMD_FIND="LANG=en_EN /bin/busybox find"
3) don't replace busybox by any other shell, not even busybox-power. Install any such augmented shell as concurrent alternative and keep original busybox in place
[edit]
4) there's a reason why gnu packages install into /bin/gnu/* and not into /bin/*. There's a rationale behind my $PATH looking like
Code:
/usr/local/sbin:/usr/local/bin:/usr/sbin/gnu:/usr/sbin:/usr/bin/gnu:/usr/bin:/sbin:/bin:/usr/bin/X11
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Last edited by joerg_rw; 2015-01-12 at 19:27.
| The Following User Says Thank You to joerg_rw For This Useful Post: | ||
|
|
2015-01-12
, 08:24
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#1343
|
Originally Posted by joerg_rw
Even better: include a custom known-to-work busybox with backupmenu. External dependencies are OK as long as the interfaces don't change. A package dependening on some particular funcionality provided by "/bin/sh" is asking for trouble.
what we learned:
1) use full qualified cmd path in all scripts:
CMD_FIND="LANG=en_EN /bin/busybox find"
2) never ever change anything in busybox. Not even fix any bugs in it, unless you made absolutely sure the fix won't break some behavior somebody relies on (e.g. nobody will depend on busybox segfaulting, so such a bug of course must get fixed as soon as it gets detected)
3) don't replace busybox by any other shell, not even busybox-power. Install any such augmented shell as concurrent alternative and keep original busybox in place
/j
The world is bad enough seeing how many shell scripts rely on bash being /bin/sh, so if you (e.g. backupmenu) have a explicit dependency then it has to be clear. In the case of busybox it's not enough to add a dependency because of the number of busybox'es available, so the only solution is to embed it in backupmenu (doesn't it include gnu-tar anyway?).
 |
|
2015-01-12
, 08:37
|
|
Posts: 6,447 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#1344
|
+1.
Especially considering its primary purpose, I am 100% behind a monolithic BM with no external dependencies.
Especially considering its primary purpose, I am 100% behind a monolithic BM with no external dependencies.
__________________
Русский военный корабль, иди нахуй!
Русский военный корабль, иди нахуй!
 |
|
2015-01-12
, 09:56
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#1345
|
I beg to differ. IMO, the best solution would be to have backupmenu as modular set of scripts, invoked by user from shell (as early as possible, preferably the way like Mentalist's recovery shell does it, as posted a page or two back). This way, if anything fails, user have:
a) full log of what's going on
b) we don't need to rely on text2screen or any other mumbo-jumbo
c) we don"t need to be kept in stone age by not upgrading busybox (stupid, as bugs and security fixes are important).
d) fixing every "module" (script) in case of changes is trivial.
I really don't like monolithic pieces of code (hello, systemd) that makes me feel like I'm using windows 8.5, and not fixing bugs/updating such critical component as busybox is not acceptable.
/Estel
a) full log of what's going on
b) we don't need to rely on text2screen or any other mumbo-jumbo
c) we don"t need to be kept in stone age by not upgrading busybox (stupid, as bugs and security fixes are important).
d) fixing every "module" (script) in case of changes is trivial.
I really don't like monolithic pieces of code (hello, systemd) that makes me feel like I'm using windows 8.5, and not fixing bugs/updating such critical component as busybox is not acceptable.
/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!
| The Following User Says Thank You to Estel For This Useful Post: | ||
|
|
2015-01-12
, 11:14
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#1346
|
Originally Posted by Estel
OK. But then what you want is a different program/system. Backupmenu, as it is now, should really include everything it needs (which is not so much), at least the pieces that are not guaranteed to be always the same (/bin/sh, or even busybox).
I beg to differ. IMO, the best solution would be to have backupmenu as modular set of scripts, invoked by user from shell (as early as possible, preferably the way like Mentalist's recovery shell does it, as posted a page or two back). This way, if anything fails, user have:
a) full log of what's going on
b) we don't need to rely on text2screen or any other mumbo-jumbo
c) we don"t need to be kept in stone age by not upgrading busybox (stupid, as bugs and security fixes are important).
d) fixing every "module" (script) in case of changes is trivial.
I really don't like monolithic pieces of code (hello, systemd) that makes me feel like I'm using windows 8.5, and not fixing bugs/updating such critical component as busybox is not acceptable.
/Estel
I'm all for an enhanced recovery shell, i.e. the normal recovery shell with a number of scripts to make the backupmenu functionality easy to use, or at least fast (i.e. avoiding typing long commands on the shell).
|
|
2015-01-12
, 17:16
|
|
Posts: 6,447 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#1347
|
I think what we need is a recovery partition 
(Sorry reinob, I reclaimed that space for optfs)
(Sorry reinob, I reclaimed that space for optfs
)
__________________
Русский военный корабль, иди нахуй!
Русский военный корабль, иди нахуй!
| The Following User Says Thank You to pichlo For This Useful Post: | ||
|
|
2015-01-12
, 19:37
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#1348
|
Originally Posted by reinob
The system shell is immutable, as already explained in my previous post. In no system you expect the system shell to be allowed to change semantics. Any complaints that it's "not updateable" are nonsense. You can update the system shell when you update the complete system - incl all app packages. And only then. What use has an "update of system shell" anyway? Isn't it like so far all packages worked great with the "old" shell? So why do you need updates? (NB I'm not talking about security bugfixes, which have to get done unconditionally, but in a way that's 100% backward compatible, i.e. doesn't change semantics of the shell commands)
[...]pieces that are not guaranteed to be always the same (/bin/sh, or even busybox).
/j
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Last edited by joerg_rw; 2015-01-12 at 20:19.
| The Following 3 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2015-01-13
, 08:45
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#1349
|
Originally Posted by joerg_rw
That may be in an ideal world, on in your world
The system shell is immutable, as already explained in my previous post. In no system you expect the system shell to be allowed to change semantics. Any complaints that it's "not updateable" are nonsense. You can update the system shell when you update the complete system - incl all app packages. And only then. What use has an "update of system shell" anyway? Isn't it like so far all packages worked great with the "old" shell? So why do you need updates? (NB I'm not talking about security bugfixes, which have to get done unconditionally, but in a way that's 100% backward compatible, i.e. doesn't change semantics of the shell commands)
/j
(which may make sense if you wanted to somehow have a "supported" system where no unexpected things happen, but Maemo is long past that phase).
my /bin/sh is busybox-power (1.23, thumb). Why? because I can
If some programs (e.g. backupmenu, apparently -- I don't use it --) don't work with it my expectation is that these programs be fixed so that they are more "resilient". Take the example of midnight commander, it needs GNU diff to be able to compare files. Busybox diff won't do because of some option that I've forgotten. This is clearly a bug in Midnight Commander. The (Maemo) user should be free to chose whatever shell he wants.
|
|
2015-01-13
, 15:04
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#1350
|
sorry, that's nonsense. Again, _every_ system will break and not boot up when you mess around with the system shell too much. Try replacing the bourne shell by a cshell on a system-V init system. How should maemo be any different in this regard? Usually the system shell must be Posix and/or Bourne, for Maemo it must be busybox in the variant that originally shipped witj it.
Because you can? You can't. You MUST NOT [RFC2119] (modulo BB-P is supposed to be 100% compatible to BB-basic, for exactly this reason to not break stuff that depends on it. So BB-P is supposed to be 'safe' for system shell, for now - until some bug in cmd syntax wants to get fixed).
I'd say e.g. FHS and in the end ultimately the system and how it ships defines what the system shell (and toolbox) is supposed to be and act alike. E.g- for mc it's perfectly sane when the package for the distro relies on diff (and depends on it) and expect it in the location it's found at when installing the default distro pkg for diff (as a dependency of mc). You could even argue that diff has to be in a certain location when FHS specifies so (it doesn't, for diff. see http://www.pathname.com/fhs/pub/fhs-...#REQUIREMENTS2 ff). Any _bug_ in mc would be in the maemo package and introduced by the pkg maintainer who failed to adapt the dependency while preparing the maemo mc pkg.
Last edited by joerg_rw; 2015-01-14 at 01:19.
Because you can? You can't. You MUST NOT [RFC2119] (modulo BB-P is supposed to be 100% compatible to BB-basic, for exactly this reason to not break stuff that depends on it. So BB-P is supposed to be 'safe' for system shell, for now - until some bug in cmd syntax wants to get fixed).
I'd say e.g. FHS and in the end ultimately the system and how it ships defines what the system shell (and toolbox) is supposed to be and act alike. E.g- for mc it's perfectly sane when the package for the distro relies on diff (and depends on it) and expect it in the location it's found at when installing the default distro pkg for diff (as a dependency of mc). You could even argue that diff has to be in a certain location when FHS specifies so (it doesn't, for diff. see http://www.pathname.com/fhs/pub/fhs-...#REQUIREMENTS2 ff). Any _bug_ in mc would be in the maemo package and introduced by the pkg maintainer who failed to adapt the dependency while preparing the maemo mc pkg.
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Last edited by joerg_rw; 2015-01-14 at 01:19.
 |
| Tags |
| backup, backupmenu, cssusupplement, max(useful), rescue-console, restore, system |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 08:44.
Afaik the developer of smscon was not aware that gnu ps had a different output. We worked out a solution so it worked with both, but I can't blame him for not considering gnu.
The idea of a small toolbox for limited devices is okay imho, but the incompatibility indeed it is a real pain.