Changed to using regular diff and removing .git directory to compare gets difference to 123 lines.

root@setzcodell:/tmp/snap# diff -r b R | grep -v "Only in" | grep -v "^---" | wc -l
123
root@setzcodell:/tmp/snap# diff -r b R | grep -v "Only in" | grep -v "^---" 
diff -r b/busybox/include/libbb.h R/busybox/include/libbb.h
731,732c731,732
< 	int (*should_poll_read_fd)(void *this); \
< 	int (*should_poll_write_fd)(void *this); \
> 	int (*have_buffer_to_read_into)(void *this); \
> 	int (*have_data_to_write)(void *this); \
diff -r b/busybox/libbb/ioloop.c R/busybox/libbb/ioloop.c
79c79
< // should_poll_write_fd() - Should ioloop poll write_fd for writability?
> // have_data_to_write() - Do we have data to write?
81c81
< // > 0: Yes, poll write_fd (has data to write, or can generate such data)
> // > 0: Has data to write (or can generate such data)
83c83
< // 0: No, don't poll write_fd currently
> // 0: No data to write currently
87c87
< // should_poll_read_fd() - Should ioloop poll read_fd for readability?
> // have_buffer_to_read_into() - Is there a buffer to read into?
89c89
< // > 0: Yes, poll read_fd (has buffer space, healthy)
> // > 0: Healthy, has buffer space, please poll read_fd
91c91
< // 0: No, don't poll read_fd. One of:
> // 0: One of:
124c124
< // Instead, you can remember EOF/error and make future should_poll_read_fd() 
respond 0.
> // Instead, you can remember EOF/error and make future 
have_buffer_to_read_into() respond 0.
130c130
< // and subsequently should_poll_read_fd() always return 0 (no more attempts to 
read);
> // and subsequently have_buffer_to_read_into() always return 0 (no more 
attempts to read);
134c134
< // After this, should_poll_write_fd() can return 0 if fd has to stay open (socket)
> // After this, have_data_to_write() can return 0 if fd has to stay open (socket)
137c137
< static ALWAYS_INLINE int should_poll_write_fd(connection_t *conn)
> static ALWAYS_INLINE int have_data_to_write(connection_t *conn)
139c139
< 	return conn->should_poll_write_fd(conn);
> 	return conn->have_data_to_write(conn);
141c141
< static ALWAYS_INLINE int should_poll_read_fd(connection_t *conn)
> static ALWAYS_INLINE int have_buffer_to_read_into(connection_t *conn)
143c143
< 	return conn->should_poll_read_fd(conn);
> 	return conn->have_buffer_to_read_into(conn);
180c180
< 		rcw = should_poll_write_fd(conn);
> 		rcw = have_data_to_write(conn);
189c189
< 		rcr = should_poll_read_fd(conn);
> 		rcr = have_buffer_to_read_into(conn);
diff -r b/busybox/networking/telnet.c R/busybox/networking/telnet.c
579c579
< static int should_poll_read_fd_stdin(void *this)
> static int have_buffer_to_read_from_stdin(void *this)
659c659
< static int should_poll_write_fd_net(void *this)
> static int have_data_to_write_to_net(void *this)
703c703
< static int should_poll_read_fd_net(void *this)
> static int have_buffer_to_read_from_net(void *this)
900c900
< static int should_poll_write_fd_stdout(void *this)
> static int have_data_to_write_to_stdout(void *this)
991,992c991,992
< 	G.conn_stdin2net.should_poll_read_fd = should_poll_read_fd_stdin;
< 	G.conn_stdin2net.should_poll_write_fd = should_poll_write_fd_net;
> 	G.conn_stdin2net.have_buffer_to_read_into = 
have_buffer_to_read_from_stdin;
> 	G.conn_stdin2net.have_data_to_write = have_data_to_write_to_net;
999,1000c999,1000
< 	G.conn_net2stdout.should_poll_read_fd = should_poll_read_fd_net;
< 	G.conn_net2stdout.should_poll_write_fd = should_poll_write_fd_stdout;
> 	G.conn_net2stdout.have_buffer_to_read_into = 
have_buffer_to_read_from_net;
> 	G.conn_net2stdout.have_data_to_write = have_data_to_write_to_stdout;
diff -r b/busybox/networking/telnetd.c R/busybox/networking/telnetd.c
282,283c282,283
< // net_to_pty::should_poll_write_fd
< // net_to_pty::should_poll_read_fd
> // net_to_pty::have_data_to_write
> // net_to_pty::have_buffer_to_read_into
311c311
< static int net_to_pty__should_poll_write_fd(void *this)
> static int net_to_pty__have_data_to_write(void *this)
474c474
< 		 * should_poll_write_fd() ensures we are only called this way
> 		 * have_data_to_write() ensures we are only called this way
527c527
< static int net_to_pty__should_poll_read_fd(void *this)
> static int net_to_pty__have_buffer_to_read_into(void *this)
622,625c622,625
< 	this->should_poll_read_fd  = net_to_pty__should_poll_read_fd;
< 	this->should_poll_write_fd = net_to_pty__should_poll_write_fd;
< 	this->read                 = net_to_pty__read;
< 	this->write                = net_to_pty__write;
> 	this->have_buffer_to_read_into = net_to_pty__have_buffer_to_read_into;
> 	this->have_data_to_write       = net_to_pty__have_data_to_write;
> 	this->read                     = net_to_pty__read;
> 	this->write                    = net_to_pty__write;
632c632
< static int pty_to_net__should_poll_read_fd(void *this)
> static int pty_to_net__have_buffer_to_read_into(void *this)
728c728
< static int pty_to_net__should_poll_write_fd(void *this)
> static int pty_to_net__have_data_to_write(void *this)
835,838c835,838
< 	this->should_poll_read_fd  = pty_to_net__should_poll_read_fd;
< 	this->should_poll_write_fd = pty_to_net__should_poll_write_fd;
< 	this->read                 = pty_to_net__read;
< 	this->write                = pty_to_net__write;
> 	this->have_buffer_to_read_into = pty_to_net__have_buffer_to_read_into;
> 	this->have_data_to_write       = pty_to_net__have_data_to_write;
> 	this->read                     = pty_to_net__read;
> 	this->write                    = pty_to_net__write;
1016,1019c1016,1019
< 	this->should_poll_read_fd  = accept_conn__can_accept;
< 	this->should_poll_write_fd = accept_conn__return_zero;
< 	this->read                 = accept_conn__accept;
< 	//this->write                = accept_conn__return_zero; //never called
> 	this->have_buffer_to_read_into = accept_conn__can_accept;
> 	this->have_data_to_write       = accept_conn__return_zero;
> 	this->read                     = accept_conn__accept;
> 	//this->write                    = accept_conn__return_zero; //never called

So that is a minor difference...

Sure there is a reason for these difference. Not sure why the .git 
directory is in the one, but not other? Could be I use https protocol 
for the download from git.busybox.net? or perhaps it didn't get 
copied since it is a hidden directory.

My biggest issue isn't with the git versions, but with the main page 
having a 1 1/2 year old setup of source code as the download? 
Instead of the greatly modified 1.38 git versions from either repo.
Perhaps you can clarify the above difference.

Thanks.


On 20 Apr 2026 at 17:15, Roberto A. Foglietta wrote:

From:           	"Roberto A. Foglietta" 
<[email protected]>
Date sent:      	Mon, 20 Apr 2026 17:15:23 +0200
Subject:        	Re: Downloading 1.37.0 from main page gives the 
27 September 2024 --
	BusyBox 1.37.0 (unstable) unpatched bz2 file??
To:             	[email protected]
Copies to:      	busybox <[email protected]>

> > > On Mon, 20 Apr 2026 at 13:15, Michael D. Setzer II <[email protected]> wrote:
> > > >
> 
> Different sizes of what? Downloading sources? From where and how?
> 
> > So, I'll stick to using the busybox 1.38 git since it is well beyond my
> > understanding. If it ain't broke don't fix it, but if it is broke needs to
> > be fixed.
> 
> AFAIK the git from busybox.net is returned in service as soon as:
> 
> - I told Petr from suse.org that it should not bother me anymore
> - I started a fork of Busybox (which is nothing else than a readme)
> 
> and precisely in sync with the new Debian Project leader maintainer election:
> 
> +:git-shell:unbuffer:busybox> frmt -a
> Fetching --all
> Fetching origin
> Fetching busybox.net
> remote: Enumerating objects: 17, done.
> remote: Counting objects: 100% (17/17), done.
> remote: Compressing objects: 100% (9/9), done.
> remote: Total 9 (delta 8), reused 0 (delta 0), pack-reused 0
> Unpacking objects: 100% (9/9), 1.27 KiB | 433.00 KiB/s, done.
> From git://busybox.net/busybox
>    bee252057..2f3b16fc1  master     -> busybox.net/master
> 
> boom! the git.busybox.net returned online. Do you see the magic? LOL
> 
> People heads are still troublesome? No worry, I can run an extra mile! ;-)
> 
> By the way, in three days the Ubuntu 26.04 LTS is expected to be released.
> 
> Mikes, you worry too much and you got worried for nothing, after all.
> 
> Best regards, R-



+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[email protected]                            
 mailto:[email protected]
 mailto:[email protected]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox