[Toybox] Fix build error after 'make allyesconfig'

2016-01-11 Thread Lipi C. H. Lee
Hi, Rob.

Some source files in 'pending' directory have link error when xfork() is
called after 'make allyesconfig'.

Lipi


fix_build_bootchard.patch
Description: Binary data


fix_build_crontab.patch
Description: Binary data


fix_build_openvt.patch
Description: Binary data


fix_build_tcpsvd.patch
Description: Binary data
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] Fix build error after 'make allyesconfig'

2016-01-11 Thread Rob Landley
On 01/11/2016 03:24 AM, Lipi C. H. Lee wrote:
> Hi, Rob.
> 
> Some source files in 'pending' directory have link error when xfork() is
> called after 'make allyesconfig'.
> 
> Lipi

Thanks for the heads up.

Hmmm. Unfortunately XVFORK() isn't quite a drop-in replacement for
xfork(). This makes the code compile, but may introduce more subtle
breakage. I'll have to take a closer look...

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] cp --help mangled.

2016-01-11 Thread enh
On Sun, Jan 10, 2016 at 9:00 PM, Rob Landley  wrote:
> On 01/09/2016 02:51 PM, enh wrote:
>> the "--preserve" help is split in two, with all the other options
>> appearing between (marked here by *** which doesn't actually appear in
>> the help output):
>
> Sigh. Yeah, I need to do another pass on scripts/config2help.c.
>
> I implemented the first pass of that file in python many moons ago, but
> rewrote it in C so python wouldn't be a build dependency for toybox.
> (And this was before python decided to commit seppuku with its 3.x
> branch, the problem was .)
>
> Doing extensive string manipulation in C isn't really a _happy_ choice
> for me, but it works and is portable.
>
> (No, not perl. Never perl.)
>
>> $ adb shell cp --help
>> usage: cp [--preserve=motcxa] [-adlnrsv] [-fipRHLP] SOURCE... DEST
>>
>> Copy files from SOURCE to DEST.  If more than one SOURCE, DEST must
>> be a directory.
>>
>> --preserve takes either a comma separated list of attributes, or the first
>> ***
>> -F delete any existing destination file first (--remove-destination)
>> -H Follow symlinks listed on command line
>> -L Follow all symlinks
>> -P Do not follow symlinks [default]
>> -R recurse into subdirectories (DEST must be a directory)
>> -a same as -dpr
>> -d don't dereference symlinks
>> -f delete destination files we can't write to
>> -i interactive, prompt before overwriting existing DEST
>> -l hard link instead of copy
>> -n no clobber (don't overwrite DEST)
>> -p preserve timestamps, ownership, and mode
>> -r synonym for -R
>> -s symlink instead of copy
>> -v verbose
>> ***
>> letter(s) of:
>
> It's seeing a paragraph starting with - and treating lines at the front
> starting with - as options, stripping them out, collating the option
> block, and sorting it (with - sorting to the beginning).
>
> Should a paragraph that starts with one or more - lines but doesn't have
> a blank line after it count as an option block? I need to work out what
> the rules are, and that basically involves looking at all the help text
> blocks to find edge cases and write them up...
>
> In theory the easy fix is to rephrase "The --preserve option" so the
> paragraph doesn't start with a -. In practice the resulting collated
> line doesn't have a blank line before it, and adding an extra blank line
> between the usage: line and the --preserve line doesn't help because
> extras get eaten in parsing...

yeah, and adding an actual "--preserve" line after rephrasing the
existing one does give us the missing blank line, but still sorts
--preserve ahead of the other options, which seems weird.

still, even without the blank line, rephrasing does makes us less
unreadable and look slightly less broken, and if the right fix isn't
going to happen any time soon...


This still isn't right (because there's a missing blank line), but
it's less unreadable than splitting the --preserve documentation
and inserting all the other options in the middle.
---
 toys/posix/cp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/toys/posix/cp.c b/toys/posix/cp.c
index f932ca4..e698d45 100644
--- a/toys/posix/cp.c
+++ b/toys/posix/cp.c
@@ -56,8 +56,8 @@ config CP_PRESERVE
   help
 usage: cp [--preserve=motcxa]

---preserve takes either a comma separated list of attributes, or the first
-letter(s) of:
+The --preserve option takes either a comma separated list of attributes,
+or the first letter(s) of:

 mode - permissions (ignore umask for rwx, copy suid and sticky bit)
ownership - user and group
-- 
2.6.0.rc2.230.g3dd15c0


> As I said, need to change config2help.c...
>
> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
From 9718d5f40213bf14c6ecf8ea504e1c2ecc72a932 Mon Sep 17 00:00:00 2001
From: Elliott Hughes 
Date: Mon, 11 Jan 2016 10:19:11 -0800
Subject: [PATCH] Work around config2help.c's cp --preserve confusion.

This still isn't right (because there's a missing blank line), but
it's less unreadable than splitting the --preserve documentation
and inserting all the other options in the middle.
---
 toys/posix/cp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/toys/posix/cp.c b/toys/posix/cp.c
index f932ca4..e698d45 100644
--- a/toys/posix/cp.c
+++ b/toys/posix/cp.c
@@ -56,8 +56,8 @@ config CP_PRESERVE
   help
 usage: cp [--preserve=motcxa]
 
---preserve takes either a comma separated list of attributes, or the first
-letter(s) of:
+The --preserve option takes either a comma separated list of attributes,
+or the first letter(s) of:
 
 mode - permissions (ignore umask for rwx, copy suid and sticky bit)
ownership - user and group
-- 
2.6.0.rc2.230.g3dd15c0

___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] ls -Z with relative paths

2016-01-11 Thread Rob Landley
On 01/09/2016 03:38 PM, enh wrote:
> i have the following internal bug:
> 
> ls -laZ doesn't properly return the SELinux label for files where a
> non-fully qualified path is provided.
> 
> Steps to reproduce (on Nexus 9):
> 
>   adb shell ls -laZ /sys/kernel/debug/tracing/tracing_on
>   adb shell ls -laZ /sys/kernel/debug/tracing/ | grep tracing_on
>   adb shell 'cd /sys/kernel/debug/tracing ; ls -laZ tracing_on'
> 
> Expected: The output of all commands should yield the same SELinux
> label: "u:object_r:debugfs_tracing:s0"

I have now ordered a 1 gig quad processor raspberry pi "b" to try to
fling marshmallow upon. (I really need an android test environment, and
that's powerful enough to potentially self-host, so...)

(I would have ordered a b+ but those are all 512M with 700 mhz processor
and I think it's only dual core... Not sure how "+" works into it here.)

> something like this seems sensible for ls:
> 
> diff --git a/toys/posix/ls.c b/toys/posix/ls.c
> index 2f44d24..08ae695 100644
> --- a/toys/posix/ls.c
> +++ b/toys/posix/ls.c
> @@ -541,6 +541,7 @@ void ls_main(void)
>// Iterate through command line arguments, collecting directories and 
> files.
>// Non-absolute paths are relative to current directory.
>TT.files = dirtree_start(0, 0);
> +  TT.files->dirfd = AT_FDCWD;
>for (s = *toys.optargs ? toys.optargs : noargs; *s; s++) {
>  dt = dirtree_start(*s, !(toys.optflags&(FLAG_l|FLAG_d|FLAG_F)) ||
>  (toys.optflags&(FLAG_L|FLAG_H)));

Yes, that's the correct fix. (I just independently did that before
noticing the second half of your message. :)

> but i'm not sure whether the semantics of dirtree_start are supposed
> to imply this? certainly defaulting dirfd to -1 rather than 0 might
> lead to fewer surprises in future.

The ls recursion is unusual because ls's recursion semantics are funky.
(It does two passes over the data to pad out columns, the "label this
directory or not" logic involves knowledge of other arguments, and so on.)

So to implement what posix wants, ls takes manual control over recursion
(calling dirtree_recurse() itself in listfiles()), which uses mostly the
same data structure and mostly the same functions, but just... connects
them up strangely so it can do crazy things that straddle nodes.

This is why there's a fake node at the top of the ls tree representing
".", which is not usually the case. (The manual recursion in ls requires
a parent node to operate, the common infrastructure doesn't). So our
"did we fall off the top of the tree logic and have no ->parent,
therefore AT_CWD" logic doesn't trigger, and sticking AT_CWD into the
fake top of tree node as its dirfd is the correct response.

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net


Re: [Toybox] ls -Z with relative paths

2016-01-11 Thread Josiah Worcester
On Mon, Jan 11, 2016 at 1:18 PM Rob Landley  wrote:

> On 01/09/2016 03:38 PM, enh wrote:
> > i have the following internal bug:
> >
> > ls -laZ doesn't properly return the SELinux label for files where a
> > non-fully qualified path is provided.
> >
> > Steps to reproduce (on Nexus 9):
> >
> >   adb shell ls -laZ /sys/kernel/debug/tracing/tracing_on
> >   adb shell ls -laZ /sys/kernel/debug/tracing/ | grep tracing_on
> >   adb shell 'cd /sys/kernel/debug/tracing ; ls -laZ tracing_on'
> >
> > Expected: The output of all commands should yield the same SELinux
> > label: "u:object_r:debugfs_tracing:s0"
>
> I have now ordered a 1 gig quad processor raspberry pi "b" to try to
> fling marshmallow upon. (I really need an android test environment, and
> that's powerful enough to potentially self-host, so...)
>
> (I would have ordered a b+ but those are all 512M with 700 mhz processor
> and I think it's only dual core... Not sure how "+" works into it here.)
>

What you ordered is the "B model 2", rather than the "B+".
It goes something like: "B", "B (later board revision)", "B+", "B model 2".
And yes I realize this is silly.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net