Re: [Toybox] [PATCH] macOS: target 10.15.

On 6/3/22 11:43, enh wrote: > There was a tentative fourth use case: back before Apple switched from > bash to > zsh I thought they might eventually show an interest in a finished toysh, > but > they did bash->zsh the same way Ubuntu went bash->dash and Canonical > showed a > sur

Re: [Toybox] [PATCH] macOS: target 10.15.

On 6/2/22 19:48, David Seikel wrote: > On 2022-06-02 17:41:09, enh via Toybox wrote: >>Oh, yeah, I think *especially* for macOS where pretty much everyone is >>always on the latest version anyway, unless your Mac equivalent of the >>seven year rule is "support the oldest macOS release t

Re: [Toybox] [PATCH] macOS: target 10.15.

On 6/2/22 19:41, enh wrote: > Oh, yeah, I think *especially* for macOS where pretty much everyone is always > on > the latest version anyway, unless your Mac equivalent of the seven year rule > is > "support the oldest macOS release that still gets security backports", there's > no reason to do t

Re: [Toybox] [PATCH] macOS: target 10.15.

On 6/2/22 12:43, enh via Toybox wrote: > 10.15 is currently the oldest macOS release that's still getting > security updates (probably until the end of 2022, if history is any > guide). Without this, toybox built on newer versions will by default > target that version. > > Tested by adding -v and

Re: [Toybox] mac CI breakage

On 6/2/22 00:47, enh via Toybox wrote: > the mac build on github has been broken for a few days: > > Run make > scripts/make.sh > readlink: illegal option -- f > usage: readlink [-n] [file ...] > readlink: illegal option -- f > usage: readlink [-n] [file ...] > $GENDIR=generated cannot include $

Re: [Toybox] Tar --transform is weird.

On 5/23/22 19:45, enh wrote: > https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/scripts/Makefile.package#49 That first one is using S (do not apply to symlinks), which is weird because it LOOKS like it's doing git archive --prefix= and why wouldn't you do that to symlin

[Toybox] FYI gmail is going boing again.

I just resubscribed everybody through the awkward and improperly encrypted web UI for the second time this week. Same old, same old: http://lists.landley.net/pipermail/toybox-landley.net/2017-March/008887.html Rob ___ Toybox mailing list Toybox@lists.l

Re: [Toybox] Tar --transform is weird.

specifically was the "easy fix"? Was this on a mailing list? Is there a web archive link to the conversation? Rob On 5/21/22 00:36, scsijon wrote: > did to check and does, xenial64 ?? > > On 21/5/22 13:55, Rob Landley wrote: >> On 5/20/22 18:02, scsijon wrote: >>

Re: [Toybox] Tar --transform is weird.

On 5/20/22 18:02, scsijon wrote: > > On 21/5/22 00:05, Rob Landley wrote: >> On 5/19/22 18:55, scsijon wrote: >>> https://www.gnu.org/software/tar/manual/html_section/transform.html#transform >>> is the refreance page for this. Look about halfway down for '

Re: [Toybox] Tar --transform is weird.

On 5/20/22 09:05, Rob Landley wrote: > And again, why a --show-stored-names if it's the default? There isn't an "rm > -r > --do-not-recurse". How does this HELP? And of course, using that one/two/three/four/five/six hierarchy where six is a file and the ones before

Re: [Toybox] Tar --transform is weird.

On 5/19/22 18:55, scsijon wrote: > Sorry for the toppost but i don't know where this should go. Eh, it was pretty long. :) > My understanding is that you should be putting the S flag at the START > of the transform= line, not the end as it's actioned in order from the = > and s is also a transf

[Toybox] Tar --transform is weird.

The "only apply transforms to certain file types" selection is CONCEPTUALLY broken because the directories leading to those entries participate in the transform, and the directories have their own type (which is not listed), and each directory is stored in its own entry because tar x doesn't mkdir

[Toybox] Is there a reason tar.tests isn't in "make tests"?

I want to chmod +x it but I vaguely remember there was some problem testing on android or something, but I ALSO think that was fixed by the new --owner :ID stuff? (Less bad, anyway. Able to hit the test conditions with a larger rock...) The tests passed built with the ndk. (Bionic spat out a lot o

Re: [Toybox] [PATCH] macOS: silence the "vfork() is deprecated" warning spam.

On 5/16/22 11:16, enh via Toybox wrote: > This was the resolution from the discussion on mailing list; basically > "if Apple does remove vfork(), things will break quite obviously, > and we'll deal with it then". > > The apparent alternative mentioned on the mailing list of setting > _POSIX_C_SOUR

Re: [Toybox] vfork() deprecated on macOS

On 5/16/22 10:47, enh wrote: > > > On Sat, May 14, 2022 at 5:59 AM Rob Landley <mailto:r...@landley.net>> wrote: > > On 5/11/22 15:20, enh via Toybox wrote: > > the toybox build is pretty noisy on a current mac, complaining that > > vfo

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

On 5/14/22 11:56, Ivo van Poorten wrote: > On Sat, 14 May 2022 04:31:24 -0500 Rob Landley wrote: >> On 5/11/22 11:55, Ivo van Poorten wrote: >> > https://github.com/rui314/chibicc >> >> Yeah, I saw your poke about that through the old qcc mailing list. :) > &g

Re: [Toybox] vfork() deprecated on macOS

On 5/11/22 15:20, enh via Toybox wrote: > the toybox build is pretty noisy on a current mac, complaining that > vfork() should be replaced by fork() or posix_spawn(). Sigh. > looks like it's because they've changed vfork() to just be fork() and > would like people to accept that they understand t

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

On 5/11/22 11:55, Ivo van Poorten wrote: > On Wed, 11 May 2022 09:04:01 -0700 enh via Toybox > wrote: >> there's plenty of C++ in the GNU stuff these days; that's orthogonal. > > Yes. gcc cannot compile itself anymore without g++. I've noticed. https://twitter.com/landley/status/9830578032238919

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

On 5/12/22 12:26, enh wrote: > > > On Thu, May 12, 2022 at 9:56 AM Rob Landley <mailto:r...@landley.net>> wrote: > > On 5/11/22 11:10, enh wrote: > >> The next version of centos does not exist. Apparently Centos has > completely gone >

Re: [Toybox] Android .config pondering.

On 5/11/22 15:00, enh wrote: > On Wed, May 11, 2022 at 7:16 AM Rob Landley wrote: >> >> On 5/10/22 12:04, enh wrote: >> > right now i think the "can't bootstrap without an existing toybox >> > binary" is the worst mac problem. (i think there'

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

On 5/11/22 11:10, enh wrote: >> The next version of centos does not exist. Apparently Centos has completely >> gone >> away. Right, I can stop caring about it then I guess? > > (that was my reaction to the recent news, yes. "fine by me", since > centos was _always_ the most problematic distro to

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

On 5/10/22 17:08, enh wrote: > attached two separate patches; one to move, the other to take > advantage of the move. I'm reluctant to specify --std= because I've never had to before. When I started using c99 I didn't have to specify --std=c99, and we've leaked c11 features into the thing already

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

On 5/10/22 13:00, enh wrote: > On Tue, May 10, 2022 at 10:44 AM Rob Landley wrote: >> >> On 5/9/22 18:54, enh via Toybox wrote: >> > i think this question already came up recently, but mainly as a joke >> > before ... "how do you feel about C11?" >

Re: [Toybox] Android .config pondering.

On 5/10/22 12:04, enh wrote: > right now i think the "can't bootstrap without an existing toybox > binary" is the worst mac problem. (i think there's already a thread > about how your sed skills are too much for BSD sed...) It has a SED= environment variable so you can point it at gsed on mac, but

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

On 5/9/22 18:54, enh via Toybox wrote: > i think this question already came up recently, but mainly as a joke > before ... "how do you feel about C11?" It's comfortably past the 7 year support horizon. I haven't got anything against C11, I just haven't needed anything from it yet? Actually, I thi

Re: [Toybox] Android .config pondering.

On 5/9/22 19:37, enh wrote: > On Sat, May 7, 2022 at 4:38 AM Rob Landley wrote: >> > iirc the reason they differ is that macos_defconfig is "everything >> > that passes the tests on a mac [the last time enh ran all the tests on >> > a mac]" whereas

Re: [Toybox] Android .config pondering.

On 5/5/22 12:24, enh wrote: > On Wed, May 4, 2022 at 8:15 PM Rob Landley wrote: >> >> So I thought there should probably be a "make android_defconfig" target even >> if >> android isn't using it, just so I have an easier time tracking stuff. Except &

[Toybox] Release 0.8.7 is out.

I also updated the nav bar to link to the youtube channel and prebuilt binary toolchains. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] Android .config pondering.

So I thought there should probably be a "make android_defconfig" target even if android isn't using it, just so I have an easier time tracking stuff. Except android has three configs: device, linux, and mac. The android .config-mac the output of "make macos_defconfig" differing seems like a "me" p

[Toybox] Prebuilt binary cross and native toolchains.

FYI, I uploaded the cross and native compilers I use with toybox and mkroot to: https://landley.net/toybox/downloads/binaries/toolchains/latest/ They're all gcc with musl. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/li

Re: [Toybox] [PATCH] xargs: open child's stdin non-O_CLOEXEC.

On 4/21/22 19:58, enh via Toybox wrote: > O_CLOEXEC is the default in toybox, so although the code as written > _looked_ correct, we need to |O_CLOEXEC to have the fd survive the > exec(). Oops. > Found by folks building the kernel with toybox. Yay! I'm building the kernel with toybox for a bun

Re: [Toybox] [landley/toybox] Add "ifconfig eth0 rename NEWNAME". (f22bec1)

On 4/15/22 18:10, enh wrote: > yeah, and it seems to have passed on github CI anyway, so i didn't notice > until > i tried to update AOSP. > > maybe those tests are just skipped on github? > >   SKIP: ifconfig (not root) > > yep. (ideally i'd run the tests _twice_ on Android: once as root and on

Re: [Toybox] [landley/toybox] Add "ifconfig eth0 rename NEWNAME". (f22bec1)

On 4/15/22 12:21, enh-google wrote: > SIOCSIFNAME is always != 0 ... this causes a test failure on Android: > > |PASS: ifconfig dummy0 default ifconfig: '1269' > 4 bytes FAIL: ifconfig > dummy0 > mtu 1269 echo -ne '' | ifconfig dummy0 mtu 1269 && ifconfig dummy0 | grep > 1269 | > wc -l --- expec

Re: [Toybox] freadahead()

On 4/12/22 20:39, enh wrote:> On Mon, Apr 11, 2022 at 11:25 PM Rob Landley <mailto:r...@landley.net>> wrote: > > On 4/11/22 19:03, enh wrote: > > On Mon, Apr 11, 2022 at 3:19 PM Rob Landley <mailto:r...@landley.net> > > <mailto:r...@landle

Re: [Toybox] freadahead()

On 4/12/22 15:15, dmccunney wrote: > On Tue, Apr 12, 2022 at 2:25 AM Rob Landley wrote: > > And speaking of PostgreSQL: > https://www.postgresql.org/about/news/trademark-actions-against-the-postgresql-community-2302/ My link was intended to demonstrate a historical pattern of beh

Re: [Toybox] freadahead()

On 4/11/22 19:03, enh wrote: > On Mon, Apr 11, 2022 at 3:19 PM Rob Landley <mailto:r...@landley.net>> wrote: > Anyway, if musl and bionic have __freadahead(), I can either #ifdef the > glibc > hack for it in portability.h, or might just move xgetline() into >

[Toybox] freadahead()

Elliott: could you add __freadahead() to bionic the way musl and z/os and so on have? I'm bothering the posix guys about this, thread starts here: https://www.mail-archive.com/austin-group-l@opengroup.org/msg09468.html The problem is calling getline() then calling fileno() and reading from tha

Re: [Toybox] toybox git: Seeking advise to refactor some functionality into lib.c

On 4/9/22 11:36, Moritz Christian Weber wrote: > Hi, > the previous mention git (clone) toy is making progress, even as I struggled a > lot with my bad C knowledge. I look forward to this. Learning is part of the process. :) > I have a 300 LOC multi-command scaffold, which > works in most parts.

Re: [Toybox] [PATCH 2/2] Replaced sizeof by strlen in wget POST

On 3/29/22 04:35, Moritz C. Weber wrote: > --- > toys/pending/wget.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Sorry for the delay applying these, git is really stupid sometimes: $ git am one.eml fatal: Dirty index: cannot apply patches (dirty: toys/other/chvt.c) I did a git rm to

Re: [Toybox] [PATCH 0/1] Added basic post-data support to wget.c

On 3/26/22 11:59 AM, Moritz C. Weber wrote: > Dear all, > I wrote the simple patch to enable wget for POST requests with an --post-data > option. > Sadly, patched wget and git HEAD segfault on my current build machine. I did some cleanups to wget recently (after talking to you about it), and appl

Re: [Toybox] [PATCH] file: don't be confused by BSS sections.

On 3/15/22 9:30 PM, enh via Toybox wrote: > BSS sections are *expected* to claim a larger size than is actually > present in the file. Unlike program headers which have two different > size fields for the memory and file sizes, sections headers only have > one size field, so we're using the right f

Re: [Toybox] Toybox tutorial videos.

On 3/3/22 1:10 AM, Rob Landley wrote: > One of my https://patreon.com/landley goals is creating toybox instructional > videos, and that goal was met recently thanks to a generous donor, so I've > been > learning how to record and edit video. I've done a few videos at http

Re: [Toybox] Toybox tutorial videos

On 3/3/22 4:06 PM, scsijon wrote: > Try flowblade, it might be what you need. The tl;dr of the three concatenated emails is that I've finally found a recording/editing workflow that works for me: simplescreenrecorder, logitech H390 headphones, editing with blender. What I need to do NOW is edit t

Re: [Toybox] [PATCH] Correct a condition to evaluate scan_uevent() result

On 3/3/22 6:27 PM, enh via Toybox wrote: > (oops... didn't see that changyeonjo had created a github pull request already > --- this is his same change, just via a different route.) > @@ -203,7 +203,7 @@ >    } >   >    // Load uevent data, look up names in database > -  if (3 !

Re: [Toybox] [PATCH] Correct a condition to evaluate scan_uevent() result

On 3/3/22 6:23 PM, enh via Toybox wrote: > Fix: 222572616 > Test: adb root && adb shell lsusb > --- > > diff --git a/toys/other/lsusb.c b/toys/other/lsusb.c > index 8d2aa13..cbe8091 100644 > --- a/toys/other/lsusb.c > +++ b/toys/other/lsusb.c > @@ -161,7 +161,7 @@ >    char *n1, *n2; >   >    if (

[Toybox] Toybox tutorial videos.

anges about that: Forwarded Message Subject: Re: Um, wow. Date: Sun, 20 Feb 2022 19:34:35 -0600 From: Rob Landley > Hi Robert, > thanks for the additional links. > > My offer is still vali: If you have a (server) source with the raw screencast > footage and some h

[Toybox] It has a name now.

Using a phone as a desktop is called "convergence". https://lwn.net/Articles/883073/#:~:text=Convergence Working on it... Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] gpiod: new commands.

On 2/21/22 7:17 PM, enh via Toybox wrote: > Equivalent to the content of the gpiod debian package. Very different > interface to the traditional Raspberry Pi command, but that command > explicitly calls itself deprecated and tells you to use the gpiod > package's commands instead. > > "Works for m

Re: [Toybox] [PATCH] in seq.c rename itoa to toybox_itoa, to avoid clashes

On 2/17/22 12:05 PM, enh via Toybox wrote: > On Thu, Feb 17, 2022 at 5:23 AM John wrote: > > This is a simple patch for seq.c to rename itoa to toybox_itoa, to avoid > > clashes with functions in the toolchain. > > > As Piraty mentioned on IIRC there are 2 different implementations of itoa in > > m

[Toybox] lib/args.c tweak

Some commands like blkid take no arguments and only use lib/args.c to ensure there's one arg, but: $ toybox blkid -file blkid: Unknown option 'file' (see "blkid --help") I _think_ that when the option string is just requiring a minimum or maximum number of arguments but has no actual _flags_,

Re: [Toybox] [PATCH] lspci: use a different default location for pci.ids on Android.

On 2/11/22 5:33 PM, enh wrote: > On Fri, Feb 11, 2022 at 3:06 PM Rob Landley Indeed. I'd forgotten that lspci already had database reading code when I > added > it to lsusb. The two file formats actually look identical, except that > pci.ids > has a third inden

Re: [Toybox] [PATCH] lspci: use a different default location for pci.ids on Android.

On 2/11/22 1:29 PM, enh wrote: > Heads up that there's another one in lsusb.c. > > thanks, but we may as well wait until someone has a specific use case. > (although > it's unfortunate that there's no workaround with lsusb to specify a path like > there is with lspci.) Just noticed the discr

Re: [Toybox] [PATCH] lspci: use a different default location for pci.ids on Android.

On 2/10/22 9:12 PM, enh via Toybox wrote: +if (!TT.i) TT.i = CFG_TOYBOX_ON_ANDROID ? "/vendor/pci.ids" : +"/usr/share/misc/pci.ids"; Applied. Heads up that there's another one in lsusb.c. My head scratch is I added the usb.ids one to /etc (because it seemed the obvious place for me to

Re: [Toybox] chroot pondering

On 2/10/22 3:35 PM, scsijon wrote: > On 11/2/22 08:08, toybox-requ...@lists.landley.net wrote: >> Anyway, anything like THAT would belongs in the "contain" command I've got in >> the post-1.0 todo heap instead, and possibly this does too, but for the >> record ... > I wonder if in this age, that r

[Toybox] chroot pondering.

One type of change that tends to accumulate in my tree are things I implement enough of to know how to finish it, but am not sure I SHOULD do? Here's a change I had lying around in my tree that I just cleaned up so it works, adding a new "-f" option to chroot that uses execveat() to run a binary t

Re: [Toybox] Implementing ldd.

On 1/28/22 8:09 PM, enh wrote: >> Sigh. You did ask nicely. And I'm not trying to make more work for you... >> >> (Personally, I don't write code on the assumption everybody else is dumber >> than >> me and that I know what people I've never met want/need better than they do.) > > whereas i have

Re: [Toybox] Implementing ldd.

On 1/24/22 4:52 PM, enh wrote: >> That said, "here are the libraries" and "you have android API version skew" >> still seem like different questions. "What libraries does this binary ask >> for" >> and "does this binary fit into its filesystem" are different questions. > > (exactly. lld is the la

Re: [Toybox] Implementing ldd.

10 days. Not gonna throw stones. Speaking of, Pascal's Apology incoming... > On Fri, Jan 14, 2022 at 9:07 PM Rob Landley wrote: >> >> On 1/13/22 1:20 PM, enh wrote: >> > TL;DR: unless you're writing your own dynamic linker, i'm not sure why >> > y

Re: [Toybox] Implementing ldd.

On 1/13/22 1:20 PM, enh wrote: > TL;DR: unless you're writing your own dynamic linker, i'm not sure why > you'd write an ldd? Well to start with uClibc had a standalone one back in the day: https://git.busybox.net/uClibc/tree/utils/ldd.c Which is basically a subset of readelf, and we have read

Re: [Toybox] Instructional video.

On 1/13/22 2:29 PM, dmccunney wrote: > On Thu, Jan 13, 2022 at 2:33 PM Rob Landley wrote: > >> But yes, toysh is to the point where lack of command history is what's >> limiting >> _me_ from using it more. So I'm poking at it. But $DAYJOB (since new year's

Re: [Toybox] Instructional video.

Replying to the toybox list because I still have to boot a VM to log into patreon to work around their website's css bug. On 1/13/22 7:13 AM, Thomas Blankenhorn commented on your post https://www.patreon.com/posts/instructional-61084697 > PS, on a tangent: I like how nicely the toybox shell is com

[Toybox] Implementing ldd.

In theory ldd is a subset of readelf, so we've already got most of the code. In practice, the OTHER thing it does is try to dlopen() each library so it can get a path and address out of /proc/self/maps. The problem is if you're statically linked, bionic links in a dlopen() stub return ing NULL. Wh

Re: [Toybox] [PATCH] vi: fix recent changes.

On 1/10/22 9:07 PM, enh via Toybox wrote: > vi was segfaulting because some of the printf() arguments were the wrong > way round. The file content also wasn't getting displayed because [%dH > isn't a correct translation of tty_jump(0, y). Personally, although I > agree that tty_esc() wasn't pulling

Re: [Toybox] [PATCH] Fix Darwin build.

On 1/10/22 3:09 PM, enh via Toybox wrote: > The recent changes to strip harder on Linux broke Darwin, which > doesn't have those options. Applied, but I'm tempted to move some of this stuff to scripts/portability.sh since that exists now... Rob ___ Toyb

Re: [Toybox] FTP Fixes

On 1/3/22 11:06 AM, Eric Molitor wrote: > Hi Rob, > I was unclear if you were going to go through and cleanup the ftp toy or > whether > you wanted me to rev the patches to simplify/remove strrchr? I got distracted, sorry. Lemme take another look... Rob __

[Toybox] mkroot tricks.

FYI, if you have to debug something like https://github.com/landley/toybox/issues/306 where "I think this is a kernel bug in btrfs but need to reproduce it", here's how I do it. 1) Set up the musl-cross-make tools according to https://landley.net/toybox/faq.html#cross2 which is a "run overnight" k

Re: [Toybox] more general sched_setattr/sched_getattr command?

On 12/10/21 2:05 PM, enh wrote: > On Fri, Dec 10, 2021 at 3:46 AM Rob Landley Could you ask them what uclamp_validate() in kernel/sched/core.c is > trying to > do? It seems like if you've set container limits for the largest or > smallest > allowed uclamp values

Re: [Toybox] [PATCH] Add uclampset(1).

On 12/10/21 1:53 PM, enh wrote: > On Fri, Dec 10, 2021 at 6:52 AM Rob Landley <mailto:r...@landley.net>> wrote: > > On 12/9/21 7:31 PM, enh via Toybox wrote: > > No standard, but part of util-linux. > > Don't default y in pending. > > yeah,

Re: [Toybox] [PATCH] Add uclampset(1).

On 12/9/21 7:31 PM, enh via Toybox wrote: > No standard, but part of util-linux. Don't default y in pending. USE_TASKSET(NEWTOY(uclampset)) doesn't match. Does this require root? >From a UI perspective, do we ever _not_ want -a? Sigh. It's HARD to come up with a good terse description of -R.

Re: [Toybox] more general sched_setattr/sched_getattr command?

On 12/9/21 7:35 PM, enh wrote:> someone sent me https://man7.org/linux/man-pages/man1/uclampset.1.html > which seems to be the > util-linux offering. it certainly looks better than the Android home-grown > thing, so i've sent a patch with a t

Re: [Toybox] more general sched_setattr/sched_getattr command?

On 12/7/21 2:27 PM, enh via Toybox wrote: > is there an existing general sched_setattr/sched_getattr command somewhere > that > we can copy? we have chrt/nice/taskset for various subsets, and i think that > _between_ them they already cover everything that sched_setattr(2) can do -- > policy/reset

Re: [Toybox] [PATCH] strace: fix m68k build.

On 12/3/21 7:38 PM, enh wrote: > On Fri, Dec 3, 2021 at 4:15 AM Rob Landley <mailto:r...@landley.net>> wrote: > > On 12/1/21 5:23 PM, enh via Toybox wrote: > > --- > >  toys/pending/strace.c | 2 +- > >  1 file changed, 1 insertion(+), 1 deleti

Re: [Toybox] [PATCH] strace: fix m68k build.

On 12/1/21 5:23 PM, enh via Toybox wrote: > --- > toys/pending/strace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, but the real problem is that different targets have different syscalls in their headers, and the C() macros build break if a given syscall isn't there. I poste

Re: [Toybox] Is: mkroot status? Was: are you on holls or has mail dumped?

On 11/25/21 12:41 AM, scsijon wrote: > OK, so you've concentrated on toybox code and not sent emails out. I was > worried if it had died and you hadn't realised. > > So I am wondering what the status of mkroot in toybox is as i'm > considering a build in a easyos container to replace my aborigon

[Toybox] 0.8.6 released

Twice as big a gap as a usual release, but 0.8.6 is out. (Yes the release notes on the web page say yesterday, but there were some last minute mkroot bugs to track down after I'd already checked in the web page update.) Rob ___ Toybox mailing list Toyb

Re: [Toybox] Is: mkroot status? Was: are you on holls or has mail dumped?

On 11/25/21 12:41 AM, scsijon wrote: > OK, so you've concentrated on toybox code and not sent emails out. Haven't had anything to say? I've been working on toysh (which nobody else cares about until it's done), and mkroot and build plumbing. I've been blogging about it, but my blog is sadly behin

Re: [Toybox] are you on holls or has mail dumped?

On 11/24/21 4:53 PM, scsijon wrote: > just wondering, nothing has appeared since the 14th of nov. commit fac49481c6b4639e5a2fad6ea08ab6cd29b9304c Author: Rob Landley Date: Mon Nov 22 23:11:03 2021 -0600 Fix $((math)) recursion order, handle "" as 0, and add more tests.

[Toybox] Poking at strace.c

So I added the register calling conventions for the architectures that scripts/mcm-buildall.sh builds toolchains for (I.E. the ones I'm testing under qemu with scripts/mkroot.sh), but when I tried to build strace for the sh4 target it went "boing" a lot because the available syscalls don't entirely

[Toybox] Question about android's header generation policy.

Why is Android checking in generated files again? I ask because I'm fiddling with scripts/single.sh so it doesn't depend on .config existing. (It should make a temporary defconfig to harvest symbols from in that case; I'm going down a rathole of adding record-commands support to mkroot.sh which ne

Re: [Toybox] ftpget - Fixes and minor new features.

On 11/7/21 12:46 PM, Eric Molitor wrote: > Aye, the backside of FTP can't come soon enough. Even sftp, basically FTP > protocol over SSH, needs to die. The same Microsoft developer who removed FTP support from chrome just implemented a way for sites to disable "view source": https://twitter.com

Re: [Toybox] ftpget - Fixes and minor new features.

On 11/5/21 11:54 PM, Rob Landley wrote: > On 11/2/21 2:00 PM, Eric Molitor wrote: >> Attention should be paid to the change to portability.h. I believe this is >> the >> correct way to expose memrchr for glibc. I've tested it and it works with >> glibc >&

Re: [Toybox] ftpget - Fixes and minor new features.

On 11/2/21 2:00 PM, Eric Molitor wrote: > Attention should be paid to the change to portability.h. I believe this is the > correct way to expose memrchr for glibc. I've tested it and it works with > glibc > but I primarily use MUSL. I'm uncomfortable trying to guess which combinations of const an

Re: [Toybox] ftpget: Remove

On 10/29/21 1:16 PM, enh wrote: > On Fri, Oct 29, 2021 at 10:47 AM Rob Landley <mailto:r...@landley.net>> wrote: > > On 10/29/21 10:51 AM, enh via Toybox wrote: > > i don't have much of an opinion here, but i was wondering about the > usefulness >

Re: [Toybox] ftpget: Remove

On 10/29/21 11:22 AM, Eric Molitor wrote: > I genuinely had trouble finding an FTP server to test until I remembered those > two. Regarding libxml2 it's poorly documented but you can pull source from > http://xmlsoft.org/sources/ *but* I believe most > people these day

Re: [Toybox] ftpget: Remove

On 10/29/21 10:51 AM, enh via Toybox wrote: > i don't have much of an opinion here, but i was wondering about the usefulness > of this in a world where all the major browsers have now removed ftp > support... > is anyone likely to still be using ftp by the time toybox hits 1.0? Other than me? (It

Re: [Toybox] WGET: OpenSSL and BoringSSL Patch

On 10/29/21 7:03 AM, Eric Molitor wrote: > Attached is a reworked patch which adds OpenSSL and BoringSSL support to wget. > It avoids the use of OpenSSL's IO abstractions and uses default settings which > should be sensible on any modern OpenSSL (1.1+) or BoringSSL version. I'm a little uncomforta

Re: [Toybox] [PATCH] wget: cleanup, add support for file disposition and fix HTTP protocol version

On 10/28/21 9:57 AM, Eric Molitor wrote: > Ok this annoyed me so I just added direct OpenSSL support parallel to the > LibTLS > support. Elliot, the OpenSSL version should work with the latest versions of > BoringSSL that Android is using. I applied the previous one (the v2 with one library), and

Re: [Toybox] The cut -C test is failing because bionic's wcwidth() doesn't match glibc or musl.

On 10/27/21 7:27 PM, enh wrote: > >     > yeah, you just need the `ln -s`s. > > > >     The ones under: > > > >         if [ ${TARGET_ARCH} = x86 -o ${TARGET_ARCH} = x86_64 ]; then > > > >     Which apparently don't have a corresponding arm version? > > > > yeah,

Re: [Toybox] [PATCH] wget: cleanup, add support for file disposition and fix HTTP protocol version

On 10/27/21 11:58 AM, Eric Molitor wrote: > Final patch which adds TLS support. > > - Eric Hmmm, the lib stuff is awkward. (If you have more than one installed, I think it will try to link to both. Which seems unlikely to work? And I dunno what android calls boringssl. It would be nice if there w

Re: [Toybox] [PATCH] xfork: fix #if.

On 10/27/21 11:14 AM, enh via Toybox wrote: > Fixes 298 where `make allyesconfig` failed with an undefined reference > to xfork(). The CFG_XXX macros are always #defined, to either 0 or 1. So #if is correct. What you just did was disable the test. What's happening here is allyesconfig is enabling

Re: [Toybox] The cut -C test is failing because bionic's wcwidth() doesn't match glibc or musl.

On 10/26/21 7:35 PM, enh via Toybox wrote: > >     Right, you disabled builtins, > > > > yeah, to try to reduce mksh/toybox confusion. if/when we switch /bin/sh > to > > toybox it should reduce compat issues too. I note that toysh has to call both NOFORK and MAYFORK commands as bu

Re: [Toybox] [PATCH] wget: cleanup, add support for file disposition and fix HTTP protocol version

On 10/26/21 9:05 AM, Eric Molitor wrote: > Attached is an initial cleanup of wget. This addresses a number of defects > with > the existing implementation and generally cleans up the code. I've squashed > the > commits but can provide a more incremental set of patches if desired. I have > two >

Re: [Toybox] The cut -C test is failing because bionic's wcwidth() doesn't match glibc or musl.

On 10/25/21 4:53 PM, enh wrote: > On Thu, Oct 21, 2021 at 12:18 AM Rob Landley On 10/20/21 4:35 PM, enh wrote: > > if you don't mind creating a /system directory (or symlink) in /, you > can just > > run like that. there's a script in AOSP bionic that

Re: [Toybox] The cut -C test is failing because bionic's wcwidth() doesn't match glibc or musl.

On 10/20/21 4:35 PM, enh wrote: > On Tue, Oct 19, 2021 at 11:56 PM Rob Landley <mailto:r...@landley.net>> wrote: > On 10/19/21 10:57 AM, enh wrote: > > my guess is that you're using a statically-linked binary? > > Yup. I can't test dynamic bionic

Re: [Toybox] [PATCH] wget: add TLS support

On 10/20/21 3:45 PM, Eric Molitor wrote: > I need to sort out a few more defects but will try both BoringSSL and the FIPS > Version of OpenSSL 3.0. In theory both should "just work" with this > integration. > Albeit with the caveat that FIPS 140-2 verification ended last mouth and I > don't > bel

Re: [Toybox] [PATCH] wget: add TLS support

On 10/20/21 12:50 PM, enh wrote: > general idea. To be honest, making puppy eyes at him to use his work > under 0BSD > and then cleaning it up to be a proper lib/tls.c that toybox and busybox > could > share would be good. Busybox already has ) > > does that seem likely? If I ask ni

Re: [Toybox] [PATCH] wget: add TLS support

On 10/20/21 11:51 AM, enh wrote: > for the ignorant (like me) --- are these libraries like BearSSL an extra > abstraction on top of stuff like openssl/boringssl, or are they roughly > equivalent? Roughly equivalent. Think openssh vs dropbear. > (i'm just thinking ahead to what i'd have to do to

Re: [Toybox] The cut -C test is failing because bionic's wcwidth() doesn't match glibc or musl.

On 10/19/21 10:57 AM, enh wrote: > are you sure? remember that if a test is currently checked in [and Android > uses > the toy; my test runner reports but ignores failures for tests where readlink > says it's not actually toybox], that means that the tests pass on Android. > > there's even a CTS

[Toybox] The cut -C test is failing because bionic's wcwidth() doesn't match glibc or musl.

Bionic's wcwidth() returns -1 (error) for combining characters, where glibc and musl return 0 (does not increase the collective width of the displayed characters). This means crunch_str() can't measure the length of the output, so cut -C behaves like cut -c. I admit the man page is written a bit c

Re: [Toybox] [PATCH] wget: add TLS support

On 10/17/21 2:48 PM, Eric Molitor wrote: > Let me take a look at signify I'll also send the missing part of the patch > with > -ltls shortly. > > Alpine has libtls, either the openssl port in the libretls package or the > original openbsd lbressl-tls. For my embedded stuff I'm statically linking

<    2   3   4   5   6   7   8   9   10   11   >