[Toybox] toybox symlink paths, OE conventions and FHS

[Eduardas Meile]

It has come to my attention that toybox is currently patched to change 
paths of some tools in Open Embedded:


http://cgit.openembedded.org/meta-openembedded/commit/meta-oe/recipes-core/toybox/toybox/OE-path-changes.patch?id=cdd3e9ab99d4ffda673b564ba802b6bd2d40eabf

Not really sure which project does the right thing: OE or toybox.

Also, I have noticed that there was a thread on the mailing list 
discussing similar issues back in 2015:


http://lists.landley.net/htdig.cgi/toybox-landley.net/2015-April/007262.html

http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150410/56dd947d/attachment-0004.patch

The end of the thread is inconclusive:

http://lists.landley.net/htdig.cgi/toybox-landley.net/2015-April/007262.html

Not sure why but some of the suggested changes for paths (like the ones 
for sed, dd and ps) were never implemented.


Also noticed that sed, dd and ps should go into /bin according to the 
FHS spec hosted by the Linux Foundation:


http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s04.html

So that raises the question whether toybox tries to follow the Linux 
Foundation FHS spec.


As it is not listed among "Relevant Standards" on 
http://landley.net/toybox/about.html


I assume it does not, but a clarification would be very welcome. It is 
unclear to me personally what


is the driving force behind how toybox sets tool symlinks. If it does 
not adhere to some specific spec,


perhaps it follows how some specific distro (or Android) does this?

My main concern here is to understand what the proper technical solution 
should be:


should I ask for changes in default toybox tool paths (like people did 
back in 2015) or patching the paths in OE


is the correct solution? The patch appeared relatively recently. The 
reason (from Yocto IRC):


  (mostly because there was a bug in update-alternatives until 
about a week ago where it didn't like alternatives for commands being in 
different directories


If patching in OE is the correct path, the patch should probably be 
extended to cover all of the toybox tools, not just the ones in the 
default defconfig.


Busybox in OE does not need any patches for paths as far as I can tell, 
so perhaps it would be a good idea for toybox to install


things where busybox installs them?




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

Re: [Toybox] toybox symlink paths, OE conventions and FHS

[enh via Toybox]

On Mon, Dec 10, 2018, 05:39 Eduardas Meile  It has come to my attention that toybox is currently patched to change
> paths of some tools in Open Embedded:
>
>
> http://cgit.openembedded.org/meta-openembedded/commit/meta-oe/recipes-core/toybox/toybox/OE-path-changes.patch?id=cdd3e9ab99d4ffda673b564ba802b6bd2d40eabf
>
> Not really sure which project does the right thing: OE or toybox.
>
> Also, I have noticed that there was a thread on the mailing list
> discussing similar issues back in 2015:
>
>
> http://lists.landley.net/htdig.cgi/toybox-landley.net/2015-April/007262.html
>
>
> http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150410/56dd947d/attachment-0004.patch
>
> The end of the thread is inconclusive:
>
>
> http://lists.landley.net/htdig.cgi/toybox-landley.net/2015-April/007262.html
>
> Not sure why but some of the suggested changes for paths (like the ones
> for sed, dd and ps) were never implemented.
>
> Also noticed that sed, dd and ps should go into /bin according to the
> FHS spec hosted by the Linux Foundation:
>
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s04.html
>
> So that raises the question whether toybox tries to follow the Linux
> Foundation FHS spec.
>
> As it is not listed among "Relevant Standards" on
> http://landley.net/toybox/about.html
>
> I assume it does not, but a clarification would be very welcome. It is
> unclear to me personally what
>
> is the driving force behind how toybox sets tool symlinks. If it does
> not adhere to some specific spec,
>
> perhaps it follows how some specific distro (or Android) does this?
>

Android puts everything in one directory, because there's no need for more
than one :-)

our one directory is /system/bin for similar historical reasons to the Unix
/ vs /usr mess, but on the latest devices that's actually obsolete and
we've been cleaning it up (or making things worse, depending on your point
of view) by adding symlinks like /bin and /etc.

but we don't use the toybox annotations at all: our build system has a list
of the toy symlinks it should generate, and it generates them all in
/system/bin. so we're not affected by any of this.

My main concern here is to understand what the proper technical solution
> should be:
>
> should I ask for changes in default toybox tool paths (like people did
> back in 2015) or patching the paths in OE
>
> is the correct solution? The patch appeared relatively recently. The
> reason (from Yocto IRC):
>
>(mostly because there was a bug in update-alternatives until
> about a week ago where it didn't like alternatives for commands being in
> different directories
>
> If patching in OE is the correct path, the patch should probably be
> extended to cover all of the toybox tools, not just the ones in the
> default defconfig.
>
> Busybox in OE does not need any patches for paths as far as I can tell,
> so perhaps it would be a good idea for toybox to install
>
> things where busybox installs them?
>
>
>
>
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] toybox symlink paths, OE conventions and FHS

[Rob Landley]

On 12/10/18 7:39 AM, Eduardas Meile wrote:
> It has come to my attention that toybox is currently patched to change paths 
> of
> some tools in Open Embedded:
> 
> http://cgit.openembedded.org/meta-openembedded/commit/meta-oe/recipes-core/toybox/toybox/OE-path-changes.patch?id=cdd3e9ab99d4ffda673b564ba802b6bd2d40eabf
> 
> 
> Not really sure which project does the right thing: OE or toybox.

This came up before... Ah, you spoted it.

> Also, I have noticed that there was a thread on the mailing list discussing
> similar issues back in 2015:
> 
> http://lists.landley.net/htdig.cgi/toybox-landley.net/2015-April/007262.html
> 
> http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150410/56dd947d/attachment-0004.patch
> 
> The end of the thread is inconclusive:
> 
> http://lists.landley.net/htdig.cgi/toybox-landley.net/2015-April/007262.html
> 
> Not sure why but some of the suggested changes for paths (like the ones for 
> sed,
> dd and ps) were never implemented.

Way back when I wrote a thing:

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Which attracted attention:

http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

Which influenced people (as in they linked to my writeup):

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Which was admittedly controversial:

https://rusty.ozlabs.org/?p=236

But it snowballed and is still going on:

https://lwn.net/Articles/773342/rss

That's probably the main reason it fell through the cracks?

That said, looking at the patch some of the changes seem to be about moving
between bin and sbin, not just /bin vs /usr/bin. When I add a command I
generally go "which command" to see where ubuntu puts it, and put it there, but
they've moved stuff in later releases a couple times...

> Also noticed that sed, dd and ps should go into /bin according to the FHS spec
> hosted by the Linux Foundation:

That sounds like the /usr merge again.

The Linux Foundation's kinda flamingoed up its standardization duties:

http://landley.net/notes-2010.html#18-07-2010

https://lwn.net/Articles/658809/

> http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s04.html
> 
> So that raises the question whether toybox tries to follow the Linux 
> Foundation
> FHS spec.

Not really, no.

http://landley.net/notes-2017.html#24-12-2017

> As it is not listed among "Relevant Standards" on
> http://landley.net/toybox/about.html
> 
> I assume it does not, but a clarification would be very welcome. It is unclear
> to me personally what is the driving force behind how toybox sets tool 
> symlinks.

"Where Ubuntu put it when I checked", "Who has complained", and "Did some
package's build script break?"

Last I checked Android was installing all the toybox binaries it builds into
/system/bin, and I didn't find anything that broke building the Linux From
Scratch packages (and a chunk of BLFS) under aboriginal linux (but that was
symlinking /bin to /usr/bin back in like 2003, so...)

> If it does not adhere to some specific spec, 
> perhaps it follows how some specific distro (or Android) does this?

"Where it was in ubuntu when I added it", although I could easily have made
mistakes. And that also means some of these I was checking ubuntu 06.06 and some
ubuntu 08.04 and so on...

> My main concern here is to understand what the proper technical solution 
> should be:
> 
> should I ask for changes in default toybox tool paths (like people did back in
> 2015) or patching the paths in OE

Sigh, let's see...

microcom is /bin -> /usr/bin

That's the /usr merge thing, I don't personally care either way?

blockdev is /usr/bin -> /sbin

Toybox blockdev works just fine as a normal user? You tend to want it to see if
blah.img is vfat or squashfs or what before feeding it into qemu? (Logically,
blockdev should be part of the "file" command, which is in /usr/bin on ubuntu
14.04...)

chrt is /usr/sbin -> /usr/bin

Modern ubuntu agrees with you.

hwclock /usr/bin -> /sbin

Sure.

modinfo /bin -> /sbin

Ok.

pmap /bin -> /usr/bin

/usr merge again, but as long as we've still got the flags...

printenv /usr/bin -> /bin

/usr merge

taskset /bin -> /usr/bin
timeout /bin -> /usr/bin
timeout /bin -> /usr/bin
nice /usr/bin -> /bin

and the rest of it is all adding or removing /usr

None of those really make any difference to me? I don't have a reason _not_ to
merge the patch?

> is the correct solution? The patch appeared relatively recently. The reason
> (from Yocto IRC):
> 
>   (mostly because there was a bug in update-alternatives until about 
> a
> week ago where it didn't like alternatives for commands being in different
> directories
> 
> If patching in OE is the correct path, the patch should probably be extended 
> to
> cover all of the toybox tools, not just the ones in the default defconfig.

The stuff in defconfig is finished. The stuff in pending isn't recommended for
general consumption (although Android's fished a half-dozen

Re: [Toybox] Tired of gmails nonsense.

[Rob Landley]

On 12/4/18 1:30 PM, Ivo van Poorten wrote:
> On Tue, 4 Dec 2018 13:54:10 +1000 David Seikel
>  wrote:
>> I'm not sure if it's gmails fault entirely, but I've only been seeing
>> about half of the posts to this list.  Mostly those from enh of late.
> 
> The same is happening here. I only see enh's replies and none of Rob.

Did you ever start seeing my replies?

https://twitter.com/antumbral/status/1072256103864446977

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

[Toybox] [PATCH] nc: IPv6, -4/-6, UDP

[Josh Gao via Toybox]

I sent some patches to add these a year ago, and the people requesting
the functionality probably just hit the same point in their
development cycle where they're wanting this again :-)
From 0f431a44804920a693e8832dbc784b70f227318a Mon Sep 17 00:00:00 2001
From: Josh Gao 
Date: Mon, 10 Dec 2018 16:57:46 -0800
Subject: [PATCH 1/2] nc: add IPv6 support.

---
 lib/lib.h |   1 +
 lib/net.c |  18 
 toys/net/netcat.c | 108 --
 3 files changed, 75 insertions(+), 52 deletions(-)

diff --git a/lib/lib.h b/lib/lib.h
index 14bb7cf6..6dc2ca2b 100644
--- a/lib/lib.h
+++ b/lib/lib.h
@@ -301,6 +301,7 @@ void xsetsockopt(int fd, int level, int opt, void *val, socklen_t len);
 struct addrinfo *xgetaddrinfo(char *host, char *port, int family, int socktype,
   int protocol, int flags);
 int xconnect(struct addrinfo *ai_arg);
+int xbind(struct addrinfo *ai_arg);
 int xpoll(struct pollfd *fds, int nfds, int timeout);
 int pollinate(int in1, int in2, int out1, int out2, int timeout, int shutdown_timeout);
 char *ntop(struct sockaddr *sa);
diff --git a/lib/net.c b/lib/net.c
index 8969306b..880ad89b 100644
--- a/lib/net.c
+++ b/lib/net.c
@@ -53,6 +53,24 @@ int xconnect(struct addrinfo *ai_arg)
   return fd;
 }
 
+int xbind(struct addrinfo *ai_arg)
+{
+  struct addrinfo *ai;
+  int fd = -1;
+
+  // Try all the returned addresses. Report errors if last entry can't connect.
+  for (ai = ai_arg; ai; ai = ai->ai_next) {
+fd = (ai->ai_next ? socket : xsocket)(ai->ai_family, ai->ai_socktype,
+  ai->ai_protocol);
+if (!bind(fd, ai->ai_addr, ai->ai_addrlen)) break;
+else if (!ai->ai_next) perror_exit("connect");
+close(fd);
+  }
+  freeaddrinfo(ai_arg);
+
+  return fd;
+}
+
 int xpoll(struct pollfd *fds, int nfds, int timeout)
 {
   int i;
diff --git a/toys/net/netcat.c b/toys/net/netcat.c
index aa251b88..d7dd9264 100644
--- a/toys/net/netcat.c
+++ b/toys/net/netcat.c
@@ -7,14 +7,16 @@
  * netcat -L zombies
 
 USE_NETCAT(OLDTOY(nc, netcat, TOYFLAG_USR|TOYFLAG_BIN))
-USE_NETCAT(NEWTOY(netcat, USE_NETCAT_LISTEN("^tlL")"w#<1W#<1p#<1>65535q#<1s:f:"USE_NETCAT_LISTEN("[!tlL][!Lw]"), TOYFLAG_BIN))
+USE_NETCAT(NEWTOY(netcat, USE_NETCAT_LISTEN("^tlL")"w#<1W#<1p#<1>65535q#<1s:f:46"USE_NETCAT_LISTEN("[!tlL][!Lw]")"[!46]", TOYFLAG_BIN))
 
 config NETCAT
   bool "netcat"
   default y
   help
-usage: netcat [-u] [-wpq #] [-s addr] {IPADDR PORTNUM|-f FILENAME}
+usage: netcat [-46] [-u] [-wpq #] [-s addr] {IPADDR PORTNUM|-f FILENAME}
 
+-4	Force IPv4
+-6	Force IPv6
 -f	Use FILENAME (ala /dev/ttyS0) instead of network
 -p	Local port number
 -q	Quit SECONDS after EOF on stdin, even if stdout hasn't closed yet
@@ -66,35 +68,10 @@ static void set_alarm(int seconds)
   alarm(seconds);
 }
 
-// Translate x.x.x.x numeric IPv4 address, or else DNS lookup an IPv4 name.
-static void lookup_name(char *name, uint32_t *result)
-{
-  struct hostent *hostbyname;
-
-  hostbyname = gethostbyname(name); // getaddrinfo
-  if (!hostbyname) error_exit("no host '%s'", name);
-  *result = *(uint32_t *)*hostbyname->h_addr_list;
-}
-
-// Worry about a fancy lookup later.
-static unsigned short lookup_port(char *str)
-{
-  struct servent *se;
-  int i = atoi(str);
-
-  if (i>0 && i<65536) return SWAP_BE16(i);
-
-  se = getservbyname(str, "tcp");
-  i = se ? se->s_port : 0;
-  endservent();
-
-  return i;
-}
-
 void netcat_main(void)
 {
-  struct sockaddr_in *address = (void *)toybuf;
-  int sockfd=-1, in1 = 0, in2 = 0, out1 = 1, out2 = 1;
+  int sockfd = -1, in1 = 0, in2 = 0, out1 = 1, out2 = 1;
+  int family = AF_UNSPEC;
   pid_t child;
 
   // Addjust idle and quit_delay to miliseconds or -1 for no timeout
@@ -109,30 +86,18 @@ void netcat_main(void)
   (!(toys.optflags&(FLAG_l|FLAG_L)) && toys.optc!=2))
 help_exit("bad argument count");
 
+  if (toys.optflags&FLAG_4)
+family = AF_INET;
+  else if (toys.optflags&FLAG_6)
+family = AF_INET6;
+
   if (TT.f) in1 = out2 = xopen(TT.f, O_RDWR);
   else {
 // Setup socket
-sockfd = xsocket(AF_INET, SOCK_STREAM, 0);
-setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &out1, sizeof(out1));
-
-address->sin_family = AF_INET;
-if (TT.s || TT.p) {
-  address->sin_port = SWAP_BE16(TT.p);
-  if (TT.s)
-lookup_name(TT.s, (uint32_t *)&(address->sin_addr));
-  if (bind(sockfd, (struct sockaddr *)address, sizeof(*address)))
-perror_exit("bind");
-}
-
-// Dial out
-
 if (!(toys.optflags&(FLAG_L|FLAG_l))) {
-  // Figure out where to dial out to.
-  lookup_name(*toys.optargs, (uint32_t *)&(address->sin_addr));
-  address->sin_port = lookup_port(toys.optargs[1]);
-// TODO xconnect
-  if (connect(sockfd, (struct sockaddr *)address, sizeof(*address))<0)
-perror_exit("connect");
+  struct addrinfo *addr = xgetaddrinfo(toys.optargs[0], toys.optargs[1],
+   family, SOCK_STREAM, 0, 0);
+  sockfd = xco

Re: [Toybox] [PATCH] nc: IPv6, -4/-6, UDP

[Rob Landley]

On 12/10/18 7:17 PM, Josh Gao via Toybox wrote:
> I sent some patches to add these a year ago, and the people requesting
> the functionality probably just hit the same point in their
> development cycle where they're wanting this again :-)

I'd say the "re-ping after a week and it's then my fault if I haven't gotten to
it" rule definitely applies. :)

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