On 11/2/23 16:56, enh via Toybox wrote:
> This frees up 'x' for xmodem transfers later.
Q to quit makes sense, adding xmodem... do you have an xmodem protocol extension
in mind that doesn't pad the last packet up to 128 bytes? What xmodem command
are you going to run at the other end to consume
Blah, forgot to click "send" and let the window get buried...
On 10/28/23 12:18, enh wrote:
> On Sat, Oct 28, 2023 at 12:29 AM Rob Landley wrote:
>>
>> On 10/25/23 19:48, enh via Toybox wrote:
>> > Rather than take up yet another key for the new functio
On 11/1/23 18:45, enh wrote:
> do you want a patch with the arm32 flags too?
Yes please. I applied your patch and then moved stuff to elf.c and tidied it a
little. Could you confirm the riscv flags still print right with the new trick?
I haven't got a test binary here. (I should break down and
On 10/30/23 17:47, enh wrote:
> On Mon, Oct 30, 2023 at 3:29 PM Rob Landley wrote:
>>
>> On 10/29/23 13:05, enh via Toybox wrote:
>> > ---
>> > lib/lib.c| 13 +
>> > lib/lib.h| 1 +
>> > toys/other
On 10/29/23 13:05, enh via Toybox wrote:
> ---
> lib/lib.c| 13 +
> lib/lib.h| 1 +
> toys/other/readelf.c | 3 ++-
> toys/posix/file.c| 5 +++--
> 4 files changed, 19 insertions(+), 3 deletions(-)
I have a bad cold and am too unfocused to trust myself
On 10/25/23 19:48, enh via Toybox wrote:
> Rather than take up yet another key for the new functionality, I've moved
> everything to a menu, similar to the one in telnet. It's not amazing,
> but it's the least code I could get away with, and it's good enough for
> now, and it leaves us in a better
On 10/25/23 18:08, enh via Toybox wrote:
> It can otherwise be quite awkward to get at this --- riscv64 puts it all
> neatly in the ELF auxv, x86-64 has it all in /proc, arm64 only exposes
> L1 instruction/data line sizes.
>
> Annoyingly, none of musl, the BSDs, or Apple implement these sysconf()
On 10/23/23 18:13, Ray Gardner wrote:
> Rob, thanks for the info, I learned some stuff about pipes from it.
>
> I also looked up setvbuf(), and the standard says it may not be used after
> a previous successful call to setvbuf(). That makes my tests below kinda
> moot.
>
> But still, using
On 10/20/23 01:05, Rob Landley wrote:
>> (though i will accept the argument that "that's a toybox xargs test
>> bug", but (a) we'll still need to fix that test
>
> Any idea off the top of your head which of the 31 tests it was? (I can use the
> git commit time
On 10/21/23 20:10, Ray Gardner wrote:
> I am working on a little something, and I found that output from my toybuf
> command redirected to a file is exceedingly slow. But if piped to cat, it
> runs about as fast as expected.
Linux pipe buffers consolidate transactions.
$ cat
On 10/20/23 01:05, Rob Landley wrote:
> P.S. Count's X/s time output is actually X/period and the period is 250ms, but
> it's also zeroing new periods and advancing into the zeroed period immediately
> in the calculation as a full period when we've only been there for less than a
>
On 10/21/23 05:04, Rob Landley wrote:
> This guy went into detail, but I have not opened that particular can of worms
> yet:
>
> http://databasearchitects.blogspot.com/2016/08/equivalence-of-unicode-strings-is.html
Sigh:
https://www.unicode.org/reports/tr10/tr10-49
On 10/20/23 23:22, Oliver Webb via Toybox wrote:
> Heya, I noticed that tr was in pending, taking a look at the source code.
Yeah, it's one of the big remaining todo items to get Linux From Scratch
building, I was looking at it briefly last week...
> It doesn't look very unclean, nor does it
On 10/19/23 13:20, enh wrote:
>> > if you had
>> > ```
>> > if (which->flags & TOYFLAG_LINEBUF) setvbuf(stdout, 0, _IOLBF, 0);
>> > ```
>> > we'd argue a lot less about buffering :-)
>>
>> The existing LINEBUF users are ascii, base64, base32, yes, echo, grep,
>> egrep, fgrep.
>
> yeah, i think
e to get
right. No matter WHAT userspace does here, it's jumping through hoops.
Some variant of a vdso fix seems better. (Is it worth trying to avoid taking a
soft fault the first time you write to that vdso write() ring buffer? I dunno
how expensive that is or if it's easily avoidable? There are also p
On 10/18/23 00:46, Rob Landley wrote:
> On 10/17/23 16:27, Oliver Webb wrote:
>>> Let me know if I screwed stuff up this time, I've been under the weather the
>>> past few days...
>>
>> I get a -Wformat-overflow warning while compiling this command.
>> S
On 10/17/23 16:27, Oliver Webb wrote:
>> Let me know if I screwed stuff up this time, I've been under the weather the
>> past few days...
>
> I get a -Wformat-overflow warning while compiling this command.
> Swapping out sprintf with snprintf gives a -Wformat-truncation warning.
What is the
On 10/16/23 22:29, Oliver Webb wrote:
>> I was hoping to get stuff to share code, but I can worry about that in the
>> eventual cleanup pass.
>
> If you are planning on code-sharing the regex line substitution stuff.
> Then this will probably be my last patch to vi.c for a while
> (Unless there
On 10/16/23 19:28, Oliver Webb wrote:
>> That said, a -l long output version that has the raw number, and the human
>> readable, and time, and recent/total rate, might be useful? (I'd prefer -l
>> instead of -v, but same general concept.)
>
> I added a -l[ong] option in the below patch, It only
On 10/15/23 23:23, Oliver Webb via Toybox wrote:
> Hey, I was looking through the command list and discovered a "count" command.
I wrote my first one of those in 1998 and couldn't figure out why it wasn't part
of the standard unix command set. I posted it all over the place (linux-kernel,
etc)
On 10/14/23 17:15, Oliver Webb via Toybox wrote:
> I have added the 'v' command (Which is essentially the opposite of the
> g[lobal] command).
> Fixed a memory leak in the g[lobal] command (Freeing data while aborting)
> Along with some code formatting (Replacing *(cmd+1) with cmd[1])
I removed
On 10/11/23 15:57, scsijon wrote:
> I knew it from ibm mainframes and FEP's for aix, try this url for a
> simple explanation, it's pretty basic what it does.
>
> https://www.ibm.com/docs/da/aix/7.3?topic=t-tsort-command
I know what it does _now_. I wrote one from scratch that works.
The topic
On 10/11/23 11:07, enh wrote:
>> It's not HARD, I just consider the compiler's behavior to be obviously wrong
>> here. My code never performs an illegal dereference. I don't see why the
>> compiler should care what pointer values I'm passing around when they're not
>> being dereferenced: in C,
On 10/6/23 05:05, Rob Landley wrote:
> Apparently the widest unicode characters are:
>
> 1. ﷽
>
> 2.
>
> 3. ∙
>
> 4. ⸻
>
> 5. ꧅
>
> The first 4 of which xfce's terminal does NOT like. And thunderbird fits the
> first one in 3 columns while vim's
On 10/10/23 12:52, enh wrote:
>> In theory ASAN should be able to spot that one! In practice, if it's a local
>> variable on the stack, not so much.
>
> you can add `-ftrivial-auto-var-init=pattern` to your CFLAGS.
$ CFLAGS="-ftrivial-auto-var-init=pattern" ASAN=1 make clean defconfig tests
...
tps://austingroupbugs.net/view.php?id=1745 in September 5th because I'd
recently mentioned tsort, and our resulting email thread was:
On Tue, Sep 5, 2023 at 4:30 PM Rob Landley wrote:
> >
> > On 9/5/23 14:36, enh wrote:
>> > > since you were talking about tsort recently..
On 10/9/23 19:53, Oliver Webb wrote:
>> I tested this. If I build toybox sed without ASAN the 1 megabyte search and
>> replace completes in 0.15 seconds. If I build it with ASAN, it takes 29.35
>> seconds. The gcc address sanitizer is slowing sed down 200 times.
>
> Huh, now sed passes it's tests
It's time to explain "toybox help text indentation policy". Like the coding
style section of code.html, only end-user visible! Yeah yeah, "watching paint
dry" levels of thrilling, but I do try to get this right. Consistency helps
comprehension, and we don't give people a LOT of documentation so
On 10/9/23 22:43, Oliver Webb via Toybox wrote:
> Heya, I added the 'g' ex command to vi
Cool. Good work, thanks.
I applied all but the help text change, where the -s previously had a tab after
it:
01f0 64 20 70 72 65 73 73 20 45 4e 54 45 52 2e 0a 0a |d press ENTER...|
0200 20 20
On 10/9/23 17:04, enh wrote:
> On Mon, Oct 9, 2023 at 2:45 PM Rob Landley wrote:
>>
>> On 10/9/23 10:26, enh wrote:
>> >> Let me know how commit 5f153b56214f works? I don't have a test environment
>> >> for this, but it seems to produce the error
I installed a mint vm (xfce flavor) and reproduced your issues. Sent in fixes
for some of them, although your gcc still produces warnings about "unused return
result" even when I typecast the return to (void). (Still, the commit comment
says _why_ each of those return results are not useful to try
On 10/9/23 10:26, enh wrote:
>> Let me know how commit 5f153b56214f works? I don't have a test environment
>> for this, but it seems to produce the errors right on 32 and 64 bit at
>> least...
>
> it's a bit early in the morning for me, but doesn't the change from
> `unsigned long long` to
On 10/8/23 11:12, Colin Cross wrote:
> On Sat, Oct 7, 2023 at 11:47 PM Rob Landley wrote:
>>
>> On 10/7/23 21:47, Colin Cross wrote:
>> > On Fri, Oct 6, 2023 at 9:29 PM Rob Landley wrote:
>> >>
>> >> On 10/6/23 17:10, Colin Cross via Toybox wr
On 10/7/23 21:47, Colin Cross wrote:
> On Fri, Oct 6, 2023 at 9:29 PM Rob Landley wrote:
>>
>> On 10/6/23 17:10, Colin Cross via Toybox wrote:
>> > I came across an issue when running the pgrep -s 0 test in Android's
>> > CI infrastructure that uses a PID n
On 10/6/23 14:59, enh wrote:
> On Fri, Oct 6, 2023 at 12:35 PM Michael Shavit via Toybox
> wrote:
>>
>> On Fri, Oct 6, 2023 at 4:41 AM Rob Landley wrote:
>> >
>> > I could adjust _just_ addr to use unsigned long instead of unsigned long
>> > l
On 10/7/23 00:35, Oliver Webb wrote:
>> Is it the "touch" that fails, or tar? Because the test is doing:
>
> Putting a ' || echo "whatever" ' after the touch command that creates the
> long filenames shows nothing,
> these are the logs from the test failure:
>
> ln: failed to create symbolic
On 10/6/23 17:10, Colin Cross via Toybox wrote:
> I came across an issue when running the pgrep -s 0 test in Android's
> CI infrastructure that uses a PID namespace, causing the test to run
> session ID 0:
>
> $ sudo unshare -fp ./toybox pgrep -s 0
> pgrep: bad -s '0'
>
> The attached patch
On 10/6/23 16:33, Oliver Webb wrote:
>> Hadn't seen that one, I'm aware of a sparse file issue on some filesystems.
>> (That hit on microsoft github.)
>
> My home directory is ecryptfs,
Yup, that would explain it.
> Testing on my /tmp directory (etx4) makes the errors
> go away for both du and
On 10/6/23 03:49, Jarno Mäkipää wrote:
>> > My problem isn't figuring out what the code is doing, my problem is
>> > figuring out
>> > what the proper behavior of "vi" is to the various inputs. Alas, "man vim"
>> > only
>> > describes command line options and then references "vimtutor" (which
On 10/5/23 15:03, enh wrote:
>> Ah. command0 is the number before the command, command1 is the number after
>> the
>> command. If you ":5d" it deletes the 5th line. If you ":d5" it deletes 5
>> lines
>> starting from the current one. Presumably if you ":5d5"... yup, it deletes 5
>> lines
On 8/31/23 02:00, Michael Shavit via Toybox wrote:
> Replace the left-shift method of computing the maximum allowed write as
> it may exibit undefined behavior.
> Add and use an unsigned version of atolx to support writing any 64bit
> value.
>
> * When bytes equals 8, devmem will left-shift an
On 10/5/23 22:50, Oliver Webb via Toybox wrote:> I ran "VERBOSE=allnopass make
tests" to see exactly what was still broken.
Note that all of them pass for me.
> (du has some symlink issues,
On what filesystem?
> tar has a long filename issue,
Hadn't seen that one, I'm aware of a sparse file
On 10/4/23 21:51, Oliver Webb wrote:
> --- Original Message ---
> On Wednesday, October 4th, 2023 at 18:59, Rob Landley
> wrote:
>> On 10/4/23 13:51, enh via Toybox wrote:
>>
>> > (since it looks like there are folks actively working on vi atm...)
On 10/4/23 19:03, Rob Landley wrote:
> And I'm backing slowly away from this Thing That Needs Focus To Clean Up.
> Gotta
> close the open cans of worms first, thanks...
The if/else staircase on TT.vi_mode in vi_main() seems like an obvious potential
place to call ex/normal/insert
On 10/4/23 13:51, enh via Toybox wrote:
> (since it looks like there are folks actively working on vi atm...)
>
> looks like 'b' goes to the _end_ of the _previous_ word, rather than
> the beginning of the current word?
There's no 'b' but there is a "b" (which is weird because all the
On 10/3/23 23:43, Colin Cross wrote:
> I caught it running in strace. There's some differences in signal
> setup in the forked child, the child exits with 126 in both the good
> and bad cases, but the parent exits with 127 after wait4 returns
> ECHILD in the bad case.
Beat me to it. (Serves me
On 10/3/23 20:18, enh wrote:
>> heh, no "cheetah" is the lunch target. pixel pro 7 was the marketing
>> name. "recent arm64 device running a hwasan build" was what i was
>> trying to say.
Bionic arm64 current android system with hwsan, reproduces in 2% of runs.
>> it's been running just that
On 10/3/23 16:07, enh wrote:
>> I don't THINK that's a likely fallback path here? Although /bin/sh not found
>> might explain it. But that would be deterministically reproducible and you're
>> having an intermittent issue, right?
>
> correct. ccross tells me it's ~2% of all runs in CI.
Ok,
On 10/3/23 13:38, enh wrote:
>> Trying that by hand on devuan (using coreutils' timeout):
>>
>> $ timeout .1 /
>> timeout: failed to run command ‘/’: Permission denied
>> $ echo $?
>> 126
>>
>> From the bash man page:
>>
>> If a command is not found, the child process created to execute
On 10/2/23 10:16, enh via Toybox wrote:
> yeah, this broke the github CI too ---
> https://github.com/landley/toybox/actions/runs/6369602289/job/17289987237
Oops.
Try now,
Rob
___
Toybox mailing list
Toybox@lists.landley.net
On 10/1/23 13:33, Jarno Mäkipää wrote:
>> A lot of ex commands don't necessarily do movement, 's' for example for
>> example shouldn't
>> effect cursor position. If a "counter" (Line range) is given, it loops
>> through the line range
>> and executes the command for each line before going down
On 9/20/23 01:41, Oliver Webb via Toybox wrote:
> I have made a implementation of the 'dc' command in toybox
I thought about adding this to pending anyway (which is not a promise to
eventually merge it), but it didn't build with gcc 8.3:
toys/pending/dc.c:193:4: error: a label can only be part
On 9/20/23 22:37, Oliver Webb wrote:
> --- Original Message ---
> On Wednesday, September 20th, 2023 at 3:07 PM, Rob Landley
> wrote:
>
>
>> On 9/20/23 01:41, Oliver Webb via Toybox wrote:
>>
>> > I have made a implementation of the 'dc' comman
On 9/19/23 23:04, scsijon wrote:
> https://github.com/magicant/yash
Is therere a project called "yet another yet another" yet?
> Came across his while perusing various linux's bookmarks (trying to
> re-find a package i'd lost it's name, just knew i'd know it when I saw
> it). Just wondering
On 9/20/23 01:41, Oliver Webb via Toybox wrote:
> I have made a implementation of the 'dc' command in toybox
>
> Since dc isn't specified in POSIX or LSB,
Which is why it's not in toybox?
There are things listed in yocto's root filesystem in the roadmap which I don't
intend to add to toybox.
On 9/19/23 14:44, enh wrote:
>> And I just noticed because somebody mentioned Android involvement. (I still
>> try
>> to check that mailing list twice/month for anything of obvious interest.)
>>
>> http://lists.busybox.net/pipermail/busybox/2023-September/090471.html
>
> (i think they were just
Wow I have a lot of old reply windows buried under other windows...
On 8/7/23 11:06, enh wrote:
>> P.S. I didn't respond to Elliott's last email about testing because I didn't
>> know what to say. "I want absolutely everything because I have a dedicated
>> staff
>> to weed out false positives"
On 9/18/23 18:08, Michael Shavit wrote:
> On Thu, Aug 31, 2023 at 3:57 AM Rob Landley wrote:
>> +unsigned long long atollu(char *str)
>> +{
>> + char *end = str;
>> + unsigned long long llu = strtoul(str, , 0);
>
> Sorry I didn't notice this earlier, b
Looks like the kernel devs rewrote stuff in 2022 to make it more dependent on
systemd, and now writing to /dev/random not only doesn't credit entropy (so it
still blocks) but has an arbitrary delay about even mixing the data in.
https://lwn.net/Articles/889452/
Apparently busybox copied code
On 9/12/23 23:43, Oliver Webb wrote:
> --- Original Message ---
> On Tuesday, September 12th, 2023 at 2:36 PM, Rob Landley
> wrote:
>
>
>> On 9/11/23 23:56, Oliver Webb via Toybox wrote:
>>
>> > I have made a implementation of the 'csplit' comm
On 9/12/23 20:25, Oliver Webb via Toybox wrote:
> This patch fixes a memory leak in ts by making sure it frees the pointers
> given by xgetline()
Blah, conventional getline() does a realloc() recycling the same buffer,
xgetline returns a string to be freed. I knew that. :P
Local variable
On 9/12/23 14:55, enh wrote:
> On Tue, Sep 12, 2023 at 12:36 PM Rob Landley wrote:
>> I dunno why csplit would want MAYFORK here. A normal command can just xexit()
>> and let the kernel close filehandles and free memory when the process exits.
>> I
>> note that 95% o
On 9/11/23 23:56, Oliver Webb via Toybox wrote:
> I have made a implementation of the 'csplit' command in about 160 lines of
> code.
You have TOYFLAG_MAYFORK on this command. Sigh, explaining the lib/toyflags.h
values is one of the tutorial videos I need to make.
Forking is the default behavior
On 9/9/23 21:17, Rob Landley wrote:
>
>
> On 9/9/23 11:39, Oliver Webb wrote:
>> --- Original Message ---
>> On Friday, September 8th, 2023 at 2:38 AM, Rob Landley
>> wrote:
>>
>>
>>> On 9/7/23 23:51, Oliver Webb via Toybox wrote:
&
On 9/9/23 11:39, Oliver Webb wrote:
> --- Original Message ---
> On Friday, September 8th, 2023 at 2:38 AM, Rob Landley
> wrote:
>
>
>> On 9/7/23 23:51, Oliver Webb via Toybox wrote:
>>
>> > I wrote a implementation of the command 'ts' for toybox
On 9/8/23 16:48, scsijon wrote:
> RFC3161
Random network protocol, that page doesn't contain the word "command". The word
"timestamp" occurs in other contexts:
$ apropos timestamp
futimens (3) - change file timestamps with nanosecond precision
futimes (3) - change file
On 9/7/23 23:51, Oliver Webb via Toybox wrote:
> I wrote a implementation of the command 'ts' for toybox
Where is this command from? It's not in posix or lsb, nor is it in
https://man7.org/linux/man-pages/dir_section_1.html and it's not installed on my
debian system either... You reference
On 9/4/23 23:49, Rob Landley wrote:
> On 9/4/23 19:10, Oliver Webb via Toybox wrote:
>> This is my first time submitting a patch to a mailing list, So please
>> forgive me if there's any etiquette or formatting I've missed.
>>
>> This is a fix I found for a bug I subm
On 9/4/23 19:10, Oliver Webb via Toybox wrote:
> This is my first time submitting a patch to a mailing list, So please
> forgive me if there's any etiquette or formatting I've missed.
>
> This is a fix I found for a bug I submitted a issue to the github repo
> (issue #453) for a few days ago
On 8/31/23 13:38, Michael Shavit wrote:
> On Thu, Aug 31, 2023 at 8:26 PM Michael Shavit wrote:
>>
>> On Thu, Aug 31, 2023 at 6:57 PM Rob Landley wrote:
>> >
>> >// DATA? Report out of range values as errors rather than truncating.
>> > - if (writ
On 8/31/23 07:26, Michael Shavit wrote:
> On Thu, Aug 31, 2023 at 6:57 PM Rob Landley wrote:
>> Could you send me the test case you hit that motivated this change? (I
>> haven't
>> got a tests/devmem.test yet and am not 100% sure how I'd even set that up in
>> mkro
On 8/31/23 02:00, Michael Shavit wrote:
> Replace the left-shift method of computing the maximum allowed write as
> it may exibit undefined behavior.
> Add and use an unsigned version of atolx to support writing any 64bit
> value.
>
> * When bytes equals 8, devmem will left-shift an unsigned long
On 4/16/23 18:54, Rob Landley wrote:
> On 3/24/23 12:11, Rob Landley wrote:
>> Here's a script that automates the first part of the Linux From Scratch 11.3
>> build (chapters 5 and 6, setting up the chroot) from
>> https://linuxfromscratch.org/lfs/downloads/11.3/LFS-BO
On 8/23/23 11:35, enh via Toybox wrote:
> %t is the appropriate choice for pointer differences on both ILP32 and
> LP64, and shorter than casting to long:
> ```
> external/toybox/toys/pending/expr.c:209:45: error: format specifies
> type 'long' but the argument has type 'int' [-Werror,-Wformat]
On 8/18/23 13:54, enh wrote:
> On Fri, Aug 18, 2023 at 11:45 AM Rob Landley wrote:
>>
>> On 8/16/23 15:26, enh wrote:
>> >> I long ago came to the conclusion I can't make a system secure, all I can
>> >> do is
>> >> annoy attackers i
On 8/16/23 15:26, enh wrote:
>> I long ago came to the conclusion I can't make a system secure, all I can do
>> is
>> annoy attackers into choosing a less vexing target. But I don't want to the
>> the
>> same to users or developers, so it's always a balancing act.
>
> meh, if your selinux
On 8/16/23 14:42, enh wrote:
> On Wed, Aug 16, 2023 at 12:33 PM Rob Landley wrote:
>>
>> On 8/16/23 09:14, enh wrote:
>> > strace other cp implementations?
>>
>> I was hoping someone somewhere would actually have/know rules. :P
>>
>> Alas strac
On 8/16/23 09:14, enh wrote:
> strace other cp implementations?
I was hoping someone somewhere would actually have/know rules. :P
Alas strace doesn't show you that it checked 3 stat fields and then did this
thing, otherwise it would have done that other thing. You just get the one
codepath it
So way back in https://github.com/landley/toybox/issues/112 I got a bug report,
which goes with this comment in cp.c:
// We only copy xattrs for files because there's no flistxattrat()
Which is a symptom, not the problem. The fundamental problem is that creating a
file gives me a filehandle so
I'm still subscribed to the coreutils mailing list because:
https://lists.gnu.org/archive/html/coreutils/2023-08/msg9.html
And recently there was:
https://lists.gnu.org/archive/html/coreutils/2023-08/msg00035.html
So I did
I am not posting a reply this long to github, it's going to the list. :)
On 8/15/23 15:57, David Legault wrote:
> I guess you are right. On QNX we default to 512 because that's what the system
> does so I guess I'll have to wedge in some code to set the value to blocksize
> value to 1024 if you
So the failing MacOS test was:
FAIL: tail -F
echo -ne '' | tail -s .1 -F walrus 2>/dev/null & sleep .2; echo hello > walrus;
sleep .2; truncate -s 0 walrus; sleep .2; echo potato >> walrus; sleep .2;
echo hello >> walrus; sleep .2; rm walrus; sleep .2; echo done > walrus;
sleep .5; kill %1
---
On 8/2/23 11:04, enh via Toybox wrote:
> i've not seen this myself, but i have _one_ report from CI of this failure:
>
> FAIL: timeout can't execute
> echo -ne '' | "/system/bin/timeout" .1 / 2>/dev/null ; echo $?
> --- expected 2023-06-21 04:02:52.42400 +
> +++ actual 2023-06-21
On 8/1/23 18:11, Lokesh Chandra Kumar wrote:
> Hello all,
>
> I am currently using toybox (version 0.8.6) to copy files in an embedded
> device,
> but the cp seems to be not preserving SMACK attributes for intermediate
> directories while doing the copy.
Alas SMACK support hasn't been properly
On 8/1/23 20:01, enh wrote:
> On Tue, Aug 1, 2023 at 5:56 PM enh wrote:
>> yes, with the obvious line added to run-tests-on-android.sh, all the
>> tests pass on my hwasan build (and the sed test only takes a couple of
>> seconds). (for reference, my linux/x86-64 hardware that timed out was
>> a
On 8/1/23 19:56, enh wrote:
> On Mon, Jul 31, 2023 at 6:52 PM Rob Landley wrote:
>>
>> On 7/31/23 09:31, enh wrote:
>> > seems like this release is in a pretty bad state?
>>
>> The tests passed locally! All of 'em! With glibc and musl! Sigh...
>>
>
I really hate having long discussions in github per-line comments to merged
commits, because nobody will ever be able to _find_ them again six months from
now if that history needs to be referenced.
Continuing from:
https://github.com/landley/toybox/commit/cbc3e2c9889e#r123308704
On 8/1/23
asan
> -- on macOS.
Didn't see it on debian's gcc+glibc ASAN, but mostly likely that has fewer
checks.
> not sure whether that's a bsd/glibc difference or a linux-only asan
> bug. the latter seems less likely, but i'll mention it to the asan folks
> anyway...)
I remind you of:
co
I was _trying_ not to call in that (sorts terribly in the directory listing) but
I have goals for 0.9.0 I didn't achieve yet (test suite running under mkroot,
and maybe a basic LFS build too albeit starting out with a pile of supplementary
binaries). And after stretching the dev cycle out to TWICE
They changed the filesystem to something that doesn't track sparse files at 4k
page granularity, so the tar tests are failing. I need to change the "breaks on
macos" test to a "breaks on filesystems that don't track sparse files" test.
Also, various things are producing "EOF detected" error
On 6/30/23 19:57, Rob Landley wrote:
>> On 6/12/23 19:40, Chet Ramey wrote:
>>> I wish you were not so reluctant. Look at how many things you've discovered
>>> that I decided were bugs based on our discussions.
>>
>> But since you asked, today's new question I
On 7/20/23 09:07, enh wrote:
> at this point, i'm pretty sure that change silently broke it --- i've never
> seen
> a gap without runs over this many changes, or this amount of time.
>
> revert
> https://github.com/landley/toybox/commit/c45e800803364c6e1f343e431f98e19a1bc1148f
> ?
Done.
I
On 7/14/23 12:08, enh via Toybox wrote:
> heh, i hadn't noticed that toybox-built kernels mention the fact before...
>
> ~/aosp-master-with-phones/bionic$ adb shell uname -a
> Linux localhost 6.3.0-mainline-g0526833d4674-ab10303652 #1 SMP PREEMPT Mon Jun
> 12 08:24:48 UTC 2023 riscv64 Toybox
Did
On 7/11/23 17:15, enh wrote:
> especially since we suspiciously haven't had any CI run at all since that
> change
> went in: https://github.com/landley/toybox/commits/master
> (i'd expected as least an error, but not even a "ran and failed"!)
I hit that problem back when we added the mac tests
On 7/10/23 16:57, enh wrote:
> and i think that's the cross-purpose we're talking at here ... the 99% case is
> app code...
> the kind of collaborative command-line debugging over a mailing list that
> you're
> familiar with doesn't exist for the TikToks of this world.
There's no amount of
On 7/11/23 01:21, Rob Landley wrote:
> On 7/10/23 18:58, enh via Toybox wrote:
>> Untested (because I don't know how to test such changes without merging
>> them), but seems plausible based on the documentation at
>> https://docs.github.com/en/actions/learn-github-ac
On 6/18/23 16:28, Rob Landley wrote:
> On 6/12/23 19:40, Chet Ramey wrote:
>> I wish you were not so reluctant. Look at how many things you've discovered
>> that I decided were bugs based on our discussions.
>
> But since you asked, today's new question I wrestled with was
On 7/6/23 20:09, Chet Ramey wrote:
> On 7/5/23 3:29 AM, Rob Landley wrote:
>>>>> It's really a useless concept, by the way.
>>>>
>>>> It's not that simple: kill has to be built-in or it can't interface with
>>>> job
>>>&
On 7/6/23 18:23, enh via Toybox wrote:
> Tested on a Raspberry Pi 400 with a BME680 connected to the relevant
> pins, and commands like `i2ctransfer 1 w3@0x77 0x60 0xb6 0xd0 r1`, which
> writes 0xb6 to register 0x60 of chip 0x77 on bus 1, and then reads one
> byte.
I broke down and did a cleanup
I have a window open with a half-finished reply in it, and if I've already
replied to this email I apologize...
On 6/19/23 18:32, Chet Ramey wrote:
> On 6/17/23 7:23 PM, Rob Landley wrote:
>> On 6/12/23 19:40, Chet Ramey wrote:
>>>> and they have a list of "special bui
201 - 300 of 2868 matches
Mail list logo
